Mattermost-server: [MM-10017] Plugin framework: add support for plugins to override right-hand sidebar

Created on 26 Jan 2019  路  12Comments  路  Source: mattermost/mattermost-server

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

The right-hand sidebar (RHS) is the sidebar that opens on the right of the application when opening a message thread, searching or looking at flagged/pinned posts. It would be very useful for plugins to be able to trigger the opening of the RHS and to supply their own custom components to render inside the RHS.

Few use cases:

1) (from customer) Click on an IP address in a Mattermost channel: this address opens the right-hand side panel with more information pulled from an internal database like the OS, browser, etc. Useful for troubleshooting.
2) Clicking on a Google map link or image preview opens the right-hand side panel with more information on the location
3) (from community) Displays a list of GIFs a user can choose from after invoking a giphy slash command

This would involve adding a new method (or two) to the client plugin registry and potentially modifying the view state/reducers of the app to better support custom right-hander sidebars.

As part of this ticket please add an example of the new functionality to the demo plugin at https://github.com/mattermost/mattermost-plugin-demo.


For general information on how plugins work see: https://developers.mattermost.com/contribute/server/plugins/

For information about building plugins see: https://developers.mattermost.com/extend/plugins/

If you have any questions, let us know!

AreIntegrations Hard Help Wanted PR Exists TecReactJS

All 12 comments

This would allow for some super useful / cool functionality - I'd like to pick this up. I would need some clarification and help to get started though:

  1. Authorization
    a. Do we want a whitelist in the config to allow certain plugins to override?
    b. Should it be runtime-configurable instead (enable/disable per plugin in the System Console)?
    c. Once plugin with override functionality is installed it'll always override?

  2. UI
    a. Build a strict template and only allow plugin devs fill out fields (guarantees style consistency)?
    b. Just keep the searchbar/header/footer/sizing locked while allowing devs to use html/css in the body?
    c. Allow basically anything (sanitized though)?

  3. Performance / Security

  4. How pro-active should we be about this? Should there be size limits and sanitization? Or can we assume that all installed plugins come from trusted plugin developers who will manage their own paging/previews/etc.

Help:

  • Is there currently any case other than Replying and Searching that uses the RHS?

hey @d28park

Is there currently any case other than Replying and Searching that uses the RHS?

  1. Pinned post
  2. Flagged posts
  3. Recent mentions

All these can be triggered via the channel header buttons alongside the search bar.

@d28park are you still working on this? If not, I would like to take a shot at it.

I鈥檝e got a working first version of the plugin RHS (see screenshot) and wanted to confirm and get some feedback on some UI details:

  1. When the plugin calls to open the RHS, it shows the side panel with the same header as with the Expand and Close buttons as it does with the Mattermost RHS use cases. The rest of the sidebar area is what is available for the plugin to use with their own custom component. I believe keeping this header bar with the Expand and Close features keeps the usability the same regardless of the content.

2.In the Mattermost-Plugin-Demo I changed the plugin button on the Channel Header to open the RHS. Let me know some other way is preferred.

Let me know your thoughts. @jwilander @esethna @jasonblais

Screen Shot 2019-05-16 at 2 41 25 PM

Awesome, looking good 馃憤

  1. IMO that makes perfect sense to me. On a tangent, is there a way for the plugin to specify the title of the RHS component? That might be something worth adding there

  2. Using the channel header button to open the RHS in the demo plugin makes sense to me. Only feedback I'd give for the demo plugin is to maybe neaten up the text inside the RHS to align it a little nicer so it's not hitting the edges of the components as much

Feel free to chime in with opinions @crspeller @jasonblais

Thanks! This is awesome.

1 - +1, that makes sense
2 - Also +1 to what you and Joram suggested. Other buttons in the header (e.g. pinned posts) open the RHS as well.

My only note is that currently clicking the channel header opens the root component as attached, and documented here. Would we have two separate actions in the header, or should we move the root component trigger to be elsewhere in the interface?

image

Tagging @jespino @asaadmahmood as well, since the changes proposed here may be related to an open PR about supporting additional metadata in RHS by plugins: https://github.com/mattermost/mattermost-webapp/pull/2305

On a tangent, is there a way for the plugin to specify the title of the RHS component? That might be something worth adding there

I wanted to do that too but given that the header is not part of the plugin, the web app would have to set that title text. Not sure there is a way for the web app to know the plugin name? We could add another pluggable for the name there but seemed a bit overkill. @jwilander

2. Using the channel header button to open the RHS in the demo plugin makes sense to me. Only feedback I'd give for the demo plugin is to maybe neaten up the text inside the RHS to align it a little nicer so it's not hitting the edges of the components as much

Agreed. Will clean that up!

My only note is that currently clicking the channel header opens the root component as attached, and documented here. Would we have two separate actions in the header, or should we move the root component trigger to be elsewhere in the interface?

The root component is also being triggered from the Main Menu, File Upload and Post Dropdown Menu. But I can add another button to the channel header if preferred. @jasonblais

@marianunez Yeah, you're totally right, so no concerns there.

@marianunez I was thinking of having it as another parameter to the registry function for adding your RHS component. Under the hood you could store it in the reducer with the plugin component. Does that make sense

This all makes sense to me. Good job @marianunez!

Was this page helpful?
0 / 5 - 0 ratings