Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
OLMIS-6855 Set pageable to no pagination for orderableFulfills
OLMIS-6855 Set pageable to no pagination for orderableFulfills
Feel free to add anyone else, I'm not sure who is on the Core team anymore.

Feel free to add anyone else, I'm not sure who is on the Core team anymore.

OLMIS-6855 Set pageable to no pagination for orderableFulfills

To avoid NPE in anything that calls /api/orderableFulfills.

OLMIS-6783 Fix Sonar issues

  1. … 8 more files in changeset.
OLMIS-6783 Update Spring Boot version to 2.x

* Update to Spring Boot 2.2.2

* Spring Security OAuth2 now needs to be reconfigured to same version (2.2.2)

* Update Flyway to version supported by Spring Boot 2.2 (Flyway 6.0.8)

* Spring Data and pagination methods have changed

* Pagination does not allow a null sort, and by default returns an object, rather than an array, so add CustomSortSerializer to serialize Sort

* Fix digest subscription DTO to serialize digestConfiguration property

* Update RAML parser and tester to fix random errors during integration tests

* Re-implement generation of Jasper reports.

* Add lombok gradle plugin in order to get build to recognize lombok annotations.

* Refactor Redis configuration to use new config classes.

* Hibernate Spatial using 5.3 instead of latest to use old JTS classes (issues with using new classes that are difficult to resolve).

* Remove migration integration tests as they are not necessary if migrations do not change.

* Change PageImplRepresentation to PageDto.

* Fix Jackson issue in supported programs in FacilityDto.

* Remove order by pageable SQL (not necessary in Spring Boot 2)

    • -3
    • +3
    ./FacilityTypeApprovedProductController.java
    • -6
    • +7
    ./OrderableDisplayCategoryController.java
  1. … 179 more files in changeset.
OLMIS-6749 RequisitionGroup update does no longer make any changes to Supervisory Nodes
OLMIS-6749 RequisitionGroup update does no longer make any changes to Supervisory Nodes
OLMIS-6749 RequisitionGroup update does no longer make any changes to Supervisory Nodes

Updating a resource should never introduce any changes in another resource other than

relationships between them. Requisition Groups update allowed changes to supervisory nodes,

morever those changes were only partial (child nodes were always cut off). This was fixed

and the RG update only allows switching the SN to another one now.

  1. … 1 more file in changeset.
Well... That's true, too. I was even looking into this matter before :/ I removed this unnecessary method.

Well... That's true, too. I was even looking into this matter before :/ I removed this unnecessary method.

OLMIS-6611: Removed unnecessary method

Why do we need a method that only calls another method? https://review.openlmis.org/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif

Why do we need a method that only calls another method?

True. The method was refactored.

True. The method was refactored.

OLMIS-6611: Refactored a method

Why do we need this step if we are returning null anyways?

Why do we need this step if we are returning null anyways?

Yes. I changed it to make sure it returns GMT. Note: when testing the api with Postman Last-Modified header was set with GMT.

Yes. I changed it to make sure it returns GMT. Note: when testing the api with Postman Last-Modified header was set with GMT.

I made sure that it returns GMT now.

I made sure that it returns GMT now.

I made sure that it returns GMT now.

I made sure that it returns GMT now.

So it looks like it may not make a lot of difference (if not make results worse) to use JPQL.

So it looks like it may not make a lot of difference (if not make results worse) to use JPQL.

Working on it. JPQL does not support LIMIT I think so I am looking into Pageable. EDIT: So it looks like it may not make a lot of difference (if not make results worse) to use JPQL.

Working on it. JPQL does not support LIMIT I think so I am looking into Pageable.
EDIT: So it looks like it may not make a lot of difference (if not make results worse) to use JPQL.

OLMIS-6611: Refactored to use GMT and removed one profiler

  1. … 5 more files in changeset.
That is not correct. Last-Modified and If-Modified-Since headers should always use GMT: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified https://developer.mozilla.org/en-US/d...
This is the date that we use in Last-Modified and If-Modified-Since, right? If so, it should use GMT: "HTTP dates are always expressed in GMT, never in local time." - https://developer.mozilla.org/...

This is the date that we use in Last-Modified and If-Modified-Since, right? If so, it should use GMT:
"HTTP dates are always expressed in GMT, never in local time." - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since

This is the date that we use in Last-Modified and If-Modified-Since, right? If so, it should use GMT: "HTTP dates are always expressed in GMT, never in local time." - https://developer.mozilla.org/...

This is the date that we use in Last-Modified and If-Modified-Since, right? If so, it should use GMT:
"HTTP dates are always expressed in GMT, never in local time." - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since

Yes. Of course. Changed it to use count-query.

Yes. Of course. Changed it to use count-query.