Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only admin should have right to edit any comment #17585

Closed
camlafit opened this issue Nov 8, 2021 · 19 comments · Fixed by #17811
Closed

Only admin should have right to edit any comment #17585

camlafit opened this issue Nov 8, 2021 · 19 comments · Fixed by #17811

Comments

@camlafit
Copy link
Contributor

camlafit commented Nov 8, 2021

Gitea Version

1.14.1

edited by team members to hide irrelevant information

Description

On organization we have create a team with write permission on repository. Any user in this team can edit any issue comment .

Edition should be move to "administrator access" to prevent any security issue

Capture d’écran de 2021-11-08 10-10-17

Capture d’écran de 2021-11-08 10-09-10

@wxiaoguang
Copy link
Contributor

wxiaoguang commented Nov 8, 2021

Is the behavior the same as GitHub? For example, as a team member, I can edit your comment (I added **edited by team members to hide irrelevant information**)

image

@JLuc
Copy link

JLuc commented Nov 8, 2021

I dont see your **edited by team members to hide irrelevant information** edit anywhere except in your own post. Did you mean you edited #17585 (comment) ? There is no such edit in cam's post.

I have edited your original post, including this one -- by wxiaoguang

@wxiaoguang
Copy link
Contributor

image

@JLuc
Copy link

JLuc commented Nov 8, 2021

yep. Well i can't do the same.

@lunny
Copy link
Member

lunny commented Nov 9, 2021

On a team, if you remove the write permission to issue/pullrequest unit, the team members will not have the permission to edit the comments.

@camlafit
Copy link
Contributor Author

camlafit commented Nov 9, 2021

Hello

Indeed if we disable issues/Pull request right we lost comment edit option. But we lost also some other behavior as manage tag, milestone, ....

If user as write permission looks logic to also edit tag, milestone to qualify code contribution. But edit comment from other contributors looks a bit different.

Should be better to move this behavior "edit comment" if use has admin permission.

@zeripath
Copy link
Contributor

zeripath commented Nov 9, 2021

As a non-admin but maintainer of this project - I frequently use my comment editing power to fix up rendering problems in other people's comments, rename issues and pulls, and to make the pull request initial comments closer to what was pulled.

It may seem like putting words into other people's mouths but I think this kind of editing functionality is important. The comments on an issue or PR are not an audit of what was said - they're a form of documentation.

@camlafit
Copy link
Contributor Author

camlafit commented Nov 9, 2021

Hello

Yes I see this use case. In our use case we have a different logic. We want allow default contribution on some organization and we allow write permission.
But editing comment looks a bit too important, with as you said " putting words into other people's mouths" and we want preserve this.

Looks possible in this case to propose a sub option to allow/restrict message edition ? Then we will manage these two use case ?

@lunny
Copy link
Member

lunny commented Nov 9, 2021

Issue unit permission is not the same as Code. With read permission of unit Issue/PullRequest, team members could post issue and post comment but cannot edit comment. With write permission of unit Issue/PullRequest, team members could edit issues/comments. I want to know why you want to give all members of org write permission of unit issue/pullrequest.

@camlafit
Copy link
Contributor Author

camlafit commented Nov 9, 2021

Hello

We have a collaborative forge where peer can approve PR/MR/commit on same repository. Then we have open enable write contribution but we don't want user rewrite collaborator content as issue comment.

For example at https://git.spip.net/spip-contrib-extensions all account are set to contrib team. Then all could contribute as any peer but should not be admin (as in this case edit other comment )

@fnordsh
Copy link

fnordsh commented Nov 11, 2021

One way to mitigate this issue would be an edit history like GitHub has. I would be okay with other people editing my comments if these edits are documented and attributable.
Come to think of it, I want this in any case.

@fnordsh
Copy link

fnordsh commented Nov 11, 2021

@lunny

Issue unit permission is not the same as Code. With read permission of unit Issue/PullRequest, team members could post issue and post comment but cannot edit comment. With write permission of unit Issue/PullRequest, team members could edit issues/comments. I want to know why you want to give all members of org write permission of unit issue/pullrequest.

Could you explain how I can allow a group of people to push code, but only post/read issues?

@fnordsh
Copy link

fnordsh commented Nov 11, 2021

@zeripath

As a non-admin but maintainer of this project - I frequently use my comment editing power to fix up rendering problems in other people's comments, rename issues and pulls, and to make the pull request initial comments closer to what was pulled.

It may seem like putting words into other people's mouths but I think this kind of editing functionality is important. The comments on an issue or PR are not an audit of what was said - they're a form of documentation.

Maybe a moderator role would be the right thing for this use case. (But even if editing is restricted to moderators and admins, I still think there should be an indicator that the comment has been edited, and by whom.)

@lunny
Copy link
Member

lunny commented Nov 11, 2021

It seems one team cannot implement it. You have to have two teams. One team for people who could push code, another for post/read issues.

@fnordsh
Copy link

fnordsh commented Nov 11, 2021

Thank you! For my current use case this is a feasible workaround, although I don't think this would scale well.
TBH, I find Giteas permission model a bit weird - giving a team the same permissions to every repository it is assigned to seems counter-intuitive to me. Maybe I should read up on the reasoning behind this.

@lunny
Copy link
Member

lunny commented Nov 12, 2021

This could be resolved by #16859

@camlafit
Copy link
Contributor Author

Hello

Yes could be optimized by this issue. 👍 But looks as a big job on long time.

Waiting this evolve is it possible to provide any work around ?

@gmingen
Copy link

gmingen commented Nov 19, 2021

@camlafit See @lunny's comment above. It's not pretty, but it does work for me.

@lunny
Copy link
Member

lunny commented Nov 26, 2021

@camlafit @gmingen I sent a PR #17811 and I think it could be merged into v1.16.

@go-gitea go-gitea locked and limited conversation to collaborators Apr 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants