Problem solving proposal for view orders requesting facility filter select

Hi all,

I am working on MW-452 / OLMIS-2724 and I would like to propose a new endpoint that will retrieve requesting facilities based on supplying facility id. The result of this endpoint will be populated to the Requesting facility filter option on UI. The proposed endpoint can be found here.

Base assumptions:

  • the endpoint checks if a user has VIEW_ORDERS right

  • the endpoint retrieves requestingFacilityId property from all orders that supplyingFacilityId match provided ID. Thanks that the endpoint should be fast because it will not retrieve full order object but only a single field.

  • the endpoint asks reference-data service for minimal facility data - for UI we need only facility name. Because of that I propose a new endpoint in the reference-data service: link

Any thoughts?

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

Sounds ok, but I think we already have an endpoint that returns name/id representations for facilities.

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, Aug 22, 2017 at 4:33 PM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi all,

I am working on MW-452 / OLMIS-2724 and I would like to propose a new endpoint that will retrieve requesting facilities based on supplying facility id. The result of this endpoint will be populated to the Requesting facility filter option on UI. The proposed endpoint can be found here.

Base assumptions:

  • the endpoint checks if a user has VIEW_ORDERS right
  • the endpoint retrieves requestingFacilityId property from all orders that supplyingFacilityId match provided ID. Thanks that the endpoint should be fast because it will not retrieve full order object but only a single field.
  • the endpoint asks reference-data service for minimal facility data - for UI we need only facility name. Because of that I propose a new endpoint in the reference-data service: link

Any thoughts?

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/CAAdp53xfxQJ7kA335noUbahPEUDn99kSCFOenLMwvAj%3DWobqtQ%40mail.gmail.com.

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

Paweł Gesek

    Technical Project Manager

     pgesek@soldevelo.com / +48 690 020 875

Hey Łukasz,

This seems fine to me; however, I would recommend that we not name the schema minimalFacilityDto. Since something that just has id and name is generic enough that it does not have to be for just a facility, we could give it a generic name. In the Reference Data Service, we have the same thing, but it is called namedResource.

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

···

Łukasz Lewczyński

Software Developer

llewczynski@soldevelo.com

@Pawel: We have endpoint but it returns all facilities, so there could be a situation in which the fulfillment service will need name for one facility but reference-data will return all facilities (in Malawi there is about 600).

@Chongsun: I will change the name of resource.

If there is no other comments/questions then I will start work on it.


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, Aug 22, 2017 at 6:03 PM, Chongsun Ahn chongsun.ahn@villagereach.org wrote:

Hey Łukasz,

This seems fine to me; however, I would recommend that we not name the schema minimalFacilityDto. Since something that just has id and name is generic enough that it does not have to be for just a facility, we could give it a generic name. In the Reference Data Service, we have the same thing, but it is called namedResource.

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 Aug 22, 2017, at 7:33 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi all,

I am working on MW-452 / OLMIS-2724 and I would like to propose a new endpoint that will retrieve requesting facilities based on supplying facility id. The result of this endpoint will be populated to the Requesting facility filter option on UI. The proposed endpoint can be found here.

Base assumptions:

  • the endpoint checks if a user has VIEW_ORDERS right

  • the endpoint retrieves requestingFacilityId property from all orders that supplyingFacilityId match provided ID. Thanks that the endpoint should be fast because it will not retrieve full order object but only a single field.

  • the endpoint asks reference-data service for minimal facility data - for UI we need only facility name. Because of that I propose a new endpoint in the reference-data service: link

Any thoughts?

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/CAAdp53xfxQJ7kA335noUbahPEUDn99kSCFOenLMwvAj%3DWobqtQ%40mail.gmail.com
.

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

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

These don’t look very restful. A start to making them more restful is to not include the facility resources name. While the UI might need the facility name, its better and more performant to not include it - I’ll try to post why that is soon.

I’m late to getting to this message, but I would encourage looking at these end points to make them more restful resources rather than remote procedure calls. I’ll check in again in the morning here to lend any support needed.

···

On Tue, Aug 22, 2017 at 6:03 PM, Chongsun Ahn
chongsun.ahn@villagereach.org wrote:

Hey Łukasz,

This seems fine to me; however, I would recommend that we not name the schema minimalFacilityDto. Since something that just has id and name is generic enough that it does not have to be for just a facility, we could give it a generic name. In the Reference Data Service, we have the same thing, but it is called namedResource.

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 Aug 22, 2017, at 7:33 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi all,

I am working on MW-452 / OLMIS-2724 and I would like to propose a new endpoint that will retrieve requesting facilities based on supplying facility id. The result of this endpoint will be populated to the Requesting facility filter option on UI. The proposed endpoint can be found here.

Base assumptions:

  • the endpoint checks if a user has VIEW_ORDERS right

  • the endpoint retrieves requestingFacilityId property from all orders that supplyingFacilityId match provided ID. Thanks that the endpoint should be fast because it will not retrieve full order object but only a single field.

  • the endpoint asks reference-data service for minimal facility data - for UI we need only facility name. Because of that I propose a new endpoint in the reference-data service: link

Any thoughts?

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/CAAdp53xfxQJ7kA335noUbahPEUDn99kSCFOenLMwvAj%3DWobqtQ%40mail.gmail.com
.

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

Łukasz Lewczyński

Software Developer

llewczynski@soldevelo.com

Josh might weigh in with more details…but I also wanted to share a perspective.

The original suggestion from Lukasz blurs or combines two different services: It has a Fulfillment endpoint to query Orders and get a list of facilities from that set of orders. That proposed endpoint uses RefData to look up facility names. The Fulfillment endpoint would return a MinimalFacilityDto. So the end result is a Fulfillment endpoint returning RefData resources.

I feel like it would help to dis-entangle whether we are really querying a list of Orders or a list of Facilities. We can separate out which service is responsible for which type of resource.

Here is one suggestion: perhaps take Fulfillment out of the picture here. We can just have ReferenceData service create a list of RequestingFacilities. After all, ReferenceData is the service that is currently responsible for knowing who supplies whom—ReferenceData owns the Requisition Groups, Supervisory Nodes, and Supply Lines, along with the Facility list. So we can make an endpoint in ReferenceData that can return all of the Requesting Facilities.

