Repository navigation
feat(gui): allow changing workflow access level - #4161
Merged
Xiao-zhen-Liu merged 4 commits intoJan 21, 2026
Merged
Xiao-zhen-Liu merged 4 commits into
Xiao-zhen-Liu merged 4 commits into
Conversation
Contributor
Author
|
@Xiao-zhen-Liu Can you review this PR please? |
Contributor
|
@seongjinyoon Thanks. Is it possible to add test cases? |
Xiao-zhen-Liu
requested changes
Jan 16, 2026
Xiao-zhen-Liu
left a comment
Contributor
There was a problem hiding this comment.
Left some comments. Please also add some unit tests.
Contributor
Author
I will add test cases after solving the issue regarding MockTexeraDB. |
Contributor
Author
|
@Xiao-zhen-Liu I have addressed your comments. |
Xiao-zhen-Liu
approved these changes
Jan 21, 2026
Xiao-zhen-Liu
left a comment
Contributor
There was a problem hiding this comment.
LGTM. You can add some test cases as a separate PR.
madisonmlin
pushed a commit
to madisonmlin/texera
that referenced
this pull request
Mar 10, 2026
<!-- Thanks for sending a pull request (PR)! Here are some tips for you: 1. If this is your first time, please read our contributor guidelines: [Contributing to Texera](https://github.com/apache/texera/blob/main/CONTRIBUTING.md) 2. Ensure you have added or run the appropriate tests for your PR 3. If the PR is work in progress, mark it a draft on GitHub. 4. Please write your PR title to summarize what this PR proposes, we are following Conventional Commits style for PR titles as well. 5. Be sure to keep the PR description updated to reflect all changes. --> ### What changes were proposed in this PR? <!-- Please clarify what changes you are proposing. The purpose of this section is to outline the changes. Here are some tips for you: 1. If you propose a new API, clarify the use case for a new API. 2. If you fix a bug, you can clarify why it is a bug. 3. If it is a refactoring, clarify what has been changed. 3. It would be helpful to include a before-and-after comparison using screenshots or GIFs. 4. Please consider writing useful notes for better and faster reviews. --> Previously, when a user was given access to a workflow, the access level (READ/WRITE) could not be changed directly. Users had to revoke access and re-add with the new level. This PR adds the ability for users with write access to change the access level of other users via a dropdown. **Frontend (`share-access.component.ts` / `share-access.component.html`):** - Added `hasWriteAccess` that checks write access. - Added `changeAccessLevel()` method with confirmation warning when a user downgrades their own access from WRITE to READ. - Dropdown disabled for users without write access. **Backend (`WorkflowAccessResource.scala`):** - Modified `grantAccess` endpoint to allow users with WRITE access to modify their own access level **Behavior:** - Users with WRITE access can change other users' access levels via dropdown - Users with WRITE access can downgrade their own access to READ - Owner's access cannot be changed **Demo:** https://github.com/user-attachments/assets/cca50be0-b086-47c1-b4ae-2f10a60b51e9 ### Any related issues, documentation, discussions? <!-- Please use this section to link other resources if not mentioned already. 1. If this PR fixes an issue, please include `Fixes apache#1234`, `Resolves apache#1234` or `Closes apache#1234`. If it is only related, simply mention the issue number. 2. If there is design documentation, please add the link. 3. If there is a discussion in the mailing list, please add the link. --> No ### How was this PR tested? <!-- If tests were added, say they were added here. Or simply mention that if the PR is tested with existing test cases. Make sure to include/update test cases that check the changes thoroughly including negative and positive cases if possible. If it was tested in a way different from regular unit tests, please clarify how you tested step by step, ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future. If tests were not added, please describe why they were not added and/or why it was difficult to add. --> Manually tested. ### Was this PR authored or co-authored using generative AI tooling? <!-- If generative AI tooling has been used in the process of authoring this PR, please include the phrase: 'Generated-by: ' followed by the name of the tool and its version. If no, write 'No'. Please refer to the [ASF Generative Tooling Guidance](https://www.apache.org/legal/generative-tooling.html) for details. --> Revised with Claude Code. --------- Co-authored-by: Xiaozhen Liu <[email protected]>
SarahAsad23
pushed a commit
to madisonmlin/texera
that referenced
this pull request
May 20, 2026
<!-- Thanks for sending a pull request (PR)! Here are some tips for you: 1. If this is your first time, please read our contributor guidelines: [Contributing to Texera](https://github.com/apache/texera/blob/main/CONTRIBUTING.md) 2. Ensure you have added or run the appropriate tests for your PR 3. If the PR is work in progress, mark it a draft on GitHub. 4. Please write your PR title to summarize what this PR proposes, we are following Conventional Commits style for PR titles as well. 5. Be sure to keep the PR description updated to reflect all changes. --> ### What changes were proposed in this PR? <!-- Please clarify what changes you are proposing. The purpose of this section is to outline the changes. Here are some tips for you: 1. If you propose a new API, clarify the use case for a new API. 2. If you fix a bug, you can clarify why it is a bug. 3. If it is a refactoring, clarify what has been changed. 3. It would be helpful to include a before-and-after comparison using screenshots or GIFs. 4. Please consider writing useful notes for better and faster reviews. --> Previously, when a user was given access to a workflow, the access level (READ/WRITE) could not be changed directly. Users had to revoke access and re-add with the new level. This PR adds the ability for users with write access to change the access level of other users via a dropdown. **Frontend (`share-access.component.ts` / `share-access.component.html`):** - Added `hasWriteAccess` that checks write access. - Added `changeAccessLevel()` method with confirmation warning when a user downgrades their own access from WRITE to READ. - Dropdown disabled for users without write access. **Backend (`WorkflowAccessResource.scala`):** - Modified `grantAccess` endpoint to allow users with WRITE access to modify their own access level **Behavior:** - Users with WRITE access can change other users' access levels via dropdown - Users with WRITE access can downgrade their own access to READ - Owner's access cannot be changed **Demo:** https://github.com/user-attachments/assets/cca50be0-b086-47c1-b4ae-2f10a60b51e9 ### Any related issues, documentation, discussions? <!-- Please use this section to link other resources if not mentioned already. 1. If this PR fixes an issue, please include `Fixes apache#1234`, `Resolves apache#1234` or `Closes apache#1234`. If it is only related, simply mention the issue number. 2. If there is design documentation, please add the link. 3. If there is a discussion in the mailing list, please add the link. --> No ### How was this PR tested? <!-- If tests were added, say they were added here. Or simply mention that if the PR is tested with existing test cases. Make sure to include/update test cases that check the changes thoroughly including negative and positive cases if possible. If it was tested in a way different from regular unit tests, please clarify how you tested step by step, ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future. If tests were not added, please describe why they were not added and/or why it was difficult to add. --> Manually tested. ### Was this PR authored or co-authored using generative AI tooling? <!-- If generative AI tooling has been used in the process of authoring this PR, please include the phrase: 'Generated-by: ' followed by the name of the tool and its version. If no, write 'No'. Please refer to the [ASF Generative Tooling Guidance](https://www.apache.org/legal/generative-tooling.html) for details. --> Revised with Claude Code. --------- Co-authored-by: Xiaozhen Liu <[email protected]>
yangzhang75
pushed a commit
to yangzhang75/texera
that referenced
this pull request
Jun 22, 2026
<!-- Thanks for sending a pull request (PR)! Here are some tips for you: 1. If this is your first time, please read our contributor guidelines: [Contributing to Texera](https://github.com/apache/texera/blob/main/CONTRIBUTING.md) 2. Ensure you have added or run the appropriate tests for your PR 3. If the PR is work in progress, mark it a draft on GitHub. 4. Please write your PR title to summarize what this PR proposes, we are following Conventional Commits style for PR titles as well. 5. Be sure to keep the PR description updated to reflect all changes. --> ### What changes were proposed in this PR? <!-- Please clarify what changes you are proposing. The purpose of this section is to outline the changes. Here are some tips for you: 1. If you propose a new API, clarify the use case for a new API. 2. If you fix a bug, you can clarify why it is a bug. 3. If it is a refactoring, clarify what has been changed. 3. It would be helpful to include a before-and-after comparison using screenshots or GIFs. 4. Please consider writing useful notes for better and faster reviews. --> Previously, when a user was given access to a workflow, the access level (READ/WRITE) could not be changed directly. Users had to revoke access and re-add with the new level. This PR adds the ability for users with write access to change the access level of other users via a dropdown. **Frontend (`share-access.component.ts` / `share-access.component.html`):** - Added `hasWriteAccess` that checks write access. - Added `changeAccessLevel()` method with confirmation warning when a user downgrades their own access from WRITE to READ. - Dropdown disabled for users without write access. **Backend (`WorkflowAccessResource.scala`):** - Modified `grantAccess` endpoint to allow users with WRITE access to modify their own access level **Behavior:** - Users with WRITE access can change other users' access levels via dropdown - Users with WRITE access can downgrade their own access to READ - Owner's access cannot be changed **Demo:** https://github.com/user-attachments/assets/cca50be0-b086-47c1-b4ae-2f10a60b51e9 ### Any related issues, documentation, discussions? <!-- Please use this section to link other resources if not mentioned already. 1. If this PR fixes an issue, please include `Fixes apache#1234`, `Resolves apache#1234` or `Closes apache#1234`. If it is only related, simply mention the issue number. 2. If there is design documentation, please add the link. 3. If there is a discussion in the mailing list, please add the link. --> No ### How was this PR tested? <!-- If tests were added, say they were added here. Or simply mention that if the PR is tested with existing test cases. Make sure to include/update test cases that check the changes thoroughly including negative and positive cases if possible. If it was tested in a way different from regular unit tests, please clarify how you tested step by step, ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future. If tests were not added, please describe why they were not added and/or why it was difficult to add. --> Manually tested. ### Was this PR authored or co-authored using generative AI tooling? <!-- If generative AI tooling has been used in the process of authoring this PR, please include the phrase: 'Generated-by: ' followed by the name of the tool and its version. If no, write 'No'. Please refer to the [ASF Generative Tooling Guidance](https://www.apache.org/legal/generative-tooling.html) for details. --> Revised with Claude Code. --------- Co-authored-by: Xiaozhen Liu <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this PR?
Previously, when a user was given access to a workflow, the access level (READ/WRITE) could not be changed directly. Users had to revoke access and re-add with the new level. This PR adds the ability for users with write access to change the access level of other users via a dropdown.
Frontend (
share-access.component.ts/share-access.component.html):hasWriteAccessthat checks write access.changeAccessLevel()method with confirmation warning when a user downgrades their own access from WRITE to READ.Backend (
WorkflowAccessResource.scala):grantAccessendpoint to allow users with WRITE access to modify their own access levelBehavior:
Demo:
Screen.Recording.2026-01-14.at.3.51.53.PM.mov
Any related issues, documentation, discussions?
No
How was this PR tested?
Manually tested.
Was this PR authored or co-authored using generative AI tooling?
Revised with Claude Code.