Inventory (UXPROD-785)

[UXPROD-2002] Implement Normalized Call Number for Sorting (LoC Parsing Only) Created: 13/Aug/19  Updated: 26/May/23  Resolved: 30/Apr/21

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: R1 2021
Parent: Inventory

Type: New Feature Priority: P2
Reporter: Holly Mistlebauer Assignee: Charlotte Whitt
Resolution: Done Votes: 0
Labels: Showstopper-Cornell, call_number, cap-mvp, inventory, mandatory, po-mvp, q4-2019-at-risk, round_iii
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: Microsoft PowerPoint LC call number sorting.pptx     PNG File screenshot-1.png     PNG File screenshot-2.png    
Issue links:
Blocks
blocks UXPROD-2174 Loans: sort by normalized call number Open
blocks UIU-1389 Add call number sorting to user's ope... Open
blocks UIU-1395 Add shelving order to loans exports Open
blocks UIU-1390 Export normalized, sortable call numb... Closed
blocks UXPROD-2128 Future Fees/Fines: Address Call Numbe... Draft
is blocked by UXPROD-1626 Store Effective Call Number Prefix, C... Closed
Cloners
is cloned by UXPROD-2219 DRAFT: Implement Type-Based Parsing f... Closed
Defines
is defined by MODINVSTOR-521 Determine shelving order for existing... Closed
is defined by MODINV-155 Map shelving order property for items Closed
is defined by MODINVSTOR-381 Store Shelving Order in item (LC call... Closed
is defined by UIIN-816 Display Shelving order on the item re... Closed
is defined by MODINVSTOR-679 Comply with the MARC4J licence Closed
Gantt End to Start
has to be done before UXPROD-3496 Sort & Browse by Holdings Level Call ... Draft
has to be done before UXPROD-2683 Display Call Number Sort Code in Requ... Draft
has to be done before UXPROD-2920 For In Transit Items Report, add norm... Draft
Relates
relates to UXPROD-1714 FOLIO wide search by call number for ... Open
relates to UXPROD-3255 Call Number browse - Back-end Closed
relates to UXPROD-3447 Subject browse - back-end Closed
relates to UXPROD-3459 Call Number browse - Front-end Closed
relates to UXPROD-3460 Subject browse - front-end Closed
relates to UXPROD-1655 Inventory. Search call number (Core f... Closed
relates to UXPROD-1854 Create Call number generator Draft
relates to UXPROD-393 Finalize display format of Call Numbe... Closed
relates to MODINVSTOR-1066 Implement normalized call number for ... Closed
relates to MSEARCH-527 Implement normalized call number for ... Closed
Epic Link: Inventory
Front End Estimate: Large < 10 days
Front End Estimator: Holly Mistlebauer
Front-End Confidence factor: Low
Back End Estimate: XL < 15 days
Back End Estimator: Holly Mistlebauer
Estimation Notes and Assumptions: Best guess given we haven't defined this yet!
Development Team: Prokopovych
PO Rank: 98
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R2
Rank: 5Colleges (Full Jul 2021): R1
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R4
Rank: Grand Valley (Full Sum 2021): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: MI State-Lib of MI (Sum 2021): R2
Rank: MO State (MVP June 2020): R1
Rank: St. Michael's College (Sum 2021): R2

 Description   

Raw LC call number data does not sort well. The purpose of this feature is to generate and store a machine-sortable call number for the purposes of sorting lists such as Loans and Fees/fines. The machine sortable call number will also be available for inclusion in reports (both in-FOLIO and external to FOLIO). The scope of this feature is implementing Library of Congress parsing to all FOLIO call numbers. Call number display and sort in the FOLIO UI is out of scope. Separate feature(s) will also be written as needed to cover type-based parsing (e.g. Dewey parsing for Dewey call numbers etc).

Per discussion with the Call number sub-group, the machine sortable call number will be based on the <Effective call number> data element on the item record. We will leverage Tod Olsen's SolrMarc code for generating the machine sortable call number.

Call number searching, both with and without punctuation & spacing, is addressed in a separate feature UXPROD-1655 Closed .

---------------------------------------

Call Number Sub-group membership:

  • Laura Wright (leader)
  • Charlotte Whitt
  • Christie Thomas
  • Felix or Martina
  • Andrea Loigman?
  • Lisa McColl
  • David Bottorff
  • Darcy Branchini
  • Cate Boerema

CB: I drafted a document which covers how call number is working today which may be a good starting point for discussion: https://docs.google.com/document/d/1FMl-_oNR6k-wVDQrZeMT_V9-ZDDaZBzdiipx0OQii9E/edit

NOTE (for those who may be looking) Agreed upon format for Call number string = <EffectiveCallNumberPrefix> <EffectiveCallNumber> <EffectiveCallNumberSuffix> <Volume> <Enumeration> <Chronology> <EffectiveCopy> <ItemCopy> (ideally we'd have <EffectiveCopy>, but that hasn't been implemented yet (see UXPROD-2170 Open )



 Comments   
Comment by Charlotte Whitt [ 14/Aug/19 ]

Hi lew235 and Holly Mistlebauer - I have added following features and linked them as blocked on this new Call number umbrella feature:

  • UXPROD-86 Closed Loans list: Display normalized call number
  • UXPROD-1714 Open FOLIO wide search by call number for any item search functionality
  • UXPROD-1854 Draft Create Call numbers generator
Comment by Cate Boerema (Inactive) [ 22/Aug/19 ]

This is important, but it was created too late to be delivered in Q3. I am removing that fix version.

Comment by David Bottorff [ 22/Aug/19 ]

Cate, the summary document is helpful, especially as I'm joining this conversation somewhat belatedly. I have one question about other item level information, such as enumeration/volume. Is that being handled separately everywhere, presumably? Most screens would need this displayed next to the call number, so should we assume that is already being handled?

Comment by Cate Boerema (Inactive) [ 22/Aug/19 ]

Hi David Bottorff. Enumeration, chronology and volume are only present on the item record. I added that to the document along with screenshots of the relevant sections of the two records. I don't think we should consider it already handled. Let's include them in the discussion.

I am curious if there was a plan at one point to combine enumeration and volume. The reason I ask is that Tania actually had volume removed from the requests app as part of UIREQ-104 Closed . The reasoning given in that JIRA was, "Because Volume information is contained within Enumeration, and doesn't exist as a separate data element, we need to remove the separate Volume field." Hopefully Charlotte Whitt knows the background

Comment by lew235 [ 22/Aug/19 ]

David Bottorff my e-mail message to you bounced – did you get an invitation to our meeting at noon today?

Comment by David Bottorff [ 22/Aug/19 ]

I did not. My email is dbottorff@uchicago.edu. Is that noon ET or CT?

Comment by David Bottorff [ 22/Aug/19 ]

I can make either.

Comment by lew235 [ 22/Aug/19 ]

Just sent you an e-mail David Bottorff

Comment by Christie Thomas [ 22/Aug/19 ]

David, I just added you to the slack channel.

Regarding the inclusion of enumeration and chronology - I have noticed that there are references to call number that are assuming that whatever is on the spine label will display; the spine label frequently includes the prefix/suffix, enumeration, chronology, copy number, and (at least at Chicago) the shelving location. It would be nice to differentiate when a call number is required for display and when the call number + other data is required for display.

Comment by Holly Mistlebauer [ 11/Oct/19 ]

lew235: Has a decision been made? I am asking because my team needs to work on UXPROD-393 Closed in Q4. Thanks!

Comment by lew235 [ 11/Oct/19 ]

Holly Mistlebauer A decision has been made about the "call number block" display, which comprises
<prefix> <call number> <suffix> <volume> <enumeration> <chronology> <copy number>

The only thing I'm not completely certain about in that is the placement of <volume> – I will find that out today if possible.

Comment by Holly Mistlebauer [ 14/Oct/19 ]

lew235: Great! Then I can write up the user story for my team to work on. I'm assuming if any of the data doesn't exist you just skip it and include what does. Thanks!

Comment by Holly Mistlebauer [ 14/Oct/19 ]

lew235: I can see where to get Call number prefix, Call number, Call number suffix, Copy number and Enumeration from, but where do I find volume and chronology?

Comment by lew235 [ 14/Oct/19 ]

Holly Mistlebauer Enumeration, Chronology, and Volume are all part of the Enumeration data accordion in the item record.

Comment by Holly Mistlebauer [ 14/Oct/19 ]

lew235: So I guess if it doesn't show up it just doesn't exist. Thanks!

Comment by lew235 [ 14/Oct/19 ]

Yes, if there is no data nothing will display. Otherwise we'd end up with odd-looking call number displays!

Comment by Holly Mistlebauer [ 14/Oct/19 ]

lew235: What I meant was that the sample record I was using had Enumeration in the Enumeration section but did not have Volume and Chronology listed at all...I thought maybe it was because they were blank...

Comment by Holly Mistlebauer [ 14/Oct/19 ]

lew235: One last question, I hope. What is the formatting of the call number field. Is there a space between each part?

Comment by lew235 [ 14/Oct/19 ]

Holly Mistlebauer Yes, all elements are separated by spaces. And in your example I think it is the case that Chronology and Volume are not displaying because they are empty.

Comment by Holly Mistlebauer [ 14/Oct/19 ]

lew235: Thanks so much! Please let me know as soon as you have confirmed the placement of VOLUME. Thanks much!

Comment by lew235 [ 14/Oct/19 ]

I'm making an executive decision, as no one has spoken up, that the order in the call number block should be the as it appears in the Enumeration data accordion:
Enumeration, Chronology, Volume

Comment by Holly Mistlebauer [ 15/Oct/19 ]

lew235: Thanks for finalizing this for us! Really appreciate your efforts!

Comment by Charlotte Whitt [ 12/Dec/19 ]

Hi lew235 - this feature did not have any fix version. I added Q1 2020.

Please correct this if you think it should be differently

CC: Cate Boerema Holly Mistlebauer

Comment by Cate Boerema (Inactive) [ 17/Dec/19 ]

lew235 and Charlotte Whitt I am moving this from Analysis complete back to Draft, as there are still open questions as to whether we can start with LoC parsing only or if we need type-based sorting. Type-based sorting definitely expands the scope of this feature. In the call number Slack channel, I proposed that we start with enabling the LoC parser only for MVP and introduce Dewey (and other call number type) parsing afterwards. So far no one has objected on the Slack channel, but I haven't had the chance to review the MM meeting recordings on this topic.

What do you think? Can we proceed with LoC and expand later? If so, I think we should restructure this features so it is just about implementing LoC parser and then creating a new UXPROD feature for enabling call number type based parsing. Folks could just rank the new feature to let us know how critical it is for them.

Comment by lew235 [ 17/Dec/19 ]

Cate Boerema I think we can proceed with LoC first. MM discussed this more last week (I was absent but I watched the recording) and while the Dewey numbers sort incorrectly it sounds like the libraries most affected by this already have workarounds in place. I think splitting these features so we can rank the additional work separately is a good plan. That way, if there are implementing libraries who need something more than LoC to start with, they can make that need known explicitly.

Comment by Charlotte Whitt [ 23/Mar/20 ]

lew235 and Charlotte Whitt are reviewing:

Cate Boerema [11:41 AM] on March 11, 2020:
A couple things:
1. Implement Normalized Call Number for Sorting (LoC Parsing Only) is very highly ranked but it doesn't actually do anything on its own. The features that will use the sort code for sorting were not highly ranked at all. I feel like we must be missing a feature or something. Why do ppl think this is so important? How will they use it? Probably a question for the MM SIG.

2. DRAFT: Implement Type-Based Parsing for Call Number Sorting by Dewey and LC - This was seen as lower priority than the above feature. I drafted this a few months ago and asked you and Laura to review it and take it out of draft so it could be ranked. It looks like you haven't had the chance to do that yet.

But due to the Coronavirus - we have not been able to meet about this/follow up yet.

Comment by David Bottorff [ 23/Mar/20 ]

Among other things, I would argue that having the normalized call number string in place is necessary for LDP and various in-app reporting and integration features to work. For example, the in-app report of exporting a list of page requests that need to be pulled is useless if the list can not be properly sorted by call number. Machine sortable call number logic is vital to any number of similar functions.

Comment by lew235 [ 22/Jun/20 ]

Sample call numbers, with sort order indicated are here:
https://docs.google.com/spreadsheets/d/1trtVmgVBclRAeKlZ8Wo1y5GyeOBpgN_tfHqDWL6bb3E/edit#gid=0
(if anyone sees a fundamental principle I failed to illustrate, please let me know or just go ahead and add it)

Comment by Sharon Beltaine [ 20/Oct/20 ]

Cornell Reporting:
Cornell needs the ability to use a Normalized Call Number in numerous reports delivered via the Library Data Platform. For example, when we need to report on a set of titles in a given classification number or range. Also, numerous reports require listing collection holdings arranged by call number.

Also, sometimes we need to identify titles in a given call number range in order to reclassify them. Accreditation reports for Annual Statistics reports include data on materials that have been reclassified by call number range.

Critical collection management decisions require the ability to inventory the collection and compile metrics associated with missing items, replacements, tattle-taping and effort expended to maintain the collection. Using normalized call numbers is required to obtain this information.

Comment by Holly Mistlebauer [ 17/Dec/20 ]

lew235 and Charlotte Whitt: Hi! This feature was very hot at one point, then seemed to disappear. What is the latest on this? I have taken over Cate's Lead PO role on the Core: Functional team so I am trying to get up to speed on the features assigned to the team. Thanks, Holly

Comment by Charlotte Whitt [ 17/Dec/20 ]

Hi Holly Mistlebauer - here the latest Slack chat on this (10/9/2020):

Charlotte Whitt:lemon: 4:29 PM
Hi @cate - re. UXPROD-2002 Closed then I checked with @Laura (she/her)
4:31
And Laura think it would work well to have it reassigned. Laura is very busy with Cornell's Implementation as project manager, and the extra time to move forward with UXPROD-2002 Closed is limited.
4:34
If you have time to pick it up for the Iris release, I think that would work well. I think, I will have my hands full with Q1 2021 timebox of search and filter work (incl. Elastic Search), Analytics and bound-with ( UXPROD-1241 Closed , UXPROD-1856 Closed ), all of the Result list features we plan for for the upcoming release, AND finally UXPROD-1925 Closed and UXPROD-1995 Closed (Acquisition data in holdings and items)

Cate Boerema 6:08 PM
Okay. I can assign it to myself mainly just to include in my relative PO rankings. I think Laura has done a good job of collecting and presenting the needed info - we just need to get it done!

Laura Daniels (Wright):pride: 6:12 PM
Thanks @cateI don't have the resources to push this forward, and I know it's needed.

Comment by Holly Mistlebauer [ 18/Dec/20 ]

Charlotte Whitt and lew235: So it sounds like everyone agrees that it would be good to get this done, but we no longer have a PO for this with Cate gone. Are all of the user stories done? (The status is 'Analysis Complete', but I just want to make sure.) If the stories are done I'm fine taking them to the Core Functional Team to be pointed. We need to get some estimates so we know what we are dealing with.
Thanks,
Holly

Comment by Holly Mistlebauer [ 18/Dec/20 ]

Just to be clear, I need a confirmation that the stories are done, then I will take them to the Core Functional Team to be pointed. We have two extra sprints in Iris now, so depending on how much work is involved we may be able to fit this in. I don't want to promise anything until the stories are pointed.

Comment by Charlotte Whitt [ 21/Dec/20 ]

Hi lew235 - would you have time this week to go over the stories, together with me and Holly Mistlebauer - just for us to be 100% sure that all spec work is done, and the stories are dev ready.

Comment by lew235 [ 04/Jan/21 ]

Charlotte Whitt I'm sorry, just now seeing this. I can make time this week.

Comment by Charlotte Whitt [ 04/Jan/21 ]

lew235, no worries. When would work for you?

E.g. Wednesday 1/6/2021 at noon EST?

Comment by Charlotte Whitt [ 12/Jan/21 ]

Hi Holly Mistlebauer - I have added the R1 2021 release tag to this feature; while Cornell and other libraries are asking when to expect to have this work done.
I know that you with the plans for the extended release date for R1 2021 also were aiming for getting this work done for Iris.

Comment by Holly Mistlebauer [ 13/Jan/21 ]

Charlotte Whitt: Thanks...I just moved added the user stories to Sprint 106...

Comment by Holly Mistlebauer [ 17/Feb/21 ]

UPDATE:  This feature was not originally planned to be part of the Iris release, but was added when the Iris development cycle was extended by 2 months.  I just learned today that the back-end dev working on MODINVSTOR-381 Closed (which blocks the other 3 user stories defining this feature) has 6 days of vacation planned starting this week and into next week (planned before I became Lead PO of the Core: Functional Team).  This means that he will not be able to finish the work for this feature before the Iris code freeze on February 26.  We are extremely short of back-end capacity, so I don't have anyone to take over.  This feature is labeled a 'showstopper' for Cornell.  There may be other institutions adversely impacted as well.  Please let me know ASAP the ramifications of this feature not being completed until the Juniper release in mid-August.  Sorry I don't have better news...

 

Comment by Tod Olson [ 17/Feb/21 ]

For Chicago, it would increase our workaround burden in the short term. We would need to figure out some good-enough temporary solutions for operational needs, it affects real daily work like generating lists for pulling materials from the bookstacks. So we would need to come up with some workarounds for a couple months. We would definitely feel pressure to fast-track moving to Juniper. 

Comment by Joanne Leary [ 18/Feb/21 ]

I agree with Tod. In terms of circulation, operations that depend on paging items from the stacks (to fulfill requests, for course reserve and document delivery scanning, for curbside checkout) would be immediately impacted. My reporting work would likewise be heavily affected. Nearly every report I do is put into call number order. Right now I am creating lists of candidate volumes to be transferred to our Annex Library, and the project has to operate on a fairly strict time schedule; this would be slowed down significantly if call numbers could not be sorted correctly. I'm not sure how this affects tech services operations, but my guess is that it would make workflows more difficult.

Comment by Sharon Beltaine [ 18/Feb/21 ]

Cornell Reporting:
Cornell needs the ability to use a Normalized Call Number in numerous reports delivered via the Library Data Platform. For example, when we need to report on a set of titles in a given classification number or range. Also, numerous reports require listing collection holdings arranged by call number.
 
Also, sometimes we need to identify titles in a given call number range in order to reclassify them. Accreditation reports for Annual Statistics reports include data on materials that have been reclassified by call number range.
 
Critical collection management decisions require the ability to inventory the collection and compile metrics associated with missing items, replacements, tattle-taping and effort expended to maintain the collection. Using normalized call numbers is required to obtain this information.

Comment by Holly Mistlebauer [ 18/Feb/21 ]

Hi all!  Thanks for the input.  I want to list specific issues this will cause.  I have summarized the case for this feature below.  Please let me know what else should be added or if I have made any errors.  Thanks.

  1. Generating lists for pulling requested materials for patrons from the bookstacks (for course reserve, document delivery scanning, curbside checkout, etc.).  The list will not be sorted in the correct order nor will the call number on the list match what is on the spine of the book.
  2. Generating list for items to be moved to a storage facility of other location.  The list will not be sorted in the correct order nor will the call number on the list match what is on the spine of the book.
  3. Identifying titles in a given call number range in order to reclassify them and report data on the Accreditation reports for Annual Statistics reports.
  4. Making collection management decisions that require the ability to inventory the collection and compile metrics associated with missing items, replacements, tattle-taping and effort expended to maintain the collection.
  5. Many reports delivered via the Library Data Platform are sorted by Normalized Call Number.
Comment by Holly Mistlebauer [ 18/Feb/21 ]

Also...

What is the workaround?  I need to explain why it is cumbersome.

 

Thanks!

Comment by Holly Mistlebauer [ 18/Feb/21 ]

Joanne Leary , Tod Olson , Sharon Beltaine :  To prepare myself for the questions I will get, I need to ask you some more questions.  

  • The work described in items 2-4 above seems like it could wait a month or two after implementation if absolutely necessary.  Is that true?  I am not sure what is included in item 5.  It seems like the real immediate issue is with item 1.  What is the impact of that item and what is the workaround?
  • Why is this only a critical concern for Chicago and Cornell?  We have implemented and implementing libraries that don't seem concerned.  Does this have to do with volume of work?  Special services others don't offer?  Something else? 

 

 

Comment by Holly Mistlebauer [ 18/Feb/21 ]

UPDATE:  EPAM has confirmed that the dev working on MODINVSTOR-381 Closed is unable to reschedule his vacation, but he will finish MODINVSTOR-381 Closed before he leaves.  That is good news.   MODINVSTOR-381 Closed blocks the other 3 user stories, which I have listed below.  EPAM is looking at other options to help us out due to our extremely limited BE dev capacity, but worse case we will need to do the following if no additional help is available...

MODINVSTOR-381 Closed blocks these user stories:

  • MODINV-155 Closed (3 pts) - assign to Core: Functional part-time community BE dev as soon as he finished CIRC-1077 Closed (I have asked him when that will be).
  • MODINVSTOR-521 Closed (8 pts) - assigning to only other Core: Functional full-time EPAM BE dev on the team, but he is unlikely to finish it by the code freeze on Feb 26 unless it is easier than we thought it would.  (8 pts usually take about 2 weeks.)
  • UIIN-816 Closed (5 pts) - I need to find out if this can be started without all of the back-end stories being complete.  If so, it can be started by a FE dev on Monday.  If not, we will need to work on this after the core freeze date. 

 

Comment by Holly Mistlebauer [ 19/Feb/21 ]

Background: This feature wasn't identified in the Capacity Plan as being part of the Iris release, but when the release date was extended I was able to add it.  This feature was chosen to be added to Iris because Cornell labelled it as a 'showstopper', and we are all trying to complete everything that is a 'showstopper' for a July implementer.  I knew it would be very tight, but I didn't know that 1.0 BE FTE would be out the last week of the sprint.  This leaves us with only 1.5 BE FTE for next week.  Also, our available 2.5 BE FTEs were all new in December.  The Capacity Planning Team, PC Exec and OLE Board are all aware of our situation, and are working to get more BE devs, but in the meantime we are doing the best we can with what we have. 

 

Comment by David Bottorff [ 19/Feb/21 ]

Holly, I think there might be one mistake in your descriptions, in that I think the display call number that already exists WILL match the call number on the label (as long as they are the effective call number string), but won't appear in the ORDER that the books are physically shelved.

For Chicago, at least, this is definitely an issue of scale/volume of work, both in terms of the number of paging requests we process daily as well as the volume of material being transferred, shifted, etc. on an ongoing basis.

Tod Olson could certainly explain our possible workaround better than I could. Manually sorting the lists would be onerous to the point of implausibility. We would likely have to build some kind of process (such as an SQL query) that would create local machine sortable versions of call numbers. This might involve relying entirely on LDP (which has data-freshness issues) or exporting lists and then importing them into a secondary tool. Either way, this would involve both initial investment to develop and ongoing investment to maintain the technical workaround, as well as likely increases to daily processing time.

Comment by Tod Olson [ 19/Feb/21 ]

With MODINVSTOR-381 Closed , we will have the normalized call number/sort key in the item data. That means it will be available in the LDP, at least in the item data, and we would rely on the LDP where we can.

Where the LDP data is not fresh enough, we would probably need to export lists and manipulate them externally. If the sort key is exposed in the exported data, we're probably okay sorting on that column using some tool outside of FOLIO. If the sort key is not available in the exported list, then we would need to add sort keys somehow, perhaps by joining with data in LDP, or perhaps by creating a filter to read the exported file and add a sort key.

Comment by Sharon Beltaine [ 19/Feb/21 ]

Holly – Your summary of what is needed for Call Number sorting for FOLIO reporting is good. I agree with David Bottorff's additional comments on the issue of order. The impact of not having this feature on Cornell is basically the same as Chicago's. We are evaluating possible workarounds in the Reporting SIG. Good to know we might have  MODINVSTOR-381.

Comment by Holly Mistlebauer [ 22/Feb/21 ]

UPDATE:  The Capacity Planning Team has given us an additional week to work on this feature.  Our freeze date will be March 5 rather than February 26.  Also, EBSCO has graciously approved overtime pay for the BE dev from EPAM, and the dev has agreed to work overtime on this.   This is the good news.  The bad news is that Marc Johnson identified yet another back-end task for this feature while reviewing the dev's code for MODINVSTOR-381 Closed .  (It's good that he thought of it, bad that we now have more work to do.)  He has created MODINVSTOR-679 Closed , which has not been pointed yet.  Here is the plan for completing this work...

  • Frontend dev TBD :  He will start UIIN-816 Closed (5 pts) as soon as Kyle finishes MODINV-155 Closed .
  • Andrii Shapovalov : He can help with any remaining back-end work when he returns from vacation on March 2.

The schedule is tight, but we will all do the best we can.  Please let me know if you have any questions or concerns. 

Thanks!

Comment by Sharon Beltaine [ 22/Feb/21 ]

With MODINVSTOR-381 complete, we have the normalized call number/sort key in the item data. We are now in a position to test this functionality to make sure it works for reporting. 

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