Server app is trying to install E20 required plugins (e.g. incident management) on non-E20 installations. We shouldn't try to install as long as preconditions satisfied.
Reducing to INFO would imply doing the same for NPS, etc. Should we consider allowing the plugin to be enabled but instead disabling the functionality somehow?
— Should we consider allowing the plugin to be enabled but instead disabling the functionality somehow?
I like that idea if we can accomplish that.
I’d suggest not trying to install the plugin, could we have a check before install to eliminate “non eligible” plugins? TBH, I am not a fan of having two different behaviors at this level. I mean if a plugin is enabled, I’d expect it to work like others.
I'm 0/5 on the actual solution. But my recommendation is to optimize for the end user experience:
1. Make it effortless to start using Incident Collaboration when someone uploads an E20 or a trial license (no steps required to get started).
2. Not make it confusing for those using E0 or E10.
The nuance here is that prepackaging is a bit of a hack:
Prior to license initialization, the config defaults distinguish TE from EE (compilation flag) and use that to /enable/ the plugin.
On startup, any plugin that’s /enabled/ will be installed automatically if found in the pre-packaged cache.
Some plugins, like Incident Management, fail to activate if they are run in a non-E20 environment.
This results in an ERROR log.
We’ll discuss in triage today, but propose we move forward with a “limited functionality” approach when enabled without a license. This serves the dual purpose of making it easy to use when an E20 license is installed (or trialed), and potentially also advertising it to E0 and E10 customers like we do other E20 features.