search

backdrop-ops / backdropcms.org

Issue tracker for the BackdropCMS.org website
https://backdropcms.org
25 stars 21 forks source link

Automate GitHub "Collaborators and Teams" for new projects #605

Open ghost opened 5 years ago

ghost commented 5 years ago

We should use the GitHub API to automatically set (and maybe adjust) permissions on all contrib repositories as follows:

1 ) Teams:

2 ) The original contributor should also have their role adjusted to Admin

Here's a link to a relevant issue: https://github.com/orgs/community/discussions/62373

Original issue:

Point 3: 'Update who gets access' on the After your Application is accepted page says:

Under 'Teams', set the following permissions:

  • Authors with permission to Triage
  • Bug Squad with permission to Write
  • Security with permission to Admin

I was just going through my projects to make sure these were setup correctly, and in a few cases I appear to have locked myself out of the Settings tab by setting 'Authors' to 'Triage'...

The first time it happened I thought I mustn't have been set as a Collaborator, and as a member of the Authors team I now don't have admin access anymore. But then it happened again on one where I'm sure I was listed as a Collaborator.

So here are some questions:

  1. What settings should be used so the maintainer has access to the Settings tab, but without giving others access to too much?
  2. How do I get access back to my own projects?
  3. What does this mean and how does it affect these settings:

    The Backdrop CMS contributed projects organization has their default repository permission set to write. This means that every member of this organization has write access to this repository, regardless of the team and collaborator access specified below.

EDIT: Updated above link due to recent handbook hierarchy changes.

stpaultim commented 4 years ago

I believe that @alanmels had this problem recently was well and @jenlampton made a comment to suggest it happens fairly often. I think I'm locked out of one of my projects as well. I need to double check.

ghost commented 4 years ago

Maybe this setting has something to do with it as well...?

Restrict editing to users in teams with push access only

oadaeh commented 4 years ago

Security with permission to Admin

I think that is not true, either, as both Herb and I are on the security team, and neither of us could administer Feeds.

ghost commented 4 years ago

If it helps work out what the issue is here, here's some repos I don't have access to the Settings tab on:

