-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
$cascade API round 3, including references #1131
Comments
…fying concept mappings queryset
…ading concept parent
Adding ideas for hierarchical response.
Open questions...
|
Pinning as high priority so that @paynejd will update to make it clear what the next steps are |
Ideas for long-term -- these will move to new tickets:
@snyaggarwal @rkorytkowski @jamlung-ri Please confirm the "what's next" list -- will move these into their own tickets and close this out when we have consensus |
@paynejd for the list above, we should make sure we have captured all OpenMRS cascade needs. Namely, the ability to cascade down multiple levels using certain map types. |
A potentially useful lo-fi drawing for a $cascade results panel: https://docs.google.com/drawings/d/19slrFyJebEKwDSve65V4tzAqKthrbA-uiP9V8vRWMcg/edit Edit: This cascade drawing is missing some key generic functionality, particularly for controlling the number of levels down you can go and the map types that you might want to be including. |
@jamlung-ri this looks good. In terms of behavior, we will need to perform $cascade request when the user is on the dialog and switching between options of the cascade. Should we disable the button to add until the results of the cascade are not displayed? |
@paulsonder might have more thoughts on this (keeping in mind that some design work is likely needed here). Makes sense that the $cascade request will occur as the user clicks the option, so there will likely be some delay as the API returns results (especially if it's a large set of results). Because of the risk for delay, I don't really want to disable the Add button, but we should at least show that the results are still loading. The user can decide if they do or don't want to wait and review the results before clicking the Add button. |
This ticket is focused only on adding OpenMRS-compatible behavior to the $cascade endpoint in the OCL API. Design discussions to expose the new $cascade behavior in the TermBrowser are taking place here #1378. @jamlung-ri Are there details in this ticket that need to be moved over to #1378? Goal: Specify criteria for inclusion of resources in a response separately from criteria for processing the cascade, e.g.:
Proposed approach: Introduce $cascade.returnMapTypes parameter (or equivalent behavior)
@paynejd To follow up with a visual using this concept: https://app.openconceptlab.org/#/orgs/CIEL/sources/CIEL/concepts/161499/ Example query: https://api.qa.openconceptlab.org/orgs/CIEL/sources/CIEL/concepts/159615/$cascade/?cascadeLevels=1&mapTypes=CONCEPT-SET,Q-AND-A |
Just copied over some necessary details
Will the address the need to go down as many levels as necessary in the $cascade operation? Or should we be mentioning that separately in the Goal section above? @paynejd |
@jamlung-ri The number of cascade levels is a separate parameter, |
Visual applies to this concept: Visual represents this query: Visual: Note that this may be introducing another new behavior related to self-maps (@snyaggarwal
|
@paynejd the first attempt at this is deployed on QA. Do give it a try. |
Let's set up a call to get this moving. Jon and I have not had luck yet. |
2 bugs to report so far:
|
…er map types criteria
|
cc @snyaggarwal I created a new source in QA that we can use to test cascade functionality: The source has the following characteristics that we want to test using cascade:
|
Bug:
This behavior can be easily replicated in the TermBrowser too, by looking at the Associations panel in HEAD and again in v3: |
cc @snyaggarwal These are all for discussion... What's up?
Questions
Food for thought
|
@paynejd Answers/comments on each are below:
|
We discovered that hierarchy_root_url attribute is not appearing in the versions of the Source. Examples: HEAD version with the attribute, and v3 version without the attribute |
Summarizing immediate next steps from the Oct 27 deep dive:
One remaining unanswered issue for round 3:
Once the above items are complete, we are hopefully ready to deploy after a final round of testing. Note that we still need to do round 3 testing in the context of collections. We'll tackle these in Round 4:
|
…dded hierarchy root url
@paynejd These are done |
@snyaggarwal I was doing some testing on this source, and I am seeing different results between a new source version and HEAD. Seems like hierarchy results are still not being included? Even though the
However, the Hierarchy option is appearing on the v4 version of the source, so that part appears to be fixed. |
…version cascade
@jamlung-ri this is fixed. |
@jamlung-ri @paynejd this is deployed everywhere |
Deployed everywhere. Closing this. |
This ticket is a placeholder to capture the next round of work on the $cascade operation and follows up on #1122. We will add details to this in the coming days.
@bmamlin @ $cascade is now functional enough (ie recursion and map type filter) to be tested for the desired OpenMRS Dictionary Manager functionality.
A couple of examples:
This round of work focuses on the ability to create collection references with $cascade, performance, features needed to utilize $cascade in a hierarchy tree view or in the OpenMRS Dictionary Manager, and addressing any bugs identified.
The text was updated successfully, but these errors were encountered: