stock-orderable-group

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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: Fixed displaying lot expiration date and stock card occurred date on stockmanagement screens

    • -57
    • +57
    ./orderable-group.service.spec.js
  1. … 7 more files in changeset.
OLMIS-6669: Added lots sorting on the SOH page and to dropdown on 'Receive' and 'Physical inventory' screen

  1. … 2 more files in changeset.
Added LotResource to fix splitting long requests
Added LotResource to fix splitting long requests
Refactored usages of LotRepositoryImpl to use LotResource because the second one implements splitting long requests

  1. … 4 more files in changeset.
I would prefer the original way

I would prefer the original way

I see. I would stick with the original approach then so we don't introduce any compatibility issues. However, we could use _.flatten instead. I'll leave it up to you.

I see. I would stick with the original approach then so we don't introduce any compatibility issues. However, we could use _.flatten instead. I'll leave it up to you.

Nikodem Graczewski There is something tricky here. Array.prototype.flatMap() works on chrome version >=69 Unfortunately my virtual machine Chrome version is 66. And flatMap is not supported. That...

Nikodem Graczewski There is something tricky here.

Array.prototype.flatMap() works on chrome version >=69

Unfortunately my virtual machine Chrome version is 66. And flatMap is not supported. That was the reason i was saying its not working.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/flatMap

So changing to flatMap won't that create a problem?

// Real lineItem JSON objectvar lineItems =[{"$errors":{"quantityInvalid":false,"occurredDateInvalid":false},"$previewSOH":99,"stockCard":{"id":"e4cd8e1a-8f3c-48d4-891c-fa5160832005","href":"https:...
// Real lineItem JSON object
var lineItems =[{"$errors":{"quantityInvalid":false,"occurredDateInvalid":false},"$previewSOH":99,"stockCard":{"id":"e4cd8e1a-8f3c-48d4-891c-fa5160832005","href":"https://uat.openlmis.org/api/stockCards/e4cd8e1a-8f3c-48d4-891c-fa5160832005"},"orderable":{"productCode":"C118","dispensable":{"dispensingUnit":"10 tab strip","displayUnit":"10 tab strip"},"fullProductName":"Stomachica","description":"Product description goes here.","netContent":1,"packRoundingThreshold":0,"roundToZero":false,"programs":[{"programId":"dce17f2e-af3e-40ad-8e00-3496adef44c3","orderableDisplayCategoryId":"15b8ef1f-a5d6-42dd-95bf-bb68a4504e82","orderableCategoryDisplayName":"Oral contraceptive","orderableCategoryDisplayOrder":6,"active":true,"fullSupply":true,"displayOrder":3,"dosesPerPatient":1,"pricePerPack":5.1}],"children":[{"orderable":{"id":"25665e10-cca7-44c0-b508-e95600d8fb99"},"quantity":10},{"orderable":{"id":"d4dbd20e-8ce2-480e-a019-4a90d115719c"},"quantity":20}],"identifiers":{},"extraData":{},"meta":{"lastUpdated":"2019-04-15T00:55:18.564Z[GMT]","versionId":"2"},"id":"0dc9c1ad-2266-4fb3-ad74-993c38b8c28a"},"lot":null,"stockOnHand":99,"processedDate":"2019-04-15T00:57:46.158Z","occurredDate":"2019-04-15","displayLotMessage":"Product has no lots","reason":{"name":"Unpack Kit","description":null,"reasonType":"DEBIT","reasonCategory":"AGGREGATION","isFreeTextAllowed":false,"tags":["consumed"],"id":"9b4b653a-f319-4a1b-bb80-8d6b4dd6cc12","creditReasonType":false,"debitReasonType":true,"adjustmentReasonCategory":false},"reasonFreeText":null,"quantity":2}];

lineItems.flatMap(function(lineItem) {
    return lineItem.orderable.children.map(function(constituent) {
        return _.extend({}, constituent, {
            reason: creditReason,
            occurredDate: lineItem.occurredDate,
            quantity: lineItem.quantity * constituent.quantity
        });
    })
});
OLMIS-6113 : Create UI for kit unpacking in stock management
OLMIS-6113 : Create UI for kit unpacking in stock management
I've checked and for AdjustmnetCreationController tests, exactly the same objects are created (and the tests pass). Could you provide a case for which this fails?

I've checked and for AdjustmnetCreationController tests, exactly the same objects are created (and the tests pass). Could you provide a case for which this fails?

This doesn't return object in a desired format. I will stick with the existing implementation

This doesn't return object in a desired format. I will stick with the existing implementation

Kits unpacking increased test coverage and solve sonar issue

  1. … 5 more files in changeset.
Ugh, this is a really strange design.

Ugh, this is a really strange design.

The message is correct but the key can't be changed this time, since Issue, Receive and Upack share similar keys for the message since they use the same html template

The message is correct but the key can't be changed this time, since Issue, Receive and Upack share similar keys for the message since they use the same html template

The message is correct but the key can't be changed this time, since Issue, Receive and Upack share similar keys for the message since they use the same html template

The message is correct but the key can't be changed this time, since Issue, Receive and Upack share similar keys for the message since they use the same html template

The message is correct but the key can't be changed this time, since Issue, Receive and Upack share similar keys for the message since they use the same html template

The message is correct but the key can't be changed this time, since Issue, Receive and Upack share similar keys for the message since they use the same html template

ditto

ditto

Issue, receive and unpack pages uses a single html view but separate message files. The prefix of the message key is up-to the page that will be rendered but the suffix is already hard coded in the...

Issue, receive and unpack pages uses a single html view but separate message files. The prefix of the message key is up-to the page that will be rendered but the suffix is already hard coded in the html file.

So in this case the message value is appropriate but the key is not. changing the key required all the message to be changed in the other modules also. So this implementation shall be refactored for the future but till then the html file is our guide.

Take a look at stock-adjustment/stock-adjustment.html

Sure

Sure

I see. The logic for this is in multiple places, which made it hard to follow for me. We could most likely refactor this a bit.

I see. The logic for this is in multiple places, which made it hard to follow for me. We could most likely refactor this a bit.

This piece of code will return a random reason No. when the unpack reason view loaded, take a look at unpack-kit-creation.routes.js line 78. Method returns ONLY two reasons of type AGGREGATION. T...

This piece of code will return a random reason


No. when the unpack reason view loaded, take a look at unpack-kit-creation.routes.js line 78. Method returns ONLY two reasons of type AGGREGATION. They are -
1. Kit Unpack (DEBIT)
2. Unpacked From Kit (CREDIT).

So we will use Unpacked From Kit (CREDIT) reason for the constituent line item