Backlog Grooming Sprint 27
Objective: to continue addressing critical bugs (performance and major UI issues)
Reference UI
NR: These will make working with the UI easier
https://openlmis.atlassian.net/browse/OLMIS-2509 - NR: Is this a dupe of OLMIS-2328
https://openlmis.atlassian.net/browse/OLMIS-2573 - NR: This should be fixed in OLMIS-1693
Stretch:
https://openlmis.atlassian.net/browse/OLMIS-249 - NR: Angular strap has hard coded string, might need another library
Requisition
Working on 3.1.5-SNAPSHOT (the incoming changes due to performance issue will most likely result in version 4.0.0 being the case)
@Brandon Bowersox-Johnson to create a ticket to (coordination and fixes on both the UI and endpoints and even other things) to either reduce requests and decreased payload. @Brandon Bowersox-Johnson were you able to create this ticket, is it either 2565, 66, 84, or 33?
https://openlmis.atlassian.net/browse/OLMIS-2565 (Which Malawi bugs does this address? A: Requisition load time)
https://openlmis.atlassian.net/browse/OLMIS-2566 (Q: Solution for this will probably be the same as for https://openlmis.atlassian.net/browse/OLMIS-2584) (Which Malawi bugs does this address? A: Requisition view/approve/convert to order)
Make sure to reference the related Malawi bugs https://openlmis.atlassian.net/browse/MW-232https://openlmis.atlassian.net/browse/OLMIS-2533 (Q: proposed solution in comment)
(In addition to what Łukasz included in his daily report on timeouts - we have increased the maximum execution time, but this is a temporary workaround. The requests already take too long time for certain things (especially reports since they usually require a lot of data). The root reason is requisition related endpoints returning a lot of unnecessary data - I've created a ticket for this in core (OLMIS-2533) but if it becomes problematic quickly we may need to fix it ourselves and contribute this to the core product - Sebastian 5/17)Remove previous requisition history
Do BA work to decide what is actually needed (where/when)
FYI, the Malawi logged bugs https://openlmis.atlassian.net/browse/MW-164,https://openlmis.atlassian.net/browse/MW-165,https://openlmis.atlassian.net/browse/MW-166,https://openlmis.atlassian.net/browse/MW-167, MW-171.
https://openlmis.atlassian.net/browse/OLMIS-2543 (@Brandon Bowersox-Johnson, does this need further directions?)
OLMIS-1133 (NR: Can we make a ticket to gather requirements/design/socialize this issue?)
Reference Data
Will be working towards 6.0.1
https://openlmis.atlassian.net/browse/OLMIS-2574
https://openlmis.atlassian.net/browse/OLMIS-2536 This endpoint should filter the facilities (this is a dependency for MW-170)
https://openlmis.atlassian.net/browse/OLMIS-2494
https://openlmis.atlassian.net/browse/OLMIS-2277 (Q: Do we want front-end validation? A: Yes)
https://openlmis.atlassian.net/browse/OLMIS-2292
https://openlmis.atlassian.net/browse/OLMIS-2385 (very small)
https://openlmis.atlassian.net/browse/OLMIS-2384 (very small)
https://openlmis.atlassian.net/browse/OLMIS-2495
Stretch:
https://openlmis.atlassian.net/browse/OLMIS-2552 (likely shouldn't pick this up, if we did, Reference Data would be working on v7.0.0 - the next major release)
Fulfillment
https://openlmis.atlassian.net/browse/OLMIS-2551
https://openlmis.atlassian.net/browse/OLMIS-2532
Platform
https://openlmis.atlassian.net/browse/OLMIS-2147
Stretch Goal:
Stock Management: Change it from Hibernate to Flyway before our next/non-beta release (or move this to Grooming 28?? Team ILL)
Stretch:
https://openlmis.atlassian.net/browse/OLMIS-2574
Reporting
Roll-over from last sprint.
Issues Discovered During Malawi UAT
https://openlmis.atlassian.net/browse/OLMIS-2584
https://openlmis.atlassian.net/browse/OLMIS-2585
https://openlmis.atlassian.net/browse/OLMIS-2586
https://openlmis.atlassian.net/browse/OLMIS-2587 (Q: As far as we remember this was the desired behavior. Do we want to clear the table when changing requisition type/any input value?) A: Waiting for OLMIS-2554
https://openlmis.atlassian.net/browse/OLMIS-2588 (Q: What is the status of this ticket?) A: Will be dead after OLMIS-2476
https://openlmis.atlassian.net/browse/OLMIS-2548
Team ILL
https://openlmis.atlassian.net/browse/OLMIS-2578
https://openlmis.atlassian.net/browse/OLMIS-2581
https://openlmis.atlassian.net/browse/OLMIS-2580
https://openlmis.atlassian.net/browse/OLMIS-2582
Contract testing dev-wide short presentation (see a few ideas on retrospective)
15-minute design meetings after stand-up (do not need a ticket for this; but we will pilot this idea during Sprint 27)
Stretch goals:
https://openlmis.atlassian.net/browse/OLMIS-2590
Performance Testing of key endpoints (find the ticket for it)
Refactor so we can accept the batch approve page in requisitions
Comments
PS I added these ticket to the page
@Ben Leibert, do you think we can have the csv uploads contributed back prior to the 3.1 release? fyi @Josh Zamor @Brandon Bowersox-Johnson. It would be nice to have this available for 3.1.
Hi @Mary Jo Kochendorfer. Can you please elaborate on what it would take to "contribute back" the scripts? They're currently in a dedicated repository, without an analog in the core project, so it wouldn't likely entail our typical pull-request.
I mentioned a few weeks ago that @Sebastian Brudziński wrote the scripts and can hold a meeting to give the team an introduction to how they work. (If nothing else is on its agenda, perhaps the Tech Committee call would be a good venue.) If it would be helpful to hold this meeting prior to the targeted 5/25 release date, I think we can do so.
Again, though, please let me know if anything else would be necessary.
Here are my 2 cents to add: The "Malawi Migration Tool" that Ben mentions on the OpenLMIS GitHub is already open source, so that's a good start. I think there are 2 bigger questions:
(1) Is the core team (with BMGF/DHI support) willing to take on on-going maintenance burden of this code? I think it would require some up-front effort to make sure it is all generic (not country specific). Perhaps we would pull apart the CSV import code from the Supply-Chain-Manager-specific code, for example (or maybe that part is already done—just an example). After the up-front effort, it requires on-going effort to keep this tool up-to-date as the OpenLMIS 3 product evolves.
(2) Does the core product want to extent this tool even further to link it into the Admin UIs to admins can upload a CSV through the UI application and have that CSV processed for import? If so, at this point how soon is that on our roadmap compared to Vaccines and other work? If we do this integration of the tool, then the core team would truly need to bite the bullet and become responsible for the on-going maintenance of it.
I'm pleased to say that we have two sets of scripts. The mw-migration-tool was used to pull data from Malawi's legacy SCM database into OpenLMIS. It's probably of no interest to the core team. The mw-refdata-seed script, however, loads the content of CSV files into OpenLMIS and is probably globally useful as-is. Offhand, I can't think of anything country-specific encumbering its use elsewhere.
I appreciate the appeal of officially "contributing back" the mw-refdata-seed tool prior to the 3.1 release. Having thought about it more, it seems this would involve:
1) Stripping "mw-" from the repository's name.
2) Ideally updating some of its namespaces.
3) Giving the team an overview of the tool.
4) Potentially making future changes to the core version of the tool exclusively via pull-request.
Am I missing anything?
Parts 1 and 2 are trivial, and #3 would simply take the length of a meeting. Part #4 may be awkward, though. Sebastian wrote the tool, and can be trusted to avoid making country-specific changes to any version under the core team's ownership. Would we nevertheless require pull-requests of someone billing to the core project?
It's unfortunate that the SCM migration tool was DB to DB. I understand it was due to speed, but it does seem like it'd be useful if we had a generic SCM migration tool.
That aside I think I'd also add to your "contribute back" list:
license and copyright
In the "we adopt" list I'd add:
utilize in demo data load for reference data
analyze performance risk - does it slow down demo data loading
I don't understand what the concern about pull requests are? Timing?
Good point about the license and copyright. Thanks Josh!
It strikes me as inefficient to require that a tool’s author ask someone less familiar with his code to approve minor changes to it. If folks prefer, though, we can certainly make pull-requests for the script just as for the rest of OpenLMIS' primary code. I just want to be clear on the expectations.
Re: pull requests, we just make Sebastian an owner of the tool & repo. So long as he can take on the responsibility of being a lead for this open source component that OpenLMIS relies on, I see no problem.
Okay; thanks again Josh!
@Sebastian Brudziński fyi
Hi @Mary Jo Kochendorfer (Deactivated), @Josh Zamor (Deactivated), and @Brandon Bowersox-Johnson. The CSV upload scripts have now been contributed to the core project.
@Sebastian Brudziński presented this and we as a group discussed in Poland. My feeling is that:
we do want to pull this in. CSV import capability is useful.
the first client of this might be reference service demo data. It would both help alleviate some of the demo data consistency issues we've seen in the past, but also create a template for implementations to start building their CSV's from. It would also give us an incentive to keep it up to date.
I do think Brandon that you're right that we'll need to do some work. I recall having some concern that the speed of this tool took closer to an hour to load the amount of country data that Malawi needs.
I am in agreement that we need to pull this in. Perhaps we can chat about this tomorrow after stand up to come up with the best path forward.
@Mary Jo Kochendorfer @Josh Zamor the Malawi team has secured some time next week to hold a meeting about configuration challenges that we have encountered while implementing OpenLMIS and to give an introduction to our reference data seed tool (aka CSV import) - its current state and capabilities.
If you think it would be helpful for the core team to learn about those things, can you suggest a good day/time to schedule this meeting? We are available everyday but 6am - 8am Seattle time on Wednesday and Thursday.
CC @Ben Leibert
Hi guys. These issues on the Malawi backlog are listed in descending order of priority and may be worth taking on this Sprint:
https://openlmis.atlassian.net/browse/MW-232 (Already part of OLMIS-2533?)
https://openlmis.atlassian.net/browse/MW-159
https://openlmis.atlassian.net/browse/MW-186 (Seemingly related to MW-159, above)
https://openlmis.atlassian.net/browse/MW-142
https://openlmis.atlassian.net/browse/MW-222 (Looks fairly easy to address)