collaborative plugin / API

[samy KHELIFI]

PITCH:

in Odeon, we have created an Env singleton object, configured with a yaml file (env.yaml), instanciated during the bootstrap (see ENV).

In this object, we have dependencies to organization objects (Project, Team, User etc.). So, you actually can define some parameters like email or teams id.
The main concept of this plugin /Api is to bring the ability to a user to send email or teams message in a webhook to communicate events (in odeon fit, could be used to declare start or end of training, some result reached, etc).

TODO:

The need is to develop an Api in an internal plugin (named collab or whatever the developper wants to call it).
The plugin has to be placed at the root of the Odeon package (next to data, models and so on).
You need to declare a python Protocol as interface. This Protocol should at least have to declare a function like send(), with parameters, and LSP compliance for signature overriding (*args, **kwargs).

from typing import Protocols

class CollabProtocol(Protocols):
    def send(some_param, *args, **kwargs):
        ...
    ...

The Mail Collaborativ Class, the Teams collaborative class should respect that protocol, but not inherit from it (contract).

After implementation, we need to have a Dynamic Registry for pluginification and for extensibility, meaning ability to add other collaborative Api in an external plugin. (the data registry to register data module is an example, see DATA REGISTRY)
And we need to create an instance of OdnPlugin to register dynamically in respect with Odeon philosophy (eat your own dog food). We can take example of the plugins instanciated in the data package ( see DATA PLUGIN)
Final, stage add the plugin in the default plugin constant( see DEFAULT PLUGIN)
Write some simple unit tests for non API regression check for the next CI/CD packaging pipeline.

CAVEAT:

we will maybe need some external library for Teams (but maybe not as weebhooks are pure http protocols). If it's the case, these libraries will be optional libraries, meaning we need to check if they are in the python environment to register the concerned APIs.

BRANCH:

the branch to use and where to make the PR is the dev branch