GNU Health - Bugs: bug #63627, Problematic restriction for...
You are not allowed to post comments on this tracker with your current authentication level.
bug #63627: Problematic restriction for editing parties from the patients view
| Submitter: | Mathias Behrle <yangoon> | ||
| Submitted: | Fri 06 Jan 2023 07:43:42 PM UTC | ||
| Category: | Functionality | Severity: | 1 - Wish |
| Item Group: | None | Status: | Works For Me |
| Privacy: | Public | Assigned to: | meanmicio |
| Open/Closed: | Closed | Release: | 4.3.0 |
| Module: | health | Component: | Hospital Management |
|
Sun 15 Jan 2023 12:08:16 PM UTC, comment #5: |
Mathias Behrle <yangoon> |
|
Tue 10 Jan 2023 04:41:35 PM UTC, comment #4: Closing the issue with the proposed solution.
|
Luis Falcon <meanmicio> |
|
Mon 09 Jan 2023 10:28:24 AM UTC, comment #3: Hi, Axel!
|
Luis Falcon <meanmicio> |
|
Mon 09 Jan 2023 09:26:06 AM UTC, comment #2: Hi Luis,
|
Axel Braun <coogor> |
|
Sun 08 Jan 2023 08:36:29 PM UTC, comment #1: Hi, Mathias, and happy 2023!
|
Luis Falcon <meanmicio> |
|
Fri 06 Jan 2023 07:43:42 PM UTC, original submission:
The field name on gnuhealth.patient relating to party has defined states={'readonly': Eval('id', 0) > 0}. I would like to hear what is the reason behind this restriction which means that new parties can be created for patients, but as soon as they are saved, they can no more be edited from the patients view. I have no idea why the correction of party data should not be possible directly from the patient view in the same way as creation of parties is allowed. I think removing this restriction will result in a substantially improved user experience. |
Mathias Behrle <yangoon> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 10 latest changes.
| Date | Changed by | Updated Field | Previous Value | => | Replaced by |
|---|---|---|---|---|---|
| 2023-01-10 | meanmicio | Status | Need Info | Works For Me | |
| Open/Closed | Open | Closed | |||
| 2023-01-09 | meanmicio | Status | None | Need Info | |
| 2023-01-09 | meanmicio | Severity | 3 - Normal | 1 - Wish | |
| Release | 4.1.0 | 4.3.0 | |||
| 2023-01-09 | coogor | Status | Works For Me | None | |
| 2023-01-08 | meanmicio | Status | None | Works For Me | |
| Assigned to | None | meanmicio | |||
| Release | None | 4.1.0 | |||
| Component | None | Hospital Management |
Powered by Savane 3.12.
Corresponding source code

Hi Luis,
late best wishes for a happy 2023 and thank you for your explanation!
I think there is still room for improvement, please read my inline comments.
comment #3:
Just for the sake of understanding: for me there is often a misunderstanding of the term security, which is often confounded with access rights.
Security: Properties of an application to not allow break in or interfere with the application by technical means.
Access rights: Properties of an application to allow access to specified parts of the application in regular usage.
Integrity: Properties of an application to guarantee the integrity of data.
JFTR with respect to those definitions I would rename all folders in health modules named security to access_rights, because that is what they are meant for.
Well, anyone with read access to the patient model using the GTK client can edit the party, because the party model is not locked down with any access permissions. I once proposed to define general access rights for all such models, but upstream denied with the argument, that it is a model that will be required to use in any scenario so it wouldn't make sense to limit access to it. I still see it differently and perhaps GH should implement access rights for the party model.
That's indeed integrity and I see your point.
I would solve the problem differently: Since there is a strict 1:1 relation between party and patient I would have modelled the patient model not as a separate model but implemented the patient fields (and methods etc.) directly on party. Display and access to different parts of the view could be implemented by view_attributes. This would remove the fuzz to care about the 1:1 relation and would improve the user experience when trying to edit patients.
What do you think?
Front Desk has currently (menu and write) access to Patient related information and Parties (which is more than Doctors have...).
Yes, at least for now there should be a relate for web client users.
Best
Mathias