Developing the "OCL for OpenMRS" Application

Hey @darius,

Unfortunately, I’ve encountered a blocker in regards to this.

The API does not support filtering by repositoryType which is a requirement when displaying collections. We would need to do this in the front end (as we’ve been doing) which requires the verbose call since the non verbose call does not return the repository_type information

I thought we might make use of the collectionType field instead, but it appears that this filter itself is not enforced when searching for a concept. An issue has been created in regards to this(

I guess we’ll have to put this on pause?

cc. @akanter @dkayiwa @c.antwi

@darius @akanter What are your thoughts on the above post?

Will this impact the MVP release date?

cc @dkayiwa

I think we should make the initial screen more efficient, but I don’t think MVP should be held up because we want to filter the list of collections. Perhaps there is a workaround where someone doesn’t have to wait for them all to load, but can type a search in to filter the results? How hard would it be to add a simple search to the main dictionary view page?

1 Like

I can’t create a new dictionary in the demo site.

This shouldn’t affect MVP release date.

Personally I do not consider View All Dictionaries as strictly MVP.

Therefore it’s okay if that page loads slowly (as long as that still means <1 minute). I’m also okay to remove the View All Dictionaries feature until the back-end fix is made.

I think a sensible compromise is removing the verbose call for only the initial screen(the one showing user dictionaries), and since we already have search on the All Dictionaries Page, just remove the initial fetch when the user navigates to this screen so that for this page, you have to search in order to get results.

I think we’ll eventually need search on this page, and I’ll add it to the tickets as well for if time opens up.

Hey @akanter, I am unfortunately not able to replicate this.

Hello Community

We shall be having our weekly sync at 15:00 UTC today.

Here is the link to the call

cc: @dkayiwa @c.antwi @akanter @darius @paynejd @tunmi

I am not able to join today due to a workshop in DC. However, I’ll get back to you shortly on how to get the multi-token search to work via the API. Feel free to reach out with additional questions.

Noted @paynejd. Other than that one, the other query was in regards to whether this issue has still not been addressed since the docs seem to imply that this functionality is indeed functional.

For the multi-token search, the web interface automatically adjusts your search based on whether the “Exact match” checkbox is ticked. When Exact match is not ticked, these searches are equivalent:

Please let me know if this resolves the issue

1 Like

That search returns the expected results, yes. Thank you.

As a quick follow up though, this comment( seemed to suggest this was implemented API side.

I will be 10-15 minutes late to today’s call. Apologies in advance.

1 Like

Hello Community,

Thanks to those that managed to make it for the call.

Link to the call

The recording is live here.

Action points from the call;

  • Rename ‘All Dictionaries’ field to ‘Public Dictionaries’
  • add ticket on JIRA pointing to localization issue on github- (priority for this will be decided by user demand/ available time)
  • The ‘do not leave the application’ message should also be present when ‘finding concepts’ is displayed: improve the warning styling if possible
  • drop the ticket removing the verbose api call for now- rationale for this is we do not expect a user to have that many collections: prioritize making the ‘public dictionaries page not load the first time a user visits’
  • It seems like the isolation ‘all dictionaries’ displays collections marked as private- investigate this

Way forward on the development team;

  • Liase with Andela Team Leaders to find resources to ensure continuity and support wider MVP testing
  • Current team should focus on updating documentation and wiki to ensure a smooth transition and allow for continuity

Thank you Lincoln and Andela for continuing to move this work forward. One specific request I have is for a “wish list” of features/tickets for the OCL core API. I’m thinking of things like “Ability to filter sources/collections by additional fields, incl. validation schema and custom attributes”. Thanks!

1 Like

Thanks @karuhanga could you share the recording of yesterdays call

Hey @darius, @akanter

Quick one;
When using the download option for a collection, I assume the downloaded file should include mappings, correct?

@karuhanga, you mean in the traditional UI? I’m not sure now that would behave.

No, the one available for each release.