Developing the "OCL for OpenMRS" Application


(Muhozi Emery) #263

Hey @emmabaye,

Thank you for this. For some clarification, what I’m suggesting is not to override bootstrap CSS. What we can do is to utilize bootstrap source Sass files to take advantage of customizing sass variables, maps, mixins, and more, then use sass compilers to convert those sass files to CSS. Check bootstrap theming Here.

I agree with you that we should not deploy changes immediately. In case we implement them, we should first check if they are not affecting any of the app functionalities. But IMO, this is also to implement best practices of building a maintainable application. Emmanuel and others, please share what you think on this.

Thanks.

CC: @alexmochu @michy @dkayiwa @nesh @emmabaye


(Alex Mochu) #264

I think we should prioritise this after the MVP has been released in order not to break things.


(Kelvin Kariuki) #265

@darius Okay. Thank you for the support.


(Kelvin Kariuki) #267

Hello community,

I need some more clarification on this ticket OCLOMRS-200. From the ticket description, I am required to enable a user to release a dictionary version. In terms of design is there a provision on the mockups where a user can view the unreleased versions of a dictionary? cc @darius @alexmochu @emmabaye @michy @muhozi @dkayiwa


(Alex Mochu) #268

A plus one on the above. Incase the provision of releasing a dictionary version is added , should we also include a retiring/remove/delete provision? @nesh @darius @dkayiwa


(Darius Jazayeri) #269

In the MVP we should have a very simple model of versions and releasing:

  • a user may browse the latest unreleased state
  • do not include any functionality for browsing past versions (yet). We should include a link to browse old versions in the traditional OCL interface.
  • a user may say “release a new version now” an this should release by capturing the current state, and marking this as a release (but as soon as the next change happens then we’re in a new unreleased state.
  • There should be no provision for retiring/removing/deleting a version in the MVP. (We might add this later.)
  • Also, it’s possible that the underlying API supports a more complex model where “released” and “published” are independent. We do not want to support this. In our application when you click Release, it creates a version that is both Released and Published.

Trying to describe the desired behavior in another way:

  1. At first, there are no released versions. I can create a bunch of concepts, but this is all in the “current unreleased state” (I think it’s called the HEAD version in the underlying API, but I’m not certain).
  2. I click the Release button and give the name “1”
  3. At this point the Versions list should show one entry for “version 1”. If I create or edit a concept, that happens in the unreleased/HEAD state, and doesn’t affect version 1.
  4. I click the Release button and give the name “2”
  5. At this point the Versions list should show two entries for “version 2” and “version 1”. Again, any edits or new concepts would go into the unreleased/HEAD state and does not affect versions 1 or 2.

Does this make sense?


(Alex Mochu) #270

Yes, it makes sense. Thank you for the clarification.

@darius A follow up question. While releasing the version should we give the user an option to add a custom version or should every version released by a user be incremented by 1??


(Kelvin Kariuki) #271

@darius So, a user can view both released and unreleased versions of a dictionary? Would it look better if there was a table for released versions and one showing unreleased versions? From the OCL API doc when a version is being created that is where the id is provided and this Id is what is used as a version number. Should there first be a feature to create a new dictionary version?


(Andrew Kanter) #272

Can I confirm this saving of a version is only for dictionaries I have authored? I want to be clear that a user cannot create a version for a source like CIEL.

Andy


(Darius Jazayeri) #273

I think we should make people specify the version number. It’s about equal dev effort, but this allows flexibility, like if you want to be versioned by date like “201809”.

@nesh, what I’m saying is that we want to present the user with a simpler model than what the underlying API actually supports. In our “OCL for OpenMRS” model, there should only be one thing, called a “version”, and there’s only one action “release a version”.

So, no we should not have separate tables for released vs unreleased versions because in our application there should be no such thing as an “unreleased version.” (Except of course that there’s an implied “unreleased current state” but there’s only one of these and it’s special.)

Does this make sense?

Yes. Releasing a version requires you to be an owner of the dictionary. You cannot release someone else’s dictionary.


It occurred to me while typing this that there’s one more detail. A dictionary in this application is a collection (the whole dictionary, really) and a source (for custom concepts, if any). I believe that “releasing a version” of the dictionary should only release a new version of the collection. It doesn’t need to create a version of the source. (The concepts within that source do have all changes saved as versions already.)

@paynejd does this sound right?


(Alex Mochu) #274

@darius before releasing a version of a Dictionary one needs to create it first. This is according to the wiki --> Create new version of a collection


(Alex Mochu) #275

You are very correct. Just like @darius said, you cannot release someone else dictionary


(Darius Jazayeri) #276

@alexmochu that is a concern for the developer of the system, but it should be invisible to the end user.

The end user should see a button that says something like “Release New Version”. If this leads to the coffee making 2 API calls (to create a version and then release it) or user doesn’t need to know.

Does this make sense? We are consuming the OCL API but we can make our application behave differently, to provide a better user experience.


(Alex Mochu) #277

@darius Yes it makes sense.

@nesh I hope this :point_up_2: clarifies your concerns.


(Jonathan Payne) #278

FYI you can publish new version and “release” in a single API call…

Thanks all for driving this forward


(Alex Mochu) #279

@paynejd you very correct. This will be by setting the “released” input to “true” by default.

cc @nesh


(Kelvin Kariuki) #280

Thank you @darius for the clarification I have now understood what is expected. Yes @paynejd, one can release a version while creating it.


(Muhozi Emery) #281

Hello Community,

After merging OCLOMRS-214 there is an issue with deployment from the build build log the issue seems to be related to storage space.

25

Any thought on this? Or someone with access can rebuild so that we can investigate more on this issue.

CC: @dkayiwa @alexmochu @nesh @emmabaye @michy @cintiadr


(Emmanuel Abaye) #282

Similar error occurred after OCLOMRS-205 was merged. It seems it is a docker space issue. Screenshot_2018-09-18%20Open%20Concept%20Lab%20-%20OCL%20client%20-%20Default%20Job%20131%20Build%20log%20-%20OpenMRS%20Bamboo

cc: @cintiadr @dkayiwa @alexmochu @nesh @michy @muhozi


(Alex Mochu) #283

Hello community,

As we come to the end of sprint seven, could you please vote for the best date and time for our Demo.

Thank you.

cc @darius @dkayiwa @emmabaye @nesh @michy @muhozi @akanter @burke