Indicate the necessity for this enhancement. What does it accomplish?
Give users the ability to do a single, compound lookup when searching for data instead of multiple individual ones. With this, users can do quicker and more precise research prior to taking action.
Give a detailed description for the enhancement. Clearly describe all concerns, eliminating ambiguities.
A new, advanced lookup option needs to be added as default delivered functionality with KRAD. This would use the data dictionary options currently available but with the added ability for users to specify multiple lines of lookup criteria. By default criteria pieces are evaluated as AND on rows and OR on columns. However, for numerical and date type fields, users should have to function to set ranges to be used for evaluation of these data pieces. All other default functionality such as data dictionary validation, export and sort options on results sets, etc. should be available with this functionality. This functionality shall be available to all applications by default.
Include at least one usage scenario, from the user's task perspective, that might be helpful in understanding the issue:
Coeus allows users to build fairly complex queries in real-time via a matrix type interface (screenshots available below). This allows users more flexibility to look at a large number of records while being able to specify more precisely what records are brought back.
Mocks and Diagrams
Include any mocks (for UI enhancements) or diagrams that might be helpful in understanding the issue:
Current, Coeus screen examples
If applicable, list expectations for performance (optimal and worst cases would be fine, give time in seconds):
While the performance should be similar to that of our current lookups, the addition of multiple rows in a search will likely slow things down since the logic will then be a search of joined searches.
Include links to other confluence pages or external resources that might be helpful for this issue:
List all requirements (individual verifiable statements) that indicate whether the work for this item has been complete. If there are requirements that are not essential to the functionality but would be nice to have if time allows, enter those under 'Non-Essential':
- Add a new tab to the basic lookup screen for advanced lookups
- Applications should have a way to define if this is the default selection when selecting a lookup
- The columns in the lookup are defined by a search criteria setting in the data dictionary
- One piece of criteria is required per row
- Wildcard should be allowable
- Criteria across a row are ANDs
- Criteria down columns are ORs by default
- Numeric and date fields need to allow for the use of common operators as well as the ellipse operator for defining ranges ( "1..10", "01/01/2012..12/31/2012").
- No validation should be added to ensure that columns or rows invalidate each other
- Applicable widgets (data picker) and KRAD features (direct inquiry) should be presented along with data
- Results sets retain default KRAD/KNS options of actions based on permissions (edit, copy, data inquiry, row inquiry, etc.)
- Results set columns should retain the option to sort
- Allow wildcard searches on number fields
- Results set should be exportable
- If the UI is constructed such that a row is added (via and add or + button), the ability to copy that to a new row would be nice. Copy the row, change the bits of data you need, and then add it. This would potential speed up the process and improve the user's experience.
- Naming, saving, and sharing these lookup's would be nice. Sharing or pushing out saved searches is something that has been requested across all lookups as well.
List any functional or technical work that must be completed before work on this item can begin:
- For the wildcard on number fields, KRAD would need to be updated to accommodate this (https://jira.kuali.org/browse/KULRICE-5814)
- KRAD update for export of results set not there right now, will be w/KNS equivalency (https://jira.kuali.org/browse/KULRICE-5287)
List any issues that need to be resolved before work on this item can begin:
- Two ways the search could be constructed and presented to users are linked above, the selection of which may need to be more technically driven. Need to determine first if both are feasible then which if both are.
QA or Regression Testing Plan
List steps needed to test the basic functionality of this update, enhancement, bug fix
Functional Analysis Complete? In progress
Needs Review by KAI? Done
Technical Analysis Complete? No
Needs Review by KTI? Yes
Estimate: N hours (completed by DM)
Technical Design: Link Here (completed by DM)
Jira: Link Here (completed by SME)
Final Documentation: Link Here (completed by DM)
Added to QA: No