Mattermost-server: Plugin framework: Enable plugins to send system-wide settings to clients

[esethna]

If you're interested please comment here and come join our "Contributors" community channel on our daily build server, where you can discuss questions with community members and the Mattermost core team. For technical advice or questions, please join our "Developers" community channel.

New contributors please see our Developer's Guide.

---

Notes: Jira ticket

Many plugins have system-wide or admin settings that need to be communicated to the client portions of a plugin. Design and implement a simple way for plugins to register client config settings that will get automatically provided to clients. This will likely involve adding a new plugin API method. Documentation is available here https://developers.mattermost.com/contribute/server/plugins/.

One possible implementation method is allowing plugins to append to the existing client config:

• https://github.com/mattermost/mattermost-server/blob/master/api4/system.go
• https://github.com/mattermost/mattermost-server/blob/master/utils/config.go#L491

If you have any questions or would like feedback, feel free to ask in the Developer Toolkit channel on our Mattermost community instance.

[dragossutu]

I would like to work on this.
But, lets see if I understand the requirements:

• > that need to be communicated to the client portions of a plugin

you are referring to the web app side of the plugin ?

• I noticed plugins can save settings in config.json, but a new, separate section needs to be added for plugin's client portion settings ?
• plugin's server-side has to be able to notify plugin's webapp-side when these settings change ?

A possible scenario:

1. client settings are changed
2. plugin publishes a custom websocket event ClientSettingsChanged using PublishWebSocketEvent API
3. webapp-side of plugin listens for the ClientSettingsChanged event, using registerWebSocketEventHandler and reacts accordingly

Just that a default implementation should be created by adding a new API method, instead of the above scenario.

Is this correct?

[jwilander]

@drgsutu your comment triggered some discussion here https://pre-release.mattermost.com/core/pl/tiejc7je5igh88xck5srmfkz9e if you'd like to participate

[jwilander]

We've chatted about it at the above link and we're going to instead implement this as an example in the demo plugin https://github.com/mattermost/mattermost-plugin-demo instead of building it into the framework.

[jwilander]

@drgsutu did you get a chance to look at submitting an example to the demo plugin?

[dragossutu]

Hi @jwilander, I have made the server-side changes when we had the initial discussion, I still have to add some front-end code.
I will do my best to create a pull request this week, if it's not too late.

[jwilander]

Sounds good and no rush :+1:

[dragossutu]

@jwilander, please have a look at https://github.com/mattermost/mattermost-plugin-demo/pull/11 when possible.

[lieut-data]

This ticket hasn't had traction, in part due to being underspecified. Closing for now, and we may revisit this in the future.