Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-2628

not sure whether without something like KimAttributeDefinition to wrap the attr defns returns from custom searchable attributes and such the urls will be right

    Details

    • Type: Task
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0, KFS Release 3.0
    • Component/s: Analysis
    • Labels:
      None
    • Rice Module:
      KEW
    • Application Requirement:
      KFS

      Description

      see linked issue (and those linked to that)

        Attachments

          Issue Links

            Activity

            Hide
            ewestfal Eric Westfall added a comment -

            Spent quite a bit of time looking at this. Can't do something similar to the KIM stuff because that is based off of custom attribute definitions. All we get in the case of search attributes is a List of Row objects. This isn't too bad except we have no way to figure out the proper lookup url from the Field object.

            One option is to make some sort of remote call to the target system (i.e. KFS in this case) but it's not possible to easily figure out which source system to target given just the Row/Field objects and the infrastructure services for such a thing aren't in place.

            The solution I settled on was to add an optional baseLookupUrl to the Field object. If present, the KualiAction.performLookup will use that to construct the lookup url.

            The final issue here is that KualiAction.performLookup is dependent upon the business object java.lang.Class being loaded. Obviously this won't work if the class is not in the classloader of the application (i.e. a KFS business object class being used on document search). It's used in two places:

            1) To do some kind of check to see if the value should be encrypted
            2) To find the responsible module service for the business object

            I'm not sure how to deal with the encrypted value issue, so there may be something left to deal with there. But for now, if the bo class cannot be loaded, it will check if the baseLookupUrl exists and if so it will use that to render the final lookup url (it will contact neither the module service or do the encryption thing).

            The baseLookupUrl is set in the LookupUtils.setFieldQuickfinder method.

            Test this with various KFS document searches with a standalone rice server and it appears to work.

            Show
            ewestfal Eric Westfall added a comment - Spent quite a bit of time looking at this. Can't do something similar to the KIM stuff because that is based off of custom attribute definitions. All we get in the case of search attributes is a List of Row objects. This isn't too bad except we have no way to figure out the proper lookup url from the Field object. One option is to make some sort of remote call to the target system (i.e. KFS in this case) but it's not possible to easily figure out which source system to target given just the Row/Field objects and the infrastructure services for such a thing aren't in place. The solution I settled on was to add an optional baseLookupUrl to the Field object. If present, the KualiAction.performLookup will use that to construct the lookup url. The final issue here is that KualiAction.performLookup is dependent upon the business object java.lang.Class being loaded. Obviously this won't work if the class is not in the classloader of the application (i.e. a KFS business object class being used on document search). It's used in two places: 1) To do some kind of check to see if the value should be encrypted 2) To find the responsible module service for the business object I'm not sure how to deal with the encrypted value issue, so there may be something left to deal with there. But for now, if the bo class cannot be loaded, it will check if the baseLookupUrl exists and if so it will use that to render the final lookup url (it will contact neither the module service or do the encryption thing). The baseLookupUrl is set in the LookupUtils.setFieldQuickfinder method. Test this with various KFS document searches with a standalone rice server and it appears to work.
            Hide
            ewestfal Eric Westfall added a comment -

            Code changes committed.

            Show
            ewestfal Eric Westfall added a comment - Code changes committed.
            Hide
            ewestfal Eric Westfall added a comment -

            Bulk change of all Rice 1.0 issues to closed after public release.

            Show
            ewestfal Eric Westfall added a comment - Bulk change of all Rice 1.0 issues to closed after public release.

              People

              • Assignee:
                ewestfal Eric Westfall
                Reporter:
                abyrne Ailish Byrne
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 2 days
                  2d
                  Remaining:
                  Remaining Estimate - 2 days
                  2d
                  Logged:
                  Time Spent - Not Specified
                  Not Specified