Nikodem Graczewski

OLMIS-5837: Made View Requisitions screen accessible to partner users
OLMIS-5837: Made View Requisitions screen accessible to partner users
OLMIS-5837: Refactored requisition-search.routes.spec.js
OLMIS-5837: Refactored requisition-search.routes.spec.js
OLMIS-5837: Refactored permission.service.spec.js
OLMIS-5837: Refactored permission.service.spec.js
I was unable to make this core proof to such changes... https://review.openlmis.org/static/ogdo0b/2static/images/wiki/icons/emoticons/sad.gif

I was unable to make this core proof to such changes...

OLMIS-5837: Added the ability to check for right based on role assignment instead of permission...
OLMIS-5837: Added the ability to check for right based on role assignment instead of permission...
Changelog for this already exists.

Changelog for this already exists.

OLMIS-5976: Moved the state resolve from home to the main state
OLMIS-5976: Moved the state resolve from home to the main state
But it feels inconsistent with the lines below doing a simple null check https://review.openlmis.org/static/ogdo0b/2static/images/wiki/icons/emoticons/sad.gif

But it feels inconsistent with the lines below doing a simple null check

I know, but what benefit does using Objects.nonNull gives us over null != item.getSupervisoryNodeId() and null != item.getProgramId()?

I know, but what benefit does using Objects.nonNull gives us over null != item.getSupervisoryNodeId() and null != item.getProgramId()?

What is the benefit of using Objects.nonNull over "null != item.getXXX()" here?

What is the benefit of using Objects.nonNull over "null != item.getXXX()" here?

Don't we have this somewhere?

Don't we have this somewhere?

Currently, the name and parameters suggest something different. It it is worth clearing that up.

Currently, the name and parameters suggest something different. It it is worth clearing that up.

Could we make it a hasMatchingHomeFacilitySupervisionRole?

Could we make it a hasMatchingHomeFacilitySupervisionRole?

OLMIS-5976: Added dependency injection for canAccess methods
OLMIS-5976: Added dependency injection for canAccess methods
Could we overload the method somehow? I see a lot of calls with all but one params being null.

Could we overload the method somehow? I see a lot of calls with all but one params being null.