Jira Link

https://jira.kuali.org/browse/OLE-2757

1. Loan Policy - KRMS

UI Approach (Option #1)

KRMS offers a UI framework to setup and manage rules. With some backend code wiring, users can create and edit rules, in particular loan periods, borrower limts etc. Some of this was covered during Eric Westfall's KRMS training in March 2012, where the focus was on exercises pertaining to Circ policies.

Setup default parameters like Category,Context,Rules etc using UI
Setup appropriate Term(s), FunctionLoaders, ActionTypeService etc using backend code
Create CircPolicy (KRMS Agenda) using both above

Pros:

User can create, view and edit rules without having to worry too much about the backend implementation details

Cons:

For this story, simple rules using the UI doesn't for setting up rules wont suffice and needs backend setup.
Updates to rules, enhancements and longer term extensibility is going to be very limited due to the mixed approach of UI and backend coding.
The version of xStream being used by rice framework is not compatible with the version of xStream needed to perform some of the docstore functionalities and hence cant go too far with the UI approach (Bug Reported in Rice).

Profile Approach (Option #2)

KRMS has been utilized for Staff Upload (Batch Ingest) process in KOLE with custom setup of rules, actions etc using a profile concept; KRMS UI doesn't offer support for setting up custom rules etc, and so the intent here is to leverage what was done for staff upload for 0.6 release and extend the functionality to circ policies.

We are going to abstract out the common parts such as setting up function loaders, term resolvers etc and then have specific implementations for staff upload, circ polices. This will also enable future extensibility of such custom setups.

Profile.xml detailing terms, rules, actions etc
Similar to staff upload profile
Create Circ Policy (KRMS Agenda) using existing ProfileBuilder which is a custom engine that uses a profile.xml and setups up all the rules/actions etc..
Apply the policy to Patron type

Pros

XML approach for defining rules, actions etc.
Extensibility and flexibility supported by providing a generic profile concept that can then be used for setting up various agendas (policies).
No prior KRMS knowledge required for setting up of rules etc.
Leveraging existing profile builder for staff upload

Cons

Complete rules set may not be viewable using the KRMS UI
May need to provide a custom UI to export the profile xml

2. Roles (For this pass we are not going to be implementing the override'en mode)

Full Circulation attendant - will have the all loan privileges including the approval permissions - being implemented for this pass

- Permissions
  - Create a loan
  - Approve a loan for borrower limit
  - Approve loan for unavailable item
  - Approve loan for non-circulating item

2. Limited circulation attendant - operator will have only the "create loan" permission - not implemented this pass

Note: Permissions will be created using DB scripts.

Creating roles and permission involves following tables:

- KRIM_ROLE_T - Insert a record to create role
- KRIM_PERM_T - Insert a record to create permission for role created
- KRIM_ROLE_PERM_T - Insert a record to map role with permission
- KRIM_PERM_ATTR_DATA_T - Insert a record for permission details
- KRIM_ROLE_MBR_T - Insert a record to map a user with a role

3. Data Model

4. Sign Off

Review complete? No (Sr.Technical Architect) - Absent

Review with Core (Handoff #2)? Yes (OLE Core Team/S&A Team) - June 26th, 2012

Browser not supported