[Endpoint] Basic Functionality Alert List #55800
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dplumlee
added
WIP
peluja1012
force-pushed
the
basic-alert-list
branch
from
d61ee4d
to
62d158b
Compare
peluja1012
reviewed
Jan 24, 2020
| @@ -0,0 +1,36 @@ | |||
| /* | |||
There was a problem hiding this comment.
Added a types file at the top level so that certain types can be shared between the FE and the BE. Also, I think we should try to keep all types in one file. When trying to determine the type of a variable, it's much easier when there is a single place where all type definitions live. If the file becomes too big and hard to manage, we could revisit and make adjustments. Thoughts @oatkiller @kevinlog @paul-tavares @parkiino?
There was a problem hiding this comment.
I also like this approach (share of types between BE/FE) and came across this need when I pushed through the Saga stuff (I had an API call there for Endpoint List data). @nnamdifrankie has a pending PR to do the same as this - create a top-level types that can be shared across - see: #54772
In that PR, he created a file plugins/endpoint/common/types.ts, which personally (having the common dir) I like better because we might have more than just types in the future that we may want to share between BE/FE. You and Franklin should sync up this in order to avoid duplication/confusion.
There was a problem hiding this comment.
One place seems okay for now. Makes sense to me to break it out when the need arises
There was a problem hiding this comment.
i've been using 1 file for all types Resolver. It's a great file to read if you want to understand everything that's being modeled by Resolver. If a module creates a type for private use, I would consider leaving that in the module itself.
Having few types makes your system easy to understand I think.
peluja1012
reviewed
Jan 24, 2020
| @@ -0,0 +1,11 @@ | |||
| /* | |||
There was a problem hiding this comment.
The types in this file would move the main types file at the top level.
There was a problem hiding this comment.
On the topic of "top level types" and given my prior comment re: PR #54772 - These types here (and in store/endpoint_list/ ) are likely not to be needed by BE. Should we instead create a under plugin/endpoint/public/types.ts and place all FE specific types there? (and use /plugin/endpoint/common/types.ts for those shared across BE/FE?
There was a problem hiding this comment.
@paul-tavares Moved the types to common/types.ts
peluja1012
reviewed
Jan 24, 2020
| @@ -0,0 +1,23 @@ | |||
| /* | |||
There was a problem hiding this comment.
We are using a simple middleware to handle side-effects here, as opposed to using oatSaga. The idea is that we shouldn't overcomplicate the app from the start. oatSaga, though simpler than redux-saga, still has a fair amount of complexity in its usage. There is no need to have this complexity now, though over time we may feel like adding some more functionality. The other supporting argument to using this simpler approach is that newcomers to the team will most likely be familiar with Redux and the basic concepts of middlewares, but they won't know about oatSaga. Thoughts @oatkiller @kevinlog @paul-tavares @parkiino.
There was a problem hiding this comment.
I'm good with this approach as well - much simpler
There was a problem hiding this comment.
seems like oatsaga has more adoption
There was a problem hiding this comment.
@peluja1012 what are some of the main differences here? It looks like we're still using appSagaFactory below which, as far as I can tell uses the existing createSagaMiddleware. Is the plan to drop some of the other functionality from https://github.com/elastic/kibana/blob/master/x-pack/plugins/endpoint/public/applications/endpoint/lib/saga.ts ?
Let me know what I'm missing @oatkiller @paul-tavares @parkiino
I'm all for simplicity, just wanna better understand what we're proposing that we remove.
There was a problem hiding this comment.
I don't think we're proposing to remove anything. Just that the alerting feature will (initially anyway) forgo lib/saga and instead just make its simple middleware: https://github.com/elastic/kibana/blob/62d158b6894f185145077c61e358f61db4566628/x-pack/plugins/endpoint/public/applications/endpoint/store/alerts/middleware.ts#L16
The logic consists of:
- call the next middleware
- Check if the action is a certain action (page loaded)
- if so, make an http request and dispatch an action when thats done.
Redux middleware, by default, provides the ability to run code on each action. lib/saga's main addition to that is to provide the stream of actions as an async generator.
peluja1012
reviewed
Jan 24, 2020
| @@ -0,0 +1,20 @@ | |||
| /* | |||
There was a problem hiding this comment.
In the past, we relied on react-router to tell us when a user entered a page and we would then fire an action to let the app know about this navigation. The approach below is simpler. We use a hook that is meant to be called from our app's main pages or containers. When the user navigates to these pages, the hook will run and will dispatch a userNavigatedToPage action. Our middleware can then listen for this action and perform side-effects like API calls. Thoughts @oatkiller @kevinlog @paul-tavares @parkiino?
There was a problem hiding this comment.
ya let's keep it simple. We could end up only having 2 pages (or less) for a long time.
There was a problem hiding this comment.
I'm ok with this approach as well.
We should also have a store action that indicates a user has left the page (userNavigatedAwayFrompage) so that proper clean up (ex. reset store namespace to clean out data loaded in memory).
peluja1012
reviewed
Jan 24, 2020
| import { usePageId } from '../use_page_id'; | ||
|
|
||
| export const AlertIndex = memo(() => { | ||
| usePageId('alertsPage'); |
There was a problem hiding this comment.
This is where we call the usePageId hook, which will dispatch a userNavigatedToPage action.
oatkiller
reviewed
Jan 24, 2020
|
|
||
| export const alertMiddlewareFactory: ( | ||
| coreStart: CoreStart | ||
| ) => Middleware<{}, GlobalState, Dispatch<AppAction>> = coreStart => { |
There was a problem hiding this comment.
Might be worth using a more strict type here.
oatkiller
reviewed
Jan 24, 2020
| import { AlertData } from '../../../../../endpoint_app_types'; | ||
|
|
||
| export interface AlertListState { | ||
| alerts: AlertData[]; |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
oatkiller
reviewed
Jan 24, 2020
| hostname: string; | ||
| ip: string; | ||
| os: { | ||
| name: string; // TODO Union types? |
There was a problem hiding this comment.
Could you remove the TODO here and use github issue tracking instead?
| @@ -0,0 +1,36 @@ | |||
| /* | |||
There was a problem hiding this comment.
I also like this approach (share of types between BE/FE) and came across this need when I pushed through the Saga stuff (I had an API call there for Endpoint List data). @nnamdifrankie has a pending PR to do the same as this - create a top-level types that can be shared across - see: #54772
In that PR, he created a file plugins/endpoint/common/types.ts, which personally (having the common dir) I like better because we might have more than just types in the future that we may want to share between BE/FE. You and Franklin should sync up this in order to avoid duplication/confusion.
| @@ -0,0 +1,23 @@ | |||
| /* | |||
There was a problem hiding this comment.
I'm good with this approach as well - much simpler
| @@ -0,0 +1,11 @@ | |||
| /* | |||
There was a problem hiding this comment.
On the topic of "top level types" and given my prior comment re: PR #54772 - These types here (and in store/endpoint_list/ ) are likely not to be needed by BE. Should we instead create a under plugin/endpoint/public/types.ts and place all FE specific types there? (and use /plugin/endpoint/common/types.ts for those shared across BE/FE?
| state = initialState(), | ||
| action | ||
| ) => { | ||
| if (action.type === 'serverReturnedAlertsData') { |
There was a problem hiding this comment.
You may want to consider (in the future) "reseting" the state when a user leaves the Alerts list so that data stored here does not take up memory in the browser.
| @@ -16,7 +18,10 @@ const initialState = (): EndpointListState => { | |||
| }; | |||
| }; | |||
|
|
|||
| export const endpointListReducer = (state = initialState(), action: EndpointListAction) => { | |||
| export const endpointListReducer: Reducer<EndpointListState, AppAction> = ( | |||
There was a problem hiding this comment.
Q. Why AppAction and not EndpointListAction?
is it so that in the future we could take advantage of other concern's Actions?
There was a problem hiding this comment.
its because combineReducers passes in all actions, not just EndpointListAction
There was a problem hiding this comment.
Ah Ok - but were you getting TS errors?
I think the benefit was that types shown here would be narrowed down to only the ones this concern cares about.
There was a problem hiding this comment.
We weren't getting errors but I think to your previous point it might be good to take advantage of being able to use other concern's or generic/global app actions in the future and this would keep that ability. Kind of like how we have the page navigated actions now. I do see what you're saying though, i don't necessarily disagree with it
There was a problem hiding this comment.
even if we filter out non-concern specific actions in the future, they aren't yet filtered out, so this type is more correct
| import { GlobalState } from './reducer'; | ||
| import * as alertListSelectors from './alerts/selectors'; | ||
|
|
||
| export const alertListData = composeSelectors( |
There was a problem hiding this comment.
FYI.
@parkiino will be pushing through a PR soon that takes a different approach for using a selector from a React component. Instead of having to re-define all your "context bound" selectors again here so that they receive the correct namespace from the GlobalStore, instead we're proposing having a hook like:
File: store/hooks.ts:
export function useEndpointListSelector<TSelected>(
selector: (state: EndpointListState) => TSelected
) {
return useSelector(function(state: GlobalState) {
return selector(state.endpointList);
});
}The idea is that each of the concerns will have an associated hook. To use this in a component, you would:
import { endpointListData } from "../store/endpoint_list/selectors;
import { useEndpointListSelector } from "../store/hooks;
const EndpointsListPage = () => {
const listData = useEndpointListSelector(endpointListData);
return (<div>...</div>)
}(Credit to @oatkiller for the idea during a recent discussion 😃 )
There was a problem hiding this comment.
@paul-tavares If we use this approach, how would a middleware (or saga) use the selector if needed to grab some data from state?
There was a problem hiding this comment.
@peluja1012 - From a saga or middleware we have access directly to the store and can get back GlobalState - so you would use the concern selector directly and feed it its namespace (ex. endpointListData(store.getState().endpointList)).
When we discussed this, the goal was to avoid the need to define all concerns selectors a second time in order for us to continue to use react-redux useSelector(). The hook does that nicely 😃
| @@ -0,0 +1,20 @@ | |||
| /* | |||
There was a problem hiding this comment.
I'm ok with this approach as well.
We should also have a store action that indicates a user has left the page (userNavigatedAwayFrompage) so that proper clean up (ex. reset store namespace to clean out data loaded in memory).
peluja1012
force-pushed
the
basic-alert-list
branch
from
0d81354
to
ca248bf
Compare
peluja1012
force-pushed
the
basic-alert-list
branch
from
ca248bf
to
919e304
Compare
paul-tavares
approved these changes
Jan 27, 2020
alexk307
reviewed
Jan 27, 2020
| * Calls the `secondSelector` with the result of the `selector`. Use this when re-exporting a | ||
| * concern-specific selector. `selector` should return the concern-specific state. | ||
| */ | ||
| function composeSelectors<OuterState, InnerState, ReturnValue>( |
alexk307
reviewed
Jan 27, 2020
| * you may not use this file except in compliance with the Elastic License. | ||
| */ | ||
|
|
||
| import { AlertData } from '../../../../../common/types'; |
There was a problem hiding this comment.
Thoughts about setting a baseUrl to remove these relative imports? https://www.typescriptlang.org/docs/handbook/module-resolution.html#base-url
I'm not sure if we are going to be able to maintain our own tsconfig.json or if we are sharing one with the rest of Kibana.
There was a problem hiding this comment.
@alexk307 We are currently not using our own tsconfig.json. We could look into this, but i think it's fine for now to use relative imports. Most IDE's that provide typescript support like VSCode or Vim make relative imports pretty easy.
There was a problem hiding this comment.
FYI - I seem remember a discussion from the Kibana platform team that suggests this is something they want to look at and possibly introduce aliases that will simplify the import paths. Found discussion on Kibana issues (look at Issue 40446).
alexk307
reviewed
Jan 27, 2020
| export const alertMiddlewareFactory: MiddlewareFactory = coreStart => { | ||
| return store => next => async (action: AppAction) => { | ||
| next(action); | ||
| if (action.type === 'userNavigatedToPage' && action.payload === 'alertsPage') { |
There was a problem hiding this comment.
I'm assuming by your above TODO, that all of this is still moving code for now, but would we be to define these action types in a types.ts file, so they're easy to use anywhere?
There was a problem hiding this comment.
@alexk307 We define actions in files like this one https://github.com/elastic/kibana/pull/55800/files#diff-c971622c4d5a45ad624ef764513a0131. The type checker will throw and error if you use an invalid action type in this if-statement. So if we were to do if (action.type === 'fooAction'), the type checker will throw an error because fooAction is not of type AppAction.
alexk307
reviewed
Jan 27, 2020
|
|
||
| const [visibleColumns, setVisibleColumns] = useState(() => columns.map(({ id }) => id)); | ||
|
|
||
| const json = useSelector(selectors.alertListData); |
oatkiller
reviewed
Jan 28, 2020
| @@ -44,3 +62,37 @@ export interface EndpointMetadata { | |||
| }; | |||
| }; | |||
| } | |||
|
|
|||
| export type AlertData = Immutable<{ | |||
There was a problem hiding this comment.
Why should this be Immutable?
There was a problem hiding this comment.
There should be one section of the alert data that is mutable... otherwise, it should all be immutable.
oatkiller
reviewed
Jan 28, 2020
|
|
||
| import { AlertData } from '../../../../../common/types'; | ||
|
|
||
| interface ServerReturnedAlertsData { |
There was a problem hiding this comment.
this would be a better place for Immutable since the code relies on the fact that action payloads aren't mutated. as it is, the payload array is mutable.
// maybe
interface ServerReturnedAlertsData {
readonly type: 'serverReturnedAlertsData';
readonly payload: readonly AlertData[];
}
// or
type ServerReturnedAlertsData = Immutable<{
type: 'serverReturnedAlertsData';
payload: AlertData[];
}>;
oatkiller
reviewed
Jan 28, 2020
| import { GlobalState } from '../reducer'; | ||
| import { AppAction } from '../action'; | ||
|
|
||
| // TODO, move this somewhere |
oatkiller
reviewed
Jan 28, 2020
| return store => next => async (action: AppAction) => { | ||
| next(action); | ||
| if (action.type === 'userNavigatedToPage' && action.payload === 'alertsPage') { | ||
| const response: AlertData[] = await coreStart.http.get('/api/endpoint/alerts'); |
oatkiller
reviewed
Jan 28, 2020
| }; | ||
| }; | ||
|
|
||
| export const alertListReducer: Reducer<AlertListState, AppAction> = ( |
There was a problem hiding this comment.
Are you using index vs page vs `list consistently here?
Some suggestions:
The feature (aka concern) is called 'alerting' and the directory takes this name.
The component that shows a list of alerts: 'alertList'
The route is called 'alertsIndex' assuming that it's written 'alerts/'
The component that renders the page is called 'alertingPage'.
@peluja1012 can explain that we might end up with a single route that shows an alert list page, an alert detail page, or both at the same time.
There was a problem hiding this comment.
Will address this in the next PR where I add a stub alert detail
oatkiller
reviewed
Jan 28, 2020
|
|
||
| import { AlertListState } from './types'; | ||
|
|
||
| export const alertListData = (state: AlertListState) => state.alerts; |
There was a problem hiding this comment.
consider naming this type AlertingState and this reducer alertingReducer and the naming the piece of global state alerting
There was a problem hiding this comment.
Will address this in the next PR where I add a stub alert detail
oatkiller
reviewed
Jan 28, 2020
| export const AlertIndex = memo(() => { | ||
| usePageId('alertsPage'); | ||
|
|
||
| const columns: Array<{ id: string }> = [ |
There was a problem hiding this comment.
consider wrapping this in useMemo so that you don't pass a new array ref to EuiGrid each render
oatkiller
reviewed
Jan 28, 2020
| } else if (columnId === 'timestamp') { | ||
| return json[rowIndex].value.source.endgame.timestamp_utc; | ||
| } else if (columnId === 'archived') { | ||
| return null; // TODO change this once its available in backend |
There was a problem hiding this comment.
Can ya move this to a github issue plz
There was a problem hiding this comment.
removed comment. Github issue here https://github.com/elastic/endpoint-app-team/issues/87
oatkiller
reviewed
Jan 28, 2020
| } else if (columnId === 'host_name') { | ||
| return json[rowIndex].value.source.host.hostname; | ||
| } else if (columnId === 'timestamp') { | ||
| return json[rowIndex].value.source.endgame.timestamp_utc; |
There was a problem hiding this comment.
This needs l10n. See https://github.com/elastic/kibana/pull/55590/files#diff-de600f9eb8a3427216e75a1cbf4bae6bR93 for ideas
There was a problem hiding this comment.
Thanks. We will add intl in future PRs. We just want to get some basic code structure and patterns merged now.
oatkiller
reviewed
Jan 28, 2020
| @@ -44,3 +62,37 @@ export interface EndpointMetadata { | |||
| }; | |||
| }; | |||
| } | |||
|
|
|||
| export type AlertData = Immutable<{ | |||
There was a problem hiding this comment.
Please add a comment (in jsdoc style) to each field.
There was a problem hiding this comment.
This data will change very soon to conform to ECS. We will document more once the format is closer to the final format. Right now we are using outdated fake data.
oatkiller
reviewed
Jan 28, 2020
| ? ImmutableSet<M> | ||
| : ImmutableObject<T>; | ||
|
|
||
| export type ImmutableArray<T> = ReadonlyArray<Immutable<T>>; |
There was a problem hiding this comment.
please add a comment to all exported identifiers
oatkiller
reviewed
Jan 28, 2020
| if (columnId === 'alert_type') { | ||
| return json[rowIndex].value.source.endgame.metadata.key; | ||
| } else if (columnId === 'event_type') { | ||
| return json[rowIndex].value.source.endgame.data.file_operation; |
There was a problem hiding this comment.
Can you confirm that all alerts are guaranteed to have this field?
There was a problem hiding this comment.
We will do this properly in future PRs. We just want to get some basic code structure and patterns merged now.
oatkiller
reviewed
Jan 28, 2020
| } else if (columnId === 'archived') { | ||
| return null; // TODO change this once its available in backend | ||
| } else if (columnId === 'malware_score') { | ||
| return json[rowIndex].value.source.endgame.data.malware_classification.score; |
There was a problem hiding this comment.
can you confirm that all alerts have this field?
There was a problem hiding this comment.
We will do this properly in future PRs. We just want to get some basic code structure and patterns merged now.
oatkiller
reviewed
Jan 28, 2020
| }, | ||
| async (context, req, res) => { | ||
| try { | ||
| // const queryParams = await kibanaRequestToEndpointListQuery(req, endpointAppContext); |
There was a problem hiding this comment.
please remove commented out code
oatkiller
reviewed
Jan 28, 2020
|
|
||
| const renderCellValue = useMemo(() => { | ||
| return ({ rowIndex, columnId }: { rowIndex: number; columnId: string }) => { | ||
| if (json.length === 0) { |
There was a problem hiding this comment.
maybe instead
if (rowIndex >= json.length) {
return null
} else {
const row = json[rowIndex]
// use `row` from here on instead of `json[rowIndex]`
}
oatkiller
approved these changes
Jan 28, 2020
gmmorris
added a commit
to gmmorris/kibana
that referenced
this pull request
Jan 29, 2020
* master: (31 commits) [SIEM] Overview page feedback (elastic#56261) refactor (elastic#56131) [NP Cleanup] Remove ui/public/inspector (elastic#55677) [SIEM] [TIMELINE] Only add endpoint logo when on event.module === endgame (elastic#56263) Basic Functionality Alert List (elastic#55800) [SIEM] Fix filters on Hosts and Network page (elastic#56234) [SIEM] Adds ability to infer the newsfeed.enabled setting (elastic#56236) [SIEM][Detection Engine] critical blocker for updated rules [SIEM][Detection Engine] critical blocker, fixes ordering issue that causes rules to not run the first time [SIEM] Add link to endpoint app through reference.url (elastic#56211) [Metrics UI] Fixing title truncation in Metrics Explorer (elastic#55917) [SIEM] Put the notice for rules in comment block (elastic#56123) [SIEM][Detection Engine] critical blocker with the UI crashing Consistent timeouts for the Space onPostAuth interceptor tests (elastic#56158) Skip tests that depend on other skipped test [SIEM] [Detection Engine] Timestamps for rules (elastic#56197) Sort server-side in SavedObject export (elastic#55128) [Reporting] Document the 8.0 breaking changes (elastic#56187) Revert "[Monitoring] Change all configs to `monitoring.*`" (elastic#56214) add owners for es_archiver (elastic#56184) ...
💔 Build FailedTest FailuresKibana Pipeline / kibana-oss-agent / Chrome UI Functional Tests.test/functional/apps/context/_date_nanos_custom_timestamp·js.context app context view for date_nanos with custom timestamp displays predessors - anchor - successors in right orderTest FailuresKibana Pipeline / kibana-intake-agent / kibana-intake / API Integration Tests.test/api_integration/apis/saved_objects/export·js.apis saved_objects export with kibana index basic amount of saved objects should return objects in dependency orderTest FailuresKibana Pipeline / kibana-xpack-agent / X-Pack Saved Object API Integration Tests -- security_and_spaces.x-pack/test/saved_object_api_integration/security_and_spaces/apis/export·ts.saved objects security and spaces enabled export superuser with the default space space aware type should return 200 with only the visualization when querying by typeTest FailuresKibana Pipeline / kibana-xpack-agent / X-Pack Saved Object API Integration Tests -- security_only.x-pack/test/saved_object_api_integration/security_only/apis/export·ts.saved objects security only enabled export superuser space aware type should return 200 with only the visualization when querying by typeTest FailuresKibana Pipeline / kibana-oss-agent / Chrome UI Functional Tests.test/functional/apps/context/_date_nanos_custom_timestamp·js.context app context view for date_nanos with custom timestamp displays predessors - anchor - successors in right orderand 2 more failures, only showing the first 3. History
To update your PR or re-run it, just comment with: |
kevinlog
changed the title
oatkiller
pushed a commit
that referenced
this pull request
Feb 18, 2020
* Add Endpoint plugin and Resolver embeddable (#51994) * Add functional tests for plugins to x-pack (so we can do a functional test of the Resolver embeddable) * Add Endpoint plugin * Add Resolver embeddable * Test that Resolver embeddable can be rendered Conflicts: x-pack/.i18nrc.json x-pack/test/api_integration/apis/index.js * [Endpoint] Register endpoint app (#53527) * register app, create functional test * formatting * update tests * adjust test data for endpoint * add endpoint tests for testing spaces, app enabled, disabled, etc * linting * add read privileges to endpoint * rename variable since its used now * remove deprecated context * remove unused variable * fix type check * correct test suite message Co-Authored-By: Larry Gregory <lgregorydev@gmail.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Larry Gregory <lgregorydev@gmail.com> * [Endpoint] add react router to endpoint app (#53808) * add react router to endpoint app * linting * linting * linting * correct tests * change history from hash to browser, add new test util * remove default values in helper functions * fix type check, use FunctionComponent as oppsed to FC * use BrowserRouter component * use BrowserRouter component lin * add comments to test framework, change function name to include browserHistory Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> * EMT-issue-65: add endpoint list api (#53861) add endpoint list api * EMT-65:always return accurate endpoint count (#54423) EMT-65:always return accurate endpoint count, independent of paging properties * Resolver component w/ sample data (#53619) Resolver is a map. It shows processes that ran on a computer. The processes are drawn as nodes and lines connect processes with their parents. Resolver is not yet implemented in Kibana. This PR adds a 'map' type UX. The user can click and drag to pan the map and zoom using trackpad pinching (or ctrl and mousewheel.) There is no code providing actual data. Sample data is included. The sample data is used to draw a map. The fundamental info needed is: process names the parent of a process With this info we can topologically lay out the processes. The sample data isn't yet in a realistic format. We'll be fixing that soon. Related issue: elastic/endpoint-app-team#30 * Resolver test plugin not using mount context. (#54933) Mount context was deprecated. Use core.getStartServices() instead. * Resolver nonlinear zoom (#54936) * [Endpoint] add Redux saga Middleware and app Store (#53906) * Added saga library * Initialize endpoint app redux store * Resolver is overflow: hidden to prevent obscured elements from showing up (#55076) * [Endpoint] Fix saga to start only after store is created and stopped on app unmount (#55245) - added `stop()`/`start()` methods to the Saga Middleware creator factory - adjust tests based on changes - changed application `renderApp` to stop sagas when react app is unmounted * Resolver zoom, pan, and center controls (#55221) * Resolver zoom, pan, and center controls * add tests, fix north panning * fix type issue * update west and east panning to behave like google maps * [Endpoint] FIX: Increase tests `sleep` default duration back to 100ms (#55492) Revert `sleep()` default duration, in the saga tests, back to 100ms in order to prevent intermittent failures during CI runs. Fixes #55464 Fixes #55465 * [Endpoint] EMT-65: make endpoint data types common, restructure (#54772) [Endpoint] EMT-65: make endpoint data types common, use schema changes * Basic Functionality Alert List (#55800) * sets up initial grid and data type * data feeds in from backend but doesnt update * sample data feeding in correctly * Fix combineReducers issue by importing Redux type from 'redux' package * Add usePageId hook that fires action when user navigates to page * Strict typing for middleware * addresses comments and uses better types * move types to common/types.ts * Move types to endpoint/types.ts, address PR comments blah 2 Co-authored-by: Pedro Jaramillo <peluja1012@gmail.com> * [Endpoint] Add Endpoint Details route (#55746) * Add Endpoint Details route * add Endpoint Details tests * sacrifices to the Type gods * update to latest endpoint schema Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> * [Endpoint] EMT-67: add kql support for endpoint list (#56328) [Endpoint] EMT-67: add kql support for endpoint list * [Endpoint] ERT-82 ERT-83 ERT-84: Alert list API with pagination (#56538) * ERT-82 ERT-83 ERT-84 (partial): Add Alert List API with pagination * Better type safety for alert list API * Add Test to Verify Endpoint App Landing Page (#57129) Conflicts: x-pack/test/functional/page_objects/index.ts * fixes render bug in alert list (#57152) Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> * Resolver: Animate camera, add sidebar (#55590) This PR adds a sidebar navigation. clicking the icons in the nav will focus the camera on the different nodes. There is an animation effect when the camera moves. Conflicts: yarn.lock * [Endpoint] Task/basic endpoint list (#55623) * Adds host management list to endpoint security plugin Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> * [Endpoint] Policy List UI route and initial view (#56918) * Initial Policy List view * Add `endpoint/policy` route and displays Policy List * test cases (both unit and functional) Does not yet interact with API (Ingest). * Add ApplicationService app status management (#50223) This was already backported, but changes to endpoint app could not be backported, since endpoint app itself hadn't been backported. Now that the endpoint app is backported, reapply the endpoint specific changes from the original commit. * Implements `getStartServices` on server-side (#55156) This was already backported, but changes to endpoint app could not be backported, since endpoint app itself hadn't been backported. Now that the endpoint app is backported, reapply the endpoint specific changes from the original commit. * [ui/utils/query_string]: Remove unused methods & migrate apps to querystring lib (#56957) This was already backported, but changes to endpoint app could not be backported, since endpoint app itself hadn't been backported. Now that the endpoint app is backported, reapply the endpoint specific changes from the original commit. Co-authored-by: Kevin Logan <56395104+kevinlog@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Larry Gregory <lgregorydev@gmail.com> Co-authored-by: nnamdifrankie <56440728+nnamdifrankie@users.noreply.github.com> Co-authored-by: Davis Plumlee <56367316+dplumlee@users.noreply.github.com> Co-authored-by: Paul Tavares <56442535+paul-tavares@users.noreply.github.com> Co-authored-by: Pedro Jaramillo <peluja1012@gmail.com> Co-authored-by: Dan Panzarella <pzl@users.noreply.github.com> Co-authored-by: Madison Caldwell <madison.rey.caldwell@gmail.com> Co-authored-by: Charlie Pichette <56399229+charlie-pichette@users.noreply.github.com> Co-authored-by: Candace Park <56409205+parkiino@users.noreply.github.com> Co-authored-by: Pierre Gayvallet <pierre.gayvallet@gmail.com> Co-authored-by: Alexey Antonov <alexwizp@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Sets up a basic alert list component on the alerts page for the endpoint plugin. Currently being populated with sample data as the backend schema is being built.
https://github.com/elastic/endpoint-app-team/issues/83
Checklist
Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n supportDocumentation was added for features that require explanation or tutorialsThis was checked for keyboard-only and screenreader accessibilityFor maintainers