obijywk / hunttracker Goto Github PK

https://api.slack.com/reference/block-kit/block-elements#static_options only support a maximum of 100 options, so many dialogs for tag updating, renaming, and deleting will stop working when more than 100 tags are introduced.

Could fix this by preventing the introduction of more than 100 tags at all, or changing all of these dialogs to gracefully degrade when more than 100 tags exist.

As a prelude to being able to implement dark mode easily (which PR #29 is aimed to start work on) we need to investigate why select2 destroys all other html5 data values that appear on the page - including reaching all the way out to the tag itself.

• document the scopes we need to add for Google Drive Activity API and Google People API
• add googlePersonResourceName to the users table schema
• when we synchronize users with Slack, also create a contact for each user in the Google service account with their name and email address, via people.batchCreateContacts... but don't store the people resourceName returned from that call, it's different from the one the Drive Activity API returns
• add an environment var for the Google Drive folder ID and document it
• periodically call activity.query with the Google Drive folder ID as ancestorName and filter restricted to edits within the past N minutes
• for each actor in the response, see if their knownUser personName already exists as a googlePersonResourceName in the users table. for the ones that aren't there, call people.getBatchGet to look them up, and update their googlePersonResourceNames in the users table.
• look up the puzzles and puzzle_users for the driveItems in the activity.query response
• if the puzzle isn't archived, for each actor in the activity.query response associated with that puzzle's driveItem, check if they are a user associated with the puzzle
• if they're not, and they've also never joined the puzzle channel before, invite them to the puzzle channel

Hello! Would you be open to adding the topic puzzle-hunt to this repository? I've been looking for puzzle hunt organization tools, and they're rather scattered right now. Cardinality's Small Board project uses this topic already, so I thought I'd ask the projects I've seen so far to start using it, too.

Thank you very much!

One thing that a few previous hunts have shown is that our system for sorting puzzles into groups is not necessarily as flexible as it ideally could be.

Part of this is the distinction we currently have where we tag puzzles as being in/<group> and then tag a meta meta/<group> then have code to process the tag names to extract just <group> where we need that for sorting purposes.

My proposal is to separate out the ability to tag puzzles as meta or not based solely on that tag without additions, and instead have all puzzles in a logical group indicated by group/<group> - this maintains the usefulness of the Meta view (where we would just display puzzles by group and sort any tagged metas to the top) and allows for simpler logic for filtering the Puzzle view.

For example, this year's Mystery Hunt had one round that contained three metapuzzles and we did not change any of the tagging in that round, so as the first meta for that group had been solved, the group was sorted to the end in meta-view despite having at least one open metapuzzle in it for the entirety of the post-solve process. It is my proposal that sorting those by group and displaying the metapuzzles at the top would show there was still meta-work to be done in that round as well.