Fix permissions for organisation and repositories

[richardreeve]

Given github is the central source of guids for the project, and the organisation is the authentication mechanism for Zulip, a lot of people with no experience of github will be members. The current system may therefore give people too much control over other people's repos and too little control over their own.

We could have teams for each of the 6 modelling repos, and an admin / lead RSE team that has control over (all +?) any private repos? Everyone will still have read access to all of the models anyway because they are public...

[alysbrett]

Richard and I have set the base permissions for the org to none and are adding back what's needed. Most projects had teams already but I created one for simple network simulation and am now making sure they have the right members and write permission on the relevant repo.

[alysbrett]

OK - there is now a team for every project and those teams have write access to the repo. I could do with confirming the situation with the Java projects is correct as we have 2 teams and 4 repos and the names don't match up exactly. Could @johnnonweiler let me know please?

[johnnonweiler]

@alysbrett It looks like you've figured it out. Contact-Tracing-Model has replaced the FMD-Model, and Covid_Simulation_Model has replaced the ND-Model.

DiscreteSpatialPhyloSimulator should be deleted (it contains only commits which exist in hxnx-sam/DiscreteSpatialPhyloSimulator, where it was forked from).

FMD-Model-1 is no longer being used, but it has some new commits which we should copy elsewhere before it is deleted. I'll let you know when it is ready to be deleted.

[alysbrett]

Thanks. I have deleted DiscreteSpatialPhyloSimulator.

[johnnonweiler]

@alysbrett FMD-Model-1 can now also be deleted.

[alysbrett]

I'm going to call this done but obviously let me know if you run into any further permission issues. You can use There is an scrc-admin team (Richard and me!) that you can '@'

[alysbrett]

@ianhinder and I have encountered an issue that may be related to our changing base permissions for the org to none. We think it means you can't assign an issue to someone not in any team since they need to be an org member with read permission on the issue tracking repo and that needs to be explicit read permission not just ability to read because it's public.

I think @richardreeve suggested that a team with everyone in the org in it would be a workaround for this and Github forums agree "If you only want "Read" access to most repositories, then yes, setting base permissions to "None" and using an "Everyone" team is currently the way to do it. There are currently no implicit teams."

I don't think there is a way to automate this but a workaround could be to have many admins (eg all the RSE leads and github-active members of the management group) so anyone likely to want to assign an issue can add the relevant person if they are not yet a member.