Skip to content

Fix WorkItemUpdate mutation permissions

What does this MR do and why?

A user that has permission to update a work item's widget might not be able to when using the workItemUpdate mutation because the mutation checks for update_work_item for every update.

For example, to subscribe to a work item with notificationsWidget we require update_subscription permissions (equivalent to read_issue) but the following mutation would fail for a user that cannot update_work_item:

mutation { 
  workItemUpdate(input: {id: "gid://gitlab/WorkItem/1", notificationsWidget: {subscribed: true}}) {
    errors
  }
}
example response
{
  "data": {
    "workItemUpdate": null
  },
  "errors": [
    {
      "message": "The resource that you are attempting to access does not exist or you don't have permission to perform this action",
      "locations": [
        {
          "line": 33,
          "column": 2
        }
      ],
      "path": [
        "workItemUpdate"
      ]
    }
  ]
}

To fix the problem this MR reduces the mutation requirement to read_work_item and separately checks for update_work_item permissions if there are attributes that don't belong to widgets.

How to set up and validate locally

  1. Using the ID of a work item in a public project and a user that is not a member of that project execute the following mutation
mutation
mutation { 
 workItemUpdate(input: { id: "gid://gitlab/WorkItem/<ID>", awardEmojiWidget: { name: "rocket", action: TOGGLE } }) {
    errors
    workItem {
      webUrl
    }
  }
}
  1. Verify that the mutation was successful and the emoji was added to the work item
  2. Add a new attribute to the input and verify that the error "The resource that you are attempting to access does not exist or you don't have permission to perform this action" is returned
mutation with title attribute
mutation workItemUpdate2 { 
  workItemUpdate(input: {id: "gid://gitlab/WorkItem/<ID>", title: "new title", awardEmojiWidget: {name: "rocket", action: TOGGLE}}) {
    errors
    workItem {
      webUrl
    }
  }
}
  1. Checkout to master and verify that step 1 fails and returns the same error as step 3.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Eugenia Grieff

Merge request reports