[User Story]: Edit a shared assurance case

[cptanalatriste]

Role

As an assurance case builder

Desired Feature

I want to be able to edit assurance cases shared with me

Benefit

So that I can work collaboratively on the development or review of an assurance case.

Acceptance Criteria

GIVEN that another user has shared an assurance case with me, with edit permissions WHEN I access this case, from the "Shared with me" section AND I have requested successfully the "lock" of the assurance case. THEN I can edit the description of any element AND I can add or remove new elements AND I can move, attach, re-attach elements AND I can export the case to JSON. AND I cannot share the case with other users.

GIVEN that another user has shared an assurance case with me, with edit permissions WHEN I access this case, from the "Shared with me" section AND I do not have the "lock" of the assurance case. THEN I cannot edit the description of any element AND I cannot add or remove new elements AND I cannot move, attach, re-attach elements AND I cannot export the case to JSON.

Dependencies

No response

Technical Notes

For an initial Proof-of-Concept, we will implement the following locking mechanism:

1. When retrieving Assurance Case information with GET cases/<case-id>, the JSON response will now include a "channel" field, with the URL of the web socket to connect to. Each assurance case will have their own web socket channel.
2. When a user with username username opens an assurance with id case-id that they own/have edit permissions, the frontend should send to the case's web socket channel the following message {"element": "case", "id": case-id, "action": "open", "username": username}
3. All the other users that have the same case open, should receive over its corresponding web socket channel the message generated in step 2. If these users happen to also have edit permissions, they should show the message: "The case case-id is being edited by user username. You cannot modify until they finish". For these users, the case will switch to read-only mode.
4. When the user in step 2. closes the assurance case with case-id, the frontend should send to the cases's web socket channel the following message {"element": "case", "id": case-id, "action": "close", "username": username}
5. All the other users that have the same case open, should receive over its corresponding web socket channel the message generated in step 4. If these users happen to also have edit permissions, they should the message: "The case case-id is now available for editing". For these users, the case will reload and switch to edit mode (if they have permissions).

This is just to get us started. On this foundation, we can build the following features:

1. Send case updates over the web-socket channel, so users in read-only mode can see the edits as they happen.
2. Enable concurrent editing.
3. On the backend, using Redis for handling channel subscriptions (the proof-of-concept will have them in memory)
4. On the backend, authenticate connections to the web socket (the proof-of-concept will no authenticate connections)

Definition of Done

• [ ] The feature fulfills all acceptance criteria.
• [ ] The code is reviewed and meets team coding standards.
• [ ] All unit, integration, and end-to-end tests are passed.
• [ ] The feature meets accessibility standards set for the project.
• [ ] The code passes the CI/CD pipeline quality controls (style and linting).
• [ ] The feature is merged into the main branch.
• [ ] The feature is deployed and functional in the QA environment.
• [ ] The feature was demonstrated to the team and accepted by the product owner.

[cptanalatriste]

@chrisdburr please check if this is the requested feature

[chrisdburr]

Just adding the roles from #565 here for ease of access:

Role	Share Assurance Case	Manage Assurance Case (e.g. rename/delete)	Edit Assurance Case (e.g. add/edit elements or branches)	Add Comments	Download	View Assurance Case
Owner	x	x	x	x	x	x
Editor			x	x	x	x
Reviewer				x	x	x
Viewer						x

[chrisdburr]

I'm not sure about the "requesting locking/unlocking" feature. Is there some alternative between this and the full real-time collaboration option?

Perhaps something like the following:

• User A (owner) is editing assurance_case_1
• User B (who also has edit access) opens assurance_case_1
• User B is unable to edit the file, but sees a notice saying "User A is currently editing this file"
• Once User A has closed the file, then User B is able to edit assurance_case_1
• A timeout feature is added, such that if a user leaves an assurance case open and is inactive for longer than 12 hours, the lock is removed

@cptanalatriste @RichGriff please let me know your thoughts.

Otherwise. I'm happy with the user story.

[RichGriff]

@cptanalatriste @chrisdburr can you both review this in staging for me please, thanks

[RichGriff]

@cptanalatriste I'm unsure what the 'lock' means?

In staging currently, if the user who is accessing the case has edit permissions then they can do those actions.

[cptanalatriste]

@RichGriff it's based on the legacy version on doing concurrent edits, without people overriding each other work. Each assurance case has a "token" (the lock), that can be passed around all the users that have edit privileges over that case.

So, let's say you, @chrisdburr and me has edit privileges over case 7. If I want to edit/modify the case 7, I need to request the token before I start (if I don't have the token, every edit would fail). While I have the token, nor you or @chrisdburr would be able to edit the case, until I give the token to any of you.

If we want to go this route, we would need some GUI components to request the lock/token and see who has the token for a given case. As well as some backend components to provide this information.

@chrisdburr , are you OK with implementing a lock/token mechanism for edits?

[chrisdburr]

@cptanalatriste and @RichGriff please can you discuss the feasibility and value of this approach, as compared with full support for websockets. I won't be able to meet next week due to annual leave, so we can come back to this in a fortnight once you have a clearer estimate.