Agreements (UXPROD-573)

[UXPROD-1943] Export full Agreement including orgs, license and resources Created: 06/Aug/19  Updated: 16/Sep/20  Resolved: 16/Dec/19

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q1 2020
Parent: Agreements

Type: New Feature Priority: P3
Reporter: Owen Stephens Assignee: Owen Stephens
Resolution: Done Votes: 0
Labels: erm, po-mvp, team-mvp
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original estimate: Not Specified

Attachments: XML File kbplus_sample_subscription_license_export.xml    
Issue links:
Defines
is defined by ERM-376 Export full Agreement as JSON Closed
Relates
relates to ERM-710 Add eholdings resources to Agreement ... Draft
Sub-tasks:
Key
Summary
Type
Status
Assignee
UXPROD-1979 Story elaboration Sub-task Closed  
Epic Link: Agreements
Development Team: Bienenvolk
PO Rank: 85
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R4
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R4
Rank: GBV (MVP Sum 2020): R1
Rank: Lehigh (MVP Summer 2020): R4
Rank: U of AL (MVP Oct 2020): R4

 Description   

To support requirements for GBV members which go beyond export built for UXPROD-1517 Closed

To fully support all their use cases GBV wish to be able to export a full agreement including all agreement data plus information on linked organisations, licenses and resources



 Comments   
Comment by Benjamin Ahlborn [ 27/Sep/19 ]

(on the assumption, that we will have a JSON schema which can map one-to-many license terms)
I have tried to use the current (Daisy) agreement export to create items in GBV union catalogue, and from the obvious gaps I hope we will get a fair idea how "full Agreement export" could look like.

  • License Terms: Term->Value, visibility, public note (internal note = optional: we use it to copy relevant parts from the legal text for easy reference, but you may not want to show this to the public)
  • Organisation ID of the tenant/library to which the data pertains (current Agreement export has no information about the tenant. If you want to batch process exports for multiple tenants by 3rd party, e.g. VZG, you must be able to map to the user in the target database).
  • ID and roles of the organisations involved (may not be the same as provided by package/platform, eg. consortium vs. publisher)
  • Agreement ID (not package ID) is needed to bullet proof identify existing items for update
  • AgreementStartDate/AgreementEndDate (e.g. if you want hide/unhide agreements Jan 1st)
  • Do titles inside an agreement still have an individual ID (TIPP in GOKb?). These IDs would have more potential use then the redundant IDs for identifier namespaces in the current agreement export.
    I have attached a "full" export in XML from a legacy KBplus subscription which worked fine for our needs.
Comment by Benjamin Ahlborn [ 30/Sep/19 ]
  • Information in fields "Active from/Active to"
Comment by Marie Widigson [ 10/Dec/19 ]

Will this export also work when using eHoldings? Khalilah Gambrell

Comment by Khalilah Gambrell [ 10/Dec/19 ]

Marie Widigson, currently the export only includes resources under ""E-Resources covered by this agreement" and not the agreement line itself. So I am writing up a feature to support displaying Agreement line in export.

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