Sprint Goal / Focus
Sprint Schedule
- Sprint: 186
- Start Mon 4 Feb 2024
- Finish Fri 15 Mar
- Sprint Board
- Jira Sprint: 110
- Sprint Report
- Release: 2024.1 Quesnalia
- Sprint 11 of 11 since Release Development Cycle Starts (Sprint 176) to Feature Freeze (Sprint 186: 15 Mar 2024)
- Sprint 187: Module Release Deadline (22 Mar 2024) [FOLREL-565]
- Sprint 189: Bugfix Release Deadline (19 Apr 2024) [FOLREL-581]
Development Meetings
- Wed 6 Mar - dev update
- Mon 11 Mar - backlog review
- Wed 13 Mar - dev update
Sprint Capacity
Team Availability: Schedule | Calendar
Notes / Exceptions:
Lead Roles:
- Code Review: Ethan Freestone
- QA: Owen Stephens
QA Environment:
- folio-snapshot, folio-snapshot-2
Present
Info | ||
---|---|---|
| ||
|
Navigation
Table of Contents |
---|
Expand | ||
---|---|---|
| ||
|
Sprint Planning
- not in sprint
or @ - in sprint
- not ready
- pending triage / planning
Sprint Focus
Info | ||||
---|---|---|---|---|
| ||||
|
Issue ID | Sprint Backlog? | Notes / Estimates / Actions | Carried Over | ||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||
| TBC
|
| |||||||||||||||||||||||||||||||||||||||||
| Claudia Malzer | ||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||
Components and Changes
Tests / Data / Dependencies Known Unknowns QA: snapshot | local | testing | other
| TBC
| ||||||||||||||||||||||||||||||||||||||||||
| 1910
| Sprint 180 |
| ||||||||||||||||||||||||||||||||||||||||
| subtle |
Jira Legacy | | server | Sprint 182 |
| |||||||||||||||||||||||||||||||||||||
| 3130Monireh Rasouli |
|
| Sprint 180 | |||||||||||||||||||||||||||||||||||||||
|
| Sprint 182 | |||||||||||||||||||||||||||||||||||||||||
| Jack Golding | Environment set up Ready to progress To follow ERM-3131
| Monireh Rasouli |
| Sprint 182 | ||||||||||||||||||||||||||||||||||||||
| Jack Golding | Environment set up Ready to progress To follow ERM-3131
|
| Ethan Freestone | Next up ...
|
| |||||||||||||||||||||||||||||||||||||
| Claudia Malzer | Progress:
TODO:
|
| ||||||||||||||||||||||||||||||||||||||||
| Ethan Freestone | Next up ...
| |||||||||||||||||||||||||||||||||||||||||
|
|
| Ethan Freestone
|
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Progress:
- Description not shown in Edit
- No related console errors
- Same even without changes made
TODO:
- Add log debug
- Check libraries that are using focus logic
- look into when states are changed
- memo-ise line 49 in React useCallback
- pull line 48 out into another React useCallback
TODO: Needs code review
Grails Track
- Changes not been successful
- Push latest wip SEC and ui-dashboard branches
- Review after lunch with Ethan
- pulled back in as resolved
- swapped implementation to import form directly and then render logic handling hook
- component and hook in place in SEC
- implemented in dashboard/widgets
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
|
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
- Currently does not seem to be a candidate for Poppy CSP, Quesnalia or a backport to Orchid
- Need to determine what approach we might take to provide case insensitive sorting
Jira Legacy | |||||
---|---|---|---|---|---|
|
|
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
|
TODO: Needs code review
- Needs some followup with Steve
Grails Track
- Success with compiling and running with Grails 6
- However, JobRunner is not behaving as expected:
- unchanged between 5 and 6
- but jobs are not being picked up
- probably an unnecessary transaction that has been added and is now scoped
- JobRunner triage indicates some client level tasks need tenant scope
- These can fail silently
- TODO:
- diagnose cause of JobRunner fail
- review areas where this may similarly occur (is this a job issue or pattern issue)
- whether this affects beyond mod-0agreements: unlikely as it is related to federation interface with databaseissue)
- UNKNOWN
- whether this affects beyond mod-0agreements: unlikely as it is related to federation interface with database
- Running out of resources when running harvest on local branch
- Not reproduced on master, so using that with postgres to get some perfomance data to compare
- mod-agreements
- compiles, builds, run
- harvest begins, but goes from 20% CPU usage to 30-90 before climbing to 1005%
- could be a local laptop issue
- dev note: set up new application.yaml for an isolated pg/kafka environment to test performance
Jira Legacy server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key ERM-3111 Jira Legacy server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key ERM-3089 Jira Legacy server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key SI-34 Jira Legacy server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key SI-38 Jira Legacy server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key ERM-3090
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Status | ||||||
---|---|---|---|---|---|---|
|
Sprint 176
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Status | ||||||
---|---|---|---|---|---|---|
|
Sprint 178
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Status | ||||||
---|---|---|---|---|---|---|
|
Sprint 178
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Steve Osguthorpe
Status | ||||||
---|---|---|---|---|---|---|
|
Sprint 180
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Status | ||||||||
---|---|---|---|---|---|---|---|---|
|
Triage
- previously created new Grails 6 project and incrementally added components
- once pitfalls identified, each module took very little time
- Approach
- will starting up a new grails project with the CLI even work?
Components and Changes
Frontend
Backend
Tests / Data / Dependencies
- gradle upgrade is necessary
Known Unknowns
- will starting up a new grails project with the CLI even work?
QA: snapshot | local | testing | other
- Release Target:
Development Estimate
- Current:
- grails and gradle versions determined
- web-toolkit passing tests
- smoother process than 4 to 5, but integration is inevitably
- TODO
- service-interaction failing
- need to build into okapi environment
- may need to rebuild rancher, which could be risky at the moment
- review migrations, but difficult to triage atm
- Release candidate for Grails 6 and okapi ready
- Should be ready to move forward
- Once merged, cannot backport to Poppy
Sprint 182
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Status | ||||||
---|---|---|---|---|---|---|
|
enforceVersionCheck
is taken from grails default rest controller - not sure of impact to changing from false to true- can add to to yaml without changing default to false
- would need to make changes to KIWT restful controller
- need to push version numbers
- likely not to be rolled in until Grails 6
- TODO:
- Jack to write up findings
- Owen to review with users
Sprint 178
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Sprint 178
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Sprint 173
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Sprint 179
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Triage
- FOLIO session-level
- Approach
- review implementation across other apps
- eg, Orders,
- eg, stripes-smart-components
useColumnManager
- can this be used as-is within ERM or does it need streamlining?
- review implementation across other apps
Components and Changes
Frontend: TBC
Backend: none
Tests / Data / Dependencies: ??
Known Unknowns: ??
QA: snapshot | local | testing | other
- Release Target: Quesnelia
Development Estimate: ??
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Triage
- NamedThreadFactory is used in string templating service
- out of end-of-life support, so should find a way to upgrade/remove
- Approach
- need to review any documented upgrade path - is there a straightforward path to go from 2 to 3
- are we vulnerable to the jetty-io vulnerabilty?
- influences backport requirements (esp Orchid which is on Grails 4)
Components and Changes
Frontend: NA
Backend:
Tests / Data / Dependencies
Known Unknowns
- whether we are affected by virtue of using netty
QA: snapshot | local | testing | other
- Release Target:
Development Estimate
Current:
- upgrade path documentation doesn't help
- looks like (via grep) this is the only use of ehcache
Sprint 182
- need to decide whether to bail ehcache to use another NamedFactory provider
- potentially could do this internally, without another dependency
- run
gradle clean
and check dependencies to see if ehcache/jetty-io are brought in transitively - CONFIRMED on v2
Sprint 183
- Current
- NamedThreadFactory doesn't seem critical or fancy
- and it looks like it's only in mod-agreements
- inclination is to create own version
- TODO:
- check with Steve
- is ehcache being used elsewhere?
- can we sue our own thread factory
- try ehcache 3
- check with Steve
- Decision on way forward by Wed 24 Jan
Sprint 182
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Not vulnerable
Triage
- need to revisit what choice we made for Poppy
- need to check whether Orchid/Poppy have the same vulnerability to determine backport requirement
- otherwise to be dealt with (for Quesnalia) by Grails 6 upgrade
- Approach
Prefer not to patch grails, but should be able to bump data-bindingTry 4.1.3, then 4.1.2, then 4.1.1Otherwise will need to change databindings specifically - which will be messyOwen: release plan
Components and Changes
Frontend: NABackend: mod-agreements, mod-licenses, mod-service-interactionshouldn't need grails-okapi or KIWT
Tests / Data / Dependencies
Known Unknowns
what's the minimum version that has the fix?confirm that grails-okapi and KIWT do not need bumping
QA: snapshot | local | testing | other
dev: does it compile and run as expected?regression testing
- Release Target: NA
Development Estimate: NA
Sprint 182
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Triage
- fetch of loadMore is causing cache of what's opened to refresh
- fetch is at rootLevel, so redraw pushes a different set of lines
- which may be because of batch fetching PO lines
- redraw closes and remounts
- fetch of loadMore is causing cache of what's opened to refresh
- Approach
- needs investigation to understand chain of events leading to invalidation or refresh
- what's the trigger?
- is there a quick fix?
- if not will need a refactor of PO line fetch handling
- Owen to revisit whether this is an issue in current versions
- needs investigation to understand chain of events leading to invalidation or refresh
Components and Changes
Frontend: ui-agreements
Backend: NA
Tests / Data / Dependencies:
- none for now, potentially add to testrails catalog
Known Unknowns
- then need to decide what's desirable behaviour - do we need to retain the user's view or reset it post-redraw?
- if we don't then any data changes won't be reflected
- if we do, we need to develop a reusable component for consistency across apps
- then need to decide what's desirable behaviour - do we need to retain the user's view or reset it post-redraw?
QA: snapshot
- Release Target: Quesnelia (no backport)
Development Estimate
Sprint 182
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
- Not clear how to verify
- Need to follow up with Molly
Sprint 182
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Approach
- set up new open source project in K-Int gitlab
- new micronaut service required (not using okapi or grails)
- set up a test instance
- will need a different dev workflow (probably using local copy of service)
- working title: pushkb
- avoid storing caches of transient data
Components and Changes
Frontend: na
Backend: new
Tests / Data / Dependencies
- Align to when GBV start testing and using pushkb endpoint
- ERM-3048 Possible package schema changes with endpoint changes
Known Unknowns
- should be (but not clear yet) about TitleInstance Resolver
- packageSchemaUpdater: potential conflicts when there are multiple copies of schemas in play where backwards compatibility is broken
QA: snapshot | local | testing | other
- Release Target: Quesnalia
Development Estimate
- Current State
- pushKb can make a scheduled call (1s, 1h) to Gokb
- will fetch roughly ~700k TIPPS
- Stores these in a local postgres db
- proteus json transform implemented with proof of concept schema
- TODO
- scaling
- extensive transformation testing
- write fetch chunks and push to FOLIO,
- implementing algorithm to ensure no data gaps
- deciding what to do with the data volume (700k feels beyond FOLIO's performance capability)
- at a minimum: need to move the FOLIO side to being not an open http request per chunk (would be killed by okapi), by, eg,
- small batch sizes? would take full day for initial ingest
- speeding up FOLIO? (not clear how this could be done)
- move pushKb to background thread (like jobs, but on a much smaller scale)?
- Constraints
- want to avoid jobs being badly interrupted by a docker container being restarted
- tradeoff is that we have a slower but more stable process
- Development Estimate
Sprint 183
- Current State
- modelling in place for setting up destinations, and links to
- improved bootstrapping
- working on algorithm to extend source record handling from single to process queue of source records without gaps and error handling
- TODO
- scaling
- extensive transformation testing
- write fetch chunks and push to FOLIO,
- implementing algorithm to ensure no data gaps
- deciding what to do with the data volume (700k feels beyond FOLIO's performance capability)
- at a minimum: need to move the FOLIO side to being not an open http request per chunk (would be killed by okapi), by, eg,
- small batch sizes? would take full day for initial ingest
- speeding up FOLIO? (not clear how this could be done)
- move pushKb to background thread (like jobs, but on a much smaller scale)?
- set up api rather than write straight to db
- scheduling
- cleanup
- then: devops work to make releaseable
- then: reciprocal changes to mod-agreements
- Constraints
- want to avoid jobs being badly interrupted by a docker container being restarted
- tradeoff is that we have a slower but more stable process
- Development Estimate (to minimum):
- Functional: end of Sprint 184
- Agreements Work:
- DevOps: need input from Steve and/or Ian (from start of Sprint 185)
- Release:
- Quesnalia - balance pushKb with mod-agreements interop
- Unknown:
- can we use snapshot to test this>?
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Triage
- needs some investigation work
- priority is for GOKb
- Approach
Components and Changes
Known Unknowns
- how do we want to track (count) the external (remote) counts?
- In the XML for the package rather than database
- once the package XML is in hand, count all TIPPs with status=current
- where do we want to populate from in other cases?
- how do we want to track (count) the external (remote) counts?
QA: snapshot | local | testing | other
- Release Target:
Development Estimate
Sprint 184
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Status | ||||||
---|---|---|---|---|---|---|
|
Deferred to BugFest environment setup (week of 25-29 Mar)
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Status | ||||||
---|---|---|---|---|---|---|
|
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Status | ||||||
---|---|---|---|---|---|---|
|
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Deferred to Sprint 186. No progress expected. Dev on vacation until Sprint 186.
Approach
- see comment on issue
- Components and Changes
Frontend: stripes-erm-components
Tests / Data / Dependencies
- new unit test to set up form and presents close as expected
- Known Unknowns: NA
QA: snapshot
- Release Target: Quesnelia
Development Estimate: <2d
- Progress
- still issues with submit dates
- react x finalform
- feels like minor gain for the effort
- TODO
- Share branch with stripes and ask for input
- De-prioritised
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Issues with frontend delaying start.
Cannot see changes on the frontend.
- Parked in favour of serials management tests
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Status | ||||||
---|---|---|---|---|---|---|
|
Triage
- is this the kind of issue that pr707 is meant to have fixed?
- review log file against pr707 zombie job
- check that jobs are not stuck, just queued?
- Approach: subject to investigation findings
Components and Changes
Frontend
Backend
Tests / Data / Dependencies: NA
Known Unknowns:
check with GBV if restarting mod-agreements is viable workaroundQA: NA
- Release Target: Quesnalia
- not expecting to backport, as restart may be viable workaround
Development Estimate
- Issues tracking this back to federation service
- Need to revisit the pulse after zombie job changes
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Status | ||||||
---|---|---|---|---|---|---|
|
- Does title count need to be fetched also?
- NO see ERM-3141
- BUT test that it is fillable with a dummy number
- Does this need to be Nullable? YES
- Update integration tests: glob this to related package schema tests
- Then ready for Code Review
Optimisation on ingest
Triage
- Approach
- Review which queries are affected to confirm that the branch is correct and complete
- All ingest queries on branch are changed, but need to be refactored
Components and Changes
Frontend
Backend
Tests / Data / Dependencies
Known Unknowns
QA: snapshot | local | testing | other
- Release Target:
Development Estimate
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
-
- Bug: clean up situation where log error causes downstream null pointer exception
- clean up for query optimisation
- title rename
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Triage
- Approach
- revert locked changes and add fallback (ERM-3151)
- add query (ERM-3148)
- investigate triplicate error message
- remove the match key modelling (ERM-3153)
Components and Changes
Frontend
Backend
Tests / Data / Dependencies
Known Unknowns
QA:
- harvesting on snapshot and snapshot-2
- initially all on live. then review
- Release Target: Quesnalia
Development Estimate
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Mockup drafted
Unlikely to be the desired solution ahead of other performance priorities
Defer to Ramsuns
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Status | ||||||
---|---|---|---|---|---|---|
|
Triage
- Query is slow because it has to count all resources every time we display agreement line, which is every time we display agreement
- May also affect title lookup
- Approach
Components and Changes
Frontend: NA
Backend: mod-agreements
Tests / Data / Dependencies
Known Unknowns
QA: snapshot
- Release Target: Quesnalia
Development Estimate
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Triage
- Approach
- Extends the work on marking a job as interrupted
- Closes loop on job interruption to mark data source as released ("idle")
Components and Changes
Frontend: NA
Backend: mod-agreements
Tests / Data / Dependencies: NA
Known Unknowns: NA
QA: dev
- Release Target: Quesnalia
Development Estimate: Wed
Closed as tested by dev. Not reproduceable for QA.
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Status | ||||||||
---|---|---|---|---|---|---|---|---|
|
Fixed by
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Pending release of STCOM
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Triage
- Approach
- changes needed to OAI-PMH adaptor
- need to parse xml to count states
- to test:
- run harvest locally from gokb-live until seeing a couple of the big packages (should take ~30 minutes)
- compare with old to make sure consistently handled
Components and Changes
Frontend: NA
Backend: mod-agreements
Tests / Data / Dependencies: NA
Known Unknowns
- best way to count in xml? needs some research by dev
- is there a cursor to point to on gokb-live
- OS to add example to ticket
QA: snapshot
- Release Target: Quesnelia
Development Estimate
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
- confer with II about deprecation
Tests
Cypress test development stalled pending implementation of
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Issue ID | Sprint Backlog? | Notes / Estimates / Actions |
---|---|---|
Release Tasks (Non-Flower Release)
Issue ID | Sprint Backlog? | Notes / Estimates / Actions |
---|---|---|
Release Tasks (Orchid CSP)
Issue ID | Sprint Backlog? | Notes / Estimates / Actions |
---|---|---|
NA |
Release Tasks (Poppy Bug Fix)
Issue ID | Sprint Backlog? | Notes / Estimates / Actions |
---|---|---|
NA |
Maintenance
Issue ID | Sprint Backlog? | Notes / Estimates / Actions |
---|---|---|
NA |
Changes
Added
Removed: note whether rescheduled or deferred
Feature ID | Issue ID | Change | Notes |
---|---|---|---|
Add column select functionality to selected MCL cases | Example: ui-orders Approach:
| ||
Sprint Summary
ERM
Jira Legacy | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Dashboard
Jira Legacy server System JIRA columnIds issuekey,summary,issuetype,assignee,status,components columns key,summary,type,assignee,status,components maximumIssues 20 jqlQuery labels = dashboard and Sprint = 2104 serverId 01505d01-b853-3c2e-90f1-ee9b165564fc
Other
Jira Legacy | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
No Label
Jira Legacy | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|