Set permissions (e.g for ticket triaging & wiki editing) for any user/anonymous

It would be great if there were an option to allow any user (and probably even anonymous users) to edit/triage tickets (ie assign labels) and maybe edit wiki pages. This can be useful for opensource projects which rely on every user out there to verify tickets (vandalism is often not that bad). The nearest existing permission here is "Reporter", but that one misses wiki permissions and in general you do not even want to assign those permissions to the users (or is there a default group I can put users on signup?). Also those people should not be able to see confidential issues, that would require a higher level of access…

There are two very similar issues: #12736 (closed) and #19397 (moved)

cc @connorshea

Added ~14213 ~430133 labels

@winniehell #12736 (closed) isn't the same thing because custom roles require assigning the role to each and every user.

As for #19397 (moved), that's only one part of this issue.

@connorshea That depends on the implementation of #12736 (closed)—if it would also allow to set the permissions for people outside a project, this issue would be solved.

@winniehell I don't want to make #12736 (closed) solve all the problems ever, though :)

I don't want to make #12736 (closed) solve all the problems ever, though :)

@connorshea Why not?

Then let's make this one the default-permissions-for-non-member-access-issue, ok?

Okay :D

Changed title: Allow ticket triaging & wiki editing for any user/anonymous → Set permissions (e.g for ticket triaging & wiki editing) for any user/anonymous

mentioned in issue #20620 (moved)

Added ~19492 ~502086 labels

Yes please!

I'd like to give access to the Wiki to many more people in my company than just Developers and I certainly don't want to give the kind of access Developer roles gets to everyone in the company

I Think this is a much needed feature for our open source Projects in order to easier get more partners and users to engage. Another maybe simpler way could be to just let the Reporter role get access to write the Project wiki, either update existing pages or also be able to create new pages (but not delete pages for example). Could be a setting in the Project "Let Reporters edit wiki pages" and "Let Reporters create pages"

Hi,

First of all, thank you for raising an issue to help improve the GitLab product. This issue was labelled as a ~"feature proposal" in the past. In order to maintain order in the issue tracker, we are starting to close off old, unpopular feature proposals that have not gained many votes since opening.

This issue will be marked for closure, as it meets the following criteria:

• Created over 1 year ago
• Labelled as a ~"feature proposal"
• Unscheduled (not associated with a milestone)
• Less than 10 upvotes

Thanks for your help and please raise any new feature proposals as a new issue.

/cc @markglenfletcher

added auto updated awaiting feedback labels

We are reverting the above policy regarding old, feature proposals until we find a better solution. Sorry for the noise.

The issue will no longer be marked for closure.

removed auto updated awaiting feedback labels

This one is quite interesting for GNOME, surprisingly we have exactly the same need, ticket triaging + wiki to be done by other people than developers (bug squad & writers respectively).

We have been trying to find a way to accommodate this, but we haven't found a way yet, so we are most likely going to disable the wikies to avoid requests for developer accounts for editing the wiki.

A new permission role, a way to give wiki + triaging permissions independently of the role, or any other solution would probably be equally good.

mentioned in issue #43566 (moved)

mentioned in issue #44188 (moved)

marked this issue as related to ux-research#62 (closed)

mentioned in issue ux-research#62 (closed)

added auto updated potential proposal labels

added Manage [DEPRECATED] label

I find it quite ironic that Wikis cannot be edited by users without extensive project permissions.

After all, the main concept of a wiki is that everyone can contribute. With the current permission model, you can't have a collaborative wiki without giving read and write access to your full source code

added devopsmanage label

added [deprecated] Accepting merge requests label

added groupauthentication and authorization [DEPRECATED] label

removed [deprecated] Accepting merge requests label

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue