UI refactors

Caused by removing status messages from requisition object, but real cause why this was not working is Requisition Watcher which was setting $modified flag after requisition was submitted/authorized. This flag is a indicator if we have some changes in requisition object stored offline, if not application is getting new changes from server. Getting fresh changes after status change is crucial to have current comments on the screen.

21

Caused by refactor of facility/program select refactor. State param 'requestingFacilty' has been changed to 'facility' in order to be compatible with this new component. Unfortunately this parameter was used for search endpoint and this change caused lack of this parameter in request. 

Caused by messages split refactor on the UI.

Caused by . There are conflicting opinions on how this functionality should work, which makes it easy to overlook. It would be easy to assume that this is correct behavior after refactoring the pagination.

While working on the message keys were changed but usage of that keys was not changed.

The whole list of columns was being passed to the validator instead of a list of the non full supply ones.

During message refactor message keys have changed but one of the if statement left unchanged, which caused to invalid values being returned.

During refactor of the template validator one of the validation wasn't implemented.

Permissions were removed from local storage and retrieved from the backend again every time when the page was refreshed or logged user changed. It to was changed to not remove permissions when the page is refreshed.

In offline mode, facilities were not retrieved from the cache. As a solution, it was updated cachedAllMinimal to get facilities from PouchDb when offline. Additionally added refactor to getAll method in local database to reject when it is not available.

This page is using cache and the "openlmis-cached-resource" was removing the pagination information from the response when fetching stock data (in the "query" function).

Pagination fix done in caused the the issue with displaying the Products.

One time binding used for iterating over collection for column generation

UI was assuming that processing period is required field, despite processing period is nullable on the backend

Plugin pouchdb-find was not in the project

New order was created with null facility

There was no condition to check if the line item with 0 SoH is newly added.

Sometimes values in quantity column are changed when row is removed on Requisition-less order page.

The active flag was changed to ‘true’ for all products every time any product was added to inventory

Validation of inactive lots was not working on Physical Inventory page.

Error message for release without order with no requisitions selected was not defined.

Error message for with the description “Bad request Trade Item is required to add a Lot Code” was not defined.

Other bug fixes

Caused by lack of check if new value is different than the previous one while running calculations in product-grid directive for each digest cycle.

It was changed while repairing lack of calculation calls for dependent columns commit

32

Caused by lack of check if recent stock on hand value was 0, the stockout days were calculated from the period between last physical inventory when SoH was zero instead of all entries when it was 0.

In order go get previous period Map<K, V> datastructure was changed to NavigableMap<K, V>

During work on , demo-data was added to Reference-Data but FTP settings in Fulfillment were not adjusted.

Validator was using calculatedOrderQuantity instead of the requestedQuantity.

Caused by gliderlabs/alpine image which is no longer maintained.

Caused by renaming apache/incubator-superset to apache/superset

Caused by external Google Analytics dependency.

Demo-v3 has a local database on the instance. It was needed to create pgdata volume for deploy properly demo-v3 with KEEP option.

There was a method that filtered out the products in which the stock on hand was zero. For the Adjustments screen, a new method has been created that retrieves all available products in the facility - also those whose SoH is 0.

Validation was added for programs in the orderable, but when creating new product program list is null and the validation threw NullPointerException, because null check was missing.

Facilities data source is no longer used since we started using Kafka. A new materialized view has been created - facilities that have all the necessary fields.

The data in the Stock Filter and District Stockout Rates over Time weren't visible. The time range setting for these charts has been changed to 'No filter'.

The current added products were not passed as a parameter to state params

Expired nifi-registry certificate. Periodic ticket for certificate renewal was not created/finished on time. Certificate renewal automation should be considered.

Resolving supervisory nodes dataset required itself in injection

Child state was not overwriting resolved children property from parent treating it as available via dedicated provider. Another form of issue from

Invalid docutils packge version was in use.

There was no 'Label' specified for program_name column.

For every dto transformation, request to referencedata was made. Timeout was caused by too many requests between stockmanagement abd referebcedata mikroservices

Invalid search criteria specified in supserset

Validation for unique product code was not implemented

Class for representing certain status had invalid styling

Feature to remember selection from other pages was not clearing selection after first convert

Missing entries for proper roles in referencedata.role_rights table. Entries were missing also for demo data

Endpoint /api/validSources and /api/validDestinations are not returning all resources by default and list to search on when confirming shipment was to small

