@sharif and @christine I’m also wondering - why do we intentionally instruct the RefApp release QA testers to not try adding a relationship when the register the patient (test scenario #1 in the test list here: https://docs.google.com/spreadsheets/d/1YyyK9_lPpFghSKR14NqI8JC4WIp-v0FMtSjBRCStXKc/edit#gid=1222728156). I added relationships when I first registered a patient (one was custom text, and one was suggested by the system from an existing patient) and found that it doesn’t save in the dashboard even though the pre-submission summary screen made it look like the relationships would be captured.
Thanks @grace for this catch ,True dat when editing relationship, the confirm button doesn’t work , this is i think is a bug to work one unless other ideas to come up , Even though you save the form using save button, Nothing happens as we see here
Technically, the view on the dashboard doesn’t come from the same place as the view in the registration app. The “FAMILY” section of the dashboard is one of the widgets defined in coreapps and doesn’t have an associated editing page, hence it’s not editable. Two of the editable items there (attachments and allergies) are actually provided by separate modules (attachement and allergies-ui respectively). The Conditions is provided in coreapps, but it comes with a page to edit the condition list.
The form to edit patient relationships is provided by the registration module, but it’s not populating the FAMILY part of things.
This could certainly be handled more intuitively, e.g., by removing the FAMILY widget from coreapps and adding one from the registration module. The question then would be: is this something we need for RefApp 2.11 or can we delay this feature for RefApp 2.12? (I don’t think there’s any change in behaviour from the current release, though it’s obviously not ideal behaviour).
I would expect that we want to require #2, i.e., we should be documenting relatives only if there’s some kind of defined relationship. #1 seems to me to be clearly a bug. Again, though, the question is if this is not a regression, should this be slated to be fixed as part of the 2.11 release or pushed to 2.12?
Thanks @ibacher for your clarification.We can definately handle it before the release refapp 2.11 perhaps we can include it the current sprint if we decide removing it.Does that means we are to bring forth the edit relationship
under GeneralAction to reflect exact changes would have placed family widget from coreapps
Thanks so much @ibacher, this was extremely helpful.
Actually @sharif, Ian is right to question the priority of upgrading the edit workflow - since this is not a regression, enabling this new more direct editing functionality is neither a blocker nor a high priority for the RefApp 2.11 release. Given that 4 of the 17 manual RefApp tests from last sprint failed either due to medium or blocker issues, I don’t think we should increase the scope with things that are nice-to-have (even though saving clinical users unnecessary clicks is generally a very good thing to do).
@sharif last night I went through the manual testing spreadsheet and ensured there were tickets captured under the RefApp 2.11 Fix Version, since it looked like some issues discovered didn’t have a clear ticket logged, or hadn’t been prioritized. Then I added things that looked like they should be higher priorities to the RefApp Release Sprint 2 - so you can see the sprint scope is already growing. Please feel free to add or remove things so that the sprint captures the most high priority work.
…Sorry, it’s my fault for bringing this up and causing distraction. Normally I would write a ticket for this but after doing more testing last night it looks like we have such a backlog that I don’t want to add anything more - and it sounds like a more structural change than I expected. Better to invest in the future 3.0 frontend in the coming months than re-work workflows in the current RefApp.
However, we do need a ticket for the issue that you can’t successfully create relationships when registering a patient. I’ll look for an existing one or log now.