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

Provide sensible defaults for integrations_widgets_urls #10454

Closed
jaywink opened this issue Jul 30, 2019 · 2 comments · Fixed by #10656
Closed

Provide sensible defaults for integrations_widgets_urls #10454

jaywink opened this issue Jul 30, 2019 · 2 comments · Fixed by #10656

Comments

@jaywink
Copy link
Member

jaywink commented Jul 30, 2019

In the case that someone running a self-hosted Riot doesn't define integrations_widgets_urls at all, Riot defaults to integrations_rest_url.

Since the integrations_widgets_urls "normally" (ie in app/develop, desktop) has defaults as follows, it would make sense to default to those in the case that the widget urls are not set:

    "integrations_widgets_urls": [
        "https://scalar-staging.vector.im/api",
        "https://scalar.vector.im/api",
        "https://scalar-staging.riot.im/scalar/api"
    ],

This would ensure that widgets created with either live or staging Scalar would work even if the Riot configuration doesn't define them. It should be possible to disable all of them still by setting integrations_widgets_urls to an empty list.

This issue comes from a real world case where custom hosted Riot didn't define these urls and failed to thus render a widget created via scalar-staging.vector.im.

@turt2live
Copy link
Member

fwiw if I get my way with the integrations API proposals then this field becomes obsolete.

@turt2live
Copy link
Member

(also insert a comment here with my community hat about dissatisfaction for continuing to default to scalar when there are other integration managers in the world)

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

Successfully merging a pull request may close this issue.

2 participants