This document sketches out a greenlight proposal for Q4 2024 to improve the developer toolkit and accelerate efforts by Deployment Engineering in supporting our customers.

#1 Centralize plugin build tooling

MM-60889: Centralize plugin build toolingOpen

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 GitHub - mattermost/mattermost-plugin-starter-template: Build scripts and templates for writing Mattermost plugins.

To solve this, let’s write all build tooling in Go (some already is) and host it in a build package as part of the public module in the monorepo. As part of this, we’ll switch to https://magefile.org/, but preserve a subset of the build interface in a Makefile to avoid CI breakage. (Running unsupported commands should teach users how to use Mage.)

Task List (~6 weeks)

• 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

https://mattermost.atlassian.net/browse/MM-60898

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” actions and actions registered by plugins. This led to burying all plugin actions behind a secondary menu:

Open

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

MM-60903: Expand starter templateOpen

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:

• A database store, interface, timerlayer generators, and support for migrations

• A working Prometheus metrics endpoint, already tied into the database store and ready for extension.

• The new “reattached” testing framework that accelerates unit testing with a minimum of mocking. (See MS Teams Plugin).

• Playwright e2e tests framework, including CI integration. (See AI Plugin and Calls Plugin)

As part of these changes, let’s evaluate what to include directly in the starter template, and what to put in the public monorepo to reduce copy/paste requirements (e.g. generators for the database store /might/ make more sense centralized.)

Task List (~6 weeks)

• 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.

Task List (~6 weeks)

• Review existing plugin API and hooks for obvious gaps. (1 week)

  • GetUsersByIDs

• Extend plugin API and hooks after review (2 weeks)

• Expose authenticated user id in the plugin context, deprecating the Mattermost-User-Id header. (3 days)

• Ensure plugin API wrapper has 100% coverage for plugin API. (1 week)

  • Build a tool to ensure 100% coverage going forward?

• Extend plugin jobs framework to simplifying running jobs only on the job server, and at a specific time of day. (1 week)

Other Ideas

• 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