Integrate Licensing & Feature Controls with ApplicationService

[joshdover]

There are 3 different cases when an application should be disabled or hidden from the UI:

• The user does not have the privileges via Feature Controls (aka uiCapabilities)
• The Elasticsearch cluster does not have the appropriate license
• The Kibana configuration has disabled the UI for a given application, but not the entire plugin (eg. timelion.ui.enabled).

In the Legacy Platform we have a few different mechanisms for controlling which apps are shown & allowed.

• Some apps are disabled using a uiExport hack that calls chrome.navLinks.update() to disable a navlink based on some of the conditions listed above. Each app has to do this separately and the implementations are not consistent.
• Feature controls filter out applications by toggling the appropriate navLink item in uiCapabilities.

The ApplicationService should expose a function that allows other systems to register an Observable of filtering functions that can be used to disable and hide applications. This would allow the Licensing and Feature Control plugins to extend the ApplicationService with this knowledge in a single place, rather than each plugin defining this logic.

Example API

type AppFilter = (app: App) => {
  visible: boolean;
  enabled: boolean;
}

interface ApplicationSetup {
  registerAppFilter(filter$: Observable<AppFilter>): void;
}

// Example usage inside the licensing plugin
core.application.registerAppFilter(
  license$.pipe(
    map(license => (app: App) => ({
      visible: license.get(`features.${app.id}.showAppLink`),
      enabled: license.get(`features.${app.id}.enableAppLink`),
    })
  )
)

[elasticmachine]

Pinging @elastic/kibana-platform

[pgayvallet]

The NP api currently have a strong 1-1 binding between App and NavLink, as aNavLink elements are directly generated from the new App properties.

In legacy, applications and navlinks are two distinct and dissociated concept, as plugins register them separately.

I lack the context of this decision, so I have to ask: what this something we already decided on ?

If I take the exemple of the legacy kibana plugin:

 uiExports: {
      [...]
      app: {
        id: 'kibana',
        title: 'Kibana',
        listed: false,
        main: 'plugins/kibana/kibana',
      },
      links: [
        {
          id: 'kibana:discover',
          title: i18n.translate('kbn.discoverTitle', {
            defaultMessage: 'Discover',
          }),
          order: -1003,
          url: `${kbnBaseUrl}#/discover`,
          euiIconType: 'discoverApp',
        },
        {
          id: 'kibana:visualize',
          title: i18n.translate('kbn.visualizeTitle', {
            defaultMessage: 'Visualize',
          }),
          order: -1002,
          url: `${kbnBaseUrl}#/visualize`,
          euiIconType: 'visualizeApp',
        },
        {
          id: 'kibana:dev_tools',
          title: i18n.translate('kbn.devToolsTitle', {
            defaultMessage: 'Dev Tools',
          }),
          order: 9001,
          url: '/app/kibana#/dev_tools',
          euiIconType: 'devToolsApp',
        },
        [...]
      ],

How would this be migrated to NP ? Will every link become an actual App in NP ?

[rudolf]

How would this be migrated to NP ? Will every link become an actual App in NP ?

Yes. We will also add "standalone applications" #41981 these are registered apps that don't add a NavLink.

[pgayvallet]

So basically today, we have two kind of apps (apps, not plugins):

• normal apps that are displayed in the navigation by default
• standalone apps that are all hidden from navigation and cannot do otherwise. (in [new-platform] Add support for chromeless applications #41981)

Regarding the normal applications, the ones that needs to be disabled for various reasons are doing it in two distinct ways:

• Changing the navlink hidden property to true, therefor hiding it from the navigation
• Changing the navlink disabled property to true, therefor keeping the navlink, but making it disabled and non-clickable.

The latest is currently only used in two plugins:

• graph
• ml

I was thinking about removing the capability to keep a disabled navlink, However, after speaking with @timroes and @flash1293 , the use case (at least for graph, but probably also for ml) is the following:

Graph has this logic for showing/disabling the graph app: x-pack/legacy/plugins/graph/server/lib/check_license.js
The gist is that the app is still shown in the sidebar but marked as disabled in case the user has a license including graph which is just expired. This makes sense because Graph isn't shown at all in the side bar for other license levels and the user might be confused why the app disappears if the license expires.
So it's about to avoid this scenario:
• User uses Graph and is happy
• License expires
• User logs in and the Graph app is missing from the menu, no other explanation
• User doesn't realize it's because of the expired license and thinks Kibana is broken.

So, basically this seems to be a way to disable the application but to keep the link to not disturb the user in case of expired license.

So we seems to have 3 possible states for the application:

• enabled (default behaviour)
• disabled (app is basically disabled, not accessible and without an icon in nav)
• expired, which is the special case I talked about previously, with the app being disabled, but the icon present but non-clickable (just here for the tooltip message on it)

So I'm think about two options here for the filter:

1/

type AppFilter = (app: App) => 'enabled' | 'disabled' | 'expired';

or

2/

type AppState =  'enabled' | 'disabled' | 'expired';
type NavlinkState = 'visible' | 'hidden' | 'inactive'; // inactive to not misinterpret with 'disabled'
type AppFilter = (app: App) => AppState | {
  app:  AppState;
  navlink: NavlinkState
}

In that scenario, we allow the filter function to be able to either return

• only an AppState status. in that case, the equivalent NavlinkState is a simple mapping (enabled->visible, disabled->hidden)
• a structure containing both AppState and NavlinkState to have more finely grained configuration options

The second one seems more generic, however I'm not sure we want to manage some combination (app=disabled + navlink=visible for exemple) and I don't see any pro for it, so I'm leaning to solution 1/

The other question I have is regarding the navlink tooltip in case of expired app.

Currently in graph, this is what is done:

const navLinkUpdates = {};
navLinkUpdates.hidden = true;
const showAppLink = xpackInfo.get('features.graph.showAppLink', false);
navLinkUpdates.hidden = !showAppLink;
if (showAppLink) {
  navLinkUpdates.disabled = !xpackInfo.get('features.graph.enableAppLink', false);
  navLinkUpdates.tooltip = xpackInfo.get('features.graph.message');
}

npStart.core.chrome.navLinks.update('graph', navLinkUpdates);

When the app should be in the new expired state, there is also a need to change the tooltip for the disabled version of it. However, with current proposal, this would needs to be done as a separate operation using the AppBase.tooltip$ property.

Issue is, if we plan at some point to centralise the app disabling logic (tolicensing and/or security probably), with current API, they will not be able to change the tooltip when setting an application state to expired, and I'm not sure how to to address that.

• Maybe we should go back on the observable tooltip (which is currently not working anyway) and allow the AppFilter to return a tooltip ?
• Or maybe (simpler, not sure if acceptable) simply display a generic tooltip when the application is expired, such as License for this (feature/app/plugin?) is expired, [...] ?

WDYT ?

[joshdover]

Option 1/ makes sense to me, though maybe we should make the states more generic to fit better in the OSS use case. I don't think expired quite makes sense as it reflects our expected consumer rather than the behavior of the AppService. Maybe these should be the names of the states:

type AppFilter = (app: App) =>
  'accessible' |
  'inaccessibleWithoutNavlink' |
  'inaccessibleWithDisabledNavlink';

With standalone/hidden apps just ignore AppFilters completely, correct? In other words, being a hidden app is an immutable property that overrides the AppFilter behavior.

---

• Maybe we should go back on the observable tooltip (which is currently not working anyway) and allow the AppFilter to return a tooltip ?
• Or maybe (simpler, not sure if acceptable) simply display a generic tooltip when the application is expired, such as License for this (feature/app/plugin?) is expired, [...] ?

I think this depends on the names of the states. If we go with expired then I think a generic tooltip would be fine, however if we use the names I suggested above, I don't think we can use a generic tooltip.

If we need to allow custom tooltips, maybe the name AppFilters isn't quite right since these functions are doing more than just offering a filter. Maybe instead we should be calling this concept "app status" or something similarly generic. We may find other similar use cases in the future that we could easily extend this API to support, without introducing breaking changes.

[pgayvallet]

The OSS argument is a good point, however I'm not a big fan of over-long-and-complicated-name-when-not-absolute-necessity.

Maybe

type AppFilter = (app: App) =>
  'accessible' |
  'inaccessible' |
  'inaccessibleWithDisabledNavlink';

Is acceptable as it should be quite clear that the behaviour for inaccessible should be to hide the navigation links (and also properly documented) ?

With standalone/hidden apps just ignore AppFilters completely, correct? In other words, being a hidden app is an immutable property that overrides the AppFilter behavior.

For standalone apps I would say yes, as long as we are sure we will never want to be able to disable one ?

If we need to allow custom tooltips, maybe the name AppFilters isn't quite right since these functions are doing more than just offering a filter. Maybe instead we should be calling this concept "app status" or something similarly generic. We may find other similar use cases in the future that we could easily extend this API to support, without introducing breaking changes.

We are going closer to the existing ChromeNavLinkUpdateableFields by doing that, but I agree that's probably safer and more futur-proof as we don't have a precise vision of all the fields we want to support. Also updating the actual App instead of the associated NavLink is definitely what we want to do.

So something like type AppStatusUpdater = (App) => Partial<AppStatusFields> seems like a good approach, and it will be easy to add new fields to it if required later in time.

[pgayvallet]

So now the current proposal is something like this:

type AppStatus = 'accessible' | 'inaccessible' | 'inaccessibleWithDisabledNavlink';

type AppStatusFields = Pick<AppBase, 'status' | 'tooltip'>

type AppStatusUpdater = (app: AppBase) => Partial<AppStatusFields> | undefined;

interface ApplicationSetup {
  [...]
  registerAppStatusUpdater(statusUpdater$: Observable<AppStatusUpdater>): void;
}

[joshdover]

Also updating the actual App instead of the associated NavLink is definitely what we want to do.

Absolutely, because these options should not just affect the Chrome UI but also the ApplicationService router.

[joshdover]

You may want to define these values as an integer enum, where the greater value (least permissive option) takes precedence over lower values. This is important since multiple AppStatusUpdaters may be registered at once.

enum AppStatus {
  accessible = 0,
  inaccessibleWithDisabledNavLink = 1,
  inaccessible = 2,
}

If one updater returns accessible and another returns inaccessibleWithDisabledNavLink, the greater of the two (inaccessibleWithDisabledNavLink) will be the final computed value.