Discourse config for organizations - #15
Conversation
✅ Deploy Preview for performant-studio-staging ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
blms
left a comment
blms
left a comment
There was a problem hiding this comment.
This is looking really good! Just wondering about a couple of areas of name collision that seem possible with the tight character limits and slugification of Discourse names.
| async function ensureGroup(config: DiscourseConfig, name: string, fullName: string) { | ||
| const existing = await find(config, `/groups/${encodeURIComponent(name)}.json`) | ||
|
|
||
| if (existing) { |
There was a problem hiding this comment.
In this lookup by name, is it possible that a Performant Studio user could take over any existing Discourse group by accident just by reusing a name?
Wondering if it should only become editable/deletable if this Performant Studio user created it—like maybe we store the id somewhere with the Performant Studio user, or something like that. And if this is expected to be a creation step, then throw if it returns an existing record.
Maybe it's an edge case we don't need to account for, since presumably if someone can create groups on a discourse instance they should have the full access to edit/delete any group—but just thinking about name collisions producing unexpected behavior.
There was a problem hiding this comment.
Discourse group creation is only for org admins, i.e. users can't self-serve Discourse groups. So I don't think we need to worry about users taking over groups, but name collisions do seem like an issue. I'm working on error handling for it now.
| if ('error' in result) { | ||
| return json(result, 400) | ||
| } | ||
|
|
There was a problem hiding this comment.
Should there be a check for name collisions after the groups are normalized? Thinking especially about truncated, slugified group and mod-group names accidentally colliding. I'm assuming the character limits come from Discourse, but they're pretty tight, and since things are being queried/keyed on name I could see this becoming a problem.
2 participants
Summary
This PR adds support for org admins to manage Discourse groups from within Performant Studio.
/api/discourse/groupsedge function that handles the form input, talking to the Discourse API to create/destroy groups/docs/discourse.mdNote
Some of the behavior involving logging into Discourse is hard/impossible to test before merging to staging, so I will likely need to put up a bugfix PR later.
Secondly, in theory we could make Discourse entirely self-serve by exposing the domain/secret/key fields in the Discourse settings page too. 🤔
Screenshots
App grid
Discourse config
Testing notes
Performant Studio UI
/docs/discourse.md/settingsshould render a "This organization is not connected to a Discourse server" notice/settingsDiscourse config