openlmis-requisition

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
They are still too weak if for both search cases there is a match for all requisitions. We need to verify whether the search works correctly, which means whether a correct subset of requisitions is...

They are still too weak if for both search cases there is a match for all requisitions. We need to verify whether the search works correctly, which means whether a correct subset of requisitions is returned. This implies we need requisition with a various modified date set.

I added more tests

I added more tests

Could you add param annotations for those to in javadoc?

Could you add param annotations for those to in javadoc?

Alright

Alright

The whole class uses this name for parameters, because params is a map

The whole class uses this name for parameters, because params is a map

It looks like currently only one case is covered: both from and to dates are set, moreover, they are the same. We should cover other cases we are supporting too.

It looks like currently only one case is covered: both from and to dates are set, moreover, they are the same. We should cover other cases we are supporting too.

I wonder why we can't simply test for an exact modified date match (by query params passed, we should get an exact date, since from and to are the same)

I wonder why we can't simply test for an exact modified date match (by query params passed, we should get an exact date, since from and to are the same)

Ok, I can change these names to match convention.

Ok, I can change these names to match convention.

In this test the new requisition is a copy of another one. There are two requisitions in a list of receivedRequisitions with the same data and, since it is for start and end dates, this assertion s...

In this test the new requisition is a copy of another one. There are two requisitions in a list of receivedRequisitions with the same data and, since it is for start and end dates, this assertion simply tests, whether this check is true for both of them. There is the same assertion for createdDate.

Why is this method param called "key"?

Why is this method param called "key"?

Any reason for using different naming convention than with initiated date?

Any reason for using different naming convention than with initiated date?

Those two methods could be reduced to one line return (optional)

Those two methods could be reduced to one line return (optional)

Can you fix those variable names to indicate they work with modified date?

Can you fix those variable names to indicate they work with modified date?

Can you fix those variable names to indicate they work with initiated date?

Can you fix those variable names to indicate they work with initiated date?

What exactly are you trying to test here?

What exactly are you trying to test here?

missing changelog entry

missing changelog entry

missing tests?

missing tests?

OLMIS-5461 added startModifiedDate and endModifiedDate parameters to Requisitions API
OLMIS-5461 added startModifiedDate and endModifiedDate parameters to Requisitions API
OLMIS-5456: fixed problem with missing status changes
OLMIS-5456: fixed problem with missing status changes
OLMIS-5456: requisition status changes should contain the latest entries
OLMIS-5456: requisition status changes should contain the latest entries
For sort we are using join, not subquery. Please try to remove it and check if tests pass

For sort we are using join, not subquery. Please try to remove it and check if tests pass