Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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?

I think we should add this message to MessageKeys and throw this message by ValidationMessageException.

I think we should add this message to MessageKeys and throw this message by ValidationMessageException.

OLMIS-6470: Fixed updating Supervisory Node via PUT api/requisitionGroups/{id}
OLMIS-6470: Fixed updating Supervisory Node via PUT api/requisitionGroups/{id}
OLMIS-6470: Fixed creating and updating Supervisory Node without Requisition Group and added validation.

  1. … 4 more files in changeset.
OLMIS-6463; Added searching ftaps by orderableId
OLMIS-6463; Added searching ftaps by orderableId
OLMIS-6463; Added searching ftaps by orderableId

    • -2
    • +11
    ./FacilityTypeApprovedProductSearchParamsDataBuilder.java
  1. … 11 more files in changeset.
OLMIS-6402: Renamed versionId to versionNumber in referencedata
OLMIS-6402: Renamed versionId to versionNumber in referencedata
OLMIS-6402: Renamed versionId field to versionNumber

    • -5
    • +5
    ./FacilityTypeApprovedProductsDataBuilder.java
  1. … 42 more files in changeset.
Feedback from QA: When using the POST facilityTypeApprovedProducts endpoint, one can't search for FTAPs using only the access token, or only the access token and the page and size parameters. One ...

Feedback from QA:

When using the POST facilityTypeApprovedProducts endpoint, one can't search for FTAPs using only the access token, or only the access token and the page and size parameters. One also has to provide the body. Usually, I think we provide each parameter separately, or we provide only the body.

What is the reason for this change?

What is the reason for this change?

OLMIS-6358: Moved pagination options to request body
OLMIS-6358: Moved pagination options to request body
OLMIS-6358: Moved pagination options to request body

    • -1
    • +14
    ./FacilityTypeApprovedProductSearchParamsDataBuilder.java
  1. … 6 more files in changeset.
Ok, even if we combined @Data with @ToString and @Equals, we can get rid of only 3 annotations here. Not worth.

Ok, even if we combined @Data with @ToString and @Equals, we can get rid of only 3 annotations here. Not worth.

OLMIS-6358: Create POST search for FTAP resource
OLMIS-6358: Create POST search for FTAP resource
the main issue with that annotation is that you can not specify if equals should call the method from the parent class.

the main issue with that annotation is that you can not specify if equals should call the method from the parent class.