openlmis-referencedata

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Done.

Done.

Yes

Yes

Should I do this?

Should I do this?

That would probably make sense, in case someone updates the wiremock version in the future

That would probably make sense, in case someone updates the wiremock version in the future

Referencedata was the only service which has used wire mock in the version 2.22.0. In 1.58 the problem doesn't occur. The only thing that we could do is to move the wire mock to the testCompile sec...

Referencedata was the only service which has used wire mock in the version 2.22.0. In 1.58 the problem doesn't occur. The only thing that we could do is to move the wire mock to the testCompile section in dependencies (in fulfillment, stockmanagement, and report).

Good catch. Did you manage to check whether the same problem exists in other services too?

Good catch. Did you manage to check whether the same problem exists in other services too?

OLMIS-6564: Fixed responses compression in the referencedata service
OLMIS-6564: Fixed responses compression in the referencedata service
OLMIS-6450 Performance improvements and adjusting tests thresholds for FTAPs
OLMIS-6450 Performance improvements and adjusting tests thresholds for FTAPs
We can just ignore this error by: @SuppressWarnings("PMD.TooManyMethods");

We can just ignore this error by: @SuppressWarnings("PMD.TooManyMethods");

Please remove one of those changelogs (or merge them somehow).

Please remove one of those changelogs (or merge them somehow).

Extracting those lines to a separate method will cause "The class has too many methods, consider refactoring it" error while building project in Gradle.

Extracting those lines to a separate method will cause "The class has too many methods, consider refactoring it" error while building project in Gradle.

OLMIS-6470: Fixed creating and updating SupervisoryNode with RequisitionGroup
OLMIS-6470: Fixed creating and updating SupervisoryNode with RequisitionGroup
Ok, throwing exception here is not desired indeed. If we want to log a message, it should be changed to indicate that the Supervisory Node doesn't exist in the database.

Ok, throwing exception here is not desired indeed. If we want to log a message, it should be changed to indicate that the Supervisory Node doesn't exist in the database.

Could we merge those calls? I think we don't need the second one, we can simply return supervisory node object from the line 329.

Could we merge those calls? I think we don't need the second one, we can simply return supervisory node object from the line 329.

It's not checking whether SN exists in update request, but if a SN with a given id (as in the request) already exists. Throwing exception now may cause more trouble in the app's behavior if I am no...

It's not checking whether SN exists in update request, but if a SN with a given id (as in the request) already exists. Throwing exception now may cause more trouble in the app's behavior if I am not mistaken. The SN presence is validated before that and is indeed throwing ValidationMessageExeption if needed. Maybe I should just correct the log message as it's indeed confusing now?