Problem solving proposal for view orders requesting facility filter select

42 views
Skip to first unread message

Łukasz Lewczyński

unread,
Aug 22, 2017, 10:33:39 AM8/22/17
to openlm...@googlegroups.com
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

Paweł Gesek

unread,
Aug 22, 2017, 11:16:04 AM8/22/17
to Łukasz Lewczyński, OpenLMIS Dev
Sounds ok, but I think we already have an endpoint that returns name/id representations for facilities.

Regards,
Paweł


--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53xfxQJ7kA335noUbahPEUDn99kSCFOenLMwvAj%3DWobqtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.



--

Paweł Gesek
Technical Project Manager
pge...@soldevelo.com / +48 690 020 875

Chongsun Ahn

unread,
Aug 22, 2017, 12:03:51 PM8/22/17
to Łukasz Lewczyński, openlm...@googlegroups.com
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.

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

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

Łukasz Lewczyński

unread,
Aug 23, 2017, 3:14:11 AM8/23/17
to Chongsun Ahn, openlm...@googlegroups.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.


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

On Tue, Aug 22, 2017 at 6:03 PM, Chongsun Ahn <chongs...@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.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

Josh Zamor

unread,
Aug 23, 2017, 3:35:00 AM8/23/17
to Łukasz Lewczyński, Chongsun Ahn, openlm...@googlegroups.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.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

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

Brandon Bowersox-Johnson

unread,
Aug 23, 2017, 6:42:45 PM8/23/17
to openlm...@googlegroups.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: <openlm...@googlegroups.com> on behalf of Josh Zamor <josh....@villagereach.org>
Date: Wednesday, August 23, 2017 at 12:34 AM
To: Łukasz Lewczyński <llewc...@soldevelo.com>
Cc: Chongsun Ahn <chongs...@villagereach.org>, "openlm...@googlegroups.com" <openlm...@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 <llewc...@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
llewc...@soldevelo.com

 

On Tue, Aug 22, 2017 at 6:03 PM, Chongsun Ahn <chongs...@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 | chongs...@villagereach.org

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/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...@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/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...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.

Paweł Albecki

unread,
Aug 23, 2017, 7:59:06 PM8/23/17
to OpenLMIS Dev
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.

Sebastian Brudziński

unread,
Aug 24, 2017, 6:05:40 AM8/24/17
to openlm...@googlegroups.com
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.

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

--

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

brandon.bowersox-johnson

unread,
Aug 24, 2017, 12:13:00 PM8/24/17
to OpenLMIS Dev

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

-          Developers please read the Dev Forum thread: 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:
...

Sebastian Brudziński

unread,
Aug 25, 2017, 11:34:49 AM8/25/17
to openlm...@googlegroups.com

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

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

--

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

Łukasz Lewczyński

unread,
Aug 29, 2017, 5:07:07 AM8/29/17
to openlm...@googlegroups.com, josh....@villagereach.org, Sebastian Brudziński, Christine Lenihan, Ben Leibert, maryjo.ko...@villagereach.org
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
llewc...@soldevelo.com

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/b49dd569-a091-4344-b220-956ebeaf40fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--

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



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

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

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

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

Josh Zamor

unread,
Sep 5, 2017, 8:00:15 PM9/5/17
to OpenLMIS Dev, josh....@villagereach.org, sbrud...@soldevelo.com, christin...@villagereach.org, ben.l...@villagereach.org, maryjo.ko...@villagereach.org
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

Łukasz Lewczyński

unread,
Sep 6, 2017, 3:19:28 AM9/6/17
to Josh Zamor, OpenLMIS Dev, Sebastian Brudziński, Christine Lenihan, Ben Leibert, maryjo.ko...@villagereach.org
Hi Josh,

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

Regards,
Lukasz


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


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

Sebastian Brudziński

unread,
Sep 6, 2017, 5:47:39 AM9/6/17
to OpenLMIS Dev, Łukasz Lewczyński, Josh Zamor, Christine Lenihan, Ben Leibert, maryjo.ko...@villagereach.org

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.

Josh Zamor

unread,
Sep 7, 2017, 12:12:52 AM9/7/17
to OpenLMIS Dev
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

Łukasz Lewczyński

unread,
Sep 7, 2017, 3:12:19 AM9/7/17
to Josh Zamor, OpenLMIS Dev
I added one acceptance criteria to make sure that View Orders screen will work after changes

Regards,
Lukasz


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


For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages