This page was created because of  OLMIS-1205 - Getting issue details... STATUS  and provide basic information about new rights that should be added into the requisition module.

New rights

The new rights have to be added into the requisition service to provide additional security for this module. The following rights are only related with a requisition endpoints and other parts of the module (like orders) are not covered in this page. Each endpoint related with CRUD operation on a requisition need unique right. The following table presents relation between endpoint and new rights.

* - a requisition can have different status when it is updated that why a user needs a different rights. The REQUISITION_CREATE right is needed when the requisition has INITIATED status, the REQUISITION_APPROVE right is needed when the requisition has AUTHORIZED status and the REQUISITION_AUTHORIZE right is needed when the requisition has SUBMITTED status.

If a user has the right REQUISITION_CREATE (or APPROVE, AUTHORIZE, DELETE), he/she will automatically have the REQUISITION_VIEW right in the system.

HTTP response

If a user has a required right(s), an endpoint should return appropriate data related with this endpoint and given parameters. Otherwise the endpoint should return HTTP 403 error code (Forbidden) with appropriate error message.

   The 403 (Forbidden) status code indicates that the server understood
   the request but refuses to authorize it.  A server that wishes to
   make public why the request has been forbidden can describe that
   reason in the response payload (if any).

The following table presents what message should be returned when the user does not have a right for the given endpoint.

How to check permission

The most easy way to check if the given user has the given permission is to use /users/{id}/hasRight endpoint. This endpoint returns a small object that contain only one bool property with the result. Also, because we need right ID we should use /rights/search endpoint to retrieve a correct right based on the provided name. In the first approach we could create/extend a service that will use those two endpoints and use it where it is needed (probably in Requisition Controller).