Uploaded image for project: 'mod-inventory-storage'
  1. mod-inventory-storage

Transform OAI-PMH view API in Inventory into general API



    • Gulfstream Sprint 6, Gulfstream Sprint 95, Gulfstream Sprint 96
    • 8
    • Gulfstream


      See 5th option and discussions in comments on the page RTAC performance improvement.

      • Introduce new API which is intended to replace /oai-pmh-view in mod-inventory-storage after mod-oai-pmh and mod-rtac completely switch to using this new API. New API endpoints should inherit the functionality from /oai-pmh-view endpoints and gain the additional one, described in this ticket below.
        • e.g. /oai-pmh-view/updatedInstanceIds => /inventory-hierarchy/updated-instance-ids
        • e.g. /oai-pmh-view/enrichedInstances => /inventory-hierarchy/items-and-holdings
      • /inventory-hierarchy/items-and-holdings endpoint should return complete holdings and items information by provided list of instance Ids. See response example.json for response details.
        • Add "holdings" section with all holdings fields
        • Complete "items" section with all items fields
      • Add new optional parameter to /updated-instance-ids, which defines whether holdings and items create/update/delete dates should be considered in filtering by dates or not and how result update date is calculated.
        • If the new parameter is set to true - define update date as the latest date among instance, its holdings and items create/update/delete dates within the requested date range and add instance id to response only if at least one of the instance, holdings or items create/update/delete dates fits the requested date range (as is).
        • If the new parameter is set to false - define update date as instance create/update/delete date and add instance id to response only if instance create/update/delete date fits the requested date range.
      • Both responses (/updated-instance-ids and /items-and-holdings) should include the instance "source" field for each instance.
      • Suppress from discovery logic: each suppressFromDiscovery value should consider instance->holding->item hierarchy using the next rule: if a precedence record is suppressed, then all successive records are considered suppressed as well. For the successive record, the flag is considered only if a precedence record isn’t suppressed.

        It means, that in cases attached
        • if result="suppress" then suppressFromDiscovery=true
        • if result="discoverable" then suppressFromDiscovery=false
      • Location name logic: use discoveryDisplayName from Location if it isn't empty or regular name otherwise.
      • Public notes logic: 'Staff only' (where true) notes should be ignored

      Acceptance criteria:

      • New API is introduced
      • All fields from response example.json are added to the /inventory-hierarchy/items-and-holdings response
      • Fields values comply with the appropriate logic described

      TestRail: Results


          Issue Links



                oyatsenko Oleksandr Yatsenko
                Anastasiia Zakharova Anastasiia Zakharova (Inactive)
                0 Vote for this issue
                2 Start watching this issue



                  TestRail: Runs

                    TestRail: Cases