2020-09-30 ERM Weekly Delivery Update

2020-09-30 ERM Weekly Delivery Update

Meeting Details

Date

Sep 30, 2020 

 

Time

10:30am ET, 3:30pm UK, 4:30pm Germany

Location

Video Call in FOLIO Slack: #erm-developers

Goals

Participants

  • @Jag Goraya

  • @Peter Böhm

  • @Ethan Freestone

  • @Aditya matukumalli

  • @Owen Stephens

  • @Claudia Malzer

  • @Gill Osguthorpe

Apologies

Discussion items

Previously: 2020-09-23 ERM Weekly Delivery Update

Time

Item

Notes

Action Items

Time

Item

Notes

Action Items

<5 mins

Introductions

 

 

WIP Update / Sprint Cutoff

Release Candidates

Code Review: 

QA / UAT 

Items at Risk / Spillover

In Progress

Sprint Backlog

  • https://folio-org.atlassian.net/browse/ERM-1125

    • Conclusion: 

      • closures are not an option

      • cannot guarantee security requirements with current technical circumstances

    • Alternatively:

      • groovy templating engine with java handlebars, through which security is built-in 

      • explicit helper registration is needed

      • at first pass - could do pre-defined (given) proxies, but not offer user-extensible (custom) methods

        • use cases that can be built or delivered in the first instance are

          • direct replace (match all or first, full or partial)

          • insert characters

          • remove characters

        • TODO: add pseudo-templates to given use cases

      • going forward, still need to address security around user extensible urls if customisation is needed

    • Default behaviour where proxy has been defined for a platform is to use the proxy, rather than require explicit per-instance user confirmation

      • firing this at PTI level should work, as this has access to the necessary platform fields

      • this will allow the proxy map to be built

  • https://folio-org.atlassian.net/browse/ERM-1123

    • expected to be ready for code review today

Blocked

  • NA

Needs Elaboration

 

<10 mins

AOB

https://folio-org.atlassian.net/browse/ERM-1114

  • Hotfix cannot be released because Goldenrod uses Agreements 2.x rather than 3 which the change needs to be made with

  • Issue will be closed as Won't Fix, with recommendation to users to not duplicate agreements with supplementary documents

  • Potential interim workaround that could be developed is to prevent access to the functionality - this is not a priority development option. 

  • Fix will be introduced to Honeysuckle, but institutions will need to upgrade.

 

Frontend Tests

  • more tests required for agreement line creation

  • Adi to create Jira