Backlog Grooming Sprint 21

Priorities

For Sprint 21, we will focus on patch work (3.0.1). This means bugs, performance issues, security issues, adding test coverage, and refactoring. We want to first work on things that that do not break API compatibility or break functionality. Our target is to put out a patch release, 3.0.1, by the end of Sprint 22 (late March). After we are done with patch work, Josh will be helping us establish a process where each Component might put out a 3.0.1 patch release and then switch to working towards 3.1.0-SNAPSHOT.

Goals for 3.0.1:

  • UI improvements and finalization (bugs)
  • Finalize requisition data validations 
  • Finish audit logging
  • Improve monitoring

Fulfillment

  • OLMIS-1428 - Getting issue details... STATUS
  • OLMIS-2003 - Getting issue details... STATUS
  • OLMIS-1453 - Getting issue details... STATUS
  • OLMIS-2002 - Getting issue details... STATUS
  • OLMIS-1916 - Getting issue details... STATUS  (need to discuss, Sebastian: we didn't put it into the sprint yet, because we don't know how to proceed)
  • OLMIS-1395 - Getting issue details... STATUS  (kinda a bug)

UI Bugs

  • OLMIS-1992 - Getting issue details... STATUS
  • OLMIS-1990 - Getting issue details... STATUS (Question from Mateusz in the ticket)
  • OLMIS-2032 - Getting issue details... STATUS  (ILL)
  • OLMIS-2016 - Getting issue details... STATUS (Sebastian: let's agree and include in the ticket description how it is supposed to look after refactor)
  • OLMIS-2006 - Getting issue details... STATUS
  • OLMIS-2000 - Getting issue details... STATUS (Sebastian: let's agree and include in the ticket description how it is supposed to work after refactor)
  • OLMIS-1999 - Getting issue details... STATUS (Sebastian: let's agree and include in the ticket description how it is supposed to look after refactor)
  • OLMIS-1998 - Getting issue details... STATUS (Sebastian: should we have a separate tab for full and non-full supply or just a column that notifies about it?)
  • OLMIS-1956 - Getting issue details... STATUS
  • OLMIS-2034 - Getting issue details... STATUS (ILL)
  • OLMIS-1884 - Getting issue details... STATUS

Needs to be reproduced

Reference Data Bugs

  • OLMIS-1977 - Getting issue details... STATUS (Sebastian: what response should we have on this "partial success"?)
  • OLMIS-1965 - Getting issue details... STATUS
  • OLMIS-1970 - Getting issue details... STATUS
  • OLMIS-1854 - Getting issue details... STATUS  (Josh is this something we should do? - yes)
  • OLMIS-1779 - Getting issue details... STATUS
  • OLMIS-1985 - Getting issue details... STATUS
  • OLMIS-1694 - Getting issue details... STATUS (Sebastian: what's the reason for this change? We assumed that we don't want referencedata to depend on any other services)


Requisition

Bugs first for the patch. Then 1911. I would like to see 1911 completed by end of March.

Fulfillment Features (do after Bugs)

  • OLMIS-905 - Getting issue details... STATUS (Sebastian: is fulfillment service README a good place to document this?)
    Hold off until after 3.0.1 patch:
    • OLMIS-1370 - Getting issue details... STATUS
    • OLMIS-1000 - Getting issue details... STATUS  (hold off till after the patch)
    • OLMIS-399 - Getting issue details... STATUS  (hold off till after the patch)

UI Features (do after Bugs)

*NOTE:* Currently we are working towards UI features for 3.0.1, which we will assume will continue to use the openlmis-requisition-refUI repository. For the UI that will be released in OpenLMIS 3.1, we will be splitting the UI into independent reusable repositories and sections (the work is scoped in OLMIS-1920 - Getting issue details... STATUS  and  OLMIS-1025 - Getting issue details... STATUS ) – the version number for this OpenLMIS-UI will be 4.0. Once this change in repositories is made work on 3.0.1 will stop, or be limited to patches.


It is my hope that Malawi will use the OpenLMIS-UI v4.0 – which should still be compatiable with OpenLMIS 3.0 services - but will use a different structure than what was released in OpenLMIS 3.0.


OpenLMIS 3.0.1 Feature Work

OpenLMIS 3.1 Feature Work



Stretch Goal

Platform Features

  • OLMIS-1696 - Getting issue details... STATUS  (ILL)
  • OLMIS-1695 - Getting issue details... STATUS  (ILL)
  • OLMIS-1773 - Getting issue details... STATUS
  • OLMIS-1444 - Getting issue details... STATUS
  • OLMIS-1733 - Getting issue details... STATUS - Request from Paweł Gesek (start with ref data to start and then follow up with others - perhaps this can happen after the 3.0.1.. need to discuss)

Audit logging

Monitoring

  • Signup with New Relic.  Can it monitor:  http connections and bytes of artifacts in a page load, overall load time, simulate networks (latency, dropped packets, throughput?  What can it offer for quick Docker monitoring?
  • Target a Discussion for sprint 21 (team ILL to come up with approach) : tracking in google analytics? modals, page load times to figure out page load times. perhaps a request identifier across service
  • Google analytics:  move GA tracking code into an environment variable type approach
  • OLMIS-1944 - Getting issue details... STATUS

Admin Screens

Nick mentioned we should look into improving navigation for these screens

Will address User Roles and Facilities in later sprints.

Reporting

Security


ILL

  • OLMIS-2048 Epic contains:  OLMIS-2049 - Getting issue details... STATUS  (Team ILL)

OLMIS-1997 - Getting issue details... STATUS  (Team ILL)

OLMIS-2029 - Getting issue details... STATUS  (ILL - Nick)

OLMIS-2030 - Getting issue details... STATUS  (ILL - Nick)

OLMIS-2031 - Getting issue details... STATUS   (ILL - Nick)


More New Bugs (found by SolDevelo during Sprint 21 should be groomed for fixing in Sprint 22):

OLMIS-2054 - Getting issue details... STATUS  (UI) (Nick, I added a comment in ticket about how you want to handle this)

OLMIS-2056 - Getting issue details... STATUS  

OLMIS-2057 - Getting issue details... STATUS  (UI) (Nick, this one needs your input about color issues)

OLMIS-2053 - Getting issue details... STATUS  (UI)



Holding off:

Spike Program Data - need tickets to be made and clearly state what the outcome of the spike should be

Performance (sprint 22)

  • Work towards (in-service) caching




OpenLMIS: the global initiative for powerful LMIS software