* Adds new SO type for persisting our signals migrations
* WIP: Migration status SO client
Trying to forge a patterrn using io-ts to validate at runtime. I think
I've got it working but I want to refactor the pipeline out into a
reusable function(s).
* Implements our SavedObjects service for signals migrations
* Defines a simple client that delegates to the base SO client with
our SO type
* Defines a service that consumes the simpler client, adding validations
and data transforms on top.
* Refactoring migration code to work with saved objects
As opposed to the previous ephemeral, encoded tokens, we now retrieve migration
info from saved objects.
At the API level, this means that both the create and finalize endpoints
receive a list of concrete indices. No more passing around tokens.
As both endpoints are idempotent, users can hammer them as much as they
want with the same lists of indices. Redundant creates and finalizes
will be met with inline 400 messages, and as one continues to poll the
finalize endpoint they should see more and more indices respond with
"completed: true"
* Fixing integration tests first, and anything upstream breaking them
* Clean up API integration tests
* standardize assignment of responses (with types)
* deletes migration SOs as test cleanup
* Split API tests into separate files
This was getting big and unwieldy; this splits these into one file per
endpoint.
* Refactor: split existing migration service functionality into atomic functions
This will allow us to repurpose the service to compose more
functionality and be more specifically useful, while keeping the
component logic separate.
* WIP: moving logic into migrationService.create
* Splitting get_migration_status into component functions
getMigrationStatus was really two separate aggregations, so I split them
out and we recompose them in the necessary routes.
* Move finalization logic into function
* migrationService exposes this as .finalize()
* adds an error field to our migration SO
* We currently only have one error that we persist there, but it would
be very time-consuming to track down that information were it not
there.
* Adds function for migration "deletion" logic
* migrationService leverages this function
* adds new boolean to our savedObject
* deletes unused function (deleteMigrationSavedObject)
* Adds route for soft-deletion of migrations
* Updating tests related to migration status
* Adding/updating mocks/unit tests necessary to satisfy the things I
need to test
* I mainly wanted to test that the the status endpoint filtered out the
deleted migrations; this was accomplished with a unit test after
fleshing out some mocks/sample data.
* Move old migration service tests to the relevant function tests
This logic was previously moved out into component functions; this moves
the tests accordingly.
* Add some unit tests around our reindex call
* Fix create migration route tests
Mocks out our migration functions, rather than stubbing ES calls
directly.
* Updates finalize route unit tests
Addresses functionality that hasn't been moved to finalizeMigration()
* Unit tests our finalization logic
Fixes a bug where we weren't accounting for soft-deleted migrations.
ALso updates our test migration SO to have a status of 'pending' as
that's a more useful default.
* Fixes finalization integration tests
These were failing due:
* a change in the migration status API response
* a bug I introduced in the finalize route
* Adds tests for our migration deletion endpoint
* unit tests
* API integration tests
* Caught/fixed bug with deleting a successful migration
* Fixes types
Removes unused code.
* Prevent race condition due to template rollover during migration
If a user has an out of date index (v1) relative to the template (v2), but the
template itself is out of date (newest is v3), then it's possible that
the template is rolled over to v3 after the v1-v2 migration has been
created but before the new index has been created.
In such a case, the new index would receive the v3 mappings but would
incorrectl be marked as v2. This shouldn't necessarily be an issue, but
it's an unnecessary state that can easily be prevented with the guard
introduced here.
* Add real usernames to migration savedObjects
In addition to the SOs themselves giving us observability into what
migration actions were performed, this gives us the additional info of
_who_ performed the action.
* Index minimal migration SO fields needed for current functionality
* Add additional migration info to status endpoint
This will allow users to finalize a migration if they've lost the
response to their POST call.
* Finalize endpoint receives an array of migration IDs, not indices
This disambiguates _which_ migrations we were finalizing if you passed
an index (which was previously: the most recent migration).
* Fix type errors in tests after we threaded through username
* Update responsibilities of migration finalize/delete endpoints
Discussions with @marshallmain lead to the following refactor:
* finalize does not delete tasks
* finalize only applies cleanup policy to a failed migration
* delete takes an array of migration ids (like finalize)
* delete hard-deletes the SavedObject of a completed (failed or
successful) migration
This gives a bit more flexibility with the endpoints, as well as
disambiguates the semantics: it just deletes migrations!
* Fix tests that were broken during refactoring
* Fix type errors
I removed some logic here but forgot the imports :(
* Move outdated integration test
In the case of a successful migration, application of the cleanup policy
is done by the deletion endpoint. In the interest of data preservation,
we do not delete a sourceIndex unless it is explicitly deleted.
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* bump version to 4.1.1-rc
* fix code to run kbn bootstrap
* fix errors
* DO NOT MERGE. mute errors and ping teams to fix them
* Address EuiSelectableProps configuration in discover sidebar
* use explicit type for EuiSelectable
* update to ts v4.1.2
* fix ts error in EuiSelectable
* update docs
* update prettier with ts version support
* Revert "update prettier with ts version support"
This reverts commit 3de48db3ec.
* address another new problem
Co-authored-by: Chandler Prall <chandler.prall@gmail.com>
* ExceptionIdentifiers -> ExceptionListIdentifiers
* Pass refreshRule through to alert context menu
* Fix type errors and rename refreshRule to onRuleChange for consistency
## Summary
This is a bug that was introduced by moi in 76537. This previous PR added a sort_field and sort_order to the call for fetching exception lists' items so that the exception item order in the viewer wouldn't jump around any time there was an update. I noticed however that when a rule had both endpoint and detection lists associated with it, when trying to fetch items from both types of lists, the following error shows:
```
"Unable to sort multiple types by field created_at, not a root property"
```
## Summary
**Components affected:** ExceptionsViewer
**Current behavior:**
- when a user edits an exception item, the order of the exception items in the viewer changes. This creates confusion and looks like updates weren't applied (even though they were, just item order changed)
**New behavior:**
- when a user edits an exception item, the order of the exception items in the viewer don't change. Sort order is now based on `created_at`
* bump ts to v4
* MOAR RAM
* fix type errors for OSS
* first pass on x-pack errors
* second pass on x-pack type errors
* 3rd pass on x-pack type-errors
* mute errors if complex cases
* don't delete if spread suffices
* mute other complex cases
* make User fields optional
* fix optional types
* fix tests
* fix typings for time_range
* fix type errors in x-pack/tests
* rebuild kbn-pm
* remove leftovers from master update
* fix alert tests
* [Telemetry Checker] TS4 Fixes
* bump to 4.0.1-rc
* fix new errors in master
* bump typescript-eslint to version supporting TS v4 syntax
* fix merge commit errors
* update to the stable TS version 4.0.2
* bump ts-eslint to version supporting ts v4
* fix typo
* fix type errors after merge
* update ts in another new package.json
* TEMP: remove me
* Revert "TEMP: remove me"
This reverts commit dc0fc3bae6.
* [Telemetry] Update snapshot for new TS4 SyntaxKind
* bump prettier to support TS v4 syntax
* fix prettier rules
* last style change
* fix new type errors
Co-authored-by: Alejandro Fernández Haro <alejandro.haro@elastic.co>
* Simplify our kibana mocks
* Simpler mock factory that returns an object instead of a thunk
* We can use mockReturnValue instead of mockImplementation to
accomplish the same
* Allows us to replace createStartServices mock
* Uses unknown instead of any for mocks
* Clean up our manual use of kibana mocks in tests
* Since our useKibana mock returns a consistent mock, we can modify its
return value instead of re-mocking the entire thing
* Removes unnecessary uses of clearing/resetting mocks
* If your mocks are configured at the beginning of each test this is
usually unnecessary.
* I left one case of clearAllMocks in all_cases/index.test since it
defined several mock functions that were persistent across tests, and
it was easier than moving their definitions to a beforeEach
* Removes some unnecessary overrides that seemed due to storage
previously not being mocked
* Rename some old occurrences of SIEM
* Cross-reference similar hooks via JSDoc
There's a good chance that the consumer might want the OTHER hook, so
let's make that discoverable.
* Adds jest tests for our useListsConfig hook
* adds mocks for the hooks upon which it depends
* Add a mock for our useListsConfig hook
Leverages this mock factory in our manual mock for this hook.
* Remove unneeded eslint exception
* Move kibana_react mocks into their own .mock file
We're trying to consolidate mocks to this pattern so that they're easier
to find and reuse.
* Remove intermediate mock factory
This was only being consumed by our general createStartServicesMock.
* Replace security_solution's alias for a core mock
This is just noise/tech debt, we should use the core mock directly when
we can.
* Remove unnecessary wrapper around core mocks
Instead let's just reference the core mocks themselves.
* Remove outdated references from upstream
* More accurate mock
Throw an error of the same type if an unexpected key is used.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Addresses feedback from https://github.com/elastic/kibana/pull/72748
- Updates `plugins/lists` tests text from `should not validate` to `should FAIL validation` after feedback that previous text is a bit confusing and can be interpreted to mean that validation is not conducted
- Remove unnecessary spreads from one of my late night PRs
- Removes `siem_common_deps` in favor of `shared_imports` in `plugins/lists`
- Updates `build_exceptions_query.test.ts` to use existing mocks
## Summary
This PR focuses on addressing issues around the pagination and functionality of rules with numerous (2+) exception lists.
- Updated the `use_exception_list.ts` hook to make use of the new multi list find API
- Updated the viewer to make use of the new multi list find API
- Previously was doing a lot of the filtering and paging manually (and badly) in the UI, now the _find takes care of all that
- Added logic for showing `No results` text if user filter/search returns no items
- Previously would show the `This rule has not exceptions` text
## Summary
This PR addresses the following:
- Adds `list_id` to `rule.exceptions_list` - this is needed in a number of features
- Updated `getExceptions` in `x-pack/plugins/security_solution/server/lib/detection_engine/signals/utils.ts` to use the latest exception item find endpoint that accepts an array of lists (previously was looping through lists and conducting a `find` for each)
- Updated prepackaged rule that makes reference to global endpoint list to include `list_id`
- Updates `formatAboutStepData` in `x-pack/plugins/security_solution/public/detections/pages/detection_engine/rules/create/helpers.ts` to include exception list `list_id`
* Refresh rule details when exception list modal modifies the rule
This addresses a bug where, when opening the exceptions modal for the first
time and creating exceptions, the details page does not reflect these
created exceptions until a full refresh.
This is due to the hook performing the refresh being dependent on the
rule's exceptions_list attribute, which is not populated until after
opening the modal. Because the UI is not informed of the rule update, it
did not know to refresh the rule.
This adds the machinery necessary to make the above work. It:
* adds a new hook for fetching/refreshing a rule
* Adds an onRuleChange callback to both the ExceptionsViewer and the
mutating AddExceptionModal
* passes the refresh function in as the onRuleChange callback
There's currently a gross intermediate state here where the loading screen is
displayed while the rule refreshes in the background; I'll be fixing
that shortly.
* Do not show loading/blank state while refreshing rule
On Rule Details, when the Add Exceptions modal creates the rule's
exception list, we refresh quietly in the background by setting our rule
from null -> ruleA -> ruleB instead of null -> ruleA -> null -> ruleB.
This also simplifies the loading logic in a few places now that we're
using our new rule: we mainly care whether or not our rule is populated.
* Display toast error if rule fetch fails
This should now have feature parity with useRule, while additionally
providing a function to refresh the rule.
* Refactor tests to leverage existing helpers
* Add return type to our callback function
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* Add loading spinners to Value Lists modal
While export or a delete is pending, we display a loading spinner
instead of the button that was clicked.
Since state is controlled in the parent, we must pass this additional
state in the same way; the table component simply reacts to this state.
* Fix bug with useAsync and multiple calls
Multiple calls to start() would not previously reset the hook's state,
where useEffect on the hook's state would fire improperly as subsequent
calls would not travel the same undefined -> result path.
* Fix style of loading spinner
This fits the size of the button it's replacing, so no shifting occurs
when replacing elements.
* Better styling of spinner
Keep it roughly the same size as the icons themselves, and fill the
space with margin.
* Fix circular dependency in value lists modal
Moves our shared types into a separate module to prevent a circular
dependency.
* Overview Alerts Histogram stacking defaults to signal.rule.name
Since this is now the default for all AlertsHistograms, I've moved this
default upstream into the histogram itself.
* Replace magic strings with our constant ENDPOINT_LIST_ID
Also replaced a few unintentional uses of this string with the
non-reserved 'endpoint_list_id'.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* Add Frontend components for Value Lists Management Modal
Imports and uses the hooks provided by the lists plugin. Tests coming
next.
* Update value list components to use newest Lists API
* uses useEffect on a task's state instead of promise chaining
* handles the fact that API calls can be rejected with strings
* uses exportList function instead of hook
* Close modal on outside click
* Add hook for using a cursor with paged API calls.
For e.g. findLists, we can send along a cursor to optimize our query. On
the backend, this cursor is used as part of a search_after query.
* Better implementation of useCursor
* Does not require args for setCursor as they're already passed to the
hook
* Finds nearest cursor for the same page size
Eventually this logic will also include sortField as part of the
hash/lookup, but we do not currently use that on the frontend.
* Fixes useCursor hook functionality
We were previously storing the cursor on the _current_ page, when it's
only truly valid for the _next_ page (and beyond).
This was causing a few issues, but now that it's fixed everything works
great.
* Add cursor to lists query
This allows us to search_after a previous page's search, if available.
* Do not validate response of export
This is just a blob, so we have nothing to validate.
* Fix double callback post-import
After uploading a list, the modal was being shown twice. Declaring the
constituent state dependencies separately fixed the issue.
* Update ValueListsForm to manually abort import request
These hooks no longer care about/expose an abort function. In this one
case where we need that functionality, we can do it ourselves relatively
simply.
* Default modal table to five rows
* Update translation keys following plugin rename
* Try to fit table contents on a single row
Dates were wrapping (and raw), and so were wrapped in a FormattedDate
component. However, since this component didn't wrap, we needed to
shrink/truncate the uploaded_by field as well as allow the fileName to
truncate.
* Add helper function to prevent tests from logging errors
https://github.com/enzymejs/enzyme/issues/2073 seems to be an ongoing
issue, and causes components with useEffect to update after the test is
completed.
waitForUpdates ensures that updates have completed within an act()
before continuing on.
* Add jest tests for our form, table, and modal components
* Fix translation conflict
* Add more waitForUpdates to new overview page tests
Each of these logs a console.error without them.
* Fix bad merge resolution
That resulted in duplicate exports.
* Make cursor an optional parameter to findLists
This param is an optimization and not required for basic functionality.
* Tweaking Table column sizes
Makes actions column smaller, leaving more room for everything else.
* Fix bug where onSuccess is called upon pagination change
Because fetchLists changes when pagination does, and handleUploadSuccess
changes with fetchLists, our useEffect in Form was being fired on every
pagination change due to its onSuccess changing.
The solution in this instance is to remove fetchLists from
handleUploadSuccess's dependencies, as we merely want to invoke
fetchLists from it, not change our reference.
* Fix failing test
It looks like this broke because EuiTable's pagination changed from a
button to an anchor tag.
* Hide page size options on ValueLists modal table
These have style issues, and anything above 5 rows causes the modal to
scroll, so we're going to disable it for now.
* Update error callbacks now that we have Errors
We don't display the nice errors in the case of an ApiError right now,
but this is better than it was.
* Synchronize delete with the subsequent fetch
Our start() no longer resolves in a meaningful way, so we instead need
to perform the refetch in an effect watching the result of our delete.
* Cast our unknown error to an Error
useAsync generally does not know how what its tasks are going to be
rejected with, hence the unknown.
For these API calls we know that it will be an Error, but I don't
currently have a way to type that generally. For now, we'll cast it
where we use it.
* Import lists code from our new, standardized modules
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* 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.
* adds 2 menu items to alert page, progress on exception modal
* adds enriching
* remove unused useExceptionList()
* implements some types
* move add exception modal files
* Exception builder changes to support latest schema
* Changes to lists plugin schemas and fix api bug
Needed to make the schemas more forgiving. Before this change they required name,
description, etc for creation and update.
The update item API was using the wrong url.
* Adding and editing exceptions working
- Modifies add_exception_modal component
- Creates edit_exception_modal component
- Creates shared comments component
- Creates use_add_exception api hook for adding or editing exceptions
- Updates viewer code to support adding and editing exceptions
- Updates alerts table code to use updated version of add_exception_modal
* fixes duplicate types
* updates os tag input
* fixes comment style
* removes checkbox programatically
* grahpql updates to expose exceptions_list
* Add fetch_or_create_exception_list hook
* fixes data population
* refactor use_add_exception hook, add tests
* fix rebase issues, pending updates to edit modal
* fix edit modal and default endpoint exceptions
* adds second checkbox
* adds signal index stuff
* switches boolean logic
* fix some type errors
* remove unnecesary code
* fixes checkbox logic in edit modal
* fixes recursive prop passing
* addresses comments/fixes types
* Revert schema type changes
* type fixes
* fixes regular exception modal
* fix more type errors, remove console log
* fix tests
* move add exception hook, lint
* close alert checkbox closes alert
* address PR comments
* add type to patch rule call, fix ts errors
* fix lint
* fix merge problems after conflict
* Address PR comments
* undo graphql type change
Co-authored-by: Davis Plumlee <davis.plumlee@elastic.co>
## Summary
This PR tries to start to tie together the server and client changes for exceptions lists.
- Updates graphql types to allow UI access to a rule's `exceptions_list` property
- Updates the exception viewer component to now dynamically take the rule `exceptions_list`, up until now we just had an empty array in it's place
- Updates the viewer logic to check if a rule has an endpoint list associated with it. If it does, then it displays both detections and endpoint UIs (in the viewer), if it does not, then it only displays the detections UI
- Updates the viewer UI to better deal with spacing when an exception list item only has one or two entries (before the and badge with the antennas was stretching passed the exception items to fill the space)
- Updates the detections engine exceptions logic to fetch list items using an exception list's `id` as opposed to it's `list_id`, this now aligns with the UI using the same params on its end
- Adds exception list `type` to information kept by the rule for exception lists
- Updates the exception list type from `string` to `endpoint | detection`
- Updates the exception list _item_ type from `string` to `simple`
- Adds unit tests for the detection engine server side util that fetches the exception list items
### Summary
This PR creates the bulk functionality of the exception builder. The exception builder is the component that will be used to create exception list items. It does not deal with the actual API creation/deletion/update of exceptions, it does contain an `onChange` handler that can be used to access the exceptions. The builder is able to:
- accept `ExceptionListItem` and render them correctly
- allow user to add exception list item and exception list item entries
- accept an `indexPattern` and use it to fetch relevant field and autocomplete field values
- disable `Or` button if user is only allowed to edit/add to exception list item (not add additional exception list items)
- displays `Add new exception` button if no exception items exist
- An exception item can be created without entries, the `add new exception` button will show in the case that an exception list contains exception list item(s) with an empty `entries` array (as long as there is one exception list item with an item in `entries`, button does not show)
- debounces field value autocomplete searches
- bubble up exceptions to parent component, stripping out any empty entries
* Add wrapper function to make an AbortSignal arg optional
Components commonly do not care about aborting a request, but are
required to pass `{ signal: new AbortController().signal }` anyway. This
addresses that use case.
* Adds hook for retrieving the component's mount status
This is useful for dealing with asynchronous tasks that may complete
after the invoking component has been unmounted. Using this hook,
callbacks can determine whether they're currently unmounted, i.e.
whether it's safe to set state or not.
* Add our own implemetation of useAsync
This does not suffer from the Typescript issues that the react-use
implementation had, and is generally a cleaner hook than useAsyncTask as
it makes no assumptions about the underlying function.
* Update exported Lists API hooks to use useAsync and withOptionalSignal
Removes the now-unused useAsyncTask as well.
* Add some JSDoc for our new functions
* Add pure API functions and react hooks for value list APIs
This also adds a generic hook, useAsyncTask, that wraps an async
function to provide basic utilities:
* loading state
* error state
* abort/cancel function
* Fix type errors in hook tests
These were not caught locally as I was accidentally running typescript
without the full project.
* Document current limitations of useAsyncTask
* Defines a new validation function that returns an Either instead of a tuple
This allows callers to further leverage fp-ts functions as needed.
* Remove duplicated copyright comment
* WIP: Perform request/response validations in the FP style
* leverages new validateEither fn which returns an Either
* constructs a pipeline that:
* validates the payload
* performs the API call
* validates the response
and short-circuits if any of those produce a Left value.
It then converts the Either into a promise that either rejects with the
Left or resolves with the Right.
* Adds helper function to convert a TaskEither back to a Promise
This cleans up our validation pipeline considerably.
* Adds request/response validations to findLists
* refactors private API functions to accept the encoded request schema
(i.e. snake cased)
* refactors validateEither to use `schema.validate` instead of
`schema.decode` since we don't actually want the decoded value, we just
want to verify that it'll be able to be decoded on the backend.
* Refactor our API types
* Add request/response validation to import/export functions
* Fix type errors
* Continue to export decoded types without a qualifier
* pull types used by hooks from their new location
* Fix errors with usage of act()
* Attempting to reduce plugin bundle size
By pulling from the module directly instead of an index, we can
hopefully narrow down our dependencies until tree-shaking does this for
us.
* useAsyncFn's initiator does not return a promise
Rather than returning a promise and requiring the caller to handle a
rejection, we instead return nothing and require the user to watch the
hook's state.
* success can be handled with a useEffect on state.result
* errors can be handled with a useEffect on state.error
* Fix failing test
Assertion count wasn't updated following interface changes; we've now
got two inline expectations so this isn't needed.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
### Summary
This PR is a follow up to #68864 . That PR used a partial to differentiate between new and existing comments, this meant that comments could be updated when they shouldn't. It was decided in our discussion of exception list schemas that comments should be append only. This PR assures that's the case, but also leaves it open to editing comments (via API). It checks to make sure that users can only update their own comments.
### Summary
This PR is meant to update the `ExceptionListItemSchema.entries` structure to align with the most recent conversations regarding the need for a more explicit depiction of `nested` fields. To summarize:
- Adds schema validation for requests and responses within `lists/public/exceptions/api.ts`. It was super helpful in catching existing bugs. Anyone that uses the api will run through this validation. If the client tries to send up a malformed request, the request will not be made and an error returned. If the request is successful, but somehow the response is malformed, an error is returned. There may be some UX things to figure out about how to best communicate these errors to the user, or if surfacing the raw error is fine.
- Updates `entries` structure in lists plugin api
- Updates hooks and tests within `lists/public` that make reference to new structure
- Updates and adds unit tests for updated schemas
- Removes unused temporary types in `security_solution/public/common/components/exceptions/` to now reference updated schema
- Updates UI tests
- Updates `lists/server/scripts`
* add babel support for export type
* bump ts version to 3.9.3
* rebuild kbn-pm
* bump typescript-eslint
* fix error in security plugin UI
* check export as works
* fix app migration type
* use correct test subj attribute
* fix errors from the old PR
* embeddable is already passed in props
* explicitly define type of fetch
* add some types for viz
* fix fetch type p.2
* add null to allow spreading without type errors due to override
* add type guard to fix type error
* cast to any, since cannot assign unknown
* add timestamp to known types
* fix type error in fetch
* fix type error. id is always defined in attibutes
* declare a type
* move ts-ignore to the lines with errors
* declare tuple type explicitly
* mute type error. cannot assign unknown
* fix errors. id is always defined
* fix error type
* fix override errors. id is always defined
* fix error. extends any doesn't work anymore
* fix type error. type is always defined
* env doesn't always contain values
* fix type error
* cast to string
* add: logs is already declared in getNodeLogsUrl
* state is already passed in props
* fix some errors in timelion
* number of fragments is always defined
* 'absolute' is not just string, but value
* TEMP: option is always defined
* always true if cast to promise manually
* both props are always defined
* explicitly define returned SO type
* workaround type
* bump tslib to be compatible with ts v3.9
* test private property
* rebuild kbn-pm
* Fix ts errors for beats management
* Fix type inference broken by the TS 3.9 upgrade
* Fix ingest manager saved object attributes typings
* Fix TS errors in cross_cluster_replication and index_management.
* Fix TS error in Watcher.
* roll back colorRange wrong type
* fix security plugin types
* TypeScript 3.9 fixes for APM
* Fix ColorRange types.
* fix actions & alerts errors. ByGidi
* fix lists error
* More APM fixes
* Remove paramaterization from `removeEmpty in agent config SettingsPage component (it's only used there and doesn't need to be parameterized.)
* Add option chain for case in registerTransactionDurationAlertType
* Cast `overallValue` in transform_metrics_chart
* Use more specific type for custom link filters
* Add more option chaining for local UI filters buckets response
* Remove unused parameters from routes
* Fix getProjection type parameter
* Use destructuring in serviceNodesLocalFiltersRoute to hide `never` error
* Revert `UnionToIntersection` change in `AggregationResponseMap`
Fixes#67804.
* fix platform type error
* Fix visualizations types.
* Fix data plugin types.
* bump TS version to 3.9.5
* Fix telemetry TS errors
* Fix dashboard code
* Adding Canvas Fixes for TS 3.9
* Fix case and security_solution types
* roll back to the old export syntax. new one might cause problems in api-extractor
* update docs
* Fix timelion code
* Fix meta
* Fix types
* fix type errors om ingest_manager
* bump babel deps
* enable private props & methods syntax
* update kbn-pm dist
* whitelist 0BSD license
* use @babel/plugin-proposal-private-methods in default set as well
* disable new babel plugins
* Revert "disable new babel plugins"
This reverts commit 04d959431d.
* cleanup security_solution types
* Fixes type error for newer TypeScript
* update docs
Co-authored-by: Nicolas Chaulet <nicolas.chaulet@elastic.co>
Co-authored-by: Felix Stürmer <stuermer@weltenwort.de>
Co-authored-by: CJ Cenizal <cj@cenizal.com>
Co-authored-by: Larry Gregory <larry.gregory@elastic.co>
Co-authored-by: Nathan L Smith <smith@nlsmith.com>
Co-authored-by: Walter Rafelsberger <walter@elastic.co>
Co-authored-by: Luke Elmers <luke.elmers@elastic.co>
Co-authored-by: Alejandro Fernández Haro <alejandro.haro@elastic.co>
Co-authored-by: Tim Roes <tim.roes@elastic.co>
Co-authored-by: Clint Andrew Hall <clint.hall@elastic.co>
Co-authored-by: Patryk Kopycinski <contact@patrykkopycinski.com>
Co-authored-by: FrankHassanabad <frank.hassanabad@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
### Summary
- Adds missing unit tests for relevant files missing them
- Changes filter search to fire request on 'Enter'
- Breaks out the main ExceptionViewer component into smaller components to make more readable and better tested
- Updates utility bar to have the specific list description text next to it as proposed by @spong in #68294 (comment)
- Adds loading state any time async request occurs
- Now fetches list on list type toggle (if user selects to view either only detections or endpoint items), before was simply filtering already fetched items
### Summary
This PR is a follow up to #68027 . It brings it all together to complete the exceptions viewer component. This component is meant to display all exception items and allow a user to create, edit, delete, and search these exception items.
- Moves ExceptionItem (from part 1) into its own folder
- Adds exceptions_viewer_header component that includes the search, list toggle, and add exception buttons
- Adds actual ExceptionViewer component
- Updates the useExceptionList hook refresh function logic. Noticed that the previous version was creating some issues
### Summary
- Updates exception list hooks to include filtering options and updates corresponding unit tests.
- Adds refreshList callback to hook that fetches the list and its items
- Updates hooks tests to test onError callback
- Updates tests to use type checking more effectively per feedback from @FrankHassanabad (thanks!)
## Summary
Adds the REST and API routes for find and filter for exception lists and value lists
* Fixes bugs with string parameters for the _find with exception lists
* Adds the _find for the value based lists
* More scripts for how to filter things for both list values and exception lists
* Misc type script fixes
* Adds a cursor to move from the previous page to the next page
* Adds name space 'agnostic' vs. 'single' feature for exception_lists
**REST API's:**
```ts
POST /api/lists/_find
POST /api/lists/items/_find
POST /api/exception_lists/_find
POST /api/exception_lists/items/_find
```
**Parameters you can send:**
* sort
* sort_order
* filter
* page
* per_page
* list_id (for list items only and required)
* cursor (for finding the next page or advancing to deep pages)
**See test scripts below:**
```sh
find_exception_list_items_by_filter.sh
find_exception_lists_by_filter.sh
find_list_items.sh
find_list_items_with_cursor.sh
find_list_items_with_sort.sh
find_list_items_with_sort_cursor.sh
find_lists.sh
find_lists_with_cursor.sh
find_lists_with_filter.sh
find_lists_with_sort.sh
find_lists_with_sort_cursor.sh
```
### Checklist
Note: Unit tests are left out as this is blocking people but I will be adding tests as this is being reviewed unless someone needs these features now. This is still all behind a feature flag and considered to be in the area of proof of concept and not production ready until more tests and end to tests are added.
- [ ] [Unit or functional tests](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#cross-browser-compatibility) were updated or added to match the most common scenarios
Added some basic functionality to help exception list UI work move forward. Wired up to exception list api and created hooks. This PR includes:
- UI api functions for basic exception list and exception list item CRUD
- useExceptionList hook to fetch the list and its items
- usePersistExceptionList hook to create or update an exception list
- usePersistExceptionListItem hook to create or update an exception item
- list_plugin_deps.tsx in the siem folder to import the lists plugin hooks
