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

Internally public projects #3801

Merged
merged 3 commits into from May 3, 2013

Conversation

8 participants
@slottermoser
Contributor

slottermoser commented May 2, 2013

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:
screen shot 2013-05-02 at 12 17 37 am

Internally public projects
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.
@slottermoser

This comment has been minimized.

Show comment
Hide comment
@slottermoser

slottermoser May 2, 2013

Contributor

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!

Contributor

slottermoser commented May 2, 2013

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!

@slottermoser

This comment has been minimized.

Show comment
Hide comment
@slottermoser

slottermoser May 2, 2013

Contributor

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.

Contributor

slottermoser commented May 2, 2013

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.

@slottermoser

This comment has been minimized.

Show comment
Hide comment
@slottermoser

slottermoser May 2, 2013

Contributor

and by 5-1 I meant 5-0-stable branch. I'm behind on the times.

Contributor

slottermoser commented May 2, 2013

and by 5-1 I meant 5-0-stable branch. I'm behind on the times.

@coveralls

This comment has been minimized.

Show comment
Hide comment
@coveralls

coveralls May 2, 2013

Coverage Status

Coverage remained the same when pulling 4c44c5e on holdtotherod:feature/internally-public-projects into 4f5aae1 on gitlabhq:master.

coveralls commented May 2, 2013

Coverage Status

Coverage remained the same when pulling 4c44c5e on holdtotherod:feature/internally-public-projects into 4f5aae1 on gitlabhq:master.

@ghost ghost assigned dzaporozhets May 2, 2013

@coveralls

This comment has been minimized.

Show comment
Hide comment
@coveralls

coveralls May 2, 2013

Coverage Status

Coverage remained the same when pulling a7ba81e on holdtotherod:feature/internally-public-projects into 4f5aae1 on gitlabhq:master.

coveralls commented May 2, 2013

Coverage Status

Coverage remained the same when pulling a7ba81e on holdtotherod:feature/internally-public-projects into 4f5aae1 on gitlabhq:master.

@amacarthur

This comment has been minimized.

Show comment
Hide comment
@amacarthur

amacarthur May 2, 2013

Contributor

+1

This looks like this would suit our needs.

Contributor

amacarthur commented May 2, 2013

+1

This looks like this would suit our needs.

Non-logged in users see public project names as static text
In the public area, project names are shown as static text for
non-logged in users, while logged-in users are given project
names as links they can follow to the project's page.
@coveralls

This comment has been minimized.

Show comment
Hide comment
@coveralls

coveralls May 2, 2013

Coverage Status

Coverage increased (+12.59%) when pulling 8589f0f on holdtotherod:feature/internally-public-projects into 4f5aae1 on gitlabhq:master.

coveralls commented May 2, 2013

Coverage Status

Coverage increased (+12.59%) when pulling 8589f0f on holdtotherod:feature/internally-public-projects into 4f5aae1 on gitlabhq:master.

@dzaporozhets

This comment has been minimized.

Show comment
Hide comment
@dzaporozhets

dzaporozhets May 3, 2013

Member

ok thank you.
Seems like everything else is fine. Lets merge this one

Member

dzaporozhets commented May 3, 2013

ok thank you.
Seems like everything else is fine. Lets merge this one

dzaporozhets added a commit that referenced this pull request May 3, 2013

@dzaporozhets dzaporozhets merged commit 2fc2361 into gitlabhq:master May 3, 2013

1 check passed

default The Travis build passed
Details
@slottermoser

This comment has been minimized.

Show comment
Hide comment
@slottermoser

slottermoser May 3, 2013

Contributor

Thanks @randx! Excited to see this merged :D

Contributor

slottermoser commented May 3, 2013

Thanks @randx! Excited to see this merged :D

@slottermoser slottermoser deleted the slottermoser:feature/internally-public-projects branch May 3, 2013

@mjdetullio

This comment has been minimized.

Show comment
Hide comment
@mjdetullio

mjdetullio May 7, 2013

Contributor

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.

Contributor

mjdetullio commented May 7, 2013

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.

@brodock

This comment has been minimized.

Show comment
Hide comment
@brodock

brodock May 7, 2013

Member

@mjdetullio is right. Althought what have been merged here is useful, it isn't the same thing asked by the community.

Member

brodock commented May 7, 2013

@mjdetullio is right. Althought what have been merged here is useful, it isn't the same thing asked by the community.

@slottermoser

This comment has been minimized.

Show comment
Hide comment
@slottermoser

slottermoser May 7, 2013

Contributor

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.

Contributor

slottermoser commented May 7, 2013

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.

@slottermoser

This comment has been minimized.

Show comment
Hide comment
@slottermoser

slottermoser May 11, 2013

Contributor

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.

Contributor

slottermoser commented May 11, 2013

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.

@mjdetullio

This comment has been minimized.

Show comment
Hide comment
@mjdetullio

mjdetullio May 13, 2013

Contributor

@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:

  1. 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
  2. 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
  3. I do not know the exact specifications the team wants for this feature to be included into core
Contributor

mjdetullio commented May 13, 2013

@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:

  1. 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
  2. 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
  3. I do not know the exact specifications the team wants for this feature to be included into core
@axilleas

This comment has been minimized.

Show comment
Hide comment
@axilleas

axilleas Jun 2, 2013

Member

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

Member

axilleas commented Jun 2, 2013

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

@slottermoser

This comment has been minimized.

Show comment
Hide comment
@slottermoser

slottermoser Jun 2, 2013

Contributor

Logged in users should definitely be able to see the Files tab. I will verify in a bit.

Contributor

slottermoser commented Jun 2, 2013

Logged in users should definitely be able to see the Files tab. I will verify in a bit.

@axilleas

This comment has been minimized.

Show comment
Hide comment
@axilleas

axilleas Jun 2, 2013

Member

This is what I see

gitlab 2013-06-02 12-34-45

Member

axilleas commented Jun 2, 2013

This is what I see

gitlab 2013-06-02 12-34-45

@slottermoser

This comment has been minimized.

Show comment
Hide comment
@slottermoser

slottermoser Jun 7, 2013

Contributor

@randx fixed the problem @axilleas saw in 3cce570. Thanks @randx!

Contributor

slottermoser commented Jun 7, 2013

@randx fixed the problem @axilleas saw in 3cce570. Thanks @randx!

@tfernandez

This comment has been minimized.

Show comment
Hide comment
@tfernandez

tfernandez Oct 18, 2013

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:

http://feedback.gitlab.com/forums/176466-general/suggestions/3776706-allow-internal-open-public-repositories

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

tfernandez commented Oct 18, 2013

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:

http://feedback.gitlab.com/forums/176466-general/suggestions/3776706-allow-internal-open-public-repositories

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment