Questions about fulfillment rights

6 views
Skip to first unread message

Łukasz Lewczyński

unread,
Mar 7, 2018, 7:41:30 AM3/7/18
to OpenLMIS Dev
Hi all,

I would like to raise issues that we found on fulfillment views.

Basically on each fulfillment view we need to retrieve several resources like order, shipment, PoD, stock reasons and so on. The problem is that for each resource we need a correct right. For example to get order we need ORDERS_VIEW right, to get shipment we need SHIPMENTS_VIEW right and so on.

To resolve some issues we decided to add ability to retrieve a resource when we have a different right for example if a user has SHIPMENT_VIEW right the user will be able to retrieve a PoD - the resource is in the read only mode in this case.

We created two tickets to somehow resolve our problems on the UI. The first ticket (OLMIS-4262) is about adding a new filter option (order id) to PoD search endpoint. In my opinion because there is no connection between PoD and orders we should not add this filter option to endpoint. The second ticket (OLMIS-4263) is about copy shipment quantity from shipment to PoD. In this case we have a data duplication and PoD will contain data that are not required (they are needed to display them on UI).

I think we could resolve the right/role issues by simple using the expand pattern here. So for 
example the PoD endpoint return standard data but because UI needs data from the shipment we expand response for shipment data - same for order data. I am not sure why and when we decided to stop using the expand pattern.

So my proposals are:
* use expand pattern on shipment and PoD endpoints
* order endpoints should require only order rights: ORDERS_VIEW, ORDERS_EDIT
* shipment endpoints should require only shipment rights: SHIPMENT_VIEW, SHIPMENT_EDIT
* PoD endpoints should require only PoD rights: PODS_MANAGE, PODS_VIEW
* UI screens should use expand pattern instead of retrieving data from several endpoints

What do you think about it?

Regards,
Lukasz


Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

Nikodem Graczewski

unread,
Mar 7, 2018, 8:16:05 AM3/7/18
to Łukasz Lewczyński, OpenLMIS Dev
Hi Łukasz,

thumbs up for using expand pattern as those screens are the perfect example for that. This, along with the v7 UI Architecture and no caching for most of the endpoints(on the UI) forces us to do a lot of extra / duplicated calls to get all the stuff we need, which isn't the most performant thing ever. The other think about fulfillment screen is whether we should base all of them on orders... Currently for each screen we have to download the list of orders (different statuses for different screens), then search for shipment/PoD based on the order id and then, due to v7 architecture, download the shipment and then order(again),

Best Regards,
Nikodem

Nikodem Graczewski
Software Developer


--
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 openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Chongsun Ahn

unread,
Mar 7, 2018, 10:25:34 AM3/7/18
to Nikodem Graczewski, Łukasz Lewczyński, OpenLMIS Dev
Hey Łukasz,

