All right. Did something in that manner. Thanks https://review.openlmis.org/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif

All right. Did something in that manner. Thanks

OLMIS-6671: Introduced an additional method for better readibility

You could extract checks for column names to the first method, and then use this method + other two checks in the second method and use it in the if statement. Or something like that https://review...

You could extract checks for column names to the first method, and then use this method + other two checks in the second method and use it in the if statement. Or something like that

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.

Did some refactoring. I extracted this into separate private method, dividing as I left seemed logically - sourcetype & if a column is displayed and what is it's name (that should be treated as one...

Did some refactoring. I extracted this into separate private method, dividing as I left seemed logically - sourcetype & if a column is displayed and what is it's name (that should be treated as one thing I think). Could not extract it all into a separate method as Sonar wasn't allowing this.

OLMIS-6671: Refactored the method in attempt to fix Sonar errors

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-6671: Refactored methods

To improve readability we could: 1. merge this with an already existing if-statement 2. Extract this check to a separate private method

To improve readability we could:
1. merge this with an already existing if-statement
2. Extract this check to a separate private 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?

OLMIS-6671: Refactoring for string literals to be on the left side of string comparisions
OLMIS-6671: Refactoring for string literals to be on the left side of string comparisions
It looks like it isn't. Moreover, the whole findOrderablesWithLatestModifiedDate method is unnecessary.

It looks like it isn't. Moreover, the whole findOrderablesWithLatestModifiedDate method is unnecessary.

Is that still necessary?

Is that still necessary?

We should be using constants for all of the literals

We should be using constants for all of the literals

Unfortunately according to the documentation, CriteriaBuilder API doesn't support equals with ignore case

Unfortunately according to the documentation, CriteriaBuilder API doesn't support equals with ignore case

Yes, we can! https://review.openlmis.org/static/ogdo0b/2static/images/wiki/icons/emoticons/biggrin.gif

Yes, we can!

Can't we use the constant from the abstract class?

Can't we use the constant from the abstract class?

This is needed for yet another partition in retrieving FTAPs (line 146)

This is needed for yet another partition in retrieving FTAPs (line 146)

We should extract all of those literals as constants

We should extract all of those literals as constants