Skip to end of metadata
Go to start of metadata

Objective: to continue addressing critical bugs (performance and major UI issues)

Reference UI

NR: These will make working with the UI easier

  • OLMIS-2509 - Getting issue details... STATUS  - NR: Is this a dupe of OLMIS-2328
  • OLMIS-2439 - Getting issue details... STATUS
  • OLMIS-2573 - Getting issue details... STATUS  - NR: This should be fixed in OLMIS-1693
  • OLMIS-2572 - Getting issue details... STATUS
  • OLMIS-2444 - Getting issue details... STATUS

  • OLMIS-1189 - Getting issue details... STATUS

  • OLMIS-1889 - Getting issue details... STATUS
  • OLMIS-1925 - Getting issue details... STATUS (Team ILL)


  • OLMIS-249 - Getting issue details... STATUS  - NR: Angular strap has hard coded string, might need another library


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?

  • OLMIS-2565 - Getting issue details... STATUS  (Which Malawi bugs does this address? A: Requisition load time)

  • OLMIS-2566 - Getting issue details... STATUS  (Q: Solution for this will probably be the same as for OLMIS-2584 - Getting issue details... STATUS ) (Which Malawi bugs does this address? A: Requisition view/approve/convert to order)
    Make sure to reference the related Malawi bugs  MW-232 - Getting issue details... STATUS

  • OLMIS-2584 - Getting issue details... STATUS
  • OLMIS-2533 - Getting issue details... STATUS  (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  MW-164 - Getting issue details... STATUS , MW-165 - Getting issue details... STATUS , MW-166 - Getting issue details... STATUS , MW-167 - Getting issue details... STATUS , MW-171.
  • OLMIS-2522 - Getting issue details... STATUS
  • OLMIS-2514 - Getting issue details... STATUS
  • OLMIS-2530 - Getting issue details... STATUS
  • OLMIS-2193 - Getting issue details... STATUS
  • OLMIS-2531 - Getting issue details... STATUS
  • OLMIS-2543 - Getting issue details... STATUS  (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

OLMIS-2574 - Getting issue details... STATUS

OLMIS-2536 - Getting issue details... STATUS  This endpoint should filter the facilities (this is a dependency for MW-170)

OLMIS-2494 - Getting issue details... STATUS

OLMIS-2277 - Getting issue details... STATUS  (Q: Do we want front-end validation? A: Yes)

OLMIS-2292 - Getting issue details... STATUS

OLMIS-2385 - Getting issue details... STATUS  (very small)

OLMIS-2384 - Getting issue details... STATUS  (very small)

OLMIS-2495 - Getting issue details... STATUS


OLMIS-2552 - Getting issue details... STATUS (likely shouldn't pick this up, if we did, Reference Data would be working on v7.0.0 - the next major release)


OLMIS-2551 - Getting issue details... STATUS

OLMIS-2532 - Getting issue details... STATUS


OLMIS-2147 - Getting issue details... STATUS

Stretch Goal: 

Stock Management: Change it from Hibernate to Flyway before our next/non-beta release (or move this to Grooming 28?? Team ILL)


OLMIS-2574 - Getting issue details... STATUS


Roll-over from last sprint.

Issues Discovered During Malawi UAT

OLMIS-2584 - Getting issue details... STATUS

OLMIS-2585 - Getting issue details... STATUS

OLMIS-2586 - Getting issue details... STATUS

OLMIS-2587 - Getting issue details... STATUS  (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

OLMIS-2588 - Getting issue details... STATUS  (Q: What is the status of this ticket?) A: Will be dead after OLMIS-2476

OLMIS-2548 - Getting issue details... STATUS

Team ILL

OLMIS-2578 - Getting issue details... STATUS

OLMIS-2581 - Getting issue details... STATUS

OLMIS-2580 - Getting issue details... STATUS

OLMIS-2582 - Getting issue details... STATUS

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:

OLMIS-2590 - Getting issue details... STATUS

Performance Testing of key endpoints (find the ticket for it)

Refactor so we can accept the batch approve page in requisitions

  • No labels


  1. Hi guys. These issues on the Malawi backlog are listed in descending order of priority and may be worth taking on this Sprint: (Already part of OLMIS-2533?) (Seemingly related to MW-159, above) (Looks fairly easy to address)

  2. PS I added these ticket to the page

  3. 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.

    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.

      1. 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.

        1. 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?

          1. 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?

            1. 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.

              1. 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.

                1. Okay; thanks again Josh!

                  1. Hi Mary Jo Kochendorfer, Josh Zamor, and Brandon Bowersox-Johnson. The CSV upload scripts have now been contributed to the core project.

        2. Sebastian Brudziński presented this and we as a group discussed in Poland.  My feeling is that:

          1. we do want to pull this in.  CSV import capability is useful.
          2. 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.

          1. 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.

            1. 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

  4. Hi Mary Jo Kochendorfer. I published meeting notes from Malawi's latest Sprint Transition meeting a moment ago. The bottom of the page delineates which bugs in Malawi’s backlog seem related to our custom development or configuration. The remainder, we think, could be reasonably addressed by either the core or Malawi team. 

    1. Wonderful! let's make sure to call this out in the Release notes for 3.1