Uploaded image for project: 'ERM Platform'
  1. ERM Platform
  2. ERM-2923

Add created/updated metadata for Resources in local KB

    XMLWordPrintable

Details

    • ERM Sprint 166, ERM Sprint 167, ERM Sprint 168, ERM Sprint 169, ERM Sprint 170, ERM Sprint 171, ERM Sprint 173, ERM Sprint 174, ERM Sprint 175, ERM Sprint 176
    • Bienenvolk
    • Poppy (R2 2023)
    • TBD

    Description

      Purpose:

      To enable users to easily identify resources that have/have not changed in the local KB within a time period, support the created/updated metadata (as already supported on Agreements and elsewhere). Include display of the metadata.

      Implementing searches based onthis data will be the subject of a separate story

      User story statement(s):

      As a e-resource librarian
      I want to see the date and time that a resource was created/updated
      so that I can easily tell when a resource was created/updated

      Scenarios:

      1. Scenario:
        • Given a new resource
        • When the resource is created
        • Then the date and time of creation will be recorded
        • AND the date and time of update will be recorded¬†
      2. Scenario:
        • Given an existing resource
        • When the resource is updated
        • Then the date and time of the update will be recorded
      3. Scenario:
        • Given a Package in the local KB
        • When I view the package in the UI
        • Then the updated/created metadata display will be included under the main heading (as used elsewhere in the app)
      4. Scenario:
        • Given a Title in the local KB
        • When I view the title in the UI
        • Then the updated/created metadata display will be included under the main heading (as used elsewhere in the app)
      5. Scenario:
        • Given a PCI in the local KB
        • When I view the title in the UI
        • Then the updated/created metadata display will be included under the main heading (as used elsewhere in the app)

      Additional information

      If we consider resources in the local KB to have a hierarchy then a change to something lower in the hierarchy should be considered an update to any objects above it in the hierarchy and therefore result in the last updated date/time being updated. The hierarchy being (top to bottom)

      Package -> PackageContentItem -> PlatformTitleInstance -> TitleInstance

      Updates to a Coverage should result in an update to the last updated date on the object to which the coverage applies

      Updates to an identifier should result in an update to the last updated date on the object to which the identifier applies

      The requirements for objects to count as updated on changes to identifiers/coverage should be put to one side for the moment, but we should not remove any logic that is already in place unless something in our changes causes issues with that existing logic

      Testing notes

      Make sure to test situations where a sync/package ingest happens but there is no actual update (i.e. nothing changes) - ensure that last updated date not changed in that case

      TestRail: Results

        Attachments

          Issue Links

            Activity

              People

                ostephens Owen Stephens
                ostephens Owen Stephens
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  TestRail: Runs

                    TestRail: Cases