Developing the "OCL for OpenMRS" Application

Development
1181

Hello Community

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

Here is the link to the call

The primary tickets we’ll discuss are here(https://issues.openmrs.org/issues/?jql=labels+%3D+14thAug).

cc: @dkayiwa @c.antwi @akanter @darius @paynejd @paulk @judeatu

1 Like
1182

I probably will not be able to attend the meeting today due to a conflict at work. Sorry.

1 Like
1183

Noted. Kindly provide feedback on the tickets if you can.

1184

Hello Community,

Thanks to everyone that was able to make it for the call. The recording is available here(https://youtu.be/X4-ay1B0w-0). Unfortunately recording began a little late.

Key points from the sync;

  • On OCLOMRS-702: Functionality OK, would be OK to add more dictionary details, not mvp
  • On OCLOMRS-701: Find list of classes relevant to concepts only(@payne, @akanter)
  • On OCLOMRS-705: Share search results comparison using bestMatch and name(for Diabetes, Pulmonary searches) for decision on which to use
  • Quantify amount of work if we were to add update functionality for a single concept(this also ties into decision @akanter and @darius have on this)
  • Results from testing add ciel concepts on slower connection
    • add ciel concepts page, request concepts from only internal mappings
    • on 2G- at worst 1 sec/ extra concept
    • adding takes alot longer though(note the slow put somewhere(ticket))
  • on add ciel concepts, point to the latest released version
    • show the version on the page
    • add should also pick from this version
    • on recursive add as well
    • basically, all operations should pick from the latest released, and not merely latest version
  • verify that latest version of CIEL is being loaded up(cc. @c.antwi , @paynejd - old ocl shows wrong latest HEAD for collections(wrong last modified date, cc. @paynejd - open issue for this

cc. @paulk @paynejd @c.antwi @dkayiwa @judeatu

1 Like
1185

Results here(OCL for OpenMRS API Sort Results - Pastebin.com).

Generally, switching from bestMatch to name gives us stable results by alphabetical display name(bestMatch results change when a concept is added to a collection).
Ideally, we would want bestMatch to work for ids as well. It does not, e.g searching for 100 displays 162858 first yet there is a perfect 100 id match. OCLOMRS-531 is tracking this issue.

1186

Can we please see these side by side in list format? It is hard to see the differences without specific examples and pastebin is hard to see.

1188

This is deployed here if you would like to test it out.

1189

@darius, in regards to this,

  1. Both qa and demo have a single unreleased version of the CIEL source.
  2. We can add a specific version of a concept that we pick from the versioned source, but the concepts that the mappings point to are not versioned(mappings · OpenConceptLab/oclapi Wiki · GitHub), so while fetching and adding dependencies, we would be pointing to the latest concept version

UPDATE: Since afaik, the CIEL source is simply loaded on deploy, would it be sufficient for MVP to only load released versions?

1190

Hello everyone, sometime last week we had a catch-up with @herbert24 concerning the testing work that was underway and one thing we agreed is that in the long run we might need to have high level automated tests that can do verifications such as doing an end to end process of adding a dictionary, or adding a concept or any other function that can be carried out in the OCL for OpenMRS.

To solve this problem and to also ensure that everything works from a regression perspective, we could write acceptance and end to end tests, to live in the OCL for OpenMRS Github repository. The acceptance tests would be high level in the sense that they would use mocked data to test user interaction with a tool like jest and puppeteer. We can use visual regression for the various steps. End to End tests would do much of what @herbert24 and team have been working on and will be used to test happy scenarios of a complete process (We do not need much of these as acceptance tests would be able to handle most scenarios); The tests will not only be useful to the developers when something changes but they can also be used to test the system’s stability in the long-run. Cypress framework can be used for the end to end tests and good thing they do have support for OpenSource.

Since these tests would be UI based, they can tend to be slow running and would recommend that they be run on a schedule and when deploying to master.

4 Likes
1191

cc @dkayiwa @c.antwi @darius

1192

Hey @c.antwi,
Just checking if you were able to reach out to @paynejd to check if the latest CIEL version could be loaded.

1193

DONE and you are in copy :slight_smile:

1 Like
1194

Hey @darius, @akanter
Were you able to come to a conclusion for what the update could look like if we were to do something for MVP?
Also in regards to how this might work on the view concept Page, I think it would still be difficult to identify which concept needs updating since addition/removal of mappings in itself does not cause a change to a concept’s version.

This would work for when a concept’s details(and therefore version) changed;

  • check if a concept is the latest version and if it is not,
  • find its latest released source
  • get its version in this source
  • if they are not equivalent, update it(including recursive concepts and cascaded mappings)

Note that this would also not take care of updating the recursive concepts themselves(achieving this would require removing them first)

cc. @dkayiwa @paulk @c.antwi @judeatu

1195

I think we did. I will let @darius describe the functionality, although even this is probably not going to be feasible for the MVP.

What concerns me about your statement is that there can be changes to mappings without a change to the released version. I would have expected that a released version is internally consistent, and that each mapped concept is to the released version. If you change a mapping, that change appears in a new version (HEAD) until the next published release. There should not be any inconsistency. Perhaps this requires another discussion with @paynejd to understand expected backend behavior.

1 Like
1196

Are you referring to the concept or source version here @akanter

Each mapped concept is to whatever concept version was used when creating the mapping.

This is the current behavior so this part is OK.

And to be clear, I don’t think this is an issue, it just stems from the fact that mappings and concepts are separate entities and updating one doesn’t affect the other.

PS. You never did get back to me on this.

1197

Sorry. I was not sure about the results… I wasn’t really happy with either of them to be honest. Let me take a look again.

1 Like
1198

After talking with Andy I think there is nothing we can possibly do before MVP that would be good enough, so let’s not touch this now.

We should document that the user can remove and add again.

Ensuring that when adding a CIEL concept, the search and the link are against the latest released version of CIEL is the key MVP requirement.

1199

Noted.

I’d mentioned something in regards to this earlier.

1200

So the demo script is loading an unreleased version of CIEL source? We should just mark it as released for the purposes of testing. Same applies to QA, but the script should only be bringing a released version of CIEL. Since I don’t manage CIEL on OCL at the moment, every release of CIEL should be “released” on OCL.

Andy

1 Like
1201

i came up with a doc on some things found out when testing OCL as seen here ,https://docs.google.com/document/d/1w9nxontTUd8y2DoJjKnLZTMWS4OnAe0PV7oK-AVgVwc/edit @karuhanga you can get to me incase of any questions from that doc. cc @darius @c.antwi @burke @wawere

1 Like