Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Users unable to edit the report they created #8589

Closed
1yuv opened this issue Sep 26, 2023 · 8 comments
Closed

Users unable to edit the report they created #8589

1yuv opened this issue Sep 26, 2023 · 8 comments
Assignees
Labels
Affects: 4.3.0 Affects: 4.3.1 Affects: 4.4.0 Priority: 1 - High Blocks the next release. Regression Affects a feature that worked in a previous release Type: Bug Fix something that isn't working as intended
Milestone

Comments

@1yuv
Copy link
Member

1yuv commented Sep 26, 2023

Describe the bug
We've seen CHT user(s) are able to create report but they are not able to edit the same report.

To Reproduce

  1. Create a report with offline CHT user for particular contact
  2. Go to Reports tab and select same report
  3. Click on Edit to edit this report.
  4. See error

Expected behavior
Users should be able to edit the report that they created if permission allows that.

Screenshots
See the video:

Screen.Recording.2023-09-26.at.2.45.52.PM.mov

Environment

  • Instance: walling.dev
  • Browser: Chrome
  • Client platform: MacOS
  • App: Webapp
  • Version: 4.3.1 and 4.4.0 both tested

Additional context
app settings and forms used for this: medic/config-nssd#406 (internal)

@1yuv 1yuv added the Type: Bug Fix something that isn't working as intended label Sep 26, 2023
@dianabarsan
Copy link
Member

dianabarsan commented Sep 26, 2023

@yrimal
Can you please also share the permissions of the form and the contact type you are adding this report for?

@1yuv
Copy link
Member Author

1yuv commented Sep 26, 2023

Hi @dianabarsan ,
Here's the forms.properties section

{
  "title": [
    {
      "locale": "en",
      "content": "Non-communicable diseases survey form"
    },
    {
      "locale": "ne",
      "content": "नसर्ने रोग सम्बन्धी सर्बेक्षण फारम"
    }
  ],
  "context": {
    "place": false,
    "person": true,
    "expression": "contact.contact_type === 'c82_person' && user._id != contact._id"
  },
  "icon": "icon-healthcare-assessment"
}

Contact type for which this report was added is c82_person.

@dianabarsan
Copy link
Member

I am able to replicate this with default config and submitting a death_report form. It looks like the form expression context does not get populated with current form data when it's evaluated for an edit.

@dianabarsan dianabarsan added Priority: 1 - High Blocks the next release. Regression Affects a feature that worked in a previous release Affects: 4.3.0 Affects: 4.4.0 labels Sep 27, 2023
@dianabarsan
Copy link
Member

I believe this started manifesting when we merged #6505 and started evaluating form context on edit. The issue is that the context that we sent on edit does not have the same format as on create.

@dianabarsan dianabarsan self-assigned this Sep 27, 2023
@dianabarsan
Copy link
Member

Thinking more about it, I'm unsure if we should even apply form expressions when editing forms.

I'm thinking of common examples where blocking editing based on form expression can be wrong:

  • it's common to block showing a form to muted contacts. Suppose that a form is submitted against a contact that is later muted, evaluating the form expression would prevent the editing because the contact is now muted.
  • a form is displayed based on some temporary contact-summary data: for example someone is pregnant or has some other transitory condition. The contact no longer having this condition should not prevent edits to the form.

List can continue. Seeking feedback from @garethbowen and @michaelkohn .

@garethbowen
Copy link
Member

I'm not 100% convinced by your examples, because in both cases someone is editing a report that is no longer relevant anyway. Why edit a report for a muted contact? Or for a condition that no longer applies to the patient? A particularly fastidious health worker may want to fix the data regardless but I think it's unlikely.

One more concerning example would be if they submitted a report that was incorrect which caused the report itself to be uneditable. For example, if a pregnant woman had a checkup, and one of the questions was "has the baby been delivered?". Answering "yes" might remove the "pregnant" condition which could make the "checkup" form irrelevant, and therefore you couldn't edit the report and turn the "yes" to a "no".

So I think your approach makes sense - for editing check permissions but don't check the expression.

@dianabarsan
Copy link
Member

Backported fix to 4.3.x

@dianabarsan
Copy link
Member

Backported to 4.4.x and merged to master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Affects: 4.3.0 Affects: 4.3.1 Affects: 4.4.0 Priority: 1 - High Blocks the next release. Regression Affects a feature that worked in a previous release Type: Bug Fix something that isn't working as intended
Projects
None yet
Development

No branches or pull requests

3 participants