Questions about fulfillment rights

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


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
Software Developer
llewczynski@soldevelo.com

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


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

···

On Wed, Mar 7, 2018 at 1:41 PM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

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
llewczynski@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 openlmis-dev@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.

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

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.

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 Wed, Mar 7, 2018 at 1:41 PM, Łukasz Lewczyński
llewczynski@soldevelo.com wrote:

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

llewczynski@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
openlmis-dev@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
.

**Nikodem Graczewski
**

Software Developer

ngraczewski@soldevelo.com

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

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 Mar 7, 2018, at 5:16 AM, Nikodem Graczewski <ngraczewski@soldevelo.com              > wrote:

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*
    

ngraczewski@soldevelo.com

              On Wed, Mar 7, 2018 at 1:41 PM, Łukasz Lewczyński
                <llewczynski@soldevelo.com>
              wrote:

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

                            llewczynski@soldevelo.com
                **![](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

                    SolDevelo** Sp. z o.o. [LLC] / [
                    www.soldevelo.com](http://www.soldevelo.com/)

                  [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)                      /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
                      openlmis-dev@googlegroups.com.

                    To view this discussion on the web visit [
                      https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com?utm_medium=email&utm_source=footer).

                    For more options, visit [
                      https://groups.google.com/d/optout](https://groups.google.com/d/optout).
          **![](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

              SolDevelo** Sp. z o.o. [LLC] / [
              www.soldevelo.com](http://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
            openlmis-dev@googlegroups.com.

          To view this discussion on the web visit [

https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVasVLqnTnq2v1mKWub2mgbS8%3DOMkixYSx1dFoGn4Ja_g%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVasVLqnTnq2v1mKWub2mgbS8%3DOMkixYSx1dFoGn4Ja_g%40mail.gmail.com?utm_medium=email&utm_source=footer).

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

  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/67768C56-97A2-4E1C-83FC-C420B964C741%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/67768C56-97A2-4E1C-83FC-C420B964C741%40villagereach.org?utm_medium=email&utm_source=footer).

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


Sebastian Brudziński

              Senior Software Developer / Team Leader


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
sbrudzinski@soldevelo.com

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


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

···

On Wed, Mar 7, 2018 at 4:33 PM, Sebastian Brudziński sbrudzinski@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](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.

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 Mar 7, 2018, at 5:16 AM, Nikodem Graczewski <ngraczewski@soldevelo.com              > wrote:

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

              SolDevelo** Sp. z o.o. [LLC] / [
              www.soldevelo.com](http://www.soldevelo.com/)

            [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)/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
            openlmis-dev@googlegroups.com.

          To view this discussion on the web visit [

https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVasVLqnTnq2v1mKWub2mgbS8%3DOMkixYSx1dFoGn4Ja_g%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVasVLqnTnq2v1mKWub2mgbS8%3DOMkixYSx1dFoGn4Ja_g%40mail.gmail.com?utm_medium=email&utm_source=footer).

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

  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/67768C56-97A2-4E1C-83FC-C420B964C741%40villagereach.org.

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


Sebastian Brudziński

              Senior Software Developer / Team Leader

     sbrudzinski@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
Software Developer
llewczynski@soldevelo.com

** Nikodem Graczewski

                                       **
  •                                          Software Developer*
    

ngraczewski@soldevelo.com

              On Wed, Mar 7, 2018 at 1:41 PM, Łukasz Lewczyński
                <llewczynski@soldevelo.com>
              wrote:

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

                            llewczynski@soldevelo.com
                **

                    SolDevelo** Sp. z o.o. [LLC] / [
                    www.soldevelo.com](http://www.soldevelo.com/)

                  [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)                      /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
                      openlmis-dev@googlegroups.com.

                    To view this discussion on the web visit [
                      https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com?utm_medium=email&utm_source=footer).

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

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


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

···

On Wed, Mar 7, 2018 at 4:39 PM, Łukasz Lewczyński llewczynski@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
llewczynski@soldevelo.com

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

On Wed, Mar 7, 2018 at 4:33 PM, Sebastian Brudziński sbrudzinski@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](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.

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 Mar 7, 2018, at 5:16 AM, Nikodem Graczewski <ngraczewski@soldevelo.com              > wrote:

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

              SolDevelo** Sp. z o.o. [LLC] / [
              www.soldevelo.com](http://www.soldevelo.com/)

            [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)/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
            openlmis-dev@googlegroups.com.

          To view this discussion on the web visit [

https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVasVLqnTnq2v1mKWub2mgbS8%3DOMkixYSx1dFoGn4Ja_g%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVasVLqnTnq2v1mKWub2mgbS8%3DOMkixYSx1dFoGn4Ja_g%40mail.gmail.com?utm_medium=email&utm_source=footer).

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

  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/67768C56-97A2-4E1C-83FC-C420B964C741%40villagereach.org.

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


Sebastian Brudziński

              Senior Software Developer / Team Leader

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

                                       **
  •                                          Software Developer*
    

ngraczewski@soldevelo.com

              On Wed, Mar 7, 2018 at 1:41 PM, Łukasz Lewczyński
                <llewczynski@soldevelo.com>
              wrote:

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

                            llewczynski@soldevelo.com
                **

                    SolDevelo** Sp. z o.o. [LLC] / [
                    www.soldevelo.com](http://www.soldevelo.com/)

                  [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)                      /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
                      openlmis-dev@googlegroups.com.

                    To view this discussion on the web visit [
                      https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com?utm_medium=email&utm_source=footer).

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

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

···

On Friday, March 9, 2018 at 6:19:38 AM UTC-8, Łukasz Lewczyński wrote:

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

Chongsun Ahn | chongs...@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 Mar 7, 2018, at 5:16 AM, Nikodem Graczewski <ngrac...@soldevelo.com              > wrote:

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*
    

ngrac...@soldevelo.com

              On Wed, Mar 7, 2018 at 1:41 PM, Łukasz Lewczyński > > > > >                     <llewc...@soldevelo.com> > > > > >                   wrote:

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](http://www.soldevelo.com/)

                  [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)                      /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
                    ...@googlegroups.com.

                    To post to this group, send email to
              ...@googlegroups.com.

                    To view this discussion on the web visit [
                      https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com?utm_medium=email&utm_source=footer).

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

              SolDevelo** Sp. z o.o. [LLC] / [
              www.soldevelo.com](http://www.soldevelo.com/)

            [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)/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.

          To view this discussion on the web visit [

https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVasVLqnTnq2v1mKWub2mgbS8%3DOMkixYSx1dFoGn4Ja_g%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVasVLqnTnq2v1mKWub2mgbS8%3DOMkixYSx1dFoGn4Ja_g%40mail.gmail.com?utm_medium=email&utm_source=footer).

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

  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/67768C56-97A2-4E1C-83FC-C420B964C741%40villagereach.org.

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


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


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

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.


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

···

On Tue, Mar 13, 2018 at 6:41 AM, josh.zamor@openlmis.org wrote:

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

On Friday, March 9, 2018 at 6:19:38 AM UTC-8, Łukasz Lewczyński wrote:

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

Chongsun Ahn | chongs...@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 Mar 7, 2018, at 5:16 AM, Nikodem Graczewski <ngrac...@soldevelo.com              > wrote:

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*
    

ngrac...@soldevelo.com

              On Wed, Mar 7, 2018 at 1:41 PM, Łukasz Lewczyński
                <llewc...@soldevelo.com>
              wrote:

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](http://www.soldevelo.com/)

                  [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)                      /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
                    ...@googlegroups.com.

                    To post to this group, send email to
              ...@googlegroups.com.

                    To view this discussion on the web visit [
                      https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com?utm_medium=email&utm_source=footer).

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

              SolDevelo** Sp. z o.o. [LLC] / [
              www.soldevelo.com](http://www.soldevelo.com/)

            [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)/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.

          To view this discussion on the web visit [

https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVasVLqnTnq2v1mKWub2mgbS8%3DOMkixYSx1dFoGn4Ja_g%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVasVLqnTnq2v1mKWub2mgbS8%3DOMkixYSx1dFoGn4Ja_g%40mail.gmail.com?utm_medium=email&utm_source=footer).

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

  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/67768C56-97A2-4E1C-83FC-C420B964C741%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/67768C56-97A2-4E1C-83FC-C420B964C741%40villagereach.org?utm_medium=email&utm_source=footer).

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


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

**
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 openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/283d3fd4-df20-445f-938b-a4572d777e34%40googlegroups.com.

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

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.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.
···

On 13.03.2018 09:20, Łukasz Lewczyński wrote:

      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](https://openlmis.atlassian.net/browse/OLMIS-3956).

Łukasz Lewczyński

                Software Developer

                llewczynski@soldevelo.com

On Tue, Mar 13, 2018 at 6:41 AM, josh.zamor@openlmis.org
wrote:

            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



              On Friday, March 9, 2018 at 6:19:38 AM UTC-8, Łukasz Lewczyński wrote:
                  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](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.
                                                      Chongsun Ahn | chongs...@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](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 Mar 7, 2018, at 5:16 AM, Nikodem Graczewski <ngrac...@soldevelo.com                                                    > wrote:
                                                  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*
    

ngrac...@soldevelo.com

                                                    On Wed, Mar 7, 2018 at 1:41 PM, Łukasz Lewczyński
                                                      <llewc...@soldevelo.com>
                                                    wrote:

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](http://www.soldevelo.com/)

                                                      [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)/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

...@googlegroups.com.

                                                      To post to this group, send email to

...@googlegroups.com.

                                                      To view this discussion on the web visit [ https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com?utm_medium=email&utm_source=footer).

                                                      For more options, visit [

https://groups.google.com/d/optout](https://groups.google.com/d/optout).

                                                **

                                                    SolDevelo**
                                                  Sp. z o.o. [LLC] / [
                                                    www.soldevelo.com](http://www.soldevelo.com/)

                                                  [                                                        Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)                                                      /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.

                                                To view this discussion on the web visit [

https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVasVLqnTnq2v1mKWub2mgbS8%3DOMkixYSx1dFoGn4Ja_g%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVasVLqnTnq2v1mKWub2mgbS8%3DOMkixYSx1dFoGn4Ja_g%40mail.gmail.com?utm_medium=email&utm_source=footer).

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

                                        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/67768C56-97A2-4E1C-83FC-C420B964C741%40villagereach.org.

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


Sebastian Brudziński

                                                                                          Senior Software Developer / Team Leader

                                           sbrud...@soldevelo.com
                                    **

                                        SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

                                      [                                            Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)                                          /98, 81-451, Gdynia, Poland

                                      Phone:                                             +48 58 782 45 40 / Fax:                                             +48 58 782 45 41
                **

                    SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

                  [                        Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)/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 openlmis-dev@googlegroups.com.


          To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/283d3fd4-df20-445f-938b-a4572d777e34%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/283d3fd4-df20-445f-938b-a4572d777e34%40googlegroups.com?utm_medium=email&utm_source=footer).


              For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
  **![](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

      SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://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 openlmis-dev@googlegroups.com.

  To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wTbvq1MjbzSLmwun-rP-czW8-k8H4A%2BaRD3foAziMX2A%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wTbvq1MjbzSLmwun-rP-czW8-k8H4A%2BaRD3foAziMX2A%40mail.gmail.com?utm_medium=email&utm_source=footer).

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


Sebastian Brudziński

              Senior Software Developer / Team Leader


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
sbrudzinski@soldevelo.com

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ł


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

···

On Tue, Mar 13, 2018 at 10:38 AM, Sebastian Brudziński sbrudzinski@soldevelo.com wrote:

  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.
  On 13.03.2018 09:20, Łukasz Lewczyński wrote:
      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](https://openlmis.atlassian.net/browse/OLMIS-3956).
  **![](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

      SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

    [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)/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 openlmis-dev@googlegroups.com.

  To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wTbvq1MjbzSLmwun-rP-czW8-k8H4A%2BaRD3foAziMX2A%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wTbvq1MjbzSLmwun-rP-czW8-k8H4A%2BaRD3foAziMX2A%40mail.gmail.com?utm_medium=email&utm_source=footer).

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

      Sebastian Brudziński

              Senior Software Developer / Team Leader

sbrudzinski@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 openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/180e4ff2-7d93-a57e-9cd5-c11074657b16%40soldevelo.com.

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

Łukasz Lewczyński

                Software Developer

                llewczynski@soldevelo.com

On Tue, Mar 13, 2018 at 6:41 AM, josh.zamor@openlmis.org
wrote:

            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



              On Friday, March 9, 2018 at 6:19:38 AM UTC-8, Łukasz Lewczyński wrote:
                  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](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.
                                                      Chongsun Ahn | chongs...@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](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 Mar 7, 2018, at 5:16 AM, Nikodem Graczewski <ngrac...@soldevelo.com                                                    > wrote:
                                                  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*
    

ngrac...@soldevelo.com

                                                    On Wed, Mar 7, 2018 at 1:41 PM, Łukasz Lewczyński
                                                      <llewc...@soldevelo.com>
                                                    wrote:

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](http://www.soldevelo.com/)

                                                      [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)/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

...@googlegroups.com.

                                                      To post to this group, send email to

...@googlegroups.com.

                                                      To view this discussion on the web visit [ https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53x6Gr76fP_F1Y2jKcjhBuKfxwsb7_kOnrb0POeoJo197g%40mail.gmail.com?utm_medium=email&utm_source=footer).

                                                      For more options, visit [

https://groups.google.com/d/optout](https://groups.google.com/d/optout).

                                                **

                                                    SolDevelo**
                                                  Sp. z o.o. [LLC] / [
                                                    www.soldevelo.com](http://www.soldevelo.com/)

                                                  [                                                        Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)                                                      /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.

                                                To view this discussion on the web visit [

https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVasVLqnTnq2v1mKWub2mgbS8%3DOMkixYSx1dFoGn4Ja_g%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVasVLqnTnq2v1mKWub2mgbS8%3DOMkixYSx1dFoGn4Ja_g%40mail.gmail.com?utm_medium=email&utm_source=footer).

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

                                        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/67768C56-97A2-4E1C-83FC-C420B964C741%40villagereach.org.

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


Sebastian Brudziński

                                                                                          Senior Software Developer / Team Leader

                                           sbrud...@soldevelo.com
                                    **

                                        SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

                                      [                                            Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)                                          /98, 81-451, Gdynia, Poland

                                      Phone:                                             +48 58 782 45 40 / Fax:                                             +48 58 782 45 41
                **

                    SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

                  [                        Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)/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 openlmis-dev@googlegroups.com.


          To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/283d3fd4-df20-445f-938b-a4572d777e34%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/283d3fd4-df20-445f-938b-a4572d777e34%40googlegroups.com?utm_medium=email&utm_source=footer).


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

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com