The benefit of this solution is that we keep separate lines of responsibility by service. It should be more RESTful and less fragile to maintain. I know this suggestion is a slight change in the logic that was discussed in the ticket (https://openlmis.atlassian.net/browse/OLMIS-2724)). But I do think we can make a change that addresses Josh’s concern.

ALSO, there is also an open question in the ticket comments that is related. The open question is about how to filter the list of facilities for this dropdown on View Orders screen. One issue is which User Rights check to perform, and another issue is whether to require a user to choose a “Supplying Facility” first on the UI and then have OpenLMIS follow the supply line hierarchy to get a short list of Requesting Facilities that are connected with a particular Supplying Facility. I think the simplest solution is to put all the facilities on the Requesting Facility dropdown without filtering by user rights and without following supply lines. That will be a longer select dropdown list compared to if we implemented the filtering by Supplying Facility first. But the benefit is that it is quicker and cleaner to implement and less fragile. Another benefit is that the filter will still be usable to search for past Orders even if a Supply Line changes over time. Finally, some day we still want to implement our re-design for the UI of how the filters/sorts work, so it does not seem wise now to invest a bunch of time in a complex set of nested filters that re-filter based on other filters.

-Brandon

···

From: openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

Date: Wednesday, August 23, 2017 at 12:34 AM

To: Łukasz Lewczyński llewczynski@soldevelo.com

Cc: Chongsun Ahn chongsun.ahn@villagereach.org, “openlmis-dev@googlegroups.comopenlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Problem solving proposal for view orders requesting facility filter select

These don’t look very restful. A start to making them more restful is to not include the facility resources name. While the UI might need the facility name, its better and more performant to not include it - I’ll try to post why that is soon.

I’m late to getting to this message, but I would encourage looking at these end points to make them more restful resources rather than remote procedure calls. I’ll check in again in the morning here to lend any support needed.

On Aug 23, 2017, at 12:14 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

@Pawel: We have endpoint but it returns all facilities, so there could be a situation in which the fulfillment service will need name for one facility but reference-data will return all facilities (in Malawi there is about 600).

@Chongsun: I will change the name of resource.

If there is no other comments/questions then I will start work on it.

Łukasz Lewczyński

Software Developer

llewczynski@soldevelo.com

On Tue, Aug 22, 2017 at 6:03 PM, Chongsun Ahn chongsun.ahn@villagereach.org wrote:

Hey Łukasz,

This seems fine to me; however, I would recommend that we not name the schema minimalFacilityDto. Since something that just has id and name is generic enough that it does not have to be for just a facility, we could give it a generic name. In the Reference Data Service, we have the same thing, but it is called namedResource.

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 Aug 22, 2017, at 7:33 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi all,

I am working on MW-452 / OLMIS-2724 and I would like to propose a new endpoint that will retrieve requesting facilities based on supplying facility id. The result of this endpoint will be populated to the Requesting facility filter option on UI. The proposed endpoint can be found here.

Base assumptions:

  • the endpoint checks if a user has VIEW_ORDERS right

  • the endpoint retrieves requestingFacilityId property from all orders that supplyingFacilityId match provided ID. Thanks that the endpoint should be fast because it will not retrieve full order object but only a single field.

  • the endpoint asks reference-data service for minimal facility data - for UI we need only facility name. Because of that I propose a new endpoint in the reference-data service: link

Any thoughts?

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/CAAdp53xfxQJ7kA335noUbahPEUDn99kSCFOenLMwvAj%3DWobqtQ%40mail.gmail.com
.

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

**

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/CAAdp53wvsfCYb60rY91YfqqjoEeS43N%3DqrSDuBNt7XB7%2B%2BjpWw%40mail.gmail.com
.

For more options, visit 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/65C8655C-6E87-4981-8219-A73DFDBADDB5%40villagereach.org
.

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

I agree with Łukasz, it’s simple and efficient solution to this bug for now. Filling that dropdown with all facilities does not make much sense. Maybe we should use supply lines and supervisory node hierarchy but that would require changing what shows in the table so it is aligned with requesting facility dropdown.

···

On Tuesday, August 22, 2017 at 4:33:39 PM UTC+2, Łukasz Lewczyński wrote:

Hi all,

I am working on MW-452 / OLMIS-2724 and I would like to propose a new endpoint that will retrieve requesting facilities based on supplying facility id. The result of this endpoint will be populated to the Requesting facility filter option on UI. The proposed endpoint can be found here.

Base assumptions:

  • the endpoint checks if a user has VIEW_ORDERS right
  • the endpoint retrieves requestingFacilityId property from all orders that supplyingFacilityId match provided ID. Thanks that the endpoint should be fast because it will not retrieve full order object but only a single field.
  • the endpoint asks reference-data service for minimal facility data - for UI we need only facility name. Because of that I propose a new endpoint in the reference-data service: link

Any thoughts?

Regards,

Lukasz

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


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

Hi Brandon,

the solution that Łukasz proposed could not be implemented directly in the reference-data service. It is actually quite similar to what you suggested with simply returning all the available facilities in the system. The only difference is that it would only include facilities that have actually ordered anything (and for the sake of this filtering it would need to happen in the fulfillment service, as we would need to know which facilities have orders associated with them). This would give us cleaner and shorter list of facilities (there may be facilities that won't ever order anything). Additionally, if we also added filtering by previously selected supplying facility it would reduce the list even further.

Simply returning all facilities is an option as well but raises a question on how to handle that. The current endpoint that returns all facilities requires specific administrative right. Do we implement a new endpoint w/o right checking? (where?) Do we alter the existing endpoint to return facilities data less restrictively? I also agree that we shouldn't try to use supply lines to try to determine the facilities.

Anyways, it looks like there are even more questions and suggestions than there were when we started this discussion. I'm also not clear on what Josh is suggesting with "While the UI might need the facility name, its better and more performant to not include it". Since this feature is critical for the CMST stuff in Malawi and we are only a few days away from the release, perhaps we should schedule a call to try to make a decision on the approach we are taking?

Best regards,

Sebastian.
···

On 24.08.2017 00:42, Brandon Bowersox-Johnson wrote:

        Josh might weigh in with more details…but I also wanted to share a perspective.
        The original suggestion from Lukasz blurs or combines two different services: It has a Fulfillment endpoint to query Orders and get a list of facilities from that set of orders. That proposed endpoint uses RefData to look up facility names. The Fulfillment endpoint would return a MinimalFacilityDto. So the end result is a Fulfillment endpoint returning RefData resources.
        I feel like it would help to dis-entangle whether we are really querying a list of Orders or a list of Facilities. We can separate out which service is responsible for which type of resource.
        Here is one suggestion: perhaps take Fulfillment out of the picture here. We can just have ReferenceData service create a list of RequestingFacilities. After all, ReferenceData is the service that is currently responsible for knowing who supplies whom—ReferenceData owns the Requisition Groups, Supervisory Nodes, and Supply Lines, along with the Facility list. So we can make an endpoint in ReferenceData that can return all of the Requesting Facilities.
        The benefit of this solution is that we keep separate lines of responsibility by service. It should be more RESTful and less fragile to maintain. I know this suggestion is a slight change in the logic that was discussed in the ticket ([https://openlmis.atlassian.net/browse/OLMIS-2724)](https://openlmis.atlassian.net/browse/OLMIS-2724%29)            . But I do think we can make a change that addresses Josh’s concern.
        ALSO, there is also an open question in the [              ticket comments](https://openlmis.atlassian.net/browse/OLMIS-2724) that is related. The open question is about how to filter the list of facilities for this dropdown on View Orders screen. One issue is which User Rights check to perform, and another issue is whether to require a user to choose a “Supplying Facility” first on the UI and then have OpenLMIS follow the supply line hierarchy to get a short list of Requesting Facilities that are connected with a particular Supplying Facility. I think the simplest solution is to put all the facilities on the Requesting Facility dropdown without filtering by user rights and without following supply lines. That will be a longer select dropdown list compared to if we implemented the filtering by Supplying Facility first. But the benefit is that it is quicker and cleaner to implement and less fragile. Another benefit is that the filter will still be usable to search for past Orders even if a Supply Line changes over time. Finally, some day we still want to implement our re-design for the UI of how the filters/sorts work, so it does not seem wise now to invest a bunch of time in a complex set of nested filters that re-filter based on other filters.

-Brandon

**From:
**
on behalf of Josh Zamor Wednesday, August 23, 2017 at 12:34 AM Łukasz Lewczyński Chongsun Ahn , Re: [openlmis-dev] Problem solving proposal for view orders requesting facility filter select

        These don't look very restful. A start to making them more restful is to not include the facility resources name. While the UI might need the facility name, its better and more performant to not include it - I'll try to post why that is soon.
        I'm late to getting to this message, but I would encourage looking at these end points to make them more restful resources rather than remote procedure calls. I'll check in again in the morning here to lend any support needed.
        On Aug 23, 2017, at 12:14 AM, Łukasz Lewczyński <llewczynski@soldevelo.com            > wrote:

@Pawel: We have endpoint but it returns all facilities, so there could be a situation in which the fulfillment service will need name for one facility but reference-data will return all facilities (in Malawi there is about 600).

@Chongsun: I will change the name of resource.

              If there is no other comments/questions then I will start work on it.

Łukasz Lewczyński

                      Software Developer

                      llewczynski@soldevelo.com
              On Tue, Aug 22, 2017 at 6:03 PM, Chongsun Ahn <chongsun.ahn@villagereach.org                  > wrote:

Hey Łukasz,

                    This seems fine to me; however, I would recommend that we not name the schema minimalFacilityDto. Since something that just has id and name is generic enough that it does not have to be for just a facility, we could give it a generic name. In the Reference Data Service, we have the same thing, but it is called namedResource.
                                  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](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 Aug 22, 2017, at 7:33 AM, Łukasz Lewczyński <llewczynski@soldevelo.com                                  > wrote:

Hi all,

                                    I am working on [MW-452](https://openlmis.atlassian.net/browse/MW-452) / [OLMIS-2724](https://openlmis.atlassian.net/browse/OLMIS-2724)                                         and I would like to propose a new endpoint that will retrieve requesting facilities based on supplying facility id. The result of this endpoint will be populated to the Requesting facility filter option on UI. The proposed endpoint can be found [here](https://github.com/OpenLMIS/openlmis-fulfillment/commit/0e466e9c24cdfb11c1c0265340924210d336aa54).
                                    Base assumptions:
                                    * the endpoint checks if a user has VIEW_ORDERS right

                                    * the endpoint retrieves requestingFacilityId property from all orders that supplyingFacilityId match provided ID. Thanks that the endpoint should be fast because it will not retrieve full order object but only a single field.
                                    * the endpoint asks reference-data service for minimal facility data - for UI we need only facility name. Because of that I propose a new endpoint in the reference-data service: [link](https://github.com/OpenLMIS/openlmis-referencedata/commit/04552e3c9e3c4080f00f3587f8b3e7c640b258b9)
                                    Any thoughts?

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/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/CAAdp53xfxQJ7kA335noUbahPEUDn99kSCFOenLMwvAj%3DWobqtQ%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53xfxQJ7kA335noUbahPEUDn99kSCFOenLMwvAj%3DWobqtQ%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/CAAdp53wvsfCYb60rY91YfqqjoEeS43N%3DqrSDuBNt7XB7%2B%2BjpWw%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wvsfCYb60rY91YfqqjoEeS43N%3DqrSDuBNt7XB7%2B%2BjpWw%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/65C8655C-6E87-4981-8219-A73DFDBADDB5%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/65C8655C-6E87-4981-8219-A73DFDBADDB5%40villagereach.org?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/B9171D5C-B52A-4BCB-99CB-97A8650676DB%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/B9171D5C-B52A-4BCB-99CB-97A8650676DB%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

    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
openlmis-dev@googlegroups.comjosh.zamor@villagereach.org
Date:
To: llewczynski@soldevelo.com
Cc: chongsun.ahn@villagereach.org"openlmis-dev@googlegroups.com"openlmis-dev@googlegroups.com
Subject:

sbrudzinski@soldevelo.com

Okay, let’s meet Friday at 7:00am PDT / 4:00pm CEST to discuss this ticket. This is an inter-related tech and UI issue. We’ll talk live because it’s time-sensitive.

Goal: Consensus on how to move forward with the ‘requesting facility’ filter select dropdown and the RESTful endpoints that power it.

Preparation:

  •      Everyone please read the ticket: [https://openlmis.atlassian.net/browse/OLMIS-2724](https://openlmis.atlassian.net/browse/OLMIS-2724)
    
  •      Developers please read the Dev Forum thread: [https://groups.google.com/forum/#!topic/openlmis-dev/AZHuzy_VR8Q](https://groups.google.com/forum/#!topic/openlmis-dev/AZHuzy_VR8Q)
    

UberConference:

Held via https://www.uberconference.com/villagereach-isg

(or dial by phone at +1 401-283-5773, PIN 66343)

···

On Thursday, August 24, 2017 at 3:05:40 AM UTC-7, Sebastian Brudziński wrote:

Anyways, it looks like there are even more questions and suggestions than there were when we started this discussion. I'm also not clear on what Josh is suggesting with "While the UI might need the facility name, its better and more performant to not include it". Since this feature is critical for the CMST stuff in Malawi and we are only a few days away from the release,     perhaps we should schedule a call to try to make a decision on the approach we are taking?



Best regards,

Sebastian.

Hi everyone,

  we have just finished the meeting and managed to reach a consensus on the approach. We will be implementing a slightly modified, more restful version of Lukasz's original proposal from the first post of this thread.

Specifically:

   - The retrieval of all minimal facilities representations ("facilities/minimal") will no longer be protected by administrative right. All logged in users will be able to retrieve the facilities. We will also be aiming to make retrieval of other pieces of reference data less restrictive in the future.

   - The UI will be caching all the available facilities upon user log in and store it for several days. Brandon or Nick will follow up with Mary Jo on the need to clear that data when user logs out. We will also need to determine the exact lifetime of the facilities cache.

   - The endpoint in the fulfillment service that Lukasz proposed will only be returning the distinct UUIDs of the available requesting facilities. This also means it won't be contacting the referencedata service at all.

   - The UI will compile the final list of available requesting facilities based on the endpoint call and the cached data it has got. It will call the endpoint in the fulfillment service to retrieve UUIDs of all available requesting facilities, check the facilities cache to match those UUIDs with names and then display the available requesting facilities to the user. Since the search order endpoint already supports filtering by requesting facility UUID, no further changes are required there.

Please feel free to chime in if any of that doesn’t sound right.

Best regards,

Sebastian.
···

On 24.08.2017 18:13, brandon.bowersox-johnson wrote:

          Okay, let's meet Friday at 7:00am PDT / 4:00pm CEST to discuss this ticket. This is an inter-related tech and UI issue. We'll talk live because it's time-sensitive.

Goal: Consensus on how to move forward with the ‘requesting facility’ filter select dropdown and the RESTful endpoints that power it.

Preparation:

  •                                  Everyone please read the ticket: [https://openlmis.atlassian.net/browse/OLMIS-2724](https://openlmis.atlassian.net/browse/OLMIS-2724)
    
  •                                  Developers please read the Dev Forum thread: [https://groups.google.com/forum/#!topic/openlmis-dev/AZHuzy_VR8Q](https://groups.google.com/forum/#%21topic/openlmis-dev/AZHuzy_VR8Q)
    

UberConference:

Held via https://www.uberconference.com/villagereach-isg

          (or dial by phone at +1 401-283-5773, PIN 66343)
    On Thursday, August 24, 2017 at 3:05:40 AM UTC-7, Sebastian Brudziński wrote:

        Anyways, it looks like there are even more questions and suggestions than there were when we started this discussion. I'm also not clear on what Josh is suggesting with "While the UI might need the facility name, its better and more performant to not include it". Since this feature is critical for the CMST stuff in Malawi and we are only a few days away from the release,               perhaps we should schedule a call to try to make a decision on the approach we are taking?



        Best regards,

        Sebastian.

  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/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.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

    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

Hi all,

As part of MW-452 ticket there’s the same problem with the program dropdown as with requesting facility dropdown - we cannot rely on supervision rights for populating it. The simplest, fastest and requiring the smallest number of changes is to start using /api/programs endpoint instead of /api/users/{id}/programs to fill the dropdown. With this change the dropdown will have all programs available in the system. What do you think about that change? Is it acceptable? Should be provide other solution?

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

On Fri, Aug 25, 2017 at 5:34 PM, Sebastian Brudziński sbrudzinski@soldevelo.com wrote:

Hi everyone,

  we have just finished the meeting and managed to reach a consensus on the approach. We will be implementing a slightly modified, more restful version of Lukasz's original proposal from the first post of this thread.

Specifically:

   - The retrieval of all minimal facilities representations ("facilities/minimal") will no longer be protected by administrative right. All logged in users will be able to retrieve the facilities. We will also be aiming to make retrieval of other pieces of reference data less restrictive in the future.

   - The UI will be caching all the available facilities upon user log in and store it for several days. Brandon or Nick will follow up with Mary Jo on the need to clear that data when user logs out. We will also need to determine the exact lifetime of the facilities cache.

   - The endpoint in the fulfillment service that Lukasz proposed will only be returning the distinct UUIDs of the available requesting facilities. This also means it won't be contacting the referencedata service at all.

   - The UI will compile the final list of available requesting facilities based on the endpoint call and the cached data it has got. It will call the endpoint in the fulfillment service to retrieve UUIDs of all available requesting facilities, check the facilities cache to match those UUIDs with names and then display the available requesting facilities to the user. Since the search order endpoint already supports filtering by requesting facility UUID, no further changes are required there.

Please feel free to chime in if any of that doesn’t sound right.

Best regards,

Sebastian.



  On 24.08.2017 18:13, brandon.bowersox-johnson wrote:
          Okay, let's meet Friday at 7:00am PDT / 4:00pm CEST to discuss this ticket. This is an inter-related tech and UI issue. We'll talk live because it's time-sensitive.

Goal: Consensus on how to move forward with the ‘requesting facility’ filter select dropdown and the RESTful endpoints that power it.

Preparation:

  •                                  Everyone please read the ticket: [https://openlmis.atlassian.net/browse/OLMIS-2724](https://openlmis.atlassian.net/browse/OLMIS-2724)
    
  •                                  Developers please read the Dev Forum thread: [https://groups.google.com/forum/#!topic/openlmis-dev/AZHuzy_VR8Q](https://groups.google.com/forum/#%21topic/openlmis-dev/AZHuzy_VR8Q)
    

UberConference:

Held via https://www.uberconference.com/villagereach-isg

          (or dial by phone at +1 401-283-5773, PIN 66343)
    On Thursday, August 24, 2017 at 3:05:40 AM UTC-7, Sebastian Brudziński wrote:

        Anyways, it looks like there are even more questions and suggestions than there were when we started this discussion. I'm also not clear on what Josh is suggesting with "While the UI might need the facility name, its better and more performant to not include it". Since this feature is critical for the CMST stuff in Malawi and we are only a few days away from the release,               perhaps we should schedule a call to try to make a decision on the approach we are taking?



        Best regards,

        Sebastian.

  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/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.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

    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/071fb55b-0465-f4d3-c1ca-7e3b962387ac%40soldevelo.com.

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

Hi Lukasz,

I talked to Mary Jo and we agree that we should allow anyone authenticated to be able to do GET /api/programs. Do you have a JIRA ticket for that? If not I’d suggest making one in the OpenLMIS project (not the Malawi project) and then when you’re done issue a PR for it.

Thanks,
Josh

···

On Tuesday, August 29, 2017 at 2:07:07 AM UTC-7, Łukasz Lewczyński wrote:

Hi all,

As part of MW-452 ticket there’s the same problem with the program dropdown as with requesting facility dropdown - we cannot rely on supervision rights for populating it. The simplest, fastest and requiring the smallest number of changes is to start using /api/programs endpoint instead of /api/users/{id}/programs to fill the dropdown. With this change the dropdown will have all programs available in the system. What do you think about that change? Is it acceptable? Should be provide other solution?

Regards,

Lukasz

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

On Fri, Aug 25, 2017 at 5:34 PM, Sebastian Brudziński sbrudzinski@soldevelo.com wrote:

Hi everyone,

  we have just finished the meeting and managed to reach a consensus on the approach. We will be implementing a slightly modified, more restful version of Lukasz's original proposal from the first post of this thread.

Specifically:

   - The retrieval of all minimal facilities representations ("facilities/minimal") will no longer be protected by administrative right. All logged in users will be able to retrieve the facilities. We will also be aiming to make retrieval of other pieces of reference data less restrictive in the future.

   - The UI will be caching all the available facilities upon user log in and store it for several days. Brandon or Nick will follow up with Mary Jo on the need to clear that data when user logs out. We will also need to determine the exact lifetime of the facilities cache.

   - The endpoint in the fulfillment service that Lukasz proposed will only be returning the distinct UUIDs of the available requesting facilities. This also means it won't be contacting the referencedata service at all.

   - The UI will compile the final list of available requesting facilities based on the endpoint call and the cached data it has got. It will call the endpoint in the fulfillment service to retrieve UUIDs of all available requesting facilities, check the facilities cache to match those UUIDs with names and then display the available requesting facilities to the user. Since the search order endpoint already supports filtering by requesting facility UUID, no further changes are required there.

Please feel free to chime in if any of that doesn’t sound right.

Best regards,

Sebastian.



  On 24.08.2017 18:13, brandon.bowersox-johnson wrote:
          Okay, let's meet Friday at 7:00am PDT / 4:00pm CEST to discuss this ticket. This is an inter-related tech and UI issue. We'll talk live because it's time-sensitive.

Goal: Consensus on how to move forward with the ‘requesting facility’ filter select dropdown and the RESTful endpoints that power it.

Preparation:

  •                                  Everyone please read the ticket: [https://openlmis.atlassian.net/browse/OLMIS-2724](https://openlmis.atlassian.net/browse/OLMIS-2724)
    
  •                                  Developers please read the Dev Forum thread: [https://groups.google.com/forum/#!topic/openlmis-dev/AZHuzy_VR8Q](https://groups.google.com/forum/#%21topic/openlmis-dev/AZHuzy_VR8Q)
    

UberConference:

Held via https://www.uberconference.com/villagereach-isg

          (or dial by phone at +1 401-283-5773, PIN 66343)
    On Thursday, August 24, 2017 at 3:05:40 AM UTC-7, Sebastian Brudziński wrote:

        Anyways, it looks like there are even more questions and suggestions than there were when we started this discussion. I'm also not clear on what Josh is suggesting with "While the UI might need the facility name, its better and more performant to not include it". Since this feature is critical for the CMST stuff in Malawi and we are only a few days away from the release,               perhaps we should schedule a call to try to make a decision on the approach we are taking?



        Best regards,

        Sebastian.

  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/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.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

    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/071fb55b-0465-f4d3-c1ca-7e3b962387ac%40soldevelo.com.

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


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

Hi Josh,

Program filter fix has been provided in this commit: link as part of MW-452

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, Sep 6, 2017 at 2:00 AM, Josh Zamor josh.zamor@villagereach.org wrote:

Hi Lukasz,

I talked to Mary Jo and we agree that we should allow anyone authenticated to be able to do GET /api/programs. Do you have a JIRA ticket for that? If not I’d suggest making one in the OpenLMIS project (not the Malawi project) and then when you’re done issue a PR for it.

Thanks,
Josh

On Tuesday, August 29, 2017 at 2:07:07 AM UTC-7, Łukasz Lewczyński wrote:

Hi all,

As part of MW-452 ticket there’s the same problem with the program dropdown as with requesting facility dropdown - we cannot rely on supervision rights for populating it. The simplest, fastest and requiring the smallest number of changes is to start using /api/programs endpoint instead of /api/users/{id}/programs to fill the dropdown. With this change the dropdown will have all programs available in the system. What do you think about that change? Is it acceptable? Should be provide other solution?

Regards,

Lukasz

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

On Fri, Aug 25, 2017 at 5:34 PM, Sebastian Brudziński sbrudzinski@soldevelo.com wrote:

Hi everyone,

  we have just finished the meeting and managed to reach a consensus on the approach. We will be implementing a slightly modified, more restful version of Lukasz's original proposal from the first post of this thread.

Specifically:

   - The retrieval of all minimal facilities representations ("facilities/minimal") will no longer be protected by administrative right. All logged in users will be able to retrieve the facilities. We will also be aiming to make retrieval of other pieces of reference data less restrictive in the future.

   - The UI will be caching all the available facilities upon user log in and store it for several days. Brandon or Nick will follow up with Mary Jo on the need to clear that data when user logs out. We will also need to determine the exact lifetime of the facilities cache.

   - The endpoint in the fulfillment service that Lukasz proposed will only be returning the distinct UUIDs of the available requesting facilities. This also means it won't be contacting the referencedata service at all.

   - The UI will compile the final list of available requesting facilities based on the endpoint call and the cached data it has got. It will call the endpoint in the fulfillment service to retrieve UUIDs of all available requesting facilities, check the facilities cache to match those UUIDs with names and then display the available requesting facilities to the user. Since the search order endpoint already supports filtering by requesting facility UUID, no further changes are required there.

Please feel free to chime in if any of that doesn’t sound right.

Best regards,

Sebastian.



  On 24.08.2017 18:13, brandon.bowersox-johnson wrote:
          Okay, let's meet Friday at 7:00am PDT / 4:00pm CEST to discuss this ticket. This is an inter-related tech and UI issue. We'll talk live because it's time-sensitive.

Goal: Consensus on how to move forward with the ‘requesting facility’ filter select dropdown and the RESTful endpoints that power it.

Preparation:

  •                                  Everyone please read the ticket: [https://openlmis.atlassian.net/browse/OLMIS-2724](https://openlmis.atlassian.net/browse/OLMIS-2724)
    
  •                                  Developers please read the Dev Forum thread: [https://groups.google.com/forum/#!topic/openlmis-dev/AZHuzy_VR8Q](https://groups.google.com/forum/#%21topic/openlmis-dev/AZHuzy_VR8Q)
    

UberConference:

Held via https://www.uberconference.com/villagereach-isg

          (or dial by phone at +1 401-283-5773, PIN 66343)
    On Thursday, August 24, 2017 at 3:05:40 AM UTC-7, Sebastian Brudziński wrote:

        Anyways, it looks like there are even more questions and suggestions than there were when we started this discussion. I'm also not clear on what Josh is suggesting with "While the UI might need the facility name, its better and more performant to not include it". Since this feature is critical for the CMST stuff in Malawi and we are only a few days away from the release,               perhaps we should schedule a call to try to make a decision on the approach we are taking?



        Best regards,

        Sebastian.

  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/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.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

    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/071fb55b-0465-f4d3-c1ca-7e3b962387ac%40soldevelo.com.

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

**
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/4e1e0483-1dbe-4104-94d1-242074a9f7ca%40googlegroups.com.

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

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

I think Josh was specifically talking about permission check on the programs endpoint. It looks like none of the program endpoints ever required an administrative right - OpenLMIS doesn’t even have a right dedicated to that. Is this intentional or was there an oversight when adding right checks? While I don’t think retrieving/searching should be additionally protected, it seems like creating, modifying or attempting to delete programs should not be available to any logged in user.

Best regards,

  Sebastian.
···

On 06.09.2017 09:19, Łukasz Lewczyński wrote:

Hi Josh,

Program filter fix has been provided in this commit: link as part of MW-452

Regards,

Lukasz

Łukasz Lewczyński

              Software Developer

              llewczynski@soldevelo.com
      On Wed, Sep 6, 2017 at 2:00 AM, Josh Zamor <josh.zamor@villagereach.org>
      wrote:

Hi Lukasz,

          I talked to Mary Jo and we agree that we should allow anyone authenticated to be able to do GET /api/programs.  Do you have a JIRA ticket for that?  If not I'd suggest making one in the OpenLMIS project (not the Malawi project) and then when you're done issue a PR for it.



          Thanks,

          Josh




              On Tuesday, August 29, 2017 at 2:07:07 AM UTC-7, Łukasz Lewczyński wrote:

Hi all,

                    As part of MW-452 ticket there's the same problem with the program dropdown as with requesting facility dropdown - we cannot rely on supervision rights for populating it. The simplest, fastest and requiring the smallest number of changes is to start using **/api/programs**                         endpoint instead of **/api/users/{id}/programs**                         to fill the dropdown. With this change the dropdown will have all programs available in the system. What do you think about that change? Is it acceptable? Should be provide other solution?

Regards,

Lukasz

Łukasz Lewczyński

                              Software Developer

                              llewczynski@soldevelo.com
                      On Fri, Aug 25, 2017 at 5:34 PM, Sebastian Brudziński <sbrudzinski@soldevelo.com>
                      wrote:

Hi everyone,

                            we have just finished the meeting and managed to reach a consensus on the approach. We will be implementing a slightly modified, more restful version of Lukasz's original proposal from the first post of this thread.

Specifically:

                             - The retrieval of all minimal facilities representations ("facilities/minimal") will no longer be protected by administrative right. All logged in users will be able to retrieve the facilities. We will also be aiming to make retrieval of other pieces of reference data less restrictive in the future.

                             - The UI will be caching all the available facilities upon user log in and store it for several days. Brandon or Nick will follow up with Mary Jo on the need to clear that data when user logs out. We will also need to determine the exact lifetime of the facilities cache.

                             - The endpoint in the fulfillment service that Lukasz proposed will only be returning the distinct UUIDs of the available requesting facilities. This also means it won't be contacting the referencedata service at all.

                             - The UI will compile the final list of available requesting facilities based on the endpoint call and the cached data it has got. It will call the endpoint in the fulfillment service to retrieve UUIDs of all available requesting facilities, check the facilities cache to match those UUIDs with names and then display the available requesting facilities to the user. Since the search order endpoint already supports filtering by requesting facility UUID, no further changes are required there.
                          Please feel free to chime in if any of that doesn't sound right.



                          Best regards,

                          Sebastian.



                                On 24.08.2017 18:13, brandon.bowersox-johnson wrote:
                                        Okay, let's meet Friday at 7:00am PDT / 4:00pm CEST to discuss this ticket. This is an inter-related tech and UI issue. We'll talk live because it's time-sensitive.

** Goal:** Consensus on how to move forward with the ‘requesting facility’ filter select dropdown and the RESTful endpoints that power it.

Preparation:

  •                                                                                              Everyone please read the ticket: [https://openlmis.atlassian.net/browse/OLMIS-2724](https://openlmis.atlassian.net/browse/OLMIS-2724)
    
  •                                                                                              Developers please read the Dev Forum thread: [https://groups.google.com/forum/#!topic/openlmis-dev/AZHuzy_VR8Q](https://groups.google.com/forum/#%21topic/openlmis-dev/AZHuzy_VR8Q)
    

UberConference:

                                        Held via [https://www.uberconference.com/villagereach-isg](https://www.uberconference.com/villagereach-isg)
                                        (or dial by phone at                                               +1 401-283-5773                                            , PIN 66343)
                                  On Thursday, August 24, 2017 at 3:05:40 AM UTC-7, Sebastian Brudziński wrote:

                                      Anyways, it looks like there are even more questions and suggestions than there were when we started this discussion. I'm also not clear on what Josh is suggesting with "While the UI might need the facility name, its better and more performant to not include it". Since this feature is critical for the CMST stuff in Malawi and we are only a few days away from the release,                                             perhaps we should schedule a call to try to make a decision on the approach we are taking?



                                      Best regards,

                                      Sebastian.

                                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/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.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

                                                                  Software Developer / Team Leader

                               sbrudzinski@soldevelo.com
                          **

                              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/071fb55b-0465-f4d3-c1ca-7e3b962387ac%40soldevelo.com](https://groups.google.com/d/msgid/openlmis-dev/071fb55b-0465-f4d3-c1ca-7e3b962387ac%40soldevelo.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/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/4e1e0483-1dbe-4104-94d1-242074a9f7ca%40googlegroups.com.

            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


Sebastian Brudziński

    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

Thank you Lukasz and Sebastian.

You’re right Sebastian in that this is an oversight. I’ve filed this bug: https://openlmis.atlassian.net/browse/OLMIS-3146

If you’d both please look over that issue, it’ll be near the top of the list to get done for v3.2.1 of Ref Distro starting in the next sprint.

Best,
Josh

···

On Wednesday, September 6, 2017 at 2:47:39 AM UTC-7, Sebastian Brudziński wrote:

  I think Josh was specifically talking about permission check on the programs endpoint. It looks like none of the program endpoints ever required an administrative right - OpenLMIS doesn't even have a right dedicated to that. Is this intentional or was there an oversight when adding right checks? While I don't think retrieving/searching should be additionally protected, it seems like creating, modifying or attempting to delete programs should not be available to any logged in user.

Best regards,

  Sebastian.
  On 06.09.2017 09:19, Łukasz Lewczyński wrote:

Hi Josh,

Program filter fix has been provided in this commit: link as part of MW-452

Regards,

Lukasz

Łukasz Lewczyński

              Software Developer

              llewczynski@soldevelo.com
      On Wed, Sep 6, 2017 at 2:00 AM, Josh Zamor <josh.zamor@villagereach.org> > >           wrote:

Hi Lukasz,

          I talked to Mary Jo and we agree that we should allow anyone authenticated to be able to do GET /api/programs.  Do you have a JIRA ticket for that?  If not I'd suggest making one in the OpenLMIS project (not the Malawi project) and then when you're done issue a PR for it.



          Thanks,

          Josh




              On Tuesday, August 29, 2017 at 2:07:07 AM UTC-7, Łukasz Lewczyński wrote:

Hi all,

                    As part of MW-452 ticket there's the same problem with the program dropdown as with requesting facility dropdown - we cannot rely on supervision rights for populating it. The simplest, fastest and requiring the smallest number of changes is to start using **/api/programs**                         endpoint instead of **/api/users/{id}/programs**                         to fill the dropdown. With this change the dropdown will have all programs available in the system. What do you think about that change? Is it acceptable? Should be provide other solution?

Regards,

Lukasz

Łukasz Lewczyński

                              Software Developer

                              llewczynski@soldevelo.com
                      On Fri, Aug 25, 2017 at 5:34 PM, Sebastian Brudziński <sbrudzinski@soldevelo.com> > > > >                           wrote:

Hi everyone,

                            we have just finished the meeting and managed to reach a consensus on the approach. We will be implementing a slightly modified, more restful version of Lukasz's original proposal from the first post of this thread.

Specifically:

                             - The retrieval of all minimal facilities representations ("facilities/minimal") will no longer be protected by administrative right. All logged in users will be able to retrieve the facilities. We will also be aiming to make retrieval of other pieces of reference data less restrictive in the future.

                             - The UI will be caching all the available facilities upon user log in and store it for several days. Brandon or Nick will follow up with Mary Jo on the need to clear that data when user logs out. We will also need to determine the exact lifetime of the facilities cache.

                             - The endpoint in the fulfillment service that Lukasz proposed will only be returning the distinct UUIDs of the available requesting facilities. This also means it won't be contacting the referencedata service at all.

                             - The UI will compile the final list of available requesting facilities based on the endpoint call and the cached data it has got. It will call the endpoint in the fulfillment service to retrieve UUIDs of all available requesting facilities, check the facilities cache to match those UUIDs with names and then display the available requesting facilities to the user. Since the search order endpoint already supports filtering by requesting facility UUID, no further changes are required there.
                          Please feel free to chime in if any of that doesn't sound right.



                          Best regards,

                          Sebastian.



                                On 24.08.2017 18:13, brandon.bowersox-johnson wrote:
                                        Okay, let's meet Friday at 7:00am PDT / 4:00pm CEST to discuss this ticket. This is an inter-related tech and UI issue. We'll talk live because it's time-sensitive.

** Goal:** Consensus on how to move forward with the ‘requesting facility’ filter select dropdown and the RESTful endpoints that power it.

Preparation:

  •                                                                                              Everyone please read the ticket: [https://openlmis.atlassian.net/browse/OLMIS-2724](https://openlmis.atlassian.net/browse/OLMIS-2724)
    
  •                                                                                              Developers please read the Dev Forum thread: [https://groups.google.com/forum/#!topic/openlmis-dev/AZHuzy_VR8Q](https://groups.google.com/forum/#%21topic/openlmis-dev/AZHuzy_VR8Q)
    

UberConference:

                                        Held via [https://www.uberconference.com/villagereach-isg](https://www.uberconference.com/villagereach-isg)
                                        (or dial by phone at                                               +1 401-283-5773                                            , PIN 66343)
                                  On Thursday, August 24, 2017 at 3:05:40 AM UTC-7, Sebastian Brudziński wrote:

                                      Anyways, it looks like there are even more questions and suggestions than there were when we started this discussion. I'm also not clear on what Josh is suggesting with "While the UI might need the facility name, its better and more performant to not include it". Since this feature is critical for the CMST stuff in Malawi and we are only a few days away from the release,                                             perhaps we should schedule a call to try to make a decision on the approach we are taking?



                                      Best regards,

                                      Sebastian.

                                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/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.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

                                                                  Software Developer / Team Leader

                               sbrudzinski@soldevelo.com
                          **

                              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/071fb55b-0465-f4d3-c1ca-7e3b962387ac%40soldevelo.com](https://groups.google.com/d/msgid/openlmis-dev/071fb55b-0465-f4d3-c1ca-7e3b962387ac%40soldevelo.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/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/4e1e0483-1dbe-4104-94d1-242074a9f7ca%40googlegroups.com.

            For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
  **<img src="https://lh3.googleusercontent.com/proxy/Kq7icsK3MEQjYLwBW84HwuYjQ8aFuyyirMOzt_ENZ5BgyyRVaFVgsbO-vnqZPEKtkcm1Gs2mKJSDSi59adej7wSt1KiO3u5QJa2SfrMvGRh8cyONHJScEXiljA=w5000-h5000" width="145" height="35">

      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


Sebastian Brudziński

    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

I added one acceptance criteria to make sure that View Orders screen will work after changes

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 Thu, Sep 7, 2017 at 6:12 AM, Josh Zamor josh.zamor@villagereach.org wrote:

Thank you Lukasz and Sebastian.

You’re right Sebastian in that this is an oversight. I’ve filed this bug: https://openlmis.atlassian.net/browse/OLMIS-3146

If you’d both please look over that issue, it’ll be near the top of the list to get done for v3.2.1 of Ref Distro starting in the next sprint.

Best,
Josh

On Wednesday, September 6, 2017 at 2:47:39 AM UTC-7, Sebastian Brudziński wrote:

  I think Josh was specifically talking about permission check on the programs endpoint. It looks like none of the program endpoints ever required an administrative right - OpenLMIS doesn't even have a right dedicated to that. Is this intentional or was there an oversight when adding right checks? While I don't think retrieving/searching should be additionally protected, it seems like creating, modifying or attempting to delete programs should not be available to any logged in user.

Best regards,

  Sebastian.
  On 06.09.2017 09:19, Łukasz Lewczyński wrote:

Hi Josh,

Program filter fix has been provided in this commit: link as part of MW-452

Regards,

Lukasz

Łukasz Lewczyński

              Software Developer

              llewczynski@soldevelo.com
      On Wed, Sep 6, 2017 at 2:00 AM, Josh Zamor <josh.zamor@villagereach.org>
      wrote:

Hi Lukasz,

          I talked to Mary Jo and we agree that we should allow anyone authenticated to be able to do GET /api/programs.  Do you have a JIRA ticket for that?  If not I'd suggest making one in the OpenLMIS project (not the Malawi project) and then when you're done issue a PR for it.



          Thanks,

          Josh




              On Tuesday, August 29, 2017 at 2:07:07 AM UTC-7, Łukasz Lewczyński wrote:

Hi all,

                    As part of MW-452 ticket there's the same problem with the program dropdown as with requesting facility dropdown - we cannot rely on supervision rights for populating it. The simplest, fastest and requiring the smallest number of changes is to start using **/api/programs**                         endpoint instead of **/api/users/{id}/programs**                         to fill the dropdown. With this change the dropdown will have all programs available in the system. What do you think about that change? Is it acceptable? Should be provide other solution?

Regards,

Lukasz

Łukasz Lewczyński

                              Software Developer

                              llewczynski@soldevelo.com
                      On Fri, Aug 25, 2017 at 5:34 PM, Sebastian Brudziński <sbrudzinski@soldevelo.com>
                      wrote:

Hi everyone,

                            we have just finished the meeting and managed to reach a consensus on the approach. We will be implementing a slightly modified, more restful version of Lukasz's original proposal from the first post of this thread.

Specifically:

                             - The retrieval of all minimal facilities representations ("facilities/minimal") will no longer be protected by administrative right. All logged in users will be able to retrieve the facilities. We will also be aiming to make retrieval of other pieces of reference data less restrictive in the future.

                             - The UI will be caching all the available facilities upon user log in and store it for several days. Brandon or Nick will follow up with Mary Jo on the need to clear that data when user logs out. We will also need to determine the exact lifetime of the facilities cache.

                             - The endpoint in the fulfillment service that Lukasz proposed will only be returning the distinct UUIDs of the available requesting facilities. This also means it won't be contacting the referencedata service at all.

                             - The UI will compile the final list of available requesting facilities based on the endpoint call and the cached data it has got. It will call the endpoint in the fulfillment service to retrieve UUIDs of all available requesting facilities, check the facilities cache to match those UUIDs with names and then display the available requesting facilities to the user. Since the search order endpoint already supports filtering by requesting facility UUID, no further changes are required there.
                          Please feel free to chime in if any of that doesn't sound right.



                          Best regards,

                          Sebastian.



                                On 24.08.2017 18:13, brandon.bowersox-johnson wrote:
                                        Okay, let's meet Friday at 7:00am PDT / 4:00pm CEST to discuss this ticket. This is an inter-related tech and UI issue. We'll talk live because it's time-sensitive.

** Goal:** Consensus on how to move forward with the ‘requesting facility’ filter select dropdown and the RESTful endpoints that power it.

Preparation:

  •                                                                                              Everyone please read the ticket: [https://openlmis.atlassian.net/browse/OLMIS-2724](https://openlmis.atlassian.net/browse/OLMIS-2724)
    
  •                                                                                              Developers please read the Dev Forum thread: [https://groups.google.com/forum/#!topic/openlmis-dev/AZHuzy_VR8Q](https://groups.google.com/forum/#%21topic/openlmis-dev/AZHuzy_VR8Q)
    

UberConference:

                                        Held via [https://www.uberconference.com/villagereach-isg](https://www.uberconference.com/villagereach-isg)
                                        (or dial by phone at                                               +1 401-283-5773                                            , PIN 66343)
                                  On Thursday, August 24, 2017 at 3:05:40 AM UTC-7, Sebastian Brudziński wrote:

                                      Anyways, it looks like there are even more questions and suggestions than there were when we started this discussion. I'm also not clear on what Josh is suggesting with "While the UI might need the facility name, its better and more performant to not include it". Since this feature is critical for the CMST stuff in Malawi and we are only a few days away from the release,                                             perhaps we should schedule a call to try to make a decision on the approach we are taking?



                                      Best regards,

                                      Sebastian.

                                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/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.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

                                                                  Software Developer / Team Leader

                               sbrudzinski@soldevelo.com
                          **

                              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/071fb55b-0465-f4d3-c1ca-7e3b962387ac%40soldevelo.com](https://groups.google.com/d/msgid/openlmis-dev/071fb55b-0465-f4d3-c1ca-7e3b962387ac%40soldevelo.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/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/4e1e0483-1dbe-4104-94d1-242074a9f7ca%40googlegroups.com.

            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/98, 81-451, Gdynia, Poland

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


Sebastian Brudziński

    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/04395aa1-401e-4490-9cd2-03269081cd9e%40googlegroups.com.

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

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