Locations and Service Points
(UXPROD-771)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Locations and Service Points |
| Type: | New Feature | Priority: | P4 |
| Reporter: | Cate Boerema (Inactive) | Assignee: | Erin Nettifee |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | locations, locations_uat_1, round_iv | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||
| Potential Workaround: | Cate Boerema: Use Location codes and display as-is as it's fully functional. The enhancements in this feature would improve usability of an infrequently used feature that is used by select few special admins who can be trusted to CRUD locations and codes responsibly. | ||||||||||||||||||||
| Epic Link: | Locations and Service Points | ||||||||||||||||||||
| Front End Estimate: | Large < 10 days | ||||||||||||||||||||
| Front End Estimator: | Zak Burke | ||||||||||||||||||||
| Front-End Confidence factor: | Medium | ||||||||||||||||||||
| Back End Estimate: | Medium < 5 days | ||||||||||||||||||||
| Estimation Notes and Assumptions: | Looks like most of this will have to be front-end stuff. Only point #3 seems to require back end modifications. Most likely that is just a matter of defining the unique indexes right, but it may need a bit of code tweaking too, and test cases, of course. | ||||||||||||||||||||
| Development Team: | Prokopovych | ||||||||||||||||||||
| PO Rank: | 42 | ||||||||||||||||||||
| PO Ranking Note: | 2020-10-04 - CB: Making my PO rank same as the calculated total rank for now.
2019-07-12: Keeping PO rank same as calculated rank (with potential minor adjustments to avoid having two features with same rank) |
||||||||||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R4 | ||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R4 | ||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R4 | ||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R1 | ||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R4 | ||||||||||||||||||||
| Rank: FLO (MVP Sum 2020): | R4 | ||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R2 | ||||||||||||||||||||
| Rank: hbz (TBD): | R1 | ||||||||||||||||||||
| Rank: Hungary (MVP End 2020): | R1 | ||||||||||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R4 | ||||||||||||||||||||
| Rank: Leipzig (Full TBD): | R1 | ||||||||||||||||||||
| Rank: Mainz (Full TBD): | None | ||||||||||||||||||||
| Rank: MI State-Lib of MI (Sum 2021): | None | ||||||||||||||||||||
| Rank: MO State (MVP June 2020): | R5 | ||||||||||||||||||||
| Rank: TAMU (MVP Jan 2021): | R4 | ||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R5 | ||||||||||||||||||||
| Description |
|
Currently, location names and codes are manually entered in FOLIO and need to be unique across the entire tenant (because it's simply the location name and/or code that displays throughout the FOLIO UI). This means, for example, if you've got a "reference" location in both the Perkins and Law libraries, you would need to make that clear in the location names you create so you can differentiate the locations from one another (e.g. "Perkins Reference" and Law Library Reference"). This is functional but is more data entry than people would like. This feature is about allowing a tenant to configure how a location displays in FOLIO so that they don't need to make each location name and code unique. Summary of Included Changes:
Out of Scope (moved to
|
| Comments |
| Comment by Cate Boerema (Inactive) [ 05/Jul/18 ] |
|
Zak Burke and Heikki Levanto can you please review and estimate this new locations feature (essentially a bundle of enhancements)? If it makes sense to break this down into smaller features, I can do that. |
| Comment by Cate Boerema (Inactive) [ 05/Jul/18 ] |
|
Thanks, Heikki Levanto for the speedy estimate! I think items 1& 2 will also require some backend changes:
Let me know if this doesn't make sense |
| Comment by Heikki Levanto [ 05/Jul/18 ] |
|
#1: The location record already has a field called code. I assume that is the one that the UI creates by concatenating the code fields from the selected location units. If we need a new field, that is a bit more work in the back end, but not too much. #2: Ok #3: You mean strings like "Campus Code"? Maybe that could be done with the regular configuration settings, and handled in the UI. Otherwise we may need a whole new table for such, that will be a bit bigger job. I adjusted the estimate to Medium to reflect this. |
| Comment by Cate Boerema (Inactive) [ 05/Jul/18 ] |
I think we do need a new field because we will use the existing Location code field for the location component of the hierarchy (just the end point of the branch. For example, for the location in Perkins Library where you will find East Asian Maps, the Location code could be "EAM". Then, the full Hierarchical location code that would be generated by the system might be DUK/MAI/PER/EAM
We are already using tokens in Settings > Circulation > Staff slips and we will also offer them for the configuration of Patron notices. I'm not sure how much back end work they require. Anyway, we don't need to work out all the details now. I think it's probably good that you increased the back end estimate to M. Thanks! |
| Comment by Theodor Tolstoy (One-Group.se) [ 09/Oct/18 ] |
|
The only requirement for Chalmers that is an actual Go-Live requirement is number 3. The other ones are not needed for some time. could these be broken up in multiple tickets? |
| Comment by Cate Boerema (Inactive) [ 10/Oct/18 ] |
|
Hi Theodor Tolstoy (One-Group.se), I actually don't think you can do #3 without also doing #2. This is because currently only the location's "FOLIO name" displays throughout FOLIO where location displays. If we implemented #3, that would allow people to set up two locations, both with the name "Reference". Given the way FOLIO location display works, there will be no way to distinguish one"Reference" from the other in the UI. So, to enable #3, I think you really need the ability to include other elements of the location hierarchy (e.g. institution, campus and library) in the location display. That's what #2 is about. Does that make sense to you? |
| Comment by Theodor Tolstoy (One-Group.se) [ 11/Oct/18 ] |
|
I think so Cate Boerema. Thank you. |
| Comment by Erin Nettifee [ 09/Nov/21 ] |
|
This feature hasn't moved since prior to 2018 and we're planning on removing the location details pane (which appears to be part of what's in the mockups here) since there's not a good understanding anymore of what was really intended, in order to develop this, we would need to start over. We also would likely break this up a little bit more finely in our development practices now, and these features are being reviewed as part of the movement of modules between Prokopovych and Vega so they need a fresh eye regardless. So I am going to close this feature and move #1 to its own feature -
#3 has an existing story -
|