Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jloleysens opened this issue Jan 27, 2020 · 7 comments
Labels
discuss enhancement New value added to drive a business result Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@jloleysens
Copy link
Contributor

jloleysens commented Jan 27, 2020

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

@mshustov mshustov added the Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc label Jan 28, 2020
@elasticmachine
Copy link
Contributor

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

@mshustov
Copy link
Contributor

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
Copy link
Contributor

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?

@mshustov mshustov added the enhancement New value added to drive a business result label Jan 28, 2020
@flash1293
Copy link
Contributor

@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
Copy link
Contributor

sebelga commented Feb 5, 2020

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
Copy link
Contributor Author

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss enhancement New value added to drive a business result Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
Status: Done (7.13)
Development

No branches or pull requests

7 participants