Associate Venues with Chapters

Do we want each venue to belong to one chapter? There are couple of reasons I can see to do this, one practical and one technical.

The practical reason is that a venue is typically going to be close to the chapter members and so forcing event creators to choose from all possible venues is unhelpful. There is also the potential for confusion if admins of multiple chapters update the same venue.

The technical reason is that the authorisation logic uses the target chapterId to determine if a user’s request should be rejected. If chapterId is not sent as part of the request, then chapter admins will not be able to manage venues. There are a few potential workarounds:

1. Give chapter admins the VenuesManage instance role
2. Handle the authorization logic in the resolver
3. Rework authorization logic

Issues:

1. is pretty awkward. In part because it’s messy (users shouldn’t need more than one role) and in part because instance permissions cannot be stopped by bans (yet).
2. mixes up concerns
3. is the nuclear option, since I’m not sure what we’d do instead

Summing up

Given that there are positive reasons to want this as well as a lack of obvious workarounds, I think this is the way to go.

Any concerns before I get on with implementing this?

[ojeytonwilliams]

Reopening since there is more to be done. Context: https://github.com/freeCodeCamp/chapter/pull/1212#issuecomment-1184301773

[allella]

Sure, if you can start with authorization for chapter specific and it won’t complicate something like adding a global venues flag, then that sounds like a decent MVP.