fix(backend): allow users with read access level to revoke their own access on shared workflows

[seongjinyoon]

What changes were proposed in this PR?

This PR fixes a permission issue where users with READ access to a workflow could not revoke their own access.

Changes:

• Updated revokeAccess() method in WorkflowAccessResource.scala to allow users to revoke their own access regardless of privilege level (READ or WRITE).
• Added owner protection which prevents workflow owners from revoking their own access to avoid orphaned workflows.

Before:

• Backend requires WRITE privilege for self-revocation.
• READ users received error when revoking their own access.

After:

• READ users can revoke their own access to a shared workflow (leave shared workflows).
• Owners cannot revoke their own access (prevent orphaned workflows).

Demo:

Screen.Recording.2025-12-29.at.6.13.00.PM.mov

Any related issues, documentation, discussions?

Fixes #4141.

How was this PR tested?

Run sbt "WorkflowExecutionService/testOnly *WorkflowAccessResourceSpec"

Was this PR authored or co-authored using generative AI tooling?

No.

[chenlica]

Thanks for the PR. A few comments:

1. In the video the user clicked the share button for the computing unit. If so, I think it should show something related to a workflow.

2. Can we add some test cases to replace manual testing?

[seongjinyoon]

What changes were proposed in this PR?

This PR fixes a permission issue where users with READ access to a workflow could not revoke their own access.

Changes:

• Updated revokeAccess() method in WorkflowAccessResource.scala to allow users to revoke their own access regardless of privilege level (READ or WRITE).
• Added owner protection which prevents workflow owners from revoking their own access to avoid orphaned workflows.

Before:

• Backend requires WRITE privilege for self-revocation.
• READ users received error when revoking their own access.

After:

• READ users can revoke their own access to a shared workflow (leave shared workflows).
• Owners cannot revoke their own access (prevent orphaned workflows).

Demo:

Screen.Recording.2025-12-29.at.6.13.00.PM.mov

Any related issues, documentation, discussions?

Fixes #4141.

How was this PR tested?

Manually tested.

Was this PR authored or co-authored using generative AI tooling?

No.

Thanks for the PR. A few comments:

1. In the video the user clicked the share button for the computing unit. If so, I think it should show something related to a workflow.
2. Can we add some test cases to replace manual testing?

For 1. In the video, the user clicks on the share button for the workflow.
For 2. I will add test cases for this PR.

[seongjinyoon]

@chenlica I have added test cases.

[chenlica]

@aicam Please review it.

[aicam]

LGTM

[seongjinyoon]

@chenlica After some investigation, I found that MockTexeraDB has a bug that does not allow the test cases to pass when running the full test suite (test cases pass when ran individually). I suggest removing the test cases for this PR, investigate the issue deeper and fix it, then add the test cases back in a separate PR.

[chenlica]

@carloea2 Is it related to a recent finding you have related to MockTexeraDB?

[carloea2]

@carloea2 Is it related to a recent finding you have related to MockTexeraDB?

Yes, I suggest he tries to add his new test cases into a test file accessing the same resources (ad-hoc solution) and later investigate what is the reason.