[Licensing] Enabling and disabling functionality based on current license in `public`

[jloleysens]

The idea

Currently setting up plugins that depend on a valid license being present (like Watcher) face some challenges on the public side in particular:

1. We do not always know license at setup time and must assume it is unknown (there is no license if it hasn't been set in session storage). Plugins must therefore register against dependencies (like ES management section), immediately disable and then re-enable once we receive a valid license post-setup time.
2. In Watcher's case specifically we can disable ES section through it's public API, but not home.

The following actions could be taken to address the above points, respectively:

1. Given [RFC][skip-ci] Prevent plugins from blocking Kibana startup #45796 (comment) setup logic of plugins that expose/hide functionality based on licenses can be simplified if we know an initial license value at setup time. Plugins should still receive an observable against which they can respond for subsequent license values.
   2. Home plugin could be updated to allow for enabling and disabling registered apps.

[UPDATE]

Created a separate issue for (2) here #57184

CC @restrry @rudolf

Additional information

Watcher setup PR: #55831

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[mshustov]

Plugins must therefore register against dependencies (like ES management section), immediately disable

Yes, plugin registration and status calculation operations should be separated.

Home plugin could be updated to allow for enabling and disabling registered apps.

👍 Is there an issue created ?

Given #45796 (comment) setup logic of plugins that expose/hide functionality based on licenses can be simplified if we know an initial license value at setup time.

Agree, the licensing plugin can inject initial data to avoid flakiness and simplify the initial setup.
Blocked by #52553.
Also we can get rid of putting data in the sessionStorage.

[joshdover]

Yes, plugin registration and status calculation operations should be separated.

+1 to this. Licensing can change at any point in time, so even having the license at setup time does not fully solve the issue.

Management sections and the feature catalogue should introduce an API similar to the ApplicationService's appUpdater$ API that allows an application to update it's availability status based on changing things in the system.

@mattkime @flash1293 Are there open issues for adding this kind of API to these plugins?

[flash1293]

@joshdover I don't know about any for feature catalogue, will create one. Once we are at it, we should introduce the same for sample data adjustments, I recently had this problem with Graph sample data.

[sebelga]

Management sections and the feature catalogue should introduce an API similar to the ApplicationService's appUpdater$ API that allows an application to update it's availability status based on changing things in the system.

I also agree that relying on an object mutability to enable or not an app can quickly break

// Create a ref
const watcherHome = {
  id: 'watcher',
  showOnHomePage: true,
  ...
};

home.featureCatalogue.register(watcherHome); // registering that object

licensing.license$.pipe(first(), map(licenseToLicenseStatus)).subscribe(({ valid }) => {
  if (valid) {
    watcherESApp.enable();
    watcherHome.showOnHomePage = true;
  } else {
    watcherESApp.disable();
    watcherHome.showOnHomePage = false; // hoping that the ref is still good
  }
});

[jloleysens]

PSA; We are currently migrating another plugin that is running into a license check issue using my sub-optimal workaround: #56781

@sebelga FWIW, that behaviour should be changed to a slightly safer version like here: https://github.com/elastic/kibana/pull/56393/files

We just disable by default initially, then still hope the value is passed by ref (which is still the hack).

[pgayvallet]

The discussions are outdated, I will close this for now. Feel free to reopen with more recent requierements if this is still a problem for some use cases