diff options
Diffstat (limited to 'core_changes.md')
| -rw-r--r-- | core_changes.md | 36 |
1 files changed, 19 insertions, 17 deletions
diff --git a/core_changes.md b/core_changes.md index fe99d55..a15e92a 100644 --- a/core_changes.md +++ b/core_changes.md @@ -1,6 +1,7 @@ ## 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: + - [MR !288](https://gitlab.com/mailman/mailman/merge_requests/288) - `plugin package` - `handlers` - `rules` @@ -11,39 +12,40 @@ - `rest` 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. Let List creator specify List Style when creating it through Postorius. - - The REST api supports it, add bindings to MailmanClient and a field to Postorius. + 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 multiple callables in `pre_hook` and `post_hook` run in order specified. Also allow callables for when Mailman exits. - - Already a [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. Allow Mailman core to send events to Postorius, HyperKitty and any app that subscribes through a new REST api call with a callback. - - [#329](https://gitlab.com/mailman/mailman/issues/329) - - 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. Drop `ext_dir`. + 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. Let plugins add routes to the REST API. Under `/plugins/<plugin_name>/...`. - - Create a new `IRESTSink` interface, that is callable `func(request, response)` and knows it's prefix relative to it's root. - - Use `falcon.API.add_sink(callable, prefix)` to add all `IRESTSink`s from both `mailman.rest` package(unused, no sinks necessary for core) and plugin's `.rest` package. - - [falcon.API.add_sink](https://falcon.readthedocs.io/en/stable/api/api.html#falcon.API.add_sink) - - Or use the current `ObjectRouter` with plugins providing a `Plugin` object with routing working as currently. - - 9. ? Make all commands be able to require confirmation and make this a configurable option. + 8. ? 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 possibility of config inclusion to `mailman.cfg`, or of per-plugin config. + 9. ? Add possibility of config inclusion to `mailman.cfg`, or of per-plugin config. - 11. ?? 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 PickedType, really a dict with, plugin-names as keys. Each plugin could access its and only its metadata attached to a given object. + 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. |