Probably makes sense to wait until you can test with the full CIEL dictionary loaded, instead of a toy subset.
@raff, Please help me clarify this. Should we use OCL_API_HOST as an environment variable in a .env file or we can just change BASE_URL to OCL_API_HOST because currently we are having BASE_URL = https://api.qa.openconceptlab.org/.
Hello, community
This is a reminder of the OCL-client team and POs weekly sync (Thursdays 6pm - 7pm EAT). I will share a link to the call 15minutes before the call. kindly attend if you can make it.
cc: @dkayiwa, @samdiano, @sheriff, @brucemakallan, @judeatu, @c.antwi, @akanter, @darius, @alexkayabula
Here is the link to the call (Weekly sync) https://hangouts.google.com/hangouts/_/ytl/7bd6FeJVUyDfYz47Ezj5CvGn83-JlsAhb2xVGJNMGcw=?eid=107163098052414183455&hl=en_US .
cc: @darius, @akanter, @dkayiwa, @samdiano, @sheriff, @stonecoder, @brucemakallan, @judeatu,
I am confused by this thread. It seems that any dictionary once released should only allow retiring of the concept. I don’t see the difference between custom and linked concepts.
I agree that once released it should be retire-able and pre-release deletable.
Once retired, the only option should be edit (to be able to see and/or unretire).
Therefore the retire/delete or unretire buttons should be on the EDIT screen.
Hello community
The team had a successful sync. Thanks to everyone that made it. For those that missed the call, here is a link to the call.
Regards!
cc: @darius, @akanter, @dkayiwa, @shine, @collinewait, @samdiano, @sheriff, @abulojoshua1, @brucemakallan, @judeatu, @alexkayabula
Sorry, I missed the call, but glad that @akanter was there.
- Please report the details of the failures in the subscription module to @raff. Both
- the fact that subscribing to a collection version fails with a 404
- the fact that subscribing to the base url of the collection fails in another way
- and in doing so give him the full details including the token
- I agree with Andy’s suggestion to move the Retire/Unretire/Delete buttons to the Edit screen. (Ideally they’d be on the View screen, but we don’t have this yet.) This is not a requirement for the MVP release. But if you’re going to modify the code related to this, if it’s just as easy to move it to the edit screen, then go ahead and move it now.
- to clarify why I think that custom concepts vs referenced concepts should be treated differently:
- custom concepts belong to the dictionary, but referenced concepts belong to someone else. We do not make a copy of them, we just have a reference.
- therefore you cannot retire a referenced concept. The only thing you can do is remove it from your dictionary. (Under the hood it will continue to belong to previously-released versions of your dictionary, but it will be removed from the HEAD version.)
- it sounds like we need to discuss this further though
About @ruffjm’s feedback, this is very good feedback, but as Andy said, most of it is post-MVP.
Completely agree. On next week’s catchup we can assign someone (me? jonathan?) to write some better wording.
It will be possible to select any source that’s in OCL and whose type is internal. Looking right now I see that LOINC is external, so that isn’t currently an option. This would be something for her to discuss with @paynejd, though, as it’s about content, and out of scope for the UI part .
This is good feedback. It also illustrates why I never wanted to have a quick search feature at all because users will want to grow it until it matches the functionality of the whole rest of the application.
Do not make this change. Also, don’t demo that quick search to anyone. 
The bulk add is supposed to be for copy-pasting a list of concepts ids from a spreadsheet, or similar.
Good feedback. After the MVP we can consider whether we could have a format for uploading things like diagnoses, symptoms, etc, that are amenable to bulk creation. That said, it would be much better to solve this in the back-end, not in the react front-end.
Can you talk a little more about the bulk add feature you mentioned?
“The bulk add is supposed to be for copy-pasting a list of concepts ids from a spreadsheet, or similar.”
I’m not sure I understand when this would happen. I’ve found that many concepts relate to answer choices that we need for select/multiple choice are in the CIEL dictionary, but I wouldn’t have a list of concept ids without first looking then up in open concept lab.
Hello @ruffjm,
Two types of “Bulk Add” were discussed during the call:
- The ability to add bulk concepts from CIEL or other sources. This feature takes in a list of Concept IDs.
- The ability to create more than one new Concept. e.g. Create 2 new Diagnosis Concepts at the same time (probably by copying all the concept details from a spreadsheet) as opposed to adding one at a time using a form.
Concerning the first one, as @darius mentioned, “The bulk add is supposed to be for copy-pasting a list of concepts ids from a spreadsheet, or similar.” Therefore the MVP will only support this behaviour.
The second one will also be considered for versions after the MVP.
@darius concerning the feedback you gave on making the search consistent across the entire application. I looked into it and the search that occurs without pressing the enter button is within a select option and it displays suggestions to select from concepts that matches what was typed.
But the search here is supposed to work as a dropdown and not a search widget. It’s purpose is to fill the form input and no to list results
1 Like
@raff This is a reminder. I request you please clarify this. Once again Should we use OCL_API_HOST as an environment variable in a .env file or we can just change BASE_URL to OCL_API_HOST because currently, we are having BASE_URL = https://api.qa.openconceptlab.org/.
@ruffjm, the idea is that the regular UI is good for people who will be managing concepts through this application in the normal way. And it supports doing a search and then adding multiple results, for example, which is basically what the quick search on the Bulk Add page does.
The real purpose of the Bulk Add page is for doing some kind of management outside of the application, e.g. some people did a shared job of mapping a diagnosis list against CIEL and they put the CIEL IDs into a column in a google sheet. Bulk Add would let you copy-paste that column from the google sheet into this application.
In the big picture I disagree with this statement.
The most common atomic action that a user will do with our application is “search [usually within a specified dictionary] and then choose a concept”. That action will be reused across many user journeys, but we should have this search action be as consistent as possible throughout. The user won’t differentiate between “searching for a concept within a dropdown” versus “searching for a concept that will display on the screen”, and both of these actually show a list of results, even if one list is floating/modal, and the other isn’t.
In the long run we will continue to perfect the main search widget that’s used on the dictionary-concepts and add-a-concept screen, and we’ll need to figure out how to incorporate that improved widget into the searches on this page (used for answer-to-question, member-of-set, and mapping-target). E.g. the function to filter by classes/datatypes, and preview the concept before selecting it are also important here. This is not part of the MVP release, but I want to highlight that’s the direction we’ll be going.
(As an aside, search-as-you-type is better UX if you can guarantee that (1) the backend can handle the load and is blazing fast, (2) the widget correctly handles all corner cases, e.g. of responses coming back out of order. If these two don’t hold, then it’s worse UX, and in my experience with OCL’s concept search we definitely can’t guarantee #1.)
So in summary, this should behave like the search on the main pages, where you have to press enter to search.
1 Like
@raff, Once again Please help me clarify this. Should we use OCL_API_HOST as an environment variable in a .env file or we can just change BASE_URL to OCL_API_HOST because currently we are having BASE_URL = https://api.qa.openconceptlab.org/.
@judeatu, to be aligned with other OCL services please rename your BASE_URL to OCL_API_HOST. Please make sure that the variable is read at runtime and not when building a docker image, because we will want to reuse the same docker image for qa and demo environments.
In addition, please make sure that you do not hardcode https://openmrs.qa.openconceptlab.org in any place in your code so that the project can be deployed under https://openmrs.demo.openconceptlab.org without breaking anything. If you want you can make use of a dedicated BASE_URL variable, which will point to https://openmrs.qa.openconceptlab.org or https://openmrs.demo.openconceptlab.org. The BASE_URL variable happens to have the same name as the one you used for the API endpoint, thus it may have confused you.
@raff I keep getting this error while trying to log into https://qa.openconceptlab.org/accounts/login. Do you know what could be the cause of the error?
@dkayiwa @darius
@raff, I have managed to rename BASE_URL to OCL_API_HOST and implemented it to be saved as environment variables using a .env file as shown in this PR but now the tests are failling because we need to pass the environment variable URLs as shown below to the Travis settings that I have no access to.
REACT_APP_OCL_API_HOST=https://api.qa.openconceptlab.org/
REACT_APP_TRADITIONAL_OCL=https://qa.openconceptlab.org
So my request is that the above environment variables are passed to the Travis environment variable settings.
Cc: @cintiadr