[FOLIO-3954] Merge mod-notify, mod-sender, mod-email and/or mod-batch-print Created: 16/Jan/24 Updated: 06/Feb/24 |
|
| Status: | Draft |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Tech Debt | Priority: | TBD |
| Reporter: | Julian Ladisch | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | architectural | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Sprint: | |
| Development Team: | Volaris |
| RCA Group: | TBD |
| Description |
|
At least some of mod-notify, mod-sender, mod-email and mod-batch-print should be merged into a single module while keeping the existing API endpoints. There is no need for such tiny modules. Each additional module takes significant additional resources when deployed, and requires significant paperwork for releases. The modules are too granular. No reason for this granularity has been shown:
Lines of code as reported by Sonar (click link to open Sonar report):
mod-batch-print design document: https://folio-org.atlassian.net/wiki/display/FOLIJET/mod-batch-print
|
| Comments |
| Comment by Charlotte Whitt [ 05/Feb/24 ] |
|
Julian Ladisch Jakub Skoczen Jenn Colt Kirstin Kemner-Heek - I’m not sure why this ticket has been created, and why it’s linked to https://folio-org.atlassian.net/browse/TCR-33. Maybe the Volaris team one day will be able to pick up the work merging those four small modules, but for the mod-batch-print module to be approved, it’s completely out of scope to do this work. This work https://folio-org.atlassian.net/browse/FOLIO-3954 might be something the FOLIO project will do when the app and platform consolidation work is being implemented - BUT not now for Quesnelia! |
| Comment by Julian Ladisch [ 05/Feb/24 ] |
|
Hi Charlotte, this ticket has been created because the modules are too granular, this is technical debt. The new module mod-batch-print increases the technical debt and therefore TCR-33 is linked to this issue. This issue is in state “draft” and doesn’t have a target flower release, therefore it’s NOT scheduled for Quesnelia. Why do you assume it might be scheduled for Quesnelia? From the Module Technical Evaluations:
Therefore this ticket is NOT linked to TCR-33 with “is blocked by”, but only with “relates to”. That way architectual issues found during evaluation are moved out of the way and don’t interfere with the acceptance process. The link redirects people so that the discussions about architectual issues take place in this ticket and not in the module evaluation process. This ticket is kept so that the raised architectural issues are not lost but can be worked on at a later time. Why do you assume the architectual issues might be in scope of the module evaluation? |