Permission check for /approvedProducts endpoint

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

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](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

llewczynski@soldevelo.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.reid@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: openlmis-dev@googlegroups.com openlmis-dev@googlegroups.com on behalf of Łukasz Lewczyński llewczynski@soldevelo.com

Sent: Friday, January 27, 2017 5:50:28 AM

To: openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Permission check for /approvedProducts endpoint

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

llewczynski@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

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+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@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.

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?

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.bowersox-johnson@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

···

From: openlmis-dev@googlegroups.com on behalf of Nick Reid nick.reid@villagereach.org

Date: Friday, January 27, 2017 at 6:46 AM

To: Łukasz Lewczyński llewczynski@soldevelo.com, "openlmis-dev@googlegroups.com" openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Permission check for /approvedProducts endpoint

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.reid@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: openlmis-dev@googlegroups.com openlmis-dev@googlegroups.com on behalf of Łukasz Lewczyński llewczynski@soldevelo.com

Sent: Friday, January 27, 2017 5:50:28 AM

To: openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Permission check for /approvedProducts endpoint

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

llewczynski@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

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.

Chongsun Ahn | chongsun.ahn@villagereach.org<mailto:chongsun.ahn@villagereach.org>
Software Development Engineer

VillageReach<http://villagereach.org/> 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
www.villagereach.org<http://www.villagereach.org>
Connect on Facebook<https://www.facebook.com/pages/VillageReach/103205113922>, Twitter<https://twitter.com/VillageReach> and our Blog<http://villagereach.org/see-our-blog/thoughts-from-the-last-mile/>

···

On Jan 29, 2017, at 1:48 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org<mailto:brandon.bowersox-johnson@villagereach.org>> wrote:

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.bowersox-johnson@villagereach.org<mailto:brandon.bowersox-johnson@villagereach.org>
Software Development Manager, Information Systems Group

VillageReach<http://www.villagereach.org/> 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<http://www.villagereach.org/>
Connect on Facebook<https://www.facebook.com/VillageReach.org>, Twitter<https://twitter.com/VillageReach> and our Blog<http://www.villagereach.org/blog/>

From: <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>> on behalf of Nick Reid <nick.reid@villagereach.org<mailto:nick.reid@villagereach.org>>
Date: Friday, January 27, 2017 at 6:46 AM
To: Łukasz Lewczyński <llewczynski@soldevelo.com<mailto:llewczynski@soldevelo.com>>, "openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>" <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>>
Subject: Re: [openlmis-dev] Permission check for /approvedProducts endpoint

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.reid@villagereach.org<mailto:nick.reid@villagereach.org>
Friendly Neighborhood Spiderman, Information Systems Group

VillageReach<http://www.villagereach.org/> 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<http://www.villagereach.org/>

________________________________
From: openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com> <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>> on behalf of Łukasz Lewczyński <llewczynski@soldevelo.com<mailto:llewczynski@soldevelo.com>>
Sent: Friday, January 27, 2017 5:50:28 AM
To: openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>
Subject: [openlmis-dev] Permission check for /approvedProducts endpoint

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

--
<image001.png><http://soldevelo.com/>
Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com<mailto:llewczynski@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<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+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@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<https://groups.google.com/d/msgid/openlmis-dev/183A1ACA-F99B-4EA9-A8B4-50CC060A5090%40villagereach.org?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

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

···

From: Chongsun Ahn chongsun.ahn@villagereach.org

Date: Sunday, January 29, 2017 at 2:51 PM

To: Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org

Cc: Nick Reid nick.reid@villagereach.org, Łukasz Lewczyński llewczynski@soldevelo.com, "openlmis-dev@googlegroups.com" openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Permission check for /approvedProducts endpoint

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.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** 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

www.villagereach.org

Connect on Facebook, **Twitter ** and our Blog

On Jan 29, 2017, at 1:48 PM, Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org wrote:

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.bowersox-johnson@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

**From: **<openlmis-dev@googlegroups.com > on behalf of Nick Reid nick.reid@villagereach.org

**Date: **Friday, January 27, 2017 at 6:46 AM

**To: **Łukasz Lewczyński llewczynski@soldevelo.com, "openlmis-dev@googlegroups.com " openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] Permission check for /approvedProducts endpoint

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.reid@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: openlmis-dev@googlegroups.com <openlmis-dev@googlegroups.com > on behalf of Łukasz Lewczyński llewczynski@soldevelo.com

