openlmis-stockmanagement-ui

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Changed version to 2.0.1-SNAPSHOT

2.0.0 release

2.0.0-SNAPSHOT release

2.0.0-RC3 release

Changed version to 2.0.0-SNAPSHOT

2.0.0-RC2 release

Changed version to 2.0.0-SNAPSHOT

2.0.0-RC1 release

Done.

Done.

OLMIS-5002: Removed duplications

Yes, this is possible. I'm working on it.

Yes, this is possible. I'm working on it.

Since this needs to be repeated eight times and it looks exactly the same for each step, is there any way to extract what happens at the failure and define it in one place in the jenkinsfile?

Since this needs to be repeated eight times and it looks exactly the same for each step, is there any way to extract what happens at the failure and define it in one place in the jenkinsfile?

OLMIS-5002: Added email notifications after failures

OLMIS-5002: Added email notification after failure
OLMIS-5002: Added email notification after failure
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: Fixed unit test

OLMIS-4404: Stock on Hand View will no longer show empty summaries

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-4933: Fixed submitting physical inventory when with today's date
OLMIS-4933: Fixed submitting physical inventory when with today's date
OLMIS-4933: Fixed submitting physical inventory when with today's date