Locations and Service Points (UXPROD-771)

[UXPROD-985] Auto-Generate Location Codes and Configure Location Display Options Created: 04/Jul/18  Updated: 09/Nov/21  Resolved: 09/Nov/21

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:
Relates
relates to UXPROD-1161 Clone Location Closed
relates to UXPROD-2704 DRAFT: Disambiguate Duplicate Institu... Closed
relates to UXPROD-2367 Prevent non-unique names for location... Draft
relates to UXPROD-3401 Autogenerate Location Codes Closed
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:

  1. Feature to auto-generate location codes
  2. Feature to configure how locations display in folio (which location elements, codes etc you want to display)
  3. Names and codes need only be unique within the context of their hierarchy

Out of Scope (moved to UXPROD-1238 Closed ):

  1. UX changes shown here: https://drive.google.com/drive/folders/16LpdBv8GmmWD-Ox2I6nazhXiMfT1-odj


 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:

  1. We may need the ability to store the full "Location hierarchy code" for the location (the one that is generated according to the format specified for the tenant) and/or the Folio location display name. I mean, I suppose we could just generate these on the fly, but I am thinking it would probably be useful to have them in reports, as well. Keep in mind, if we store them, we want to make sure the stored data is updated if the tenant changes how they want these configured.
  2. We need to make the institution, campus and library codes required fields, as we'll need that data for auto-generating hierarchy codes and folio display names
  3. Finally, we need to offer the tokens for use in the hierarchy code and display name configuration. See this wireframe for what I mean: https://drive.google.com/file/d/1XzTeOxyOPu2HtGSotzBsBjrWoFC4-McR/view?usp=sharing

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 ]

#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.

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

#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.

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 - UXPROD-3401 Closed

#3 has an existing story - UITEN-21 Open - that I'm going to move to another feature for now - UXPROD-2367 Draft . What that'll let me do is close this feature and restart some of that exploration from a fresh slate.

Generated at Fri Feb 09 00:12:00 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.