| Reason | Bug | Notes | Total |
|---|
| 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. | 8 |
| 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. |
| 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 | 17 |
| 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 |
| 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. | 3 |
| 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. |
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 |
| 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  . |