-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
External user permissions #4334
Comments
* Add User.IsRestricted * Add "Restricted" column to admin/users * Add "Is Restricted" checkbox to admin/users/ID
* Change access.accessLevel to accept a *User instead of a user ID * Ditto for AccessLevel, hasAccess and HasAccess * When user is restricted, don't allow read to public repos * Update all callers to pass a *User object
Such a feature would be very useful to any organization using gitea internally with the need to give customers access to their projects. I propose introducing a new user flag called "IsRestricted", presented as another checkbox in the user admin pages. A restricted user's view would be limited to:
To put it another way, a restricted user would simply not see or be able to access anything public. |
* Add User.IsRestricted * Add "Restricted" column to admin/users * Add "Is Restricted" checkbox to admin/users/ID
* Change access.accessLevel to accept a *User instead of a user ID * Ditto for AccessLevel, hasAccess and HasAccess * When user is restricted, don't allow read to public repos * Update all callers to pass a *User object
* Add User.IsRestricted * Add "Restricted" column to admin/users * Add "Is Restricted" checkbox to admin/users/ID
* Change access.accessLevel to accept a *User instead of a user ID * Ditto for AccessLevel, hasAccess and HasAccess * When user is restricted, don't allow read to public repos * Update all callers to pass a *User object
* Add User.IsRestricted * Add "Restricted" column to admin/users * Add "Is Restricted" checkbox to admin/users/ID
* Change access.accessLevel to accept a *User instead of a user ID * Ditto for AccessLevel, hasAccess and HasAccess * When user is restricted, don't allow read to public repos * Update all callers to pass a *User object
* Add User.IsRestricted & UI to edit it * Pass user object instead of user id to places where IsRestricted flag matters * Restricted users: maintain access rows for all referenced repos (incl public) * Take logged in user & IsRestricted flag into account in org/repo listings, searches and accesses * Add basic repo access tests for restricted users Signed-off-by: Manush Dodunekov <manush@stendahls.se>
* Add User.IsRestricted & UI to edit it * Pass user object instead of user id to places where IsRestricted flag matters * Restricted users: maintain access rows for all referenced repos (incl public) * Take logged in user & IsRestricted flag into account in org/repo listings, searches and accesses * Add basic repo access tests for restricted users Signed-off-by: Manush Dodunekov <manush@stendahls.se>
* Restricted users (#4334): initial implementation * Add User.IsRestricted & UI to edit it * Pass user object instead of user id to places where IsRestricted flag matters * Restricted users: maintain access rows for all referenced repos (incl public) * Take logged in user & IsRestricted flag into account in org/repo listings, searches and accesses * Add basic repo access tests for restricted users Signed-off-by: Manush Dodunekov <manush@stendahls.se> * Mention restricted users in the faq Signed-off-by: Manush Dodunekov <manush@stendahls.se> * Revert unnecessary change `.isUserPartOfOrg` -> `.IsUserPartOfOrg` Signed-off-by: Manush Dodunekov <manush@stendahls.se> * Remove unnecessary `org.IsOrganization()` call Signed-off-by: Manush Dodunekov <manush@stendahls.se> * Revert to an `int64` keyed `accessMap` * Add type `userAccess` * Add convenience func updateUserAccess() * Turn accessMap into a `map[int64]userAccess` Signed-off-by: Manush Dodunekov <manush@stendahls.se> * or even better: `map[int64]*userAccess` * updateUserAccess(): use tighter syntax as suggested by lafriks * even tighter * Avoid extra loop * Don't disclose limited orgs to unauthenticated users * Don't assume block only applies to orgs * Use an array of `VisibleType` for filtering * fix yet another thinko * Ok - no need for u * Revert "Ok - no need for u" This reverts commit 5c3e886. Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com> Co-authored-by: Lauris BH <lauris@nix.lv>
This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions. |
How close is this to be done? |
It is done (#6274) |
GitLab provides a special type of local users called "external users". The current version of GitLab's documentation descibes this role as follows:
This type of user is particulary useful when the Gitea instance is private and a guest/external user should access only specific repositories while the rest is hidden. Currently (as of version 1.4.3) local users can see other repositories when they use the "Explore" functionality even if they are not part of any organization or added as collaborator to these repositories.
Remaining tasks:
The text was updated successfully, but these errors were encountered: