[ERM-109] Support the ability to create an Agreement from the eholdings app Created: 01/Mar/19  Updated: 08/Apr/19  Resolved: 08/Apr/19

Status: Closed
Project: ERM Platform
Components: ui-agreements
Affects versions: None
Fix versions: None

Type: Story Priority: P3
Reporter: Khalilah Gambrell Assignee: Unassigned
Resolution: Done Votes: 0
Labels: eholdings_integration, erm
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original estimate: Not Specified

Issue links:
Defines
defines UXPROD-1548 Agreements work: EBSCO KB + Agreement... Closed
Gantt End to Start
has to be done after ERM-110 Agreement Detail Record | View attach... Closed
Relates
relates to STCON-78 Add ability to fetch resource conditi... Closed
relates to ERM-168 Display coverage for Agreement lines ... Closed
Requires
is required by ERM-119 Update Agreement Line UI Closed
is required by UIEH-629 Show Package Record: Allow a user to ... Closed
is required by UIEH-631 Show title+package (aka Resource) Rec... Closed
Sub-tasks:
Key
Summary
Type
Status
Assignee
ERM-123 Render the agreement lines in the Cre... Sub-task Closed md331  
ERM-124 Create endpoint to return eholdings a... Sub-task Closed  
Sprint: ERM Sprint 60
Development Team: Bienenvolk

 Description   

As a Librarian
I want the ability to create an agreement and attach an agreement to a package in the knowledge base

Requirement

  • Need ERM dev team to support the ability to create an agreement via eholdings app AND attach the package and title+package to the agreement created
  • eholdings users will have the ability to create an agreement on Package and Title+Package records

See eholdings requirements



 Comments   
Comment by Khalilah Gambrell [ 12/Mar/19 ]

Ian Ibbotson (Use this one) to support UIEH-631 Closed and UIEH-629 Closed , we may need md331 to make some updates.

Comment by Jag Goraya [ 15/Mar/19 ]

There is no current way for sharing data as needed. Two options are being discussed between md331, Igor Godlevskyi and Yurii Danylenko. There are some unknowns to be addressed before we can make a decision or estimate.

  1. Pass eholdings resource id (to pick up from modkb endpoints and translate in Agreements)
    • What endpoints are for what fetch type, and where the data is from?
    • What are the URL query parameters to use (when linking from eHoldings to Agreements)?
  2. Have shared FOLIO-wide state
    • We'd like to see a proof of concept model for what this would look like in ui-agreements
Comment by Jag Goraya [ 19/Mar/19 ]

Hi Khalilah Gambrell - can you confirm the option we're taking for this and assign to the team member best placed to furnish the info needed please? Thx

Comment by Khalilah Gambrell [ 19/Mar/19 ]

Igor Godlevskyi and Yurii Danylenko, can one of describe what has been agreed upon to implement this story? Also does md331 know which mod-kb-ebscojava endpoints he will us?

Comment by Igor Godlevskyi (Inactive) [ 19/Mar/19 ]

Hi Khalilah Gambrell, as we discussed we would stick to the 1st option for now as it is currently a "folio way" and the 2dn option will require some time for the spike/investigation.

Regarding the 1st aproach:
We can pass basically the id's in the URL like: resource=[resourceId]

Regarding the endpoints for md331,
mod-kb-ebsko-java endpoints could be found here: https://dev.folio.org/reference/api/#mod-kb-ebsco-java

Just need to find the modkbebskojava section. And check the view1 links.

Comment by Sobha Duvvuri [ 19/Mar/19 ]

This might be additional information but ids in eHoldings are a combination :
For providers ->

{providerId}

For packages ->

{providerId-packageId}

For resources ->

{providerId-packageId-titleId}

While it may be fine as a first step on ERM's side to save the complete id and corresponding agreement information in the data model, for another requirement of displaying all associated agreements of a provider, ERM might also want to consider a data model for saving relationship between providerId and all agreements associated with that providerId for eHoldings to be able to fetch all agreements associated with a provider. There might be another user story associated with this though.

Comment by md331 (Inactive) [ 19/Mar/19 ]

This is still not super clear to me. Here's my understanding for what the ui-agreements code will do when the Create Agreement page loads. I'm basing this off of going through the eholdings code.

  1. Look at the query string and pull off the resource parameter and save the value. (Let's call it resourceId.)
  2. Fetch /eholdings/resources/[resourceId]
  3. Render the agreement line preview based on the response from that.
  4. Push a new item into the agreement's items (entitlements / agreement lines) array that contains the following:
  5. { type: 'external', authority: 'EKB', reference: resourceId }
  6. Continue standard Create Agreement flow.

Please confirm that those steps are correct for both packages/titles.

Comment by md331 (Inactive) [ 19/Mar/19 ]

For step #3 above, we currently render a Name, Type, Titles (count), and Platform.

According to this page, I assume I can pull Name from attributes.name and Type from attributes.publicationType, but I'm not sure about the count of Titles if the added resource is a package.

Also, I don't know what was decided about Platform. Originally I heard to hide it, then I heard that it may map to the Provider (attributes.providerName ?). Owen Stephens or Khalilah Gambrell, do we know what we're doing with that field?

Comment by Sobha Duvvuri [ 19/Mar/19 ]

md331: Yes, the above steps are correct. Just to add some more detail on the specific endpoints to be used for fetching packages/resources, please see below:
Endpoint for getting package - https://s3.amazonaws.com/foliodocs/api/mod-kb-ebsco-java/packages.html#eholdings_packages__packageid__get
Endpoint for getting resource - https://s3.amazonaws.com/foliodocs/api/mod-kb-ebsco-java/resources.html#eholdings_resources__resourceid__get
The additional work that I was talking about in my previous comment is mostly backend. Please don't worry about it now and proceed with your approach above. Thanks!

Comment by Khalilah Gambrell [ 19/Mar/19 ]

md331 - I defer to Owen Stephens on this question: "Also, I don't know what was decided about Platform. Originally I heard to hide it, then I heard that it may map to the Provider (attributes.providerName ?). Owen Stephens or Khalilah Gambrell, do we know what we're doing with that field?"

Comment by Owen Stephens [ 19/Mar/19 ]

md331 I added the list of columns for Agreement lines (going forward) to https://folio-org.atlassian.net/browse/ERM-119 this morning. We need to agree where "Provider" comes from on the ERM/Agreement side - which is a conversation with Ian Ibbotson (Use this one) and me I think.

Comment by Khalilah Gambrell [ 19/Mar/19 ]

md331
Pull "titleCount" for count of Titles.

Comment by md331 (Inactive) [ 19/Mar/19 ]

OK, I'm all clear on the endpoints now.

So the support I'm planning on implementing from the Agreements is that when the Create Agreement page loads, I will look on the query string for two optional parameters:

  • resourceId which will be an eholdings resource id I can use for the /eholdings/resources/[resourceId] endpoint
  • packageId which will be an eholdings package id I can use for the /eholdings/packages/[packageId] endpoint

The data from those endpoints will only be used for the rendering of the agreement lines in the Create Agreement page. Subsequent fetches will be routed via mod-agreements functionality Ian Ibbotson (Use this one) is working on.

The reference key I'm passing in the items array will be the resourceId or packageId I get on the query string.

Igor Godlevskyi, Yurii Danylenko, are y'all on board with those parameters?

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