Internally public projects
Created by: slottermoser
Public projects listed in the public section will be linked to the actual project's page. Public projects now give any user Guest permissions to the project, allowing them to download the code, read and create issues, and view anything else in the project's pages.
Ample access tests have been added to the project_access_spec to verify correct permissions and behavior on public projects.
- Visitors to the site who are not logged in still cannot view the project's pages.
- Logged-in users visiting a public project where they are not a team member can create issues, but not snippets. They can view the projects code, issues, merge requests, etc, just as if they were a Guest member of the project.
- Since this is a public project, the user is also granted :download_code permissions, a permission normally reserved for Reporters, since they can clone the repo anyways and browse commits and branches locally.
This pull request is related to http://feedback.gitlab.com/forums/176466-general/suggestions/3159951-allow-public-repositories and http://feedback.gitlab.com/forums/176466-general/suggestions/3776706-allow-internal-open-public-repositories
Public Area with project names as links:
Merge request reports
Activity
Created by: slottermoser
I started some spinach tests for the public area, hoping to add a test to verify project names are turned into links, and that a user clicking the link will be led to the project's activity feed, even though they aren't on the project's team. However, I'm new to spinach and didn't get that finished yet. If that's a requirement to getting this merged and/or if someone would love to help me out with that, let's make the spinach test more robust!
By Administrator on 2013-05-02T07:26:22 (imported from GitLab project)
By Administrator on 2013-05-02T07:26:22 (imported from GitLab)
Created by: slottermoser
Hmmm, something went wrong with the tests. I'm investigating. I should have checked the tests on master before submitting this PR; this work was done on the 5-1 stable branch and tests pass just fine in the vagrant dev vm.
By Administrator on 2013-05-02T07:47:37 (imported from GitLab project)
By Administrator on 2013-05-02T07:47:37 (imported from GitLab)
9 9 %li.clearfix 10 10 %h5 11 11 %i.icon-share 12 = project.name_with_namespace 12 - if current_user 9 9 %li.clearfix 10 10 %h5 11 11 %i.icon-share 12 = project.name_with_namespace 12 - if current_user 9 9 %li.clearfix 10 10 %h5 11 11 %i.icon-share 12 = project.name_with_namespace 12 - if current_user Created by: slottermoser
That's correct. This PR only enables the browsing of public repos for users who are logged in. If the user is not logged in, they will need to do so first before they can view the public project's pages, file issues, etc. It would be optimal if a non-logged in user redirected to the login page who then signed in was redirected back to the public project page they were trying to view. Do you think that needs to be included, or is this patch good enough as it stands?
By Administrator on 2013-05-02T20:32:45 (imported from GitLab project)
By Administrator on 2013-05-02T20:32:45 (imported from GitLab)
9 9 %li.clearfix 10 10 %h5 11 11 %i.icon-share 12 = project.name_with_namespace 12 - if current_user 9 9 %li.clearfix 10 10 %h5 11 11 %i.icon-share 12 = project.name_with_namespace 12 - if current_user Created by: mjdetullio
Just a note, the name of this feature/pull request is a little misleading because the internally public feature is inclusive to the existing public project feature. I.E. it is not possible to have just an internally public project, internally public projects are still open for HTTP clone to anonymous users.
I haven't gotten around to sharing it, but my implementation makes projects internally public (by granting all logged in users Reporter access, listing the projects with the others, showing their feeds, etc. but not adding to projec team), without making it clone-able by anonymous users. I think that is closer to the requested feature on the feedback website. Take James' comment for example:
On-premise behind a firewall is not the same thing as allowing authenticated users to view all repositories. Contractors and other third parties sometimes need to be on-premise and connected to the same network the GitLab server is on. Allowing them unrestricted access to repositories in GitLab would be less than ideal.
By Administrator on 2013-05-07T01:25:38 (imported from GitLab project)
By Administrator on 2013-05-07T01:25:38 (imported from GitLab)
Created by: brodock
@mjdetullio is right. Althought what have been merged here is useful, it isn't the same thing asked by the community.
By Administrator on 2013-05-07T12:03:41 (imported from GitLab project)
By Administrator on 2013-05-07T12:03:41 (imported from GitLab)
Created by: slottermoser
Yeah, the decision by the GitLab team to make public projects allow anonymous access existed long before this PR, and changing that behavior was beyond the scope of this. A better name would have been helpful, but I couldn't think of one at the time. Maybe "Internally public project pages." Ideally, only authenticated users would be able to clone the public repos too. I would love to see a pull request about that @mjdetullio.
By Administrator on 2013-05-07T21:29:24 (imported from GitLab project)
By Administrator on 2013-05-07T21:29:24 (imported from GitLab)
Created by: slottermoser
All you'd really need to do is remove any project.public checks in /lib/gitlab/backend/grack_auth.rb so that people downloading code have to be users registered with your gitlab instance in order to download code, even if the project is marked public. You'd also want to modify the text in the public area and projects settings pages to reflect this change in behavior @mjdetullio and @brodock.
By Administrator on 2013-05-11T20:37:56 (imported from GitLab project)
By Administrator on 2013-05-11T20:37:56 (imported from GitLab)
Created by: mjdetullio
@holdtotherod @brodock @randx I cherry-picked out my custom commit and applied it to a fresh 5-1-stable branch. I'm using these exact changes in a production environment and it's working very nicely.
You can find it here: https://github.com/mjdetullio/gitlabhq/commit/ade50b9a9044bba27eff18cb40f4102f872ff518
Note: requires adding a column to the projects table:
ALTER TABLE projects ADD COLUMN internal bool DEFAULT 0 NOT NULL AFTER public;However, I will not be submitting a pull request for a few reasons:
- No tests
- I'm not a Ruby dev
- I simply can't make time to write them (this customization was for
${DAYJOB}) - I'm perfectly fine with functionally testing my customizations
- I made the modifications solely for the instance I administrate, so I feel perhaps if I had written it for the community it would be slightly different
- I do not know the exact specifications the team wants for this feature to be included into core
By Administrator on 2013-05-13T19:17:13 (imported from GitLab project)
By Administrator on 2013-05-13T19:17:13 (imported from GitLab)
- No tests
Created by: axilleas
Logged-in users visiting a public project where they are not a team member can create issues, but not snippets. They can view the projects code, issues, merge requests, etc, just as if they were a Guest member of the project.
Logged in users cannot see the Files tab. Is this a bug? See #4152 (closed)
By Administrator on 2013-06-02T09:17:51 (imported from GitLab project)
By Administrator on 2013-06-02T09:17:51 (imported from GitLab)
Created by: tfernandez
I agree with @mjdetullio
It is being very hard to understand what are you doing with public/internal/non-public-but-public options. I see the next suggestion completed/closed:
However it has not been actually solved, and I think it is causing some missunderstanding. Also seems that this PR has been a first step to get fully public projects, but the two options are usefull, anounymously public, and logger-in public.
Would be great have a real internal public project option. In a organization the gitlab instance could not be firewalled, the organization could have external employees (ok they can use a VPN), but also external contributors that are not in the "intranet" and however they have a gitlab user.
And of course if the project is internally public, the organization doesn't want offer anonymous access to his repositories! :). Both project pages and the repository should be hidden and restricted for anonymous access
Could I ask what is the status of this matter?
Thanks
By Administrator on 2013-10-18T10:18:33 (imported from GitLab project)
By Administrator on 2013-10-18T10:18:33 (imported from GitLab)
