2022-07-14 Meeting notes

Date

Attendees

Discussion items

TimeItemWhoNotes

mod-configuration - should it be deprecated or not?

mod-configuration has been discussed on the development channel recently. Developers like it because they can simply drop variables to the /configurations/entries API. Simply use the "configuration.*" permission shared by all modules and you are done. No need to add schema validation, no need to add dedicated permissions, no need to add a dedicated API.
Drawbacks:

  • A big institution need config write permissions with module granularity. One member of staff may be allowed to edit circulation config but not aquisition config.
  • No validation. mod-configuration cannot validate a POST or PUT request because it doesn't know. Only the module it belong to knows this. Relevant use case: Using curl/wget/postman/...
  • No documentation. mod-configuration has no documentation, one needs to search, maybe the module's README has some? A dedicated module API always publishes the API documentation at https://dev.folio.org/reference/api/
  • Performance. Requests to mod-configuration result in latency. If the config API belongs to the module the module can cache it and can invalidate the cache if the config is changed. Caching requests to mod-configuration will always result in a time period with outdated values. In mod-inventory-storage we've combined fetching the HRID config and HRID generation into a single SQL query.
  • Coupling. Modules should be loosely coupled and therefore each module should store its own configs.


It was requested that a formal RFC/Architecture Decision Record been created if mod-configuration should no longer been used for module-specific configurations.

Team decided we want to have this as a RFC. Target should be to have this implemented within Nolana. Could discuss in your meetings while the RFC process moves on.


Today:

  • Still need an RFC for this.
5 minedge-lti-coursesTeam

edge-lti-courses has been unmaintained since July 2021. Open Jiras:

key summary created updated assignee priority status
Loading...
Refresh

Last updates:

  • No real news here... Erin N. mentioned that she'll raise this with the staff at Duke.  Maybe someone there can support these modules.
  • Let's give it another week and then we might consider to move this out of the folio repo since there is no maintainer
  • We asked Erin N. if there anything new on that
  • Still awaiting response from Duke (Erin).
  • Charlotte Whitt changed MODCR-81 status to "In progress" on 13/Jun/22.
  • No progress, not even for the "In progress" Jira MODCR-81 on July 7.

Today:


Kafka security Team

The topic of Kafka security was raised as part of a conversation at the TC yesterday.  

The Security Team should be aware of this and probably should weigh in on the topic, or even generate proposals if we have ideas for how to solve the problem.

*

Review the Kanban boardTeam
  • There are several JIRAs on our board that haven't moved in a long time (well over a year in some cases...)
    • Do we want to possibly close these as won't do?
    • Craig McNally adjusted the base filter to sort by priority, then updated date, and also added a new quick filter to show only issues that haven't been updated in the last 90 days
  • Core platform teams has prioritized several tickets and will handle them for Nolana: https://folio-org.atlassian.net/secure/RapidBoard.jspa?rapidView=80&view=planning.nodetail&quickFilter=1688&issueLimit=100
  • Regarding file upload size issues (See FOLIO-3317 - Getting issue details... STATUS ), let's brainstorm ideas for mitigating the cumulative upload problem, not just he large file upload size problem.  
    • Some APIs are more vulnerable to this than others, such as those not protected by permissions - e.g. mod-login, edge APIs, etc.

Action items