Permission check for /approvedProducts endpoint

7 views
Skip to first unread message

Łukasz Lewczyński

unread,
Jan 27, 2017, 8:50:35 AM1/27/17
to openlm...@googlegroups.com

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

unread,
Jan 27, 2017, 9:46:21 AM1/27/17
to Łukasz Lewczyński, openlm...@googlegroups.com

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



From: openlm...@googlegroups.com <openlm...@googlegroups.com> on behalf of Łukasz Lewczyński <llewc...@soldevelo.com>
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

unread,
Jan 29, 2017, 4:48:10 PM1/29/17
to Nick Reid, Łukasz Lewczyński, openlm...@googlegroups.com

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

 

 

VillageReach Starting at the Last Mile

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

PHONE: 1.217.766.1166 FAX: 1.206.860.6972

SKYPE: brandonbowersox

www.villagereach.org

Connect on Facebook, Twitter and our Blog

Chongsun Ahn

unread,
Jan 29, 2017, 5:51:51 PM1/29/17
to Brandon Bowersox-Johnson, Nick Reid, Łukasz Lewczyński, openlm...@googlegroups.com
Hey guys,

Sorry I wasn’t able to reply to this earlier.

So from looking at the problem, I don’t see why non full supply products should be different from full supply products here. Products are products; being full supply or non full supply only varies by program. Just like for full supply products, a requisition should know a list of approved non full supply products. If product information changes, that requisition should not change what products were approved at that time, full supply or non full supply.

As a result, it makes sense to me that the Requisition Service would request the list of non full supply approved products for the facility from the Reference Data Service, rather than the UI doing it. It can then pass that list back to the UI to show on the non full supply tab.

Shalom,
Chongsun

-- ​
There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Software Development Engineer
 
VillageReach Starting at the Last Mile
2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA
DIRECT: 1.206.512.1536   CELL: 1.206.910.0973   FAX: 1.206.860.6972
SKYPE: chongsun.ahn.vr
Connect on Facebook, Twitter and our Blog
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.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

 
 

-- 

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.

Brandon Bowersox-Johnson

unread,
Jan 29, 2017, 6:18:19 PM1/29/17
to Chongsun Ahn, Łukasz Lewczyński, Nick Reid, openlm...@googlegroups.com

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

unread,
Jan 30, 2017, 5:49:36 AM1/30/17
to Brandon Bowersox-Johnson, Chongsun Ahn, Nick Reid, openlm...@googlegroups.com

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

Reply all
Reply to author
Forward
0 new messages