5c3f8b9941
* Add API functions and hooks for reading and creating the lists index
* Ensure KibanaApiError extends the Error interface
It has a name, so we should type it as such. This way, we can use it
anywhere that an Error is accepted.
* Return an Error from validationEither and thus from our useAsync hooks
Because an io-ts pipeline needs a consistent type across its left value,
and validateEither was returning a string, we were forcing all our
errors to strings. In the case of an API error, however, this meant a
loss of data, since the original error's extra fields were lost.
By returning an Error from validateEither, we can now pass through Api
errors from useAsync and thus use them directly in kibana utilities like
toasts.addError.
* WIP: implements checking for and consequent creation of lists index
This adds most of the machinery that I think we're going to need. Not
featured here:
* lists privileges (stubbed out currently)
* handling when lists is disabled
* tests
* Add frontend plugin for lists
We need this to deteremine in security_solution whether lists is enabled
or not. There's no other functionality here, just boilerplate.
* Fix cross-plugin imports/exports
Now that lists has a client plugin, the optimizer cares about code
coming into and out of it.
By default, you cannot import another plugin's common/ folder into your
own common/ nor public/ folders. This is fixed by adding 'common' to
extraPublicDirs, however: extraPublicDirs need to resolve to modules.
Rather than adding each folder from which we export modules to
extraPublicDirs, I've added common/index.ts and exporting everything
through there.
By convention, I'm adding shared_exports.ts as an index of these exported modules,
and shared_imports.ts is used to import on the other end.
For now, I've left the ad hoc _deps files so as to limit the changes
here, but we should come back through and remove them at some point. NB
that I did remove lists_common_deps as it was only used in one or two
spots.
* Fix test failing due to lack of context
This component now uses useKibana indirectly through useListsConfig.
* Lists and securitySolution require each other's bundles
Without lists being a requiredBundle of securitySolution, we cannot
import its code when the plugin is disabled. The opposite is also true,
but there's no lists "app" to break.
* Fix logic in useListsConfig
Lists needs configuration if the index explicitly does not exist. If it
is true (already exists) or null (lists is disabled or we could not read
the index), we're good.
* useList* behavior when lists plugin is disabled
When the lists plugin is disabled, our calls in useListsIndex become no-ops so that:
* useListsIndex state does not change
* useListsConfig.needsConfiguration remains false as indexExists is
never non-null
This also removes use of our `useIsMounted` hook. Since the effects
we're consuming come from useAsync hooks, state will (already) not be
updated if the component is unmounted.
* Fix warning due to dynamic creation of a styled component
* Revert "Fix warning due to dynamic creation of a styled component"
This reverts commit 7124a8fbd9.
(This was already fixed on master)
* Check user's lists index privileges when determining configuration status
If there is no lists index and the user cannot create it, we will
display a configuration message in lieu of Detections
* Adds a lists hook to read privileges (missing schemae)
* Adds security hook useListsPrivileges to perform and parse the
privileges request
* Updates useListsConfig to use useListsPrivileges hook
* Move lists hooks to their own subfolder
* Redirect to main detections page if lists needs configuration
If:
* lists are enabled, and
* lists indexes DNE, and
* user cannot manage the lists indexes
Then they will be redirected to the main detections page where they'll
be instructed to configure detections. If any of the above is false,
things work as normal.
* Lock out of detections when user cannot write to value lists
Rather than add conditional logic to all our UI components dealing with
lists, we're going the heavy-handed route for now.
* Mock lists config hook in relevant Detections page tests
* Disable Detections when Lists is enabled
This refactors useListsConfig.needsConfiguration to mean:
* lists plugin is disabled, OR
* lists indexes DNE and can't be created, OR,
* user can't write to the lists index
In any of these situations, we want to disable detections, and so we
export that as a single boolean, needsConfiguration.
* Remove unneeded complexity exception
We refactored this to work 👍
* Remove outdated TODO
We link to our documentation, which will describe the lists aspects of
configuration.
30 lines
1 KiB
TypeScript
30 lines
1 KiB
TypeScript
/*
|
|
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
|
|
* or more contributor license agreements. Licensed under the Elastic License;
|
|
* you may not use this file except in compliance with the Elastic License.
|
|
*/
|
|
|
|
import {
|
|
CoreSetup,
|
|
CoreStart,
|
|
Plugin as IPlugin,
|
|
PluginInitializerContext,
|
|
} from '../../../../src/core/public';
|
|
|
|
import { PluginSetup, PluginStart, SetupPlugins, StartPlugins } from './types';
|
|
|
|
export class Plugin implements IPlugin<PluginSetup, PluginStart, SetupPlugins, StartPlugins> {
|
|
// eslint-disable-next-line @typescript-eslint/no-unused-vars
|
|
constructor(initializerContext: PluginInitializerContext) {} // eslint-disable-line @typescript-eslint/no-useless-constructor
|
|
|
|
// eslint-disable-next-line @typescript-eslint/no-unused-vars
|
|
public setup(core: CoreSetup<StartPlugins, PluginStart>, plugins: SetupPlugins): PluginSetup {
|
|
return {};
|
|
}
|
|
|
|
// eslint-disable-next-line @typescript-eslint/no-unused-vars
|
|
public start(core: CoreStart, plugins: StartPlugins): PluginStart {
|
|
return {};
|
|
}
|
|
}
|