Streamlining UX

Hi. We're already running Nextcloud in our organization and are currently exploring different platforms for our volunteers to communicate with each other – including Discourse. If we go for it, we'd obviously like to use the Discourse integration. Unfortunately, the whole process seems a bit complicated.

First and foremost: Users should not have to enter the Discourse instance URL on their own. Instead it should be set system-wide by the admin. The added benefit would be that you could completely skip the redirect to the settings page. Instead, users just click the "Connect with Discourse" button on the Dashboard, accept the protocol authorization if necessary and get redirected to the Discourse server. I know, in some use cases, being able to change the Discourse instance URL on a per-user basis might be useful, but I definitely feel like this should be a setting and not the default.

Once the user accepts the Discourse API access, they should be redirected back to the Dashboard and not to the settings page. Search settings might also be managed globally, but for us they aren't relevant anyways.

Additionally, it might be a good idea to allow other ways of supplying the Discourse integration with a valid API key, but this might not be easily doable, so I'm just mentioning it aspirationally. This is our situation: All of our users log into our Nextcloud via OIDC (using this plugin), and we could include whatever data we like in the OAuth2 claim. So it would be super cool if we could pre-generate API keys for the users and then supply them to your plugin without them having to do anything. This is probably hard to achieve, especially because it would be implementation dependent and there's a few other OIDC/SAML apps out there.

Let me know what you think. If this sounds like a good idea to you, I could try and find some volunteers to help with implementation.

Begin at the Dashboard’s “Connect with Discourse” flow and the settings page, then trace the Discourse API authorization return. Separate the requested system-wide instance URL and post-authorization redirect from the aspirational OIDC/OAuth2 API-key delivery idea. Done requires an agreed, testable scope for these behaviors.