Uploaded image for project: 'mod-inn-reach'
  1. mod-inn-reach

Record Contribution, Ongoing: Trigger contribution or update of Bibs and Items to INN-Reach central Server



    • Volaris Sprint 131, Volaris Sprint 132, Volaris Sprint 133, Volaris Sprint 134
    • 5
    • Volaris
    • Lotus R1 2022



      After an initial record contribution, mod-inn-reach needs to continue to monitor the creation, update, and deletion of inventory records (instance, holdings, and item) and evaluate them for contribution, if they are not already contributed, update (if some relevant attribute has changed), or de-contribution (if the record has been deleted or no longer qualifies for contribution according to the specified criteria. These actions should be logged in a similar fashion to that used for initial record contribution.


      • When an Inventory instance, holding, or item record is created, evaluate it according to the same process used for initial record contribution and contribute it using the same methods if necessary.
      • When an item record is moved to a new holding + instance, evaluate whether the number of items available for contribution on the associated instance record has changed, issuing a bib status update, specifically the itemCount (D2IR API reference, pg. 37). Alternatively, we can just contribute the same bib record again and it will update the relevant data, as well (D2IR API reference, pg. 29)
      • When an item record has its status updated evaluate using the criteria for determining circulation status at contribution and update¬† its itemCircStatus¬†(and due date, if status is "Checked out") if necessary using either the update item status API (D2IR API reference, pg. 38) or the contribute batch items api (D2IR API reference, pg. 27-28)
      • When a request record is created or closed, adjust itemHoldCount as necessary for associated contributed items (CIRCSTORE-302)
      • Log each evaluation, contribution, and/or update flow occurrence using the same approach as for initial record contribution.

      Acceptance Criteria

      • New instances and items that are eligible for contribution are contributed upon creation
      • Instance and items that become eligible due to a change in their record attributes are contributed within 5 minutes (or after completion of an ongoing initial record contribution job, if necessary)
      • The number of eligible items associated with a contributed Bib record is updated when the number of eligible FOLIO item records associated with an instance changes
      • itemCircStatus is updated when necessary (using the criteria to determine itemCircStatus used for initial record contribution)
      • Item dueDate is updated when an items status is changed to "checked out" or the associated loan is renewed
      • The itemHoldCount is updated when requests on contributed items are created or closed
      • Activities are logged in accordance with existing initial record contribution logging

      Additional Information:

      This functionality needs to be present for record contribution to be complete. We can split it if we need to, but as it's not of much value if only partially completed I think it makes sense to keep it together.


      Provide an api endpoint that accepts a CSV (list of instanceIds), CQL (inventory query) file (like those provided by the Inventory app for use with Data Export) and processes the corresponding records for contribution/decontribution (or update) as Bibs to a specified INN-Reach central server (specified by INN-Reach central code, or all configured central servers if no code is specified) using the existing transformation process (MODINREACH-48). The endpoint should also provide a flag to only update Bib status (itemCount and titleHoldCount). Module should create a queued job to process the request asynchronously and return a reference to that for later status retrieval.


      • Endpoint should accept (via POST) a properly formatted CSV or CQL file, as currently provided by the Inventory UI app for use in the Data Export app
      • Endpoint should require a central server code be specified to direct the module as to which central server to contribute records to
        • Implementation Detail: URL path argument or query parameter?
      • Calls to this API should create a queued job and return a reference to that job for later status and log retrieval as its response (MODINREACH-51)
      • Endpoint should accept an optional parameter to direct the module to only update (titleHoldcount, itemCount) already-contributed Bibs from the provided set of instances

      Acceptance Criteria:

      • AC: The endpoint accepts a CSV or CQL file that conforms to the file specification provided by the Inventory app for use in Data Export
      • AC: The endpoint successfully creates a queued job based on the provided file and parameters
      • AC: The endpoint returns a reference to the created queued job if created
      • AC: The endpoint provides meaningful error messages if unable to create a queued job successfully

      TestRail: Results


          Issue Links



                brookstravis Brooks Travis
                brookstravis Brooks Travis
                0 Vote for this issue
                3 Start watching this issue



                  TestRail: Runs

                    TestRail: Cases