Rethinking project visibility
Description
Now you can enable / disable / make only accessible to project members each feature of GitLab projects, setting a project to either public, private or internal is not covering all cases anymore.
By providing more options during project creation and in the settings, we can make it easier to use and understand what the possibilities are.
Alternatively, we can create a new visibility level, which could help avoiding confusion about whether a project is private or public.
Proposal
Several ideas:
1. Maintain current method, provide templates in creation and options
We add several more options, with descriptions when creating or modifying a project.
2. Maintain current method, provide option to change in creation
3. Make public / internal / private alternatives to 'Custom'
A custom visibility level that allows you to set each feature as public / internal / private.
Links / references
Activity
Mentioned in issue #19734 (closed)
Mentioned in issue #22165 (closed)
Dear science please yes. All I ask is that you include the Wiki as part of this feature - being able to make the wiki AND issues public while the project is private would be a very big deal.
Just thought I'd note, your competitors have some or all of this feature already implemented:
Bitbucket: "You can set your Bitbucket repository, wiki, and issue tracker as private or public, independently of each other."
Github: "GitHub does not provide issues-only access permissions, but you can accomplish this using a second repository which contains only the issues." Although Github's implementation is clunky and not working well.
I bet A LOT of people are stuck with Bitbucket as a way to have a private repository while allowing their users to submit issues and view a wiki because there's no alternative. If Gitlab could do this... oh man. You'd be ahead of Github in an even bigger way.
Edited by username-removed-713411@regisF If option #2 (closed) is correctly documented, then it doesn't allow the option to change after creation. This feature needs to be available at all times to the user to switch on and off as needed.
@rahlzel well, the body of the issue clearly says
project creation and in the settings, so you'd be able to change settings after creation too (wouldn't make sense otherwise).Good.
Then on another note about #2 (closed), the image is confusing to me.
What are the Public, Internal, and Private bubbles at the top for if they're not used in the Fine-Grained Access below?
Why not just simplify it:
Or simply add the above options to the current dropdown menu:
@rahlzel @vbezruchkin just making sure we're on the same page.
All I ask is that you include the Wiki as part of this feature - being able to make the wiki AND issues public while the project is private would be a very big deal.
This is already supported. This issue is about improving the UX, because the current design clearly confuses people.
What are the Public, Internal, and Private bubbles at the top for if they're not used in the Fine-Grained Access below?
The "Everyone with access" option inherits the permissions from the public, internal, private settings.
@axil I guess not.
This is already supported. This issue is about improving the UX, because the current design clearly confuses people.
No, at the moment it's impossible to configure the project as described. You cannot make the project code private and enable your visitors/registered members to view WIKI pages & Issues. So it's not about design changes only.
Probably I somehow missed the way to configure this, if so - please advise.The idea is as follows:
- Developers group should only have access to repository code
- The project should be public, so guests/registered members could have access to wiki, snippets, issues
- Guests/registered members MUST not have access to the repository/builds features, any code related logs should be hidden/disabled for them
Please advise. Thanks in advance.
-
Just a minor addition... If you make the project public, it works as expected except one thing - it still allows to clone public projects by a direct repo url, which does not sound secure.
Yeah, this is what I did so you're right. This seems like a bug as described by @elishahastings above.Edited by Achilleas Pipinellis -
Ok I tested this again and it's possible to have the functionality you want. Not sure how you managed get the project to be cloned. Can you try with my test project https://gitlab.com/axil/test-visibility?
These are the settings I used.
Hmm, that works. Must've been fixed since I last tested. Thanks @axil
Yes, seems to be working fine for me as well.
Please check similar request:
https://gitlab.com/gitlab-org/gitlab-ce/issues/22165I used to have the same configuration and I was able to clone without any auth :) That was the case. Now it seems to be fine
Thanks
@axil It looks good. Is container registry always public?
-
@djanosik yeah, seems like container registry follows the visibility level. I guess it could also be configurable. Maybe open a new issue?
mentioned in issue #25285 (closed)
I'm voting for option #2 (closed).
#1 (closed): Using templates would be aggravating since you'd need a huge drop-down menu with every conceivable combination of options.
#3 (closed): I have no idea what this means, and it just sounds like #2 (closed). An "alternative to Custom"? There's nothing in the project settings called "custom".
Edited by username-removed-713411This is the only issue my team is waiting on before we switch our project from Github to Gitlab.
Even if it's currently "working", the act of setting our private project to "Public" in order to make it work so that we have a private repository and a public issue tracker is not something we're comfortable doing, especially when not too long ago anyone was able to clone a public repo simply using the URL.
Thank you for the work done on this. We look forward to joining up with Gitlab when this is closed.
Edited by username-removed-713411
I would like to offer some additional input on this.
I got super confused when doing the following:
I asked a colleague to push something to a project I had recently created. The project visibility was set to Internal, and all other drop-downs were set to "Everyone with access". Together, we made sure that he could actually see the project. After cloning it and commiting something, when trying to push, he go the info that he doesn't have permission to push. I looked a bit further, and noticed that the branch was protected (duh). I unprotected the branch. He still could not push!
I guess my main source of confusion is that "Everyone with access" means everyone who can see a project - but that doesn't seem to be true.
I can't even figure out right now, without thinking really hard and long, what the intended behaviour / scenario here is.
Is anybody actually on this / planning to do something about this?
Is there still need for discussion?
What can I do to push this further?
The UI looks nicer but it's still confusing.
- "Everyone with access"? Who is that? How does anyone have access if this is where everyone's access is turned off and on?
- The Project visibility's help icon links to this page, https://gitlab.com/help/public_access/public_access, which states that "Public projects can be cloned without any authentication."
- I have a repository that I want to stay private, but I have to set the entire project to "Public" in order to get public Issues and Wiki? That's pretty scary. This is why my team hesitated for months before moving from Github to Gitlab.
- The words "Everyone with access" and "Internal" are confusing to me, and I'm guessing to everyone who isn't part of the Gitlab team. Common vernacular on things like forums would be "Guests" or "Everyone" and "Registered Users", and might make more sense.
In my humble opinion, the permissions page is still in need of a redesign for clarity.
I drew up a mockup that I feel would make this more clear to myself and hopefully most everyone else:
-
I think @rahlzel's mockup is much better than what we currently have
moved to gitlab#6853
Hey!
GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current
gitlab-cerepository will become a read-only mirror, without any proprietary code. All development is moved to the currentgitlab-eerepository, which we will rename to justgitlabin the coming weeks. As part of this migration, issues will be moved to the currentgitlab-eeproject.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/13855You 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/13855What 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 theee/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/13304Will 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.
