Skip to end of banner
Go to start of banner

Creation of a repeatable field for additional call numbers - requirements analysis

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

This page contains requirements regarding the creation of a repeatable field for additional call numberss.

Inhalt

Proposal D-Metadaten Management

Description

  • It should be possible to assign multiple call numbers to a holdings/item record.
  • As it would be disruptive to make the existing field repeatable, a new repeatable field should be created, which could labelled as
    • Additional call numbers 
  • Each field should consist of the following fields:        
    • Call number type
    • Call number prefix
    • Call number
    • Call number suffix
  • Levels: This refers to the call numbers on the levels:
    • Item
    • Holdings
  • Primary call number:  It should be possible to mark the currently valid call number ("primary call number") by a function that includes the following properties:
    • The current field call number is always the main or primary call number with all currently applied functionality (display in tables, catalogs, ...).  
    • One or several  Additional call number can be added to the primary call number
    • It may occur that call numbers must be exchanged, for example if an object is changed to a new location.  
      • A manual change of the values in the fields Call number and Additional call number should be avoided.
      • Instead a function should exchange the values in the fields. 
        • The function is available at each Additional call number and can be triggered in the form of a button.
        • The function has the following effects
          • Transfer of the values from the fields Additional call number to the fields Call number
          • Transfer of the values from the fields Call number to the fields Additional call number
        • Suggested label for the button: 
          • Declare as Call number
  • Delete: Each call number should can be deleted individually with all associated call number fields. For example by a bin icon. 
  • Indexing: All call numbers should be included in the call number index so that it is possible to search for all call numbers.
  • Filter/Search: A filter option should be implemented in order to enable the limitation of the results to records which match only values of the field "primary call number". 
  • Exports: All call numbers should be included in exports, unless they are marked as "Suppress display in discovery".


Use cases

  1. As a librarian I want to keep an old call number in the record after I assigned a new call number in order to be able to ensure traceability in the future. For example, items are moved from one location to another, and I want to capture the previous call number as well as the current one.
  2. Certain reference works in the reading room (open collection) already have a stacks call number assigned. They'll be moved into the closed stacks some time in the future, e.g. as soon as they are outdated or no longer used on a regular basis.
  3. The current issues of print journals are presented in the reading room, but the older volumes are placed in the stacks. The records of the new issues should already contain the stacks call number under which they will be placed in the future.

Data structure

Proposed: → Array with objects

  "callNumbers" : [ {
    "callNumber" : "PR6056.I4588 B749 2016",
    "callNumberPrefix" : "PRE",
    "callNumberSuffix" : "SUF",
    "callNumberTypeId" : "512173a7-bd09-490e-b773-17d83f2b63fe",
    "primary" : true
  }, {
    "callNumber" : "2023 A 3987",
    "callNumberPrefix" : "PRE",
    "callNumberSuffix" : "SUF",
    "callNumberTypeId" : "512173a7-bd09-490e-b773-17d83f2b63fe",
    "primary" : false
  } ]

Created Jira-Tickets

UXPROD-4334 - Getting issue details... STATUS


Relevant existing Jira-Tickets

...


  • No labels