When 'Remarks' is disabled in the requisition template, there is a null pointer exception when approving requisition.

Validation on product code duplicate was not checking existing orderable properly

active property was missing after creating difference between draft line items and display line items group

Validation on product quantity input was not checking empty/null values properly

Regex in form decorator didn’t detect changes in reasonQuantity field in case of removing this field from form.

There was the issue with sorting products. Now it works in such way that products are sorted by 'Original Index'.

While investigation of this bug it realized that there was an issue when there was no draft created. Next page couldn’t be loaded when user chose program and click ‘start'. ‘PhysicalInventory’ form was displayed when user clicked again on ‘start’ button. This error didn’t happened when there was already created draft. The reason of this bug was an error with handling ‘null’ in ‘physical-inventory-factory.js’ within 'getStockAdjustments’ function.

This problem was related to 'losing states of Redux' after either refreshing or reloading application.

Unaccounted Quantity was not calculated when entering the draft, nor it was saved for items in draft.

Problem caused by cached some basic data related to permissions and list of programs/facilities. Now in “requisitions->create/authorize” those data are refreshed.

The ‘Search’ button on Initiate Report and Requisition page did not included the start date of a given program, but returned all found periods for a given facility and program.

Caused by a method that calculates stockout days. The method did not take into account the beginning balance of a given period and also incorrectly verified the occurrence of stock on hand in a given period.

Design error

There was neither unique constraint nor unique index on name in facility_types table

18

There was no PROGRAM_MANAGE right at all, so it had to be added.

Caused by assumption that all modules that are using facility/program select component are using Requisition rights which is not true.

After authorize skipped line items are cleared and lack of price per pack field was causing the problem

Loading modal was closed too soon just after user update request finished, not after user list page was loaded.

Loading spinner close method was always called before login modal appeared. Now there is a check if loading spinner was opened before opening loading modal, if so it will be reopened after successful login.

Check for approving requisition was including only program, supervisory node was missing. Fixed for approve and reject endpoint.

Requisition repository was returning page of filtered requisition, then right were checked and paginated once again, where total elements was number of requisitions on the page.....

We were using statusText property from server response, but it turned out that it was not always available. Lack of default message caused this issue.

Offline flag at the start was always set as false at the start of offline service, so checking if user is offline just after reloading page/application always returned false. Resolved by storing offline flag in local storage.

Loading modal was closing after syncing was completed and then reopened when state changed(which happens after every requisition-related action).

Handling situation when there are no more products to add was never designed nor included in the acceptance criteria.

CalculationFactory was trying to calculate order quantity(rather than just taking the requestedQuantity) when requested quantity was empty.

Subject and Content for notifications were part of demo-data. The system that didn't used demo-data was not able to go through Requisition statuses hierarchy because of absence settings in database. Settings were moved to Transifex messages and environment variables.

No thought was given to the transactional implications when the code was written.

Incorrect calculation not taking borders into consideration which led to ever increasing table width.

During adding pagination to Manage POD view, clearing the requesting facility was not added when it was part of state params.

The password field was being cleared when we successfully logged in.

Questionable if this a bug

This is more a requirements change than a bug.

5

This is more a requirements change than a bug.

This wasn't really a bug, more like an unrepresentative demo data.

There was no way to retrieve warehouses from server before.

This is more a requirements change than a bug.

Not following style guide

UI style guide - programmers were not following styleguide sections: Titles and Buttons which say that first letter of each word should be capitalized.

3

Inline elements should have the same height.

Inline elements should be aligned to center.

Invalid demo data

Some of the requisitions that were in pre-release state had supplyingFacilityId set to a value that was not an UUID of one of the available supplying depot for that requisition.

1

Some values of orderable identifiers were uppercase but expected to be lowercase

Backend refactors

Caused by refactoring done to the Auth context setup in .

6

Caused by refactor to do db filtering in

Caused by upgrading to Spring Boot 2.x . Since the upgrade, the Hikari connection wasn't closed and after it reached its limit (10 connections), the Jasper Reports were not generated.

Poor performance has been fixed by clearing Hibernate session after order and shipment created and setting Hibernate batch insert properties

When entity graph is used to fetch orderables with programs in one database query and the orderables are filtered by program code the list of related programs will also be filtered (not all programs will be returned for orderable).

Caused by refactoring done to the Requisition Service in .