Each of those repos I created myself either as a port from Drupal or from scratch for Backdrop (i.e. they weren't existing repos that I was added to as maintainer after the fact). If someone with God-like access can check those for me and see what they have in common that might be preventing me access, that'd be greatly appreciated!

jenlampton commented 4 years ago

Most of the projects were not set up correctly initially (or we changed things since then), I've been going back and updating them as I have time. If you need anything updated sooner -- please note here!

edit: @BWPanda I updated the 3 you noted above.

jenlampton commented 4 years ago

I appear to have locked myself out of the Settings tab by setting 'Authors' to 'Triage'...

You can prevent this by adding yourself as a collaborator with "maintain" before you make any changes to teams. :) (but... That shouldn't have been what did it, unless authors were set to admin before?)

ghost commented 4 years ago

Thanks @jenlampton. I now have access to the Settings tab on those 3 repos, but it's a very limited set of options compared to what I had before/have on other repos. Maybe it's meant to be like that, but one thing I find helpful that I don't have access to anymore is the Branches settings/tab where you can set the default branch for the repo.

jenlampton commented 4 years ago

I now have access to the Settings tab on those 3 repos, but it's a very limited set of options

@BWPanda on any project where someone had set themselves with Admin, I have not touched that because I didn't want them to loose any access - but on repos where there was no specific maintainer added I added them with Maintain permission. (this should be more access than they had before)

but one thing I find helpful that I don't have access to anymore is the Branches settings/tab where you can set the default branch for the repo.

Oh, that's unfortunate. Maintainers should have that... Maybe we need to make maintainers into Admins? It looks like Admin is the only level that gives people permission to do that. I was hoping to avoid giving maintainers admin because I didn't want them to retain permission to Delete or transfer repositories out of the organization. But maybe that can't be avoided...

https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization

ghost commented 4 years ago

@jenlampton If I understand this correctly, the Teams permissions are for setting bulk permissions for groups of people, while the Collaborators section is for setting permission for individual users?

If so, I recommend a new practice of giving everyone listed as a maintainer in a project's README file 'maintain' permission under Collaborators section and documenting this in the handbook. So whenever someone makes a PR adding themselves as a maintainer, in addition to merging that PR they be made a collaborator too.

Thanks for that link. Its helpful to see how permissions are divided between the different access levels. I think 'maintain' is fine for maintainers. Maybe we just open an issue somewhere if/when the default branch needs changing, since I can't see that happening often.

ghost commented 4 years ago

Also, what does it mean when there's no access level listed for me as a collaborator? Does that mean I'm an admin by default?

IMG_20191115_073611

ghost commented 4 years ago

What does it mean when there's no access level listed for me as a collaborator?

Nevermind. I added my work account as a collaborator so I could login and see it from another point of view. Now I see that my main (BWPanda) account is set to Admin, it's just that you can't change your own access level :slightly_smiling_face:

image

jenlampton commented 4 years ago

the Teams permissions are for setting bulk permissions for groups of people, while the Collaborators section is for setting permission for individual users?

Yep, that's right.

If so, I recommend a new practice of giving everyone listed as a maintainer in a project's README file 'maintain' permission under Collaborators section and documenting this in the handbook. So whenever someone makes a PR adding themselves as a maintainer, in addition to merging that PR they be made a collaborator too.

This was my plan, but it looks like maintainers are missing two important permissions: the ability to change the default branch, and also permission to add new maintainers.

I'd say when requested, or even for trusted members of contrib, we can give Admin access. It's a bit of a risk to give Admin to everyone. I was looking at @biolithic as an example. Andy is a trusted member of contrib, but has so many repos that if someone were to gain access to his GitHub account they could do a lot of damage by deleting or transferring all his projects.

Here's an idea: What if we require 2FA for anyone who wants admin access? edit: I wonder how many of our current maintainers are already using 2FA.

ghost commented 4 years ago

I think the 2FA for Admins is a good idea. I personally find 2FA annoying and unnecessary (for me, since I use different, 30-character randomised passwords on each site (thanks to my password manager)), but I understand that security trumps convenience. So yeah, I'd be willing to setup 2FA in order to get admin access to my repos and I support making that a criteria for other developers too.

alanmels commented 4 years ago

I also was unable to edit branches, so had to request someone else with sufficient permissions to set 1.x-1.x as default instead of master. And to say frankly it feels little bit helpless and uncomfortable to bother others for such trivial things as setting branches. I understand security concerns, but at the same time I do believe if anyone starts actively contributing to Backdrop community, then s/he there not to harm.

If s/he somehow makes mistakes in the very beginning, then s/he just needs some guidance and understanding and not over reactive precautions. Believe me: if someone starts contributing to Backdrop community and s/he has full control of his/her project before entrusting it to contribs, but when s/he suddenly is stripped off permissions afterwards, then it does not feel alright. On the contrary, it makes people to just keep their projects at their own command and not transferring them to contribs.

I can make any kind of changes on the projects we contribute to Drupal.org. And I really wouldn't want Backdrop to send completely wrong impressions to new comers stripping them off simple permissions to be able to manage their own projects.

jenlampton commented 4 years ago

I agree there are some serious limitations to GitHub's permissions systems. Unfortunately, this is what we're stuck with!

On Fri, Nov 15, 2019, 11:06 AM Alan Mels notifications@github.com wrote:

I also was unable to edit branches, so had to request someone else with sufficient permissions to set 1.x-1.x as default instead of master. And to say frankly it feels little bit helpless and uncomfortable to bother others for such trivial things as setting branches. I understand security concerns, but at the same time I do believe if anyone starts actively contributing to Backdrop community, then s/he there not to harm.

If s/he somehow makes mistakes in the very beginning, then s/he just needs some guidance and understanding and not over reactive precautions. Believe me: if someone starts contributing to Backdrop community and s/he has full control of his/her project before entrusting it to contribs, but when s/he sees stripped permissions when s/he finally does, then it does not feel alright. On the contrary, it makes people to just keep their projects at their own command.

I can make any kind of changes on the projects we contribute to Drupal.org. And I really wouldn't want Backdrop to send completely wrong impressions to new comers stripping them off simple permissions to be able to manage their own projects.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/backdrop-ops/backdropcms.org/issues/605?email_source=notifications&email_token=AADBER46RYK7S5RHIMS6EBTQT3XKJA5CNFSM4JK4PFP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEGNFQA#issuecomment-554488512, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADBERYI3J7QZ3J67LJKPVTQT3XKJANCNFSM4JK4PFPQ .