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.
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.
|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.|
|- OLMIS-7217Getting issue details... STATUS||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.|
|- OLMIS-7220Getting issue details... STATUS||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).|
|- OLMIS-7271Getting issue details... STATUS||Pagination fix done in - OLMIS-7246Getting issue details... STATUS 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
Validator was using calculatedOrderQuantity instead of the requestedQuantity.
|- OLMIS-7168Getting issue details... STATUS||Caused by gliderlabs/alpine image which is no longer maintained.|
|Caused by renaming apache/incubator-superset to apache/superset|
|- OLMIS-7203Getting issue details... STATUS||Caused by external Google Analytics dependency.|
|- OLMIS-6856Getting issue details... STATUS||Demo-v3 has a local database on the instance. It was needed to create pgdata volume for deploy properly demo-v3 with KEEP option.|
|- OLMIS-6813Getting issue details... STATUS||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.|
|- OLMIS-7248Getting issue details... STATUS||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.|
|- OLMIS-7253Getting issue details... STATUS||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.|
|- OLMIS-7254Getting issue details... STATUS||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'.|
|- OLMIS-7291Getting issue details... STATUS||The current added products were not passed as a parameter to state params|
|- OLMIS-7398Getting issue details... STATUS||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|
|- OLMIS-7420Getting issue details... STATUS||Child state was not overwriting resolved |
|- OLMIS-7437Getting issue details... STATUS||Invalid docutils packge version was in use.|
|- OLMIS-7429Getting issue details... STATUS||There was no 'Label' specified for program_name column.|
|- OLMIS-7442Getting issue details... STATUS||For every dto transformation, request to referencedata was made. Timeout was caused by too many requests between stockmanagement abd referebcedata mikroservices|
There was neither unique constraint nor unique index on name in facility_types table
|- OLMIS-3146Getting issue details... STATUS||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.|
|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.|
|Inline elements should have the same height.|
|Inline elements should be aligned to center.|
|Invalid demo data|
- OLMIS-2531Getting issue details... STATUS
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.
|Backend refactors||Caused by refactoring done to the Auth context setup in - MW-390Getting issue details... STATUS .||6|
|- OLMIS-3461Getting issue details... STATUS||Caused by refactor to do db filtering in - OLMIS-3187Getting issue details... STATUS|
|- OLMIS-7169Getting issue details... STATUS|
|- OLMIS-7219Getting issue details... STATUS||Poor performance has been fixed by clearing Hibernate session after order and shipment created and setting Hibernate batch insert properties|
|- OLMIS-7251Getting issue details... STATUS||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).|
|- OLMIS-7376Getting issue details... STATUS||Caused by refactoring done to the Requisition Service in - OLMIS-5226Getting issue details... STATUS .|