Permission check for /approvedProducts endpoint
Łukasz Lewczyński
Hi
I am working on OLMIS-1586 (Enforce Right: Manage Facility).
Generally my task is to add to several facility endpoints check
for FACILITIES_MANAGE permission. The problem is with /facilies/{id}/approvedProducts
endpoint because it is used directly on UI in the product grid.
Currently when a requisition is initialized a list of approved
products are used to create a list of requisition line item.
Thanks that if products will be changed in the future in the reference-data
service the requisition will be still the same.
Non-full supply products are added manually on UI so when products
will be changed in the reference-data service the
requisition will also be changed (not directly but because of new
data in approved product). Are we okay with that?
If we agree with that then I user that fill a requisition will
need a FACILITIES_MANAGE permission to get a list of
non-full supply products. Other options is to use another right
for this endpoint or modify the way we get non-full supply
products on UI.
If the requisition should not be changed (when the non-full supply
product is changed) then I think we could simple add non-full
supply products to the requisition when it is initialized. Because
of that the UI will not have to call endpoint from the
reference-data service to get the list and the user will not
need additional permission because the requisition service
will communicate with the reference-data service by
tokens.
Regards,
Łukasz
Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia
http://www.soldevelo.com
Place of registration: Regional Court for the City of
Gdansk KRS: 0000332728, TAX ID:
PL5862240331, REGON: 220828585, Share capital:
60,000.00 PLN
Nick Reid
I'm a fan of putting more data into the requisition endpoint... as long as that is a well documented extension point. Freezing the list of products available at the moment the requisition was initialized would be kinda cool — I'm not sure how helpful, but I feel like someone adding a new product that needs to be in the requisition is rare.
I feel another solution would be to only put FACILITIES_MANAGE on some request methods of -- but that could get into a wonky pattern that feels difficult to remember/describe
Nick Reid | nick...@villagereach.org
Friendly Neighborhood
Spiderman, Information Systems Group
VillageReach Starting
at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
www.villagereach.org
Sent: Friday, January 27, 2017 5:50:28 AM
To: openlm...@googlegroups.com
Subject: [openlmis-dev] Permission check for /approvedProducts endpoint
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/6c31bced-6982-85a9-c69f-da35dc787a0e%40soldevelo.com.
For more options, visit https://groups.google.com/d/optout.
Brandon Bowersox-Johnson
Hi Łukasz and Nick,
I also support the idea of putting this logic into the Requisition endpoint. When a user initiates the requisition, that Requisition endpoint can call the Reference Data service and include the list of products available at that time.
However, I believe that option does not work for non-full-supply products. An alternative solution might work better for both non-full and full-supply products: Consider adding a permission like “FACILITIES_VIEW_MINE” that looks at a user’s facility and works similar to Requisition permissions. If they have permissions to initiate or edit a requisition for a given facility and program, then also allow them to View that facility’s approved products. Don’t allow them to edit (MANAGE) the facility or the product list, just allow them to view it. Only allow that at facilities where they have Requisition permissions.
You raised another question:
Q: If products will be changed in the future the existing requisitions will stay the same. Is that OK?
A: Yes. I think that’s a good thing.
Should the 3 of us jump on Skype to solve this together? I like using this email list usually, but it seems like a final answer here is time-sensitive before the end of the sprint (Wednesday). Chongsun has also worked a lot on the Role/Rights model, so perhaps he has a solution in mind.
-Brandon
Brandon Bowersox-Johnson | brandon.bowe...@villagereach.org
Software Development Manager, Information Systems Group
PHONE: 1.217.766.1166 FAX: 1.206.860.6972
SKYPE: brandonbowersox
Chongsun Ahn
Shalom,
Chongsun
--
There are 10 kinds of people in this world; those who understand binary, and those who don’t.
Hi
I am working on OLMIS-1586 (Enforce Right: Manage Facility). Generally my task is to add to several facility endpoints check for FACILITIES_MANAGE permission. The problem is with /facilies/{id}/approvedProductsendpoint because it is used directly on UI in the product grid.
Currently when a requisition is initialized a list of approved products are used to create a list of requisition line item. Thanks that if products will be changed in the future in the reference-data service the requisition will be still the same.
Non-full supply products are added manually on UI so when products will be changed in the reference-data servicethe requisition will also be changed (not directly but because of new data in approved product). Are we okay with that?
If we agree with that then I user that fill a requisition will need a FACILITIES_MANAGE permission to get a list of non-full supply products. Other options is to use another right for this endpoint or modify the way we get non-full supply products on UI.
If the requisition should not be changed (when the non-full supply product is changed) then I think we could simple add non-full supply products to the requisition when it is initialized. Because of that the UI will not have to call endpoint from the reference-data service to get the list and the user will not need additional permission because the requisition service will communicate with the reference-data service by tokens.
Regards,
Łukasz
Łukasz Lewczyński
Software Developer
llewc...@soldevelo.comSolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia
http://www.soldevelo.com
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/183A1ACA-F99B-4EA9-A8B4-50CC060A5090%40villagereach.org.
Brandon Bowersox-Johnson
Hi All,
I like Chongsun’s suggestion that we add the list of available non-full-supply products into the Requisition data structure during initiation of the Requisition. We would just need to make sure this data structure has enough information to allow the UI modal window where users select and add non-full-supply products.
This way the UI will not need to hit the Reference Data service for product information. All of the product information would be included in the requisition data by the Requisition Service which uses a service-level token to get the information when a requisition is initiated.
Łukasz, I’m hoping you can let us know if this provides enough answers for you to proceed with the ticket.
-Brandon
Łukasz Lewczyński
Hi,
I would try to provide Chongsun’s suggestion to the code. I will
let you know if I have any questions.
- Łukasz
Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia
http://www.soldevelo.com
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN