...

#1 Centralize plugin build tooling

Why is this important?

Efforts to ship the Legal Hold plugin alongside Mattermost v10 were held up by missing build tooling. Additionally, it’s hard to tell when looking at a plugin if it’s “up-to-date” with the latest tooling. How far behind is the plugin? How hard is it to get the plugin up-to-date? Can we even release a new version of the plugin?

What’s the big idea?

Today, the Makefile and build/ infrastructure is copied from repo to repo, often getting out of date relative to the source of truth in https://github.com/mattermost/mattermost-plugin-starter-template

...

• Evaluate and prototype Mage in the starter template (1 week)

• Centralize build tooling in the public module and upgrade starter template to match (1 week)

• Upgrade demo plugin with these changes (2 days)

• Upgrade supported plugins inside the Mattermost organization to use the new tooling (3 weeks)

  • Upgrading the build tooling will bring in a new version of the server and other supporting code, and might require tangential changes from any breaking changes in the API.

• Document steps to convert a repository to adopt the new build format (2 days)

• Document steps to upgrade a repository’s dependence on the public module (1 day)

• Investigate using dependabot to prompt keeping plugins up-to-date? (2 days)

#2 Support Primary vs. Secondary Post Actions

Why is this important?

Customers are having trouble finding the functionality DE is shipping via plugins. This requires extra education and training to successfully ship a deliverable.

What’s the big idea?

When plugins gained the ability to add post menu actions, the drop down quickly became cluttered between primary “primary” actions and actions registered by plugins. This led to burying all plugin actions behind a secondary menu:

...

Unfortunately, this limitation stymies efforts by Deployment Engineering to give customers genuinely new primary actions. A similar change occurred in the past with the app bar vs. the channel header, and we should follow suit by restoring plugins' ability to register primary vs secondary post actions.

Note that there is another type of registration that puts buttons directly on the post menu and not under a flyout. As part of this, we might want to clarify terminology, as that location might be more properly “primary”, with “secondary” and “tertiary” to boot.

Task List (~3 weeks)

• Introduce API to register primary post actions (1 week)

• Update demo plugin to use both post actions (2 days)

• Update e2e tests to ensure coverage of the new registration points (8 days)

Future?

• Root menu (primary) vs. three dot menu (secondary) vs. message actions menu (tertiary)

• Conditional display (i.e. no attachment => hide option, ability to delete => hide option)

  • Callback vs return null

  • Dynamic decision on server call

• Can we extend this /now/ so we’re set for the future (not having to wait for server upgrade)

#3 Expand starter template

Why is this important?

DE doesn’t use the starter template all that often anymore: instead, a more up-to-date plugin is selected with all the necessary plumbing, and the unneeded parts are ripped out there.

What’s the big idea?

New efforts initiated by Deployment Engineering are stymied by a fairly bare bones starter template: just enough code to kickstart a server and webapp component in a plugin. Let’s expand the starter template with enough substance to accelerate new efforts, including:

...

• Add database access to starter template (1 week)

• Add metrics to starter template (1 weeks)

• Productize and add “reattached” testing framework to starter template (2 weeks)

• Add e2e tests to starter template (1 week)

• Update demo plugin with latest starter template (1 week)

• Document – inside the starter template – how to both use each of these extensions, and also how to remove them if unneeded. (1 day)

Ideas

• Command package!

• Jobs examples

• “Advanced-starter-template” vs. making the starter template overwhelming vs. “plugin-barebones”

• “Commented out code”: just uncomment and fill out what you need.

• Skeleton code for registering a REST API

• Avoid having to dig through documentation.

• Maybe database → advanced? adding menus? Draw a line between “starter” and “advanced”

#4 Review and polish API, Hooks, Wrapper & Utilities

Deployment engineering has run into various requirements that would ideally be fulfilled by a plugin hook, but wasn’t yet implemented in core (and thus not deployed to customers). Similarly, there are Plugin API gaps that create security review hurdles or add complexity to rapid plugin development. Let’s review and address these holistically.

...

• Common UI components: button, checkbox…

• Single “mattermost-webapp” or “plugin-api” package import to rule them all

• Common eslint configs / golangci configs?

  • Can we avoid plugin-specific configs and just force all plugins to “look the same”

  • Can we check these configs when the public submodule is updated to enforce they stay in sync? (Requires manual step, but “better” than auto-generating, having to .gitignore, works out of the box with editors, etc.)

• Post menu pluggable section, deprecate to allow for accessibility

  • filtering, string <> localization

• Rely on dependabot to automate updates of the public module and in turn help spur unified tooling across all the plugin repositories.

• Review webpp plugin API for completeness

• Adopt logrus-style conventions (hopefully using mlog).

  • Add helpers like WithUser([string | model.User]) to standardize logging keys like user_id

• Formalize Redux package for use by plugins

  • Supported set of selectors

  • POJO actions (no thunks)

• Explicit hook registration vs implicit