Problem solving proposal for view orders requesting facility filter select
Łukasz Lewczyński
* 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.
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
--
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
Shalom,
Chongsun
--
There are 10 kinds of people in this world; those who understand binary, and those who don’t.
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
Łukasz Lewczyński
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
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.
Josh Zamor
To unsubscribe from this group and stop receiving emails from it, send an 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.
Brandon Bowersox-Johnson
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/65C8655C-6E87-4981-8219-A73DFDBADDB5%40villagereach.org.
Paweł Albecki
Sebastian Brudziński
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/B9171D5C-B52A-4BCB-99CB-97A8650676DB%40villagereach.org.
For more options, visit https://groups.google.com/d/optout.
Sebastian
Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com
brandon.bowersox-johnson
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
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.
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.
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
Łukasz Lewczyński
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/071fb55b-0465-f4d3-c1ca-7e3b962387ac%40soldevelo.com.
Josh Zamor
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
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/4e1e0483-1dbe-4104-94d1-242074a9f7ca%40googlegroups.com.
Sebastian Brudziński
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
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
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/04395aa1-401e-4490-9cd2-03269081cd9e%40googlegroups.com.