Unable to edit Planner items created by others

[sivaavkd]

Here is an example: 2164 was created by Mitesh. Both Bob and Brad tried to edit it and they cannot ("Problem in update Workitem"). However, I am able to edit. So, Bob created another item 2395 and I am able to edit that too.

Is there any additional step that needs to be done to get these accesses properly set ?

cc @bmicklea @miteshvp

[joshuawilson]

I think you might not be Contributors on the Space. I was able to change Bob's issue to closed.

[sivaavkd]

Both Mitesh and Bob are contributors so am I. We also noticed that Sam is unable to edit a feature that I created who is also a contributor. @joshuawilson @samuzzal-choudhury

[sivaavkd]

I just tried and couldn't update 2395 which Bob created. Interestingly, I was able to update it few days ago when I created this issue.

[michaelkleinhenz]

There is no AuthZ beyond the contributor check. If there is a problem with the update, this is likely caused by something else. Can you check the request to the backend (look for a PATCH request that has a URL following this format: https://api.openshift.io/api/workitems/[UUID]) and report back the result of the request?

[rgarg1]

I can confirm that being a contributor, I can edit work items created by others. So, this must be an auth related issue.

[miteshvp]

It seems to me that, when there are more than one user working on same item, this becomes a problem.

1. User A is modifying Experience 1
2. User B has Planning page open
3. User A saves Experience 1
4. User A sees refreshed contents
5. User B still on Planning page and does not see refreshed contents related to Experience 1
6. User B tries to modify Experience 1
7. They get the error 409 conflict but notification displays problem in updation

Error logs from Patch

PATCH https://api.openshift.io/api/workitems/f1319362-03f5-450a-b13b-849d260deddf 409 (Conflict)
main.2e4f6bb80555b19139fa.bundle.js:1 retryWhen callback
main.2e4f6bb80555b19139fa.bundle.js:1 ERROR [WorkItemService] Updating work item failed.

[sivaavkd]

Thanks @miteshvp .. @michaelkleinhenz @joshuawilson - Given this scenario, should we ask user B to refresh the page instead of an unknown error message ?

[rgarg1]

Thanks, @miteshvp for the insight.

The issue is with the version information of the work item. Each patch request relies on the version information and if the patch request carries an unexpected version, we see 409 error.

In this case, since the UI is not refreshed for user B, the version number sent in the patch request is older, hence 409.

Maybe UI requesting the updated version from the backend, before every patch request, would solve the problem.

@sanbornsen @vikram-raj ??

[michaelkleinhenz]

@rgarg1 it is not that easy, actually. What should we do if there is an update coming in that conflicts with local changes? After the ngrx/store integration, we have already scheduled the integration of push updates. For these, we will also need to revisit the conflict scenarios. I don't see how we can do a quick fix for this.

But I agree with @sivaavkd that we should signal the user that there is a conflict happening and he should refresh manually (for now).

@rgarg1 can you add a new story for this to the backlog?

[bmicklea]

Please make sure there's also an issue in the backlog for the proper fix, asking for a refresh isn't ideal as you've mentioned.

Do we have a list of issues generated from our team's use of planner - the dog fooding issues? --

Brad Micklea // Director, Product Management // Developer Tools // 416.707.0792

[nimishamukherjee]

@michaelkleinhenz @rgarg1 the right fix is the technical feature of "polling" that we need to introduce in planner. This would be a feature that we would have to work with Platform team as the notification display mechanism is tied to the user profile.

As @michaelkleinhenz said, a fix for this would be to display relevant error message other than "Something went wrong".

[rgarg1]

@michaelkleinhenz https://openshift.io/openshiftio/openshiftio/plan/detail/2437