Just to be pedantic (for teaching purposes!): View concept option is not MVP, but it might go in the first release if time opens up.
(MVP is a concept.)
Next week I’m unavailable Tuesday-Thursday. We could reschedule the catchup for Friday, or else if @akanter is definitely available then you all can catch up without me.
Hey @darius, in regards to the Synonym nae type value being stored as null. Is there any particular reason we have to use null. I worry it might cause confusion between when a name_type is actually blank, that is not specified and when the user selects Synonym.
One particular place this is a worry is for example when setting defaults on names in the UI.
Is managing collections that are owned by an organization to which I belong within the scope of MVP?
Currently, the collections page displays only collections the logged in user owns.
Yes this is required. You can already create collections belonging to an org.
You also need to be able to see/edit them (assuming you have privileges).
Hey @darius@akanter,
A few questions on my mind from the weekend.
First, on the page main user dictionaries page,
How many orgs can someone realistically have on that page?
If the answer to this is > say 15, we might need to;
stop displaying the concept counts to eliminate the need for a verbose call or
implement pagination for this page
On the latter point, further, given the API (afsaik) does not support something like get all collections I am allowed to manage, we currently have to fetch these separately for each org, meaning we might have to separate each org’s collections and paginate them separately.
Secondly, on the view all dictionaries page,
I suppose this page can have a large amount of dictionaries.
We currently fetch ALL collections here and then filter out those without OpenMRS validation. I think this might be a problem.
Introducing pagination using the API here would require us to either;
do that filter on the backend(for validated collections) or
we could display them all and grey out those that the OCL client can’t manage
*Given that we persist state between user visits, these issues sometimes aren’t obviously visible. But doing things like searching sometimes does expose them
**It would also be helpful to keep the extra test data that had been added last week, as it is harder to see these issues with a few collections. cc @paynejd