[KULRICE-2239] Rewrite RuleBaseValuesLookupableImpl to use KNS framework Created: 02/Sep/08  Updated: 17/Aug/09  Resolved: 17/Feb/09

Status: Closed
Project: Kuali Rice Development
Component/s: Development
Affects Version/s: None
Fix Version/s: 1.0

Type: Task Priority: Blocker
Reporter: Eric Westfall Assignee: Jeremy Hanson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
is related to KULRICE-2238 Convert KEW Rule and Delegate rule do... Closed
is relied upon by KULRICE-2651 Implement a "Routing Rule Delegation"... Closed
is relied upon by KULRICE-1457 Convert Workflow to use KNS Closed
Rice Module:


org.kuali.rice.kew.lookupable.RuleBaseValuesLookupableImpl needs to be rewritten to use the KNS lookup framework

See KULRICE-1457 for more details

Comment by Eric Westfall [ 23/Jan/09 ]

Jeremy, I've actually started on this particular task, you can see it by going to "Routing Rules" in the KEW "portal" in the sample app. It's just got 3 fields at the moment.

To get yourself familiar with how the original screen worked, take a look at Kuali Test Drive. There should be a link there to "Rule Quick Links". Click on "Search" on one of those and you will see the original Rule lookup. Notice how the fields that are displayed for search change based on the RuleTemplate that is selected. The RuleTemplate defines a series of RuleAttributes. Each of those rule attributes points to a class which implements WorkflowAttribute. WorkflowAttribute has a getRuleRows method on it which returns a list of Rows. The Rows that used to be returned were the old KEW Row object. If you recall, we changed that so that it returns the KNS Row object now.

This is helpful because there is a way on a lookup to customize the lookup. We will need to implement a LookupableHelperService for the RuleBaseValues lookup. You can see in the KEWSpringBeans.xml how this has been done already for EDocLite, Document Type, etc.

That class has a hook point where we can customize the getRows() method. So we will need to be able to respond to the case where the RuleTemplate on the lookup is changed and then customize what is returned from getRows() so that it displays the additional Rows. Note that the KualiLookupableHelper.checkForAdditionalFields gets called after we return back to the Rule lookup from an external lookup (such as RuleTemplate). So that might likely be the hook you would need to update in order to update any internal state in the lookup itself.

See KualiLookupAction.refresh and other methods if you want to get a better idea for how the lookup framework operates.

A couple of other notes:

1) You will want to look at the original KEW-lookup based implementation of the Rule lookup to make sure you are including everything. It's still in the project and is called RuleBaseValuesLookupableImpl
2) One thing you will notice is that, in addition to WorkflowAttribute.getRuleRows() it also supports OddSearchAttribute.getSearchRows() so we will need to be sure to include support for that as well in our customized lookup
3) It's likely that the default mechanism for executing the search in the lookup is not going to work in this case. So instead we may need to execute the search using RuleService.search as the original lookup did. We did something similar to this for the DocumentType lookup so you can see that code in DocumentTypeLookupableHelperServiceImpl

I'm sure there are other potential issues here as I haven't had a chance to do a full analysis on this. Please take a look yourself before you get started on coding and see if there are any potential issues you can envision. I know you are new to this framework so keep me posted on progress and let me know if you have questions.


Comment by Jeremy Hanson [ 28/Jan/09 ]

I have the screen returning the extra fields after the lookup for Rule Template, but is there a button that should be added the the screen to update for the extra field(s) if the Template Name or Id is entered manually?

Also, I'm guessing we want to add the other default fields that show up in the Test Drive?

Do we want the extra fields to show up in the results?

Comment by Eric Westfall [ 28/Jan/09 ]

Hmm, I thought there was a way to make a field read only in the KNS but it looks like that's only for documents and not lookups. I'm not sure if there would even be a way to render a button there using the lookup framework, so for now let's not worry about it. If they want the extra fields they will need to do a lookup on the Rule Template. Typical entry into this screen will likely be from the Rule Quick Links anyway which will pass the rule template to the lookup.

So we will want to make sure as part of this that the Rule Quick Links are generating proper URLs for the "Search" links and that by passing the rule template it properly displays any custom fields.

Comment by Eric Westfall [ 28/Jan/09 ]

As far as the other fields in the test drive, yes, let's include those except change "Workgroup Reviewer" to "Group Reviewer"

Comment by Eric Westfall [ 28/Jan/09 ]

Regarding fields in the result set, yes we do want to include those since the original Rule lookup did. However I'm not sure if this is possible with the lookup framework. You might want to talk to Chris since he is doing something similar to this for Document Search so you could either leverage his work or, if it's already possible, he could help you figure out how to do it.

Comment by Jeremy Hanson [ 02/Feb/09 ]

Committed a portion of the resolution. The lookup is working, but the links on the quick links page don't work yet, and the extra fields don't show up in the results yet.

Comment by Jeremy Hanson [ 05/Feb/09 ]

I've commited more changes. The RuleBaseValues lookup's results now contain the columns with the extra fields. It also fixes the links on the RuleQuickLinks page to the correct lookup.

Currently, the return location on the lookup from RuleQuickLinks just goes back to the main index page. I'm not sure where we want this to go to since the lookup is brought up in a separate page, but it seems to need to be set or errors occur.

Comment by Eric Westfall [ 13/Feb/09 ]

That's fine as far as return location goes, and yes it does have to be set or the lookup framework throws errors.

Comment by Eric Westfall [ 17/Aug/09 ]

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

Generated at Wed Sep 30 14:14:52 CDT 2020 using JIRA 7.0.11#70121-sha1:19d24976997c1d95f06f3e327e087be0b71f28d4.