Thank you @zacbutko for the 4.0 migration PR. After the migration, the UI layout was broken because of the new version of the carbon design. I was working on fixing them and here’s the PR. Can you review this? @jayasanka
Next, I will work on fixing the tests that broke due to this migration. Thank you!
Hello everyone! I have some concerns regarding the “Search by SQL Queries” features. One of the main concerns is security(ex: SQL injection). It’s difficult to create an API that covers all the security issues and will be hard to maintain as well.
Another reason is, that this feature cannot be used by someone who doesn’t know SQL and the database schema.
Instead of the SQL query runner, we can extend the search criteria. ex: Search by allergies. Which will be safer and user-friendly.
I agree with you @anjisvj ! We need to further validate the requirement. I think it would be better if we could move it to the outer scope and polish up the current features.
This might be a better question for our design team @cduffy and @pauladams. I’m not sure what the goal of the cohort builder is within O3. For my app I was going to have a redirect workflow - a button to take you to the cohort builder and then redirect logic to put you back in the app after - so really in that workflow it wouldn’t need any permanent links. From that regard maybe this is more like “patient registration” resource. But I’ll defer to the experts.
Personally, I think it belongs in the App Switcher, but with some kind of privilege guard around it (the UserHasAccess component). To my mind, this is less to do with how it’s used than how easily discoverable we need the feature to be.
Well said Ian. However in this particular example - let’s think about the workflow:
Who needs the cohort builder tooling? People with Admin access.
How do those people usually find the tools? In the System Administration menu.
How do those people usually find the cohort builder? In the relevant section of the Sys Admin page, eg here:
Thus, executive decision here: we should keep the User Experience consistent and continue linking to the Cohort Builder UI from that same place. It just means that when you click on the thing in the old Admin Page UI, it takes you to the new Cohort Builder UI instead of the old one. Is that technically feasible for you to do @anjisvj?
(Otherwise, the App Switcher menu will grow crazy long over time and get increasingly difficult for Admins to find what they need.)
That makes sense @grace. But before replacing the old one it’s better to do some testing and ensure it’s stable. @tanderson said that they are willing to help with testing. But in dev3 cohort builder seems to be not working. It does work locally. I will check what’s the issue there.
In terms of usage, we at PIH-Rwanda use it in 3 ways.
Indicators at the coordinator level. (This is used very frequently in Rwanda for PIH sites by the coordinators and by the IT’s at MOH supported hospitals)
Data pulls by the coordinators using Data Export from the Admin page using saved cohorts from Cohort builder
The creation of saved cohorts that are the initial basis of what mUzima pulls (I don’t totally understand this as it feels like MySQL is part of the pull as well)
#'s 2 and 3 are naturally administrative actions. #1 is is done only by people who have access to the admin page, but it hasn’t felt as adminny. We have historically had access through a header menu along with ‘dictionary’ which was natural for use #1.
Admin fits fine for us, this is just the broader context for PIH-Rwanda.
