Versions Compared

Old Version 1

changes.mady.by.user Ben Leibert

Saved on

compared with

New Version 2

changes.mady.by.user Ben Leibert

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

Participants / Stakeholders

Retrospective

  • We weren’t able to focus on SELV as much as in past sprints: Aleksandra was out of the office last week, and Mateusz was out for a day or two and then focused on Angola support. Given the amount of time available for SELV, though, we achieved a fair amount. Our attention was primarily dedicated to its Superset reports.

Showcase

Aleksandra Ciesińska finished:

Mateusz Kwiatkowski was primarily focused on https://openlmis.atlassian.net/browse/SELV3-60 and Angola’s https://openlmis.atlassian.net/browse/AO-547, though was still able to finish https://openlmis.atlassian.net/browse/SELV3-73 .

Planning

  • https://openlmis.atlassian.net/browse/SELV3-66 is dedicated to adding Min and Max stock amount values to the Stock on Hand report. We found, however, that NiFi’s processor doesn’t retrieve these values from OpenLMIS' database, however, and that it getting it to do so will require substantial redesign.

    Specifically: NiFi's requisition processor uses the old endpoint which doesn't support versioning of Orderables nor FTAPs. The data it returns doesn’t include the minimum-periods-of-stock values we need. Furthermore, the default behavior of endpoints in requisition service is to return exclusively the latest requisitions. We'll need to determine and then manually request historical requisitions. All of this redesign involves a relatively high degree of uncertainly and could easily take 5 or more days.

    We’d potentially use Jolt, which allows data to be extracted from JSON, and for JSON objects to be transformed. Jolt is new to us, though, and relying on it thus involves a bit of risk.

    It isn’t that our current NiFi flows are poorly designed - they simply lack the data we need.

    As mentioned, exposing the data we need to Superset would take approximately five days and perhaps more. Devoting this amount of time to https://openlmis.atlassian.net/browse/SELV3-66 isn’t warranted right now, and we should thus deprioritize the ticket.

  • It has been difficult to obtain Orderable’s volumes. For now, we can therefore use arbitrary ones. Additionally, the minStorageTemperature of each Orderable should be set to 2, and the maxStorageTemperature should be set to 8.

  • Although we still need to check in with Aida, we also still aim to perform UAT sometime next week. Matthew Kumbuyo (Deactivated) plans to finish writing the test cases tomorrow, and he and Felimone Amone Junior will thereafter start executing them. Felimone Amone Junior has already performed a number of them informally and, so far, found that the system behaves as desired.

  • Aside from pending configuration changes, our highest priority for the UAT involves reports. https://openlmis.atlassian.net/browse/SELV3-86 is our lowest priority report. The Fulfillment and Stockout reports are higher priority. We have a mockup for the Fulfillment report which needs to be reviewed, and will create mockups for the Stockout report as soon as possible.

  • https://openlmis.atlassian.net/browse/AO-547 is potentially done - it depends on how its testing goes.

  • Regarding https://openlmis.atlassian.net/browse/SELV3-61:

    • Requisitions for district-level facilities will involve one level of approval, whereas requisitions for provincial facilities will require two. The first page shown on the mockup can look the same regardless of which level or approver is using it. District level users, however, will only see their own district on the page. Showing the Total for All District columns would be redundant for such users. The district-level Approval button would be similarly unnecessary. The page should therefore hide these elements whenever it displays one or fewer districts.

    • We’ll implement the Batch Approval functionality using a new microservice and data-feed. (So, data will be pushed to the new microservice.) Using this architecture, it would be just as easy for the backend to group requisitions by district as by supervisory node. The former is preferable given that it’s congruous with what the UI presents users.

Action Items