The concept of different screens only requiring the corresponding rights (ORDERS_VIEW for orders screen, SHIPMENTS_VIEW for shipments screen, etc.) makes sense to me. The reason why we decided to stop using the expanded pattern is because it’s not very RESTful (see https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md#restful-interface-design--documentation) and it can create large responses where most of the data is not used by the API client. However, the expanded pattern is useful and perhaps necessary in some cases, as we see here—but we should not try to make it the default pattern.

So I would suggest supporting the expanded pattern as an option on GET shipment and PoD endpoints, but not to make it the default. We already use that pattern for getting an order. As for your other proposal points, they sound good.

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

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.

Sebastian Brudziński

unread,
Mar 7, 2018, 10:33:44 AM3/7/18
to OpenLMIS Dev, Chongsun Ahn, Nikodem Graczewski, Łukasz Lewczyński

Thanks for the quick reply, Chongsun.

Łukasz, can you create tickets for this work, based on the output of the discussion and add them to our current sprint?

Thanks,
Sebastian.


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

--

Sebastian Brudziński
Senior Software Developer / Team Leader
sbrud...@soldevelo.com

Łukasz Lewczyński

unread,
Mar 7, 2018, 10:39:27 AM3/7/18
to Sebastian Brudziński, OpenLMIS Dev, Chongsun Ahn, Nikodem Graczewski
I created two tickets:
  • OLMIS-4266 - to provide expand pattern to endpoints and use them by UI
  • OLMIS-4267 - to verify that endpoints required correct rights
Thanks,
Lukasz


Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com

On Wed, Mar 7, 2018 at 4:33 PM, Sebastian Brudziński <sbrud...@soldevelo.com> wrote:

Thanks for the quick reply, Chongsun.

Łukasz, can you create tickets for this work, based on the output of the discussion and add them to our current sprint?

Thanks,
Sebastian.

On 07.03.2018 16:25, Chongsun Ahn wrote:
Hey Łukasz,

The concept of different screens only requiring the corresponding rights (ORDERS_VIEW for orders screen, SHIPMENTS_VIEW for shipments screen, etc.) makes sense to me. The reason why we decided to stop using the expanded pattern is because it’s not very RESTful (see https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md#restful-interface-design--documentation) and it can create large responses where most of the data is not used by the API client. However, the expanded pattern is useful and perhaps necessary in some cases, as we see here—but we should not try to make it the default pattern.

So I would suggest supporting the expanded pattern as an option on GET shipment and PoD endpoints, but not to make it the default. We already use that pattern for getting an order. As for your other proposal points, they sound good.

Shalom,
Chongsun

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

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

--

Sebastian Brudziński
Senior Software Developer / Team Leader
sbrud...@soldevelo.com



SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

Łukasz Lewczyński

unread,
Mar 9, 2018, 9:19:38 AM3/9/18
to Sebastian Brudziński, OpenLMIS Dev, Chongsun Ahn, Nikodem Graczewski
It seems like because our fulfillment views use orders to display basic information, we will need to add orderId parameter to PoD search endpoint for OpenLMIS 3.3 to avoid retrieving shipment on Manage PoD view. From what I understand a person that will have access to Manage PoD screen and be able to confirm PoDs probably will not have rights to view/edit shipments - because he/she does not need to see them. With current approach the person will see an error message about missing permissions.

I am not very happy with that change (check the first mail in the topic) but it seems like there is no other way for now and there is no much time to create a new solutions.

Also I think we should rethink how to display shipments and PoDs on related views. Mainly because in the future we want to add ability to create a shipment without an order and because there will be no order what data should be displayed on UI?

Regards,
Lukasz


Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com

On Wed, Mar 7, 2018 at 4:39 PM, Łukasz Lewczyński <llewc...@soldevelo.com> wrote:
I created two tickets:
  • OLMIS-4266 - to provide expand pattern to endpoints and use them by UI
  • OLMIS-4267 - to verify that endpoints required correct rights
Thanks,
Lukasz


Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com

On Wed, Mar 7, 2018 at 4:33 PM, Sebastian Brudziński <sbrud...@soldevelo.com> wrote:

Thanks for the quick reply, Chongsun.

Łukasz, can you create tickets for this work, based on the output of the discussion and add them to our current sprint?

Thanks,
Sebastian.

On 07.03.2018 16:25, Chongsun Ahn wrote:
Hey Łukasz,

The concept of different screens only requiring the corresponding rights (ORDERS_VIEW for orders screen, SHIPMENTS_VIEW for shipments screen, etc.) makes sense to me. The reason why we decided to stop using the expanded pattern is because it’s not very RESTful (see https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md#restful-interface-design--documentation) and it can create large responses where most of the data is not used by the API client. However, the expanded pattern is useful and perhaps necessary in some cases, as we see here—but we should not try to make it the default pattern.

So I would suggest supporting the expanded pattern as an option on GET shipment and PoD endpoints, but not to make it the default. We already use that pattern for getting an order. As for your other proposal points, they sound good.

Shalom,
Chongsun

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

josh....@openlmis.org

unread,
Mar 13, 2018, 1:41:19 AM3/13/18
to OpenLMIS Dev
Just following up on this Lukasz, it sounds like we have an approach for the 3.3 release, but if I understand you correctly it introduces tighter coupling than we'd like?  And that tight coupling revolves around Order ids in resources such as shipments and proofs of delivery?  Do I have that correct?

Best,
Josh
To unsubscribe from this group and stop receiving emails from it, send an email to ...@googlegroups.com.
To post to this group, send email to ...@googlegroups.com.


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41


--
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 ...@googlegroups.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.

--

Sebastian Brudziński
Senior Software Developer / Team Leader
sbrud...@soldevelo.com



SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

Łukasz Lewczyński

unread,
Mar 13, 2018, 4:21:20 AM3/13/18
to josh....@openlmis.org, OpenLMIS Dev
Yes, all of our fulfillment views are based on order details. If we decide to provide non-order shipments, we will have a problem to display them on UI. Also in this case we create a connection between PoD and Order which was removed in OLMIS-3956.


Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com

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

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

Sebastian Brudziński

unread,
Mar 13, 2018, 5:38:49 AM3/13/18
to openlm...@googlegroups.com

Just to chime in - I wouldn't call it a connection. It's just the ability to search a proof of delivery by the orderId - which can yield no results and that's perfectly fine. I agree though that all our fulfillment UI views use order in one way or another - if we decide to ever support orderless shipments (which also produces orderless PODs) we will need to do redesign those screens.

Best regards,
Sebastian.


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

--

Sebastian Brudziński
Senior Software Developer / Team Leader
sbrud...@soldevelo.com

Paweł Albecki

unread,
Mar 13, 2018, 5:58:00 AM3/13/18
to Sebastian Brudziński, OpenLMIS Dev
I think we shouldn't worry to much about future orderless shipments from UI perspective. The API was designed to be orderless in future but for UI maybe we will want to have separate view.

Regards, 
Paweł

--

Sebastian Brudziński
Senior Software Developer / Team Leader
sbrud...@soldevelo.com



SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

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

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



--

Paweł Albecki
Software Developer
palb...@soldevelo.com

Reply all
Reply to author
Forward
0 new messages