Circulation Rules Editor - Integrate Location Menu

Description

Purpose:
To extend the functionality of the existing circulation rules editor to include the addition of Location in encoded circulation rules. Note that while the editor currently has an existing designated syntax (s) for this attribute, it is not yet fully functional in the system. The new attributes for Organizational Hierarchies (UICIRC-258) and Locations are used in conjunction with other patron and item-related attributes, as well as appropriate policies to create 'circulation rules'. As the system performs an action, such as an item checkout or recall request for an item, the appropriate circulation rule is chosen and the associated policy pertinent to the incoming query is retrievable. Organizational hierarchies are parent components of configured Locations in FOLIO. When a circulation event occurs related to an item in FOLIO, the circulation rules are queried to determine the most appropriate match giving the incoming patron and item details. The addition of organizational hierarchies and locations will allow for rules to be configured efficiently at the desired level, and have the rule be inherited by library collection items configured with appropriate child Locations to the parent hierarchy.

*Note: This story is an extension of UICIRC-258. As noted above, Organizational Hierarchies are parents to Locations and the menu selections described in that story are meant to used in conjunction with Locations to allow the appropriate parent Organization, Campus and Library selections to be made to facilitate selection of the appropriate child Location.

Description:

  • Fully implement the location hierarchy such that:
    s - corresponds to a menu for the configured Locations list (Settings>Tenant>Location)

When implementing, the menu should always default to the top level Institution list, but the specific value used should tell the editor how far down the tree to go. s for example, should allow for Institution>Campus>Library>Location. By defaulting to the top-level (i.e., Institution) for each selection, the user is ensured of selecting a lower level value that is contained appropriately within the hierarchy. This is done to avoid ambiguity that may be caused by location-related code values that may be unique within their specific hierarchy, but ambiguous if the specific hierarchical path was not used to make the appropriate selection.

*Note: Location menu should include:

  • 'Type ahead' field to filter results by any string in [Code (Folio name)] string
    - Scrolling capability to select the desired value(s)
    - Check-boxes to allow for multi-select of Location values
    - Implementation of a ‘DONE’ button to trigger the interface that multi-select is complete and the selections are ready to load into the rules
    - Selections from the menu should allow the full view of [Code (Folio name)] string, but only write the code
    E.g., Menu: Location: DUK/WC/PER/PKEM2 (East Asian Collection Microforms Microfiche)
    Rule= s DUK-WC-PER-PKEM2
    - Note: Multiple selections should be possible from this menu so the editor needs to properly encode these into the circulation rules, e.g.,
    : Selection in the menu of:
    __Institution - ’DUK (Duke)’
    ____Campus - ‘WC (West Campus)’
    _______Library - ‘PER (Perkins)’
    ___________Location - ‘PER>PKEM2 (East Asian Collection Microforms Microfiche)’
    ___________Location - ‘PER>PKEM1 (East Asian Collection Microforms Microfilm)’
    : would generate the following in the Circulation Rules Editor:

    : where ’s’ is used to designate specific location(s)

    : where a space is used to separate multiple location values
    : where a dash has replaced the non-alpha-numeric character (>) from the Code fields of the Location Records (UICIRC-260)
    : where the location ‘FOLIO Name’ has been stripped from the rule encoding, leaving only the value from the Code field of the appropriate location records

Scenarios

Scenario 1: Location selection

  • Given the circulation rule editor

  • When adding/editing a new circulation rule and

  • When editing the attributes section of the rule

  • When typing s following a space

  • Then display in the editor an expandable menu that contains the configured list of Institution Codes

  • When clicking on the desired Institution Code, e.g., DUK

  • Then display in the editor a menu that contains the configured list of Campus Codes (limited to those configured in FOLIO as children of the selected parent Institution)

  • When clicking any individual Campus Code entry, e.g., WC (DUK)

  • Then display in the editor a menu that contains the configured list of Library Codes (limited to those configured in FOLIO as children of the selected parent Campus)

  • When clicking any individual Library Code entry, e.g., PER (DUK-WC)

  • Then display in the editor a menu that contains the configured list of Location Codes (limited to those configured in FOLIO as children of the selected parent Library)

  • When selecting any individual Location via the select box next to the entry, e.g., PER-PKEM1 (East Asian Collection Microforms Microfiche)

  • Then toggle the select box to state <select=yes>; repeated as necessary to allow multiple selections

  • When clicking 'Done' in the menu

  • Then close the menu and the entry should appear in the editor on the rule line in the form:

    ; Note that the FOLIO name has been removed from the written rule

**Note: when selected codes are written to the rule line, the editor should ensure that a space exists between the attribute syntax (a, b, c, s) and the chosen code, either as entered by the user or padded as part of installing the chosen code.

***Note: See attached menu wireframes

Environment

None

Potential Workaround

None

Attachments

8

Checklist

hide

TestRail: Results

Activity

Show:

Yevhenii MaltsevSeptember 4, 2019 at 12:56 PM

As it was agreed the note "when selected codes are written to the rule line, the editor should ensure that a space exists between the attribute syntax (a, b, c, s) and the chosen code, either as entered by the user or padded as part of installing the chosen code." will be implemented in scope of the .

The changes were deployed to https://folio-testing.aws.indexdata.com. Could you please review them?

sthomasAugust 12, 2019 at 3:19 AM

I haven't had a chance to review the deployment on https://folio-testing.aws.indexdata.com, however, I did have a chance to review the latest videos. These all look good to me and I think the DONE button on the bottom of the window works fine. Thanks.

Yevhenii MaltsevAugust 6, 2019 at 3:09 PM
Edited

, The current solution for campuses and libraries is deployed to https://folio-testing.aws.indexdata.com, so you can review with it .
In general, the width and height of columns are flexible but there are max values of width and height. So if there are a lot of items the list will be scrollable. I attached several videos for example: test_many_institutions.mov (the test data set is used) and temp_location_solution.mov (this is not a final implementation for locations - just for example).

Additionally, I had some time to provide quick changes to show use cases with the moved button (Please, take a look at the attached videos. Note: the test items are used):

  • moved_button.mov - the usual case to show button state changes and the button position. There are the next states:

    • The button is hidden before the location section is selected

    • The button is disabled before an item is selected

    • The button is enabled after an item is selected

    • The button is disabled after an item is not selected again

  • moved_button_with_long_instituion_list.mov - in case of the long other lists the button will be displayed at the bottom of the locations list

  • hidden_button_for_empy_locations_list.mov - the button is hidden if there are not any locations (only ANY is displayed)

  • moved_button_after_long_list.mov - if there are a lot of locations and the list is scrollable the button is placed at the bottom of the list. The items list in the location section has a little bit less height, and the button is always displayed so a user can scroll the list and see a button.

Are you okay with these changes or should we move the button the to the header (like it is displayed on the attached picture)?

sthomasAugust 6, 2019 at 2:44 PM

"It looks like the "Done" button can be moved to the bottom of the "Location" section. Please, take a look at the attached image moved_done_button.png (I should note that it's only a quickly drawn picture to show the idea). I think this place can be more intuitive for a user. What do you think about it?"

  • ST: I'm not opposed to placing the DONE button at the bottom of the menu, but the mockups had it in the top bar because I know that some of these menus lists will have a long set of results. In that case, if the menu selection window resized based on the length of the result set, it would vary the position of the DONE button with each result set and I thought that consistency of placement would be better. Are you implementing this such that the menu window will remain static despite length of the result set? I know that we'd noted the need for scrolling, but hadn't discussed fixed versus variable window sizing.

sthomasAugust 6, 2019 at 2:35 PM

"What behavior should be applied to the "done" button if there are not selected locations or a user doesn't reach a locations list (for example she selected an institution and the campuses list was filled)? I would suggest button disabling if a user doesn't select at least one location."

  • ST: I agree that the DONE button should be disabled until a valid selection(s) is made in the Locations panel.

Done

Details

Assignee

Reporter

Priority

Story Points

Sprint

Development Team

Concorde

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created May 20, 2019 at 11:43 PM
Updated September 19, 2019 at 10:34 AM
Resolved September 4, 2019 at 6:30 PM
TestRail: Cases
TestRail: Runs