John Barrett

@russellholt This seems useful if we're going to automate topic posts - everyone's doing this by hand right now.

Yep, pretty much - there should be an easy way for developers who merged your changes to sync their postgres instance and it could also act as an audit trail....

I guess we'll leave it up to the next person making database changes to set the policy :)

`ddgc_schema_diff` produces a lot of erroneous extra output - ideally, if you were to use it, you would at least prune this. But yeah, that's the gist :)

To address this specific issue, I was going to try applying a unique per-thread ID to a given user - it just persists in that thread so can't be used...

We do happen to have a stash of... daxen :) https://duck.co/help/settings/holiday-logos Wonder if there's a good subset that's distinguishable at 32-48px

The session is used to construct some CSRF and other stuff before login. We should restrict it to when some login or register resource is requested. I think this would...

As far as implementation goes, I thought I could use a Plack Middleware session handler which doesn't send the `Set-Cookie` header until the session has data but this was not...

There is a user account called 'deleted' which is configured in `DDGC->config->deleted_user`. What currently occurs on user deletion: https://github.com/duckduckgo/community-platform/blob/bd6ce62/lib/DDGC.pm#L711-L764 - Translation contributions user is set to 'deleted' - Comments content...

What's actually stored in that column? If it's a DDGC user, it should refer to it with `users_id` (though one of the translation system tables uses username...)