Dashboard

sonar always shows as critical vulnerability when to field that has "password" in name is assigned some static text

sonar always shows as critical vulnerability when to field that has "password" in name is assigned some static text

fix sonar issues
fix sonar issues
add unused imports to pmd ruleset and fix some trivial sonar issues

sonar issue

sonar issue

no need to throw exception, empty block would work. sonar shows it as "not covered by tests".. Maybe this would be better https://projectlombok.org/api/lombok/NoArgsConstructor.html#access-- with p...

no need to throw exception, empty block would work. sonar shows it as "not covered by tests"..
Maybe this would be better https://projectlombok.org/api/lombok/NoArgsConstructor.html#access-- with private access

change & to &&

change & to &&

sonar issue

why it's better?

why it's better?

same as above

same as above

Sorry, had to reopen this. I didn't reviewed this enough before. Add your recent changes to review too.

Sorry, had to reopen this. I didn't reviewed this enough before. Add your recent changes to review too.

the description should be more clear that we search by conjunction

the description should be more clear that we search by conjunction

we should check if it's called with proper params. Tests are wrong, that's why some bug was discovered by QA, not before

we should check if it's called with proper params. Tests are wrong, that's why some bug was discovered by QA, not before

OLMIS-3179: made search catalog items restful
OLMIS-3179: made search catalog items restful
Okay, the new stuff for that all looks good.

Okay, the new stuff for that all looks good.

I added new changes; the main thing is adding Pageable in the RequisitionRepositoryImpl. This is so we do paging in the database, and only return results specified by the client.

I added new changes; the main thing is adding Pageable in the RequisitionRepositoryImpl. This is so we do paging in the database, and only return results specified by the client.

pass params before reload state for performance

OLMIS-3187 Update repository method to do db paging

Do paging in the database, so that we do not return all results and then page at the end. This should be slightly more performant, depending on the number of results returned.

It is sort of on purpose, but now that I think about it again, I think it's worth it to do all paging in the database, instead of just paging the results returned from the database.

It is sort of on purpose, but now that I think about it again, I think it's worth it to do all paging in the database, instead of just paging the results returned from the database.

I think I might actually make this method paginated; it seems like it's worth it for the work.

I think I might actually make this method paginated; it seems like it's worth it for the work.

Okay, thanks!

Okay, thanks!

Nick Reid I would say that a specific test is better than none (they have a chance to catch some bugs, and those test aren't really that specific), but I'm OK with dropping HTML tests, as we don't ...

Nick Reid I would say that a specific test is better than none (they have a chance to catch some bugs, and those test aren't really that specific), but I'm OK with dropping HTML tests, as we don't have any pattern for them. I was hoping we could keep HTML test as some kind of integration tests, but I guess we don't really want them at the moment.

Add Facility "button" ??

Add Facility "button" ??

Hmm yea, this 'environment' looks cool, not sure how it could be implemented. Nikodem Graczewski So for now just move message declaration before confirm modal call.

Hmm yea, this 'environment' looks cool, not sure how it could be implemented.
Nikodem Graczewski So for now just move message declaration before confirm modal call.

These unit tests still scare the hell out of me – they feel like they are overly specific and defensive (if thats a thing) – where as good unit tests are supposed to maintain a contract and ignore ...

These unit tests still scare the hell out of me – they feel like they are overly specific and defensive (if thats a thing) – where as good unit tests are supposed to maintain a contract and ignore the inner workings of the implementation as much as possible

Are you sure this is a good practice?

LGTM

LGTM