Skip to content

[WIP] Add team option to automatically add new organization repos #8048

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

Closed

Conversation

davidsvantesson
Copy link
Contributor

This PR will add a team setting that allows to automatically add new (or transferred) repositories to a team. It only affects when a new repo is created in organization (including migrated or transferred) by adding the repository to the team's access.

Screenshot

image

Left todo for this PR:

  • Make proper translation strings
  • Update API
  • Create database migration
  • Add tests

@lafriks
Copy link
Member

lafriks commented Sep 1, 2019

imho for this there is better option that team has all org repositories (there is even PR for this already)

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Sep 1, 2019
@guillep2k
Copy link
Member

There might be cases where this is useful, but it doesn't make much sense if your teams are separated by project. In my company, developers that deal with some clients' projects can't see government-related projects and vice-versa, and nevertheless they are all below the same organization (company branch).

@lafriks
Copy link
Member

lafriks commented Sep 1, 2019

But anyway this does not guarantee that no incorrect repository is not added to the team.

@davidsvantesson
Copy link
Contributor Author

@lafriks I had missed that PR (#6791). What I can see that PR has two differences from mine:

  • All repositories are added when setting is activated
  • It is not possible to remove a repository from the team if it has all repositories setting

Drawback with first point, because of how that PR is designed, is if someone add the setting by mistake, it can be a lot of work to restore previous setting (Specially if there is no warning this will happen). Second point can be discussed and probably have both benefits and drawbacks, but it makes sense given the first point.

Anyhow I don't think it makes sense and will be confusing to have both these PRs, so I close this in favor of #6791.

@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants