Content Comparison

5min

Announcements

Martina Schildt

• Prioritization - adoption of ACQ process

10min

Development progress update

Owen Stephens

• Bug “Handle duplicate IDs in local KB digest” is fixed, but may not be in CSP#10 > Owen is waiting for feedback on this

• upload documents: there are 2 config options

  • store files in database or

  • store files in S3 compatible storage

  • the secret key can be stored safely on server through environment settings now > this feature is in QA

• local KB: user can select to sync packages or pause the sync

• Bug in Agreements: with a single result in result pane, the display is loading over and over again

  • this is known and solution is known

  • team is working on resolving this issue until end of the week

• ERM Sunflower Dashboard: https://folio-org.atlassian.net/jira/dashboards/10485

• Question by UB Freiburg: is Gradle/Java issue been resolved

  • current software versions in use don’t allow needed Java version

  • TC delays requirement until Trillium

• Team is currently using Grails 6 and Java 17

• plan to move away from Grails 6, but that is a large piece of work

• Team may change the framework in use

~15min

eUsage

Stefan Dombek

• New wiki page to get an overview of what is planned in which release. https://folio-org.atlassian.net/wiki/x/BADHLw

• The first meeting to discuss the requirements of exception handling will be in March or April. There will be an invitation via Slack.

• Difference between “eUsage” and “eUsage Reports” and what this means for requirements and development.

  • eUsage has 2 product components.

    • Core component “eUsage” for managing the providers and their statistics. The development of the core component “eUsage” takes place via the DevTeam Leipzig.

      Jira Legacy
      server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-576

    • Additional component “eUsage Reports”, which makes the matching with the KB and also the calculations and visualizations. It is also known as a plugin in agreements, which can be seen as an accordion. The development was coordinated by the SLUB (Cooperation partner) and developed by Index Data as a development contract.

      Jira Legacy
      server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-1253

  • Further development

    • Responsibility for the core component is clear. The Leipzig DevTeam will continue to be responsible for development.

    • The responsibility for the additional component is not yet quite so clear. The SLUB was contacted to enquire about the further development of the additional component. Unfortunately, the SLUB does not have the necessary resources to further develop the additional component, which is why further coordination has been shifted to Leipzig for the time being. It was asked whether the component could be further developed in Leipzig. Unfortunately, there are no resources for technical development in Leipzig either. At the moment, the product owner is only allowed to collect the requirements for it. As there are no resources in Leipzig, the product component is currently on the economic test bench. In the worst case, the component will not be developed further. But there is hope. We recently received a signal from the FOLIO community that someone would be willing to finance and coordinate the further development of the “eUsage Reports” plugin and take over the technical development. But this has not yet been officially and conclusively clarified.

30min

Implementers' topics:

1. Term field values resetting upon changing term types.

2. Filter for agreements that have no “Renewal priority” set

Postponed

3. Adding tags for License Amendments

1. Clara Marino

2. Martina Schildt

3. Irina Trapido (Stanford) - can never attend due to time zone

1. When working on a term, if you put content into either the internal or public notes, or set visibility from internal to public, then changing the term type will also reset all of those fields. It makes sense that the term’s value(s) field would reset, since those can be different for every term, but it’s harder to understand why this is the case for the other fields, and it seems like it could lead to lost work.

Outcome: Requirement is understood. Owen will create a ticket that the ERM SIG can then vote on.

2. Description:

   a user wants to create a Dashboard widget that shows all agreements where the renewal priority is NOT ‘Cancel’. To do this, the user selects the ‘Renewal Priority’ filter and sets it to ‘is not definitely_cancel’

   Current behaviour:

   All agreements are displayed that have a value for the renewal priority that is not ‘Cancel’. However, all agreements that have no value at all for renewal priority are left out.

   Wish:

   1. When listing the data records, also include those that have no renewal priority (empty then counts as a value, so to speak)

   2. Add the option ‘Renewal Priority is empty / not empty’ to the filter options in the widget

Outcome: Requirement is understood and supported by Sara. Owen will create a ticket that the ERM SIG can then vote on.

Postponed

3. Our Licensing Librarian would like to track metadata for each document signed (e.g., signatory, fiscal year, type of purchase, etc.). He wants to record this information at both the license and the license amendment levels. Tags would be ideal for this purpose, but they are currently only available at the license level. Would it be possible to make tags available at the amendment level as well, similarly to how they are available at the Order and Order Line levels, the Agreement and Agreement Line levels?