# | Requirement | Description | Functionality | Related tickets | Requirement status |
---|
1 | | Initial implementation focused on implementing type-based shelving orders for LC and Dewey call numbers, based on the marc4j library, as well as Other scheme Added normalized shelving orders based on NLM and SuDoc types (Poppy release) The sorting mechanism should consider the call number, volume, enumeration, chronology, copy number, and suffix data
| Browse | | |
2 | Allow users to select which specific call number type they'd like to browse | - Current implementation of the following call number type options:
- Call numbers (all)
- Call numbers, Dewey Decimal classification
- Call numbers, Library of Congress classification
- Call numbers, Local
- *where "Local" includes any call numbers with a type of source: Local
- Call numbers, National Library of Medicine classification
- Call numbers, Other scheme
- Call numbers, Superintendent of Documents classification
- These call number types have been made uneditable (with source: system)
POTENTIALLY: Change this implementation to use a filter instead of a facet | Browse | FE -initial:
UXPROD-3459
-
Getting issue details...
STATUS
BE - initial:
UXPROD-3255
-
Getting issue details...
STATUS
FE - browsing by type:
UXPROD-4327
-
Getting issue details...
STATUS
BE - browsing by type:
UXPROD-3569
-
Getting issue details...
STATUS
| |
3 | Populate browse results list with all item-level call numbers | Item call numbers can either be specified in the Item record, or inherited from the Holdings record Browse results will contain ALL item-level call numbers (see below for navigating forward and backward through the list) - A single Instance can have multiple items with call numbers of different types
| Browse |
| |
4 | Sort by calculated effective shelving order |
| Browse |
| |
5 | Browse results should contain preceding and succeeding call numbers per shelving order | | Browse |
| |
6 | Users should be able to navigate forward and backward through the list |
| Browse |
| |
7 | |
| Browse |
| |
8 | The results should indicate a match if: | Currently, since the shelving key does not contain the prefix, when the user browses the call number with the prefix value, it will not find a match, but will show the visually matching call number directly below the “X would be here” message. It is confusing to some users. But it is expected behavior.
| Browse |
MSEARCH-558
-
Getting issue details...
STATUS
| |
9 | If no exact match is found, the browse query should be placed in proper order (with preceding and succeeding call numbers) as a placeholder (“x would be here) | - If no exact match is found, display this placeholder, do not display a "No results found" message
| Browse |
| |
10 | | | Browse |
| |
11 | When browsing typed call numbers, the effective location facet should only contain the locations of the specific call numbers types on the Instance |
| Browse | | |
12 | Users should be able to search Items in Inventory by the Effective call number (item), eye-readable | - Should be exact in terms of characters & spacing, but it should be case insensitive
| Search | | |
13 | Users should be able to search Items in Inventory by the Effective call number (item), normalized | - Should ignore characters & spacing and be case insensitive
| Search | -
UIIN-857
-
Getting issue details...
STATUS
| |
14 | Users should be able to search Holdings in Inventory by the eye readable call number (holdings) | - Should be exact in terms of characters & spacing, but should be case insensitive
| Search | -
UIIN-858
-
Getting issue details...
STATUS
| |
15 | Users should be able to search Holdings in Inventory by the normalized call number (holdings) | - Should ignore characters & spacing and be case insensitive
| Search | | |
16 | Users should be able to search Instances in Inventory by the effective shelving order of the item call number | - I think this facilitates the ability to navigate from a result in the call number browse list to the Instance in Inventory
| Search |
| |
17 | Effective location facet selection should be retained when selecting a record in the browse results list for call number browse by type |
| Search |
| |
18 | In Call numbers (all) option, sort call numbers alphabetically |
| Browse |
MSEARCH-713
-
Getting issue details...
STATUS
| COMPLETE |
19 | Effective location facet should only include the locations for the specific call number type |
| Browse |
MSEARCH-600
-
Getting issue details...
STATUS
| COMPLETE |
20 | There should be no validation of format per call number type | Sort by algorithm per assigned type, regardless of format of call number | Browse |
MODINVSTOR-1177
-
Getting issue details...
STATUS
| COMPLETE |
21 | In ECS central tenant, there should be no Shared facet | All call numbers included are only on items on shared instances | Browse |
| COMPLETE |
22 | In ECS, effective location facet should only include item locations on the instances based on the Shared and Held by facets |
| Browse |
| COMPLETE |
23 | In ECS, held by facet results should only include item call numbers that are on holdings on either shared/local records |
| Browse |
| COMPLETE |
24 | In ECS member tenants, there should be a shared facet | Call numbers included are on items on either shared/local instances, based on Shared facet selection | Browse |
| COMPLETE |
25 | Users should be able to configure which call number types should be sorted per sorting algorithm (call number type sort option) | Similar implementation to Classification browse in order to resolve ID and reference data issues - For ECS, this should be configurable on the central tenant only
- Likely need new permission for call number browse configuration (similar to classification browse config)
| Browse |
| COMPLETE |
26 | Preceding call numbers should be displayed regardless of the number of characters that are shared between different call numbers |
| Browse |
MSEARCH-705
-
Getting issue details...
STATUS
MSEARCH-641
-
Getting issue details...
STATUS
MSEARCH-614
-
Getting issue details...
STATUS
| COMPLETE |
27 | Item records should inherit call number type and call number components if neither is specified on the item record |
|
|
| COMPLETE |
Isn't it confusing to show prefix in results as it will brake alphabetical order of the results due to not being a part of shelving order?