1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
## Proposed changes to Mailman core
1. Add configuration option similar to `config.styles.paths` but for general plugins. Paths in this list will be used to find components that Mailman will use, similar to `find_components` coupled with a standardized plugin structure:
- `plugin package`
- `handlers`
- `rules`
- `chains`
- `commands`
- `pipelines`
- `styles`
- `rest`
- [MR !288](https://gitlab.com/mailman/mailman/merge_requests/288)
Adds a whole configuration section for plugins, where each plugin has the following options:
- name of the section
- `class:` a class implementing the new `IPlugin` interface.
- `path:` a python package available on `sys.path` under which the aforementioned plugin structure, searched for components, resides.
- `enable:` whether the plugin is enabled, only enabled plugins are searched for components, their classes instantiated, their hooks run and their REST routes exposed.
- `configuration:` optional configuration path, which the plugin can use to read/write it's configuration file.
2. Let plugins add Pipelines the same way they can add Handlers, Rules etc...
- [MR !287](https://gitlab.com/mailman/mailman/merge_requests/287)
- This means refactoring `BasePipeline`, `OwnerPipeline`, `PostingPipeline`, `VirginPipeline` from `mailman.core.pipelines.py` into a package `mailman.pipelines`
- Use `find_components`, or rather it's sibling function created in 1.
3. Let plugins subscribe to receive events.
- [MR !288](https://gitlab.com/mailman/mailman/merge_requests/288)
4. Allow multiple callables in `pre_hook` and `post_hook` run in order specified. Also allow callables for when Mailman exits.
- [MR !288](https://gitlab.com/mailman/mailman/merge_requests/288)
- Already a similar [MR #264](https://gitlab.com/mailman/mailman/merge_requests/264).
5. Allow Mailman core to send events to Postorius, HyperKitty and any app that subscribes through a new REST api call with a callback.
- Also add an `IEvent` interface, as currently events don't implement any interface at all.
6. Drop `ext_dir`.
- [MR !288](https://gitlab.com/mailman/mailman/merge_requests/288)
7. Let plugins add routes to the REST API. Under `/plugins/<plugin_name>/...`.
- [MR !288](https://gitlab.com/mailman/mailman/merge_requests/288)
- Use the current `ObjectRouter` with plugins providing a REST object.
8. Add per-plugin config.
- [MR !288](https://gitlab.com/mailman/mailman/merge_requests/288)
9. ? Make all commands be able to require confirmation and make this a configurable option.
- How?
- Abstract out confirmation of commands (is actually almost there with Pendables)
- Add another field to `MailingList` model, for a list of commands that require confirmation for that list?
10. ?? Add a new attribute to several core models (MailingList, User, Address, ...) in which plugins can store metadata about said objects. This attribute woul be a PickleType, really a dict with, plugin-names as keys. Each plugin could access its and only its metadata attached to a given object.
## Proposed changes to MailmanClient
1. Add bindings for specifying list-style on list creation.
- [MR !28](https://gitlab.com/mailman/mailmanclient/merge_requests/28)
2. Add bindings for `/plugins/<plugin_name>/...`.
- Pretty low-level, since each plugin can handle requests as it wants.
- [MR !34](https://gitlab.com/mailman/mailmanclient/merge-requests/34)
## Proposed changes to Postorius and HyperKitty
1. Add additional blocks to some base templates.
2. Add a dropdown list-style selection field to list creation template + view.
- [MR !214](https://gitlab.com/mailman/postorius/merge_requests/214)
3. Let Postorius and HyperKitty subscribe to receive events from Mailman Core, add an API route to receive them in django-mailman3.
|
