We have multiple issues with possible malconfiguration or unmet requirements.
First, we don't want to check everything and have false positive error in system requirements.
All plugins have config based instances.
Problems could be:
- IMAP contains wrong credentials.
- Many unprocessed items in IMAP or any other queue based fetcher.
- Unmet php library dependency, example pgp signing / check library.
Some of the issues can be covered by Monitoring project. Others need new coverage, typically the hook_requirements.
Let inmail implement hook_requirements.
Let inmail cycle through all instances of plugins (deliverer, analyser, handler) and ask each handler if it is healthy.
Could be checkRequirements().
For this, we will introduce a new method on the interface.
Checking for a library dependency is easy.
Make sure to not check if an item is disabled. thus if no pgp analyser is enabled, no error if the library is missing.
Manually disabling is a different thing to being unable based on runtime checks.
We can add an argument to checkRequirements, identifying "runtime" for runtime checks and "requirements" for the global hook.
The requirements check can be verbose, even trying to connect to each service configured to warn about wrong credentials setup.
The runtime check will only quickly check the situation to avoid fatal errors. It need to be fast and should be performed prior to interacting with the plugin instance. Not sure where exactle the API should be called, but for sure in check / fetch of IMAP.
May be, we even want to create two different methods?
- For hook_requirements, we need the requirements return value.
- For the runtime check, we might want to throw an exception?
User interface changes
Data model changes