As an event keeping their hotel booking link secret, I want a super-secret config option for it

[kitsuta]

If I want to distribute a secret hotel booking link to attendees who have registered, I don't want to publish said link by putting it in GitHub. I would instead like to have it treated as a [secrets] config option, much like Stripe keys.

[thaeli]

Let's think about if this makes sense for all events. In general, do we want to say "here's stuff that's sometimes secret, so it lives in Secrets" or "entries in the main config file can be overridden by Secrets and Secrets is the top priority file that overrides anything else, so you can put them either place"..

[kitsuta]

Whoops, typed this one up during a meeting so it's a bit vague!

As far as the app is concerned, the [secrets] config section merely prevents config options from being exposed over the basic API we have. It still works like the rest of config, being defined in configspec.ini, development-defaults.ini, then development.ini. We already have this section, it's where we shove our Stripe and AWS keys.

For our infrastructure, we specifically don't puppetize any of these variables, instead putting them on our MCP server directly. That way we don't accidentally publish our private app keys to the world.

This issue is mostly to remind us that, even though the booking link is just gonna be used once in one email template, it should be a config option so we can keep it secret, keep it safe. It doesn't actually need to be in the [secrets] section to do this, I don't think!

[RobRuana]

This is another one of those things that I'd prefer to keep out of our config files. I hate the idea that a developer has to ssh to another machine, type some stuff into a text editor, and then redeploy our whole production server.

Like, why can't the event runner just type it into a web form and click a "Send Email" button? Why does a developer even need to be involved in that process?

I know we've always done things that way, but that doesn't mean we have to keep doing them that way.

[kitsuta]

I mean, do YOU want to do that refactor? Cause my plate is full. :( Or are you thinking we just start implementing things differently now? I worry that it will create a lot of extra technical debt to just start hobbling things into database format now.

[RobRuana]

There's another possibility here. We could always do an export of people who've selected the "request a hotel room" option, and then turn that into a MadMimi mailing list. It would be a very manual process. But we'd have a bit more control with how and when we send out the email.

Thoughts?

[kitsuta]

Hmm, I have very little insight into how our madmimi email stuff works, but it DOES make more sense from a code perspective -- instead of implementing our specific business logic, we'd be gathering intel to use in other systems, so that's neat. We'll have to ask @nickthenewbie1 or someone else with MadMimi experience if it's feasible/a good idea on their side, particularly when it comes to setting a useful reply-to address, dealing with things getting junked in people's inboxes, etc.

[nickthenewbie1]

My main aversion to it would be the manual-ness off the process -- there would be a lag time for people who registered on uber to be imported into mad mimi.

That being said, there is a madmimi api that you could use to keep the two in sync, but I'm willing to bet some github secret repo would take less work than an api implementation.

[kitsuta]

Hm, that's true -- if we want to continually send out emails to people after we send out the initial blast, that'd be an issue. But if we wanted a cut-off time for "register before now to get a hotel link sent to you," and THEN send out the link, that wouldn't be a problem. Moreover, I think that might be a better idea overall. Once we send out the link, it's unlikely we'd want to keep sending more links out to people, because so many folks will have it already. So then the workflow for us would be:

1. Open prereg
2. Have the form stop accepting "I want a hotel link" requests after $datetime
3. After $datetime, export a CSV of attendees (heck, you don't even need a special export of this, technically)
4. Then send the email

The biggest downside is that it creates another concentrated explosion/blast for the hotel link, just with a smaller audience. So maybe we do want to have the emails still go out to people after we turn on the link..?

[nickthenewbie1]

I was hoping we could continually send it out from uber until the popcorn rule kicks in, then manually simultaneously switch off the auto-mailer and post the link on the website. Thoughts?

[kitsuta]

Hm, but we'd send out the link some time after prereg opens, right? Or were you thinking it'd be in the system from the start?

[nickthenewbie1]

We would send the link some time after pre-reg opens, then send out the link to everyone, including anyone that registers in the following few hours, until the hubbub dies down. Once it looks like it's leveled off, we'd stop sending the e-mail, and post it publicly on the site.

[RobRuana]

We're no longer responsible for this 😄