Sent: Friday, January 27, 2017 5:50:28 AM

To: openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Permission check for /approvedProducts endpoint

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 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

<image001.png>

Łukasz Lewczyński

Software Developer

llewczynski@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+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@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.

For more options, visit https://groups.google.com/d/optout.

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

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](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

llewczynski@soldevelo.com
On 01/30/2017 12:18 AM, Brandon Bowersox-Johnson wrote:

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

**From:
** Chongsun Ahn Sunday, January 29, 2017 at 2:51 PM Brandon Bowersox-Johnson Nick Reid , Łukasz Lewczyński , Re: [openlmis-dev] Permission check for /approvedProducts endpoint

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.
                        Chongsun Ahn | 
  •                          Software Development Engineer*
    

Village****Reach* ** 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](https://www.facebook.com/pages/VillageReach/103205113922),** **[Twitter](https://twitter.com/VillageReach) **                            and our **[Blog](http://villagereach.org/see-our-blog/thoughts-from-the-last-mile/)**
              On Jan 29, 2017, at 1:48 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org                  > wrote:
                  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 | 
  •                    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

                  Connect on [Facebook](https://www.facebook.com/VillageReach.org), [Twitter](https://twitter.com/VillageReach) and our [Blog](http://www.villagereach.org/blog/)

**From: **< > on behalf of Nick Reid <>

                    **Date: **                        Friday, January 27, 2017 at 6:46 AM

                    **To: **                        Łukasz Lewczyński <llewczynski@soldevelo.com                        >, "openlmis-dev@googlegroups.com                        " <openlmis-dev@googlegroups.com>

                    **Subject: **                        Re: [openlmis-dev] Permission check for /approvedProducts endpoint
                    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 |

                      *                              Friendly Neighborhood <s>Spiderman</s>                              , 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](http://www.villagereach.org/)

From: < > on behalf of Łukasz Lewczyński <>

                    **Sent:**                         Friday, January 27, 2017 5:50:28 AM

                    **To:** 

                    **Subject:**                         [openlmis-dev] Permission check for /approvedProducts endpoint

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

<image001.png>

Łukasz Lewczyński

                      Software Developer 

                      llewczynski@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](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 .

                                      To post to this group, send email to .

                                      To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/183A1ACA-F99B-4EA9-A8B4-50CC060A5090%40villagereach.org?utm_medium=email&utm_source=footer).

                                      For more options, visit [](https://groups.google.com/d/optout).

chongsun.ahn@villagereach.org
Date:
To: brandon.bowersox-johnson@villagereach.org
Cc: nick.reid@villagereach.orgllewczynski@soldevelo.com"openlmis-dev@googlegroups.com"openlmis-dev@googlegroups.com
Subject:

chongsun.ahn@villagereach.orgwww.villagereach.orgbrandon.bowersox-johnson@villagereach.orgwww.villagereach.orgopenlmis-dev@googlegroups.comnick.reid@villagereach.orgnick.reid@villagereach.orgopenlmis-dev@googlegroups.comopenlmis-dev@googlegroups.comllewczynski@soldevelo.comopenlmis-dev@googlegroups.comopenlmis-dev+unsubscribe@googlegroups.comopenlmis-dev@googlegroups.comhttps://groups.google.com/d/msgid/openlmis-dev/183A1ACA-F99B-4EA9-A8B4-50CC060A5090%40villagereach.orghttps://groups.google.com/d/optout