Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option for homeservers to set a default integration manager #4913

Closed
turt2live opened this issue Aug 28, 2017 · 6 comments · Fixed by matrix-org/matrix-react-sdk#3340
Closed

Comments

@turt2live
Copy link
Member

Description

Full disclosure: I'm obviously biased for wanting this due to my work on Dimension. Please keep that in mind while considering this proposal.

If individuals want to change their integrations manager then they must deploy their own instance of Riot, or compile it themselves if they are electron users. Instead, power users should be able to set the rest api url and ui url in a synced setting. This does have the downside of people having to enter 2 more urls (see: login page), but ideally it would be put under the "advanced" section to avoid people accidentally changing them. The user should also have the option to disable the integrations manager entirely, or reset the settings to the default (inherit from config.json).

A question would be should the config.json expose flags for overriding the user's preference? This would probably only be useful in corporate environments where security is a concern (force disable or force use corporate deployment).

I'm open to writing the PR for this, but would like feedback from the team/community on the approach. The 2 fields is an option, but it isn't as smooth as it could be. Ideally users would be able to select from a dropdown which manager they'd like to use, but this leaves the question of how do new integration managers get on that list (or in the case of Dimension, self-deployed instances). It could be hardcoded into the source, or provided through a config.json list, but that leaves the question of "should manager X be used on client Y when Y doesn't explicitly list support for manager X?" (I would think yes, and Riot should show the selected manager in the dropdown anyways, even if it isn't supported on the current client).

Thoughts?

Version information

  • Platform: web (in-browser)
  • Browser: Chrome 60
  • OS: Windows 10
  • URL: riot.im/develop
@ara4n
Copy link
Member

ara4n commented Sep 5, 2017

Hm, technically users don't need to compile it themselves - they can just change the config.json whether it's for riot-desktop or riot-web. But agreed we should support alternative integration management UIs. We haven't really thought this through yet as scalar was a fairly rushed custom job specifically for Riot, but possible directions include:

  • Implementing the integration manager as just another widget, and so let users deploy their own managers as custom widget (deployed straight from the client rather than going via scalar)
  • Providing a button to pick an alternative integ manager (including letting the user define a URL). This definitely shouldn't be at login though, but surely be located somewhere when they actually hit the integrations management button in the top right.

@rxl881 is leading the integs work and is on holiday this week, but I'll sync with him on his return :)

@turt2live
Copy link
Member Author

There's the challenge of not being able to edit the config.json when you're using someone else's service though, like riot.im/app. Ideally people would be able to pick independent of their provider, although I imagine some people (corporate) are going to want control over preventing that.

I like the idea of a app-level widget that would be a mix of both directions. Riot should almost certainly provide a default (Scalar) for users not wanting to fuss with figuring out what the widget does, but also allow for the user to change at a whim. This concept could be taken further to other parts of the UI, if desired. For example, you could 'install' an app-level widget that replaces the room directory or call handling (jitsi, freeswitch, custom, etc).

In the meantime though, I'll eagerly await for Richard's return :)

@turt2live
Copy link
Member Author

ftr, matrix-org/matrix-spec-proposals#1957 is the proposal for this

@nadonomy
Copy link
Contributor

nadonomy commented Jul 5, 2019

After validating today, latest comps are in Zeplin, with Integration Management as a part of Settings: https://zpl.io/brMdWo3

@turt2live turt2live self-assigned this Aug 7, 2019
turt2live added a commit to matrix-org/matrix-react-sdk that referenced this issue Aug 9, 2019
It was already in a common place, but this is the boilerplate for supporting multiple integration managers, and multiple integration manager sources. 

For element-hq/element-web#4913 / element-hq/element-web#10161
turt2live added a commit to matrix-org/matrix-react-sdk that referenced this issue Aug 9, 2019
For element-hq/element-web#4913 / element-hq/element-web#10161

Relies on the structure defined by [MSC1957](matrix-org/matrix-spec-proposals#1957)

This is just the bit of code to parse the user's widgets (while watching for changes) and allow for it to be the default manager.
@turt2live turt2live changed the title Option for individual users to choose their integration manager Option for homeservers to set a default homeserver Aug 12, 2019
@turt2live
Copy link
Member Author

I've repurposed this for homeservers being able to set a default IM. #10161 tracks the per-user side.

@turt2live turt2live changed the title Option for homeservers to set a default homeserver Option for homeservers to set a default integration manager Aug 12, 2019
@jittygitty
Copy link

jittygitty commented May 15, 2022

What's the STATUS on this? How do we use our own integrations manager server when we connect to our own private servers??
element-hq/element-integration-manager#86
#6430
matrix-org/synapse#7702

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants