cardinalitypuzzles
Multi-tenancy: smallboard should support per-hunt settings to allow multiple teams to use the same smallboard instance simultaneously
Right now, Smallboard assumes a single team (Cardinality), but it'd be great to support users creating different teams and working on hunts using the same site in the long run.
See https://github.com/cardinalitypuzzles/smallboard/issues/156#issuecomment-732500049 for prior discussion.
This is probably not a high priority for Cardinality's prep for the upcoming MIT Mystery Hunt 2021. But I'm sure there are lots of puzzlers around the world who might enjoy using this tool for other teams, so it's probably worth tracking for some milestone.
One thing we might have to change is the association between Puzzles and Answers, since different Teams will likely work on the same Puzzles with different sets of Answers at different times. We'd probably want to use the existing Puzzle model as the unique representation of a given puzzle and introduce something like a SolveAttempt model relating a Team's Answers to a particular Puzzle.
It might be easiest to just sandbox every hunt from each other, so each hunt instance corresponds to one team's view of one hunt and nothing is shared between hunt instances
I've been itching to get this working, so I'm planning on putting up a WIP PR this week 👍
Copying over a comment from #501:
Currently any user who can login to a smallboard instance can see all the created hunt instances.
It would be nice if several different teams could use the same smallboard instance for the same and/or different hunts simultaneously, where each team creates its own hunt instance specifying its own Google Drive folder, team members who have access, Sheets template file, Discord server, etc.
Also, WIP PR here: #393
I think the biggest piece still missing here is per-hunt permissions. Login right now is still tied to one global Drive folder & we don't have a way of separating the permissions for individual hunts. I think we probably want to add something like django-guardian and then integrate that with the API. It's probably not too much work once somebody finds the time to actually do it.
The other part is actually exposing a way of configuring these settings in the UI--some kind of hunt settings page. This can probably just use a Django view/form, it doesn't need React. We can use the object permissions from above to restrict this page to the person that created the hunt (and if we're feeling fancy, anyone else they delegate).