Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
OK, I figured that was the case given that all the controller tests seems to be written in the same form.

OK, I figured that was the case given that all the controller tests seems to be written in the same form.

Basically we are writing our controller contract tests mocking other services and only testing web communication. I think this is written in some styleguide. You can definitely encounter some contr...

Basically we are writing our controller contract tests mocking other services and only testing web communication. I think this is written in some styleguide. You can definitely encounter some controller integration tests that are only mocking db, but we are not doing it anymore.

Adding this type of boolean parameters can be problematic, especially if there ever needs to be multiple boolean parameters added to the builder. Using the existing builder pattern along with a flu...

Adding this type of boolean parameters can be problematic, especially if there ever needs to be multiple boolean parameters added to the builder. Using the existing builder pattern along with a fluent interface to define this types of optional-ish parameters might be a more future-proof option that would be easier to read and understand.

This doesn't actually seem like an integration test given that many (all?) of the downstream services are mocked. While I noticed that all the tests in this test class seem to follow the same behav...

This doesn't actually seem like an integration test given that many (all?) of the downstream services are mocked. While I noticed that all the tests in this test class seem to follow the same behavior, these tests seem more like unit tests then integration tests.

OLMIS-4404: Updated api definition

please add info that this flags defaults to false.

please add info that this flags defaults to false.

OLMIS-4404: Added nonEmptyOnly flag to the v2 stockCardSummaries endpoint
OLMIS-4404: Added nonEmptyOnly flag to the v2 stockCardSummaries endpoint
OLMIS-4404: Added nonEmptyOnly flag to the v2 stockCardSummaries endpoint

  1. … 8 more files in changeset.
OLMIS-4746: fixed page parameter description in api definition

done

done

OLMIS-4706: removed stock out days API design

  1. … 2 more files in changeset.
Mateusz Kwiatkowski could you revert those changes if they are on the master branch? The related ticket has been closed (as won't fix)

Mateusz Kwiatkowski could you revert those changes if they are on the master branch? The related ticket has been closed (as won't fix)

OLMIS-4035: added new stock card summary with reasons API
OLMIS-4035: added new stock card summary with reasons API
After the meeting we agreed that Total Losses and Adjustments is not needed so I've just changed endpoint to group amounts by tags instead of reasons.

After the meeting we agreed that Total Losses and Adjustments is not needed so I've just changed endpoint to group amounts by tags instead of reasons.

I've updated names of schema files

I've updated names of schema files

OLMIS-4035: renamed schema from reason to range

  1. … 4 more files in changeset.
From what I understand we have to put everything that wasn't included in Total Consumed and Total Received columns into Total Losses and Adjustments. Total Losses and Adjustments contains not only ...

From what I understand we have to put everything that wasn't included in Total Consumed and Total Received columns into Total Losses and Adjustments.
Total Losses and Adjustments contains not only the calculated amount but it has list of reasons and amounts assigned to them so we need reason info to build this column, at least from what I understand. This will allow user to open Total Losses and Adjustment modal and see specific reasons like in regular requisition. The requisition API also takes the list of reasons + amounts for totalLossesAndAdjustments in RequsisitionLineItem.

great

great

Done: OLMIS-4737.

Done: OLMIS-4737.

I've added one of them. The second one, which checks if the exception is thrown when reasonType is invalid, is not valid anymore. Currently, we check it in ValidReasonAssignmentSeachParams class.

I've added one of them. The second one, which checks if the exception is thrown when reasonType is invalid, is not valid anymore. Currently, we check it in ValidReasonAssignmentSeachParams class.

Klaudia Pałkowska please create a new ticket for that to avoid too many changes on backend/UI.

Klaudia Pałkowska please create a new ticket for that to avoid too many changes on backend/UI.