Dashboard

I think that the reason for having this value greater than or equal was to avoid saving the Stock on hand value to the database for the same occurred date. If there was no Stock on hand value for g...

I think that the reason for having this value greater than or equal was to avoid saving the Stock on hand value to the database for the same occurred date. If there was no Stock on hand value for given occurred date it was saved to database before calculations, and then saved again after being recalculated. If there was already such a value it was only updated.
Now we are deleting these stock on hand values, so there are no two records saved for the same occurred date, just the current one.

OLMIS-6728 Refactored code, added changelog and tests

toDate function from dateUtils transforms dates from array/string to Date object, which is passed to the openlmisDate filter then. openlmisDate filter prepares date to be displayed in the proper fo...

toDate function from dateUtils transforms dates from array/string to Date object, which is passed to the openlmisDate filter then. openlmisDate filter prepares date to be displayed in the proper format and it's still used in the HTML (also for occurredDate or expirationDate).

So, in general, will openlmisDate filter be of any use now and in the future?

So, in general, will openlmisDate filter be of any use now and in the future?

OLMIS-6511: Fixed displaying lot expiration date and stock card occurred date on stockmanagement...
OLMIS-6511: Fixed displaying lot expiration date and stock card occurred date on stockmanagement...
OLMIS-6511: Added missed test for stockCardService

    • -0
    • +71
    /src/stock-card/stock-card.service.spec.js
OLMIS-6511: Fixed displaying lot expiration date and stock card occurred date on stockmanagement screens

    • -3
    • +15
    /src/stock-card/stock-card.service.js
OLMIS-6739: Renamed the minimum/maximumToleranceTemperature variables

    • -0
    • +15
    /src/main/resources/db/migration/20200124111526354__renamed_temperature_columns_in_orderables_table.sql
Revert "Updated memory limits for referencedata service on perftest"

This reverts commit a0e0596107ca51d623bc37f8462a5778476769f0.

Updated memory limits for referencedata service on perftest

Revert "Reduced scenario duration to 60s for orderables search and non full supply products search"

This reverts commit 223418818159cde48306b088b7426afc06208452.

    • -1
    • +1
    /performance/tests/approvedProductsForEssentialMedsAndDistrictHospital.yml
In the context of this method, those seem to be just stock on hands

In the context of this method, those seem to be just stock on hands

setStockOnHand can set negative value, and we should prevent this.

setStockOnHand can set negative value, and we should prevent this.

Can this ever be negative?

Can this ever be negative?

It's very inefficient that we make a call to the database with each iteration. We could somehow preserve those previous stock on hands so we don't have to retrieve them each time.

It's very inefficient that we make a call to the database with each iteration. We could somehow preserve those previous stock on hands so we don't have to retrieve them each time.

Why do we need to clear this list?

Why do we need to clear this list?

Just name it deleteStockOnHands - this method doesn't do any logic - it just deletes what it receives.

Just name it deleteStockOnHands - this method doesn't do any logic - it just deletes what it receives.

You don't need this if

You don't need this if

Why do we only use line items that are after the given occured date here, while for calculated SoHs we use both after the date and AT the given date. Won't we lose data in that case?

Why do we only use line items that are after the given occured date here, while for calculated SoHs we use both after the date and AT the given date. Won't we lose data in that case?

Changelog reminder

Changelog reminder

OLMIS-6728 Fixed incorrect calculation of Stock On Hand
OLMIS-6728 Fixed incorrect calculation of Stock On Hand
OLMIS-6728 Fixed incorrect calculation of Stock On Hand

I see that if a statement is located in StockCardSummariesService so it should be tested in this class as it should be done while writing unit tests. If you are testing it below it should be moved ...

I see that if a statement is located in StockCardSummariesService so it should be tested in this class as it should be done while writing unit tests. If you are testing it below it should be moved to another test method.

I think it should have tests in the repository test class where you would test this method with different data and parameters. I don't see such tests. Sonar only says if code line is used while exe...

I think it should have tests in the repository test class where you would test this method with different data and parameters. I don't see such tests. Sonar only says if code line is used while executing tests, not if it is tested properly.

In StockCardRangeSummaryParamsTest.java class there are separate tests to verify if null is assigned to startDate / endDate if they're absent from parameters. Additionally I added unit tests to che...

In StockCardRangeSummaryParamsTest.java class there are separate tests to verify if null is assigned to startDate / endDate if they're absent from parameters. Additionally I added unit tests to check if a proper exception is thrown if startDate / endDate is empty.

The method is tested in StockCardSummariesServiceTest (lines 351 and below, not usued anywhere else), analogical to similar findByStockCardIdAndOccurredDateBetween. Also sonar marks this as code co...

The method is tested in StockCardSummariesServiceTest (lines 351 and below, not usued anywhere else), analogical to similar findByStockCardIdAndOccurredDateBetween. Also sonar marks this as code covered by tests. Could you give me a hint if there is more that could / should be done here?