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.
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
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
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:
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).
I click the Release button and give the name “1”
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.
I click the Release button and give the name “2”
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.
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??
@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?
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.
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.)
@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.
clarifies your concerns.
