Locations and Service Points
(UXPROD-771)
|
|
| Status: | In Refinement |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Locations and Service Points |
| Type: | New Feature | Priority: | TBD |
| Reporter: | Erin Nettifee | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Epic Link: | Locations and Service Points |
| Development Team: | None |
| PO Rank: | 0 |
| Rank: Cornell (Full Sum 2021): | R2 |
| Description |
|
Current situation or problem: This is especially important for libraries that are using requesting as part of staff workflows - for example, placing requests for items that are needed to be delivered for cataloging work at a tech services location. This is also important for libraries using INN-REACH or other ILL solutions that require handling requests for institutional patrons or representing pickup locations within a consortium in order route requests properly. For these staff-only locations, you want to somehow indicate they are staff-only so that they are not pulled into a discovery layer for patrons to send items to. Some schools have been working around this by using naming conventions and building a custom integration with their discovery layer tool. A better approach would be to add/tweak an additional field to the In scope
Out of scope
Use case(s)
Proposed solution/stories Links to additional info Questions |
| Comments |
| Comment by Erin Nettifee [ 28/Feb/22 ] |
|
Brooks Travis, can you elaborate on how INN-REACH might use this if it was available? Either as a comment or feel free to edit the jira directly. |