Add notifications plugin, offering basic email service #143303

gsoldevila · 2022-10-13T16:23:31Z

The goal of this PR is to implement a new 'notifications' plugin that will expose a service to send simple, plain text, email notifications, using the 'actions' plugin Email connector under the hood.

Addresses #140743

…into kbn-140743-notifications-api-mvp

x-pack/plugins/notifications/server/services/email.ts

…/unsecured-client

…into kbn-140743-notifications-api-mvp

Dosant · 2022-10-17T10:06:52Z

x-pack/plugins/actions/server/create_unsecured_execute_function.ts

+ actionsToExectute: ExecuteOptions[]
+) => Promise<T>;
+
+export function createBulkUnsecuredExecutionEnqueuerFunction({


I am curious what does unsecured vs secured mean? That apiKey is null?

I think the idea is to highlight the fact that this API does not require any form of authentication whatsoever (apiKey or request object), so it should be used cautiously.

This is part of the changes that response-ops are performing to support the case assignment email notifications.

@Dosant Normally action execution enqueuing is secured via Kibana RBAC where the actions client checks that the user has access to the Actions and Connectors Kibana feature using the request object before allowing execution enqueuing. For this use case, the system will be scheduling the action so there is no user involved in the request.

x-pack/plugins/actions/server/create_unsecured_execute_function.ts

x-pack/plugins/notifications/common/lib/promise_utils.ts

Dosant · 2022-10-17T10:14:25Z

x-pack/plugins/notifications/server/plugin.ts

+ }
+
+ public setup(core: CoreSetup, plugins: NotificationsPluginSetupDeps) {
+ // TODO this must be defaulted to 'elastic-cloud-email' for cloud


Will we configure this in cloud deployment templates or hardcode in Kibana?

In the cloud deployment template I'm guessing (hoping)?

Yes, that's the idea, gonna remove the TODO line.

This is addressed by https://github.com/elastic/cloud/pull/109221

vadimkibana

Very good, LGTM overall! My only "big" question (aside from the optional nits below): Is it possible to execute the action (send email) without creating any saved objects and enqueueing them in the Task Manager? (Using the execute method.)

.../plugins/actions/server/unsecured_actions_client/unsecured_actions_client_access_registry.ts

vadimkibana · 2022-10-17T08:21:00Z

x-pack/plugins/notifications/README.md

+
+1. Make sure `notifications` is in your `optionalPlugins` in the `kibana.json` file:
+
+```json5


Ah, TIL: json5 👍

vadimkibana · 2022-10-17T09:09:32Z

x-pack/plugins/notifications/common/lib/promise_utils.ts

+export type ResolvablePromise<T> = Promise<T> & {
+ doResolve: (value: unknown) => void;
+ doReject: (reason?: any) => void;
+};
+
+export function getResolvablePromise<T>(): ResolvablePromise<T> {
+ const resolvablePromise: Partial<ResolvablePromise<T>> = {};
+
+ Object.assign(
+ resolvablePromise,
+ new Promise((resolve, reject) => {
+ resolvablePromise.doResolve = resolve;
+ resolvablePromise.doReject = reject;
+ })
+ );
+
+ return resolvablePromise as ResolvablePromise<T>;
+}


nit: In kibana_utils plugin there is Defer class, which does the same. Maybe could be re-used instead of creating this.

I suspected that something like this would probably exist already, but I couldn't find it. Thanks!

vadimkibana · 2022-10-17T10:00:14Z

x-pack/plugins/notifications/server/plugin.ts

+ private email: ResolvablePromise<EmailService>;
+ private emailConnector: string;
+
+ constructor(initializerContext: PluginInitializerContext<NotificationsConfigType>) {
+ this.logger = initializerContext.logger.get();
+ this.email = getResolvablePromise();
+ this.initialConfig = initializerContext.config.get();
+ }
+
+ public setup(core: CoreSetup, plugins: NotificationsPluginSetupDeps) {
+ // TODO this must be defaulted to 'elastic-cloud-email' for cloud
+ if (!plugins.actions) {
+ this.email.doReject(`Error starting notification services: 'actions' plugin not available.`);
+ return { email: this.email };
+ }
+
+ const emailConnector = this.initialConfig.connectors?.default?.email;
+ if (!emailConnector) {
+ this.email.doReject('Error starting notification services: Email connector not specified');
+ return { email: this.email };
+ }
+
+ if (!plugins.actions.isPreconfiguredConnector(emailConnector)) {
+ this.email.doReject(
+ `Error starting notification services: Unexisting email connector '${emailConnector}' specified`
+ );
+ return { email: this.email };
+ }
+
+ plugins.actions.registerUnsecuredActionsClientAccess(PLUGIN_ID);
+
+ this.emailConnector = emailConnector;
+
+ return {
+ email: this.email,
+ };
+ }
+
+ public start(core: CoreStart, plugins: NotificationsPluginStartDeps) {
+ if (this.emailConnector) {
+ plugins.actions.getUnsecuredActionsClient().then(
+ (actionsClient) => {
+ const email = new EmailService(PLUGIN_ID, this.emailConnector, actionsClient);
+ this.email.doResolve(email);
+ },
+ (error) => {
+ this.logger.warn(`Error starting notification services: ${error}`);
+ this.email.doReject(error);
+ }
+ );
+ }
+
+ return {
+ email: this.email,
+ };
+ }


Two things I would like to suggest here:

From what I understand the email service is async only to handle the case of connectors not being available and to be able to store a specific error message in that promise. I'm not sure that is a good reason to make the service async, would be still nice to keep it sync.

All the business logic here (about 50 lines of code) is specific to the EmailService, there will be other services here in the future, to make it self contained and future proof, would be nice to remove this EmailService construction code out of the plugin.ts file.

Something like:

private email?: EmailService; public setup(core: CoreSetup, plugins: NotificationsPluginSetupDeps) { this.email = new EmailService(core, plugins.actions); return { email: this.email } } public start() { this.email._boot(); return { email: this.email! }; }

where:

class EmailService { public error?: Error; constructor (protected readonly core, protected readonly actions) {} public _boot(): void { this.core.getStartServices().then(() => { // ... }); } private assertIsReady() { // ... } public async sendPlainTextEmail(options) { await this.assertIsReady(); // send email ... } }

Another option could be to create a "provider" for the email service, where in the future we could use it to setup a non-connector based email sender:

private emailProvider?: EmailServiceProvider; public setup(core: CoreSetup, plugins: NotificationsPluginSetupDeps) { this.emailProvider = new EmailServiceProvider(); if (core.email) { this.emailProvider.setImplementation(new CoreEmailService(core)); } else if (plugins.cloud) { this.emailProvider.setImplementation(new CloudEmailService(core, plugins.cloud)); } else if (plugins.actions) { this.emailProvider.setImplementation(new AlertingEmailService(core, plugins.actions)); } return { email: () => this.emailProvider.create() } } public start() { this.emailProvider._boot(); return { email: () => this.emailProvider.create() } }

Thanks for the suggestions!

(1) The email service is actually async because the Actions plugin's getUnsecuredActionsClient() method is also async, so I cannot instantiate the EmailService until I have an instance of the ActionsClient. That being said, looking at the Actions plugin code, I don't see a strong reason why this method is async, so perhaps we can simply make it synchronous. @ymao1 WDYT?
Another reason is, if we want to expose it on the setup() contract, we have to await for Actions plugin start() contract in order to get the ActionsClient, but again, I don't know if there's a good reason not to expose the getUnsecuredActionsClient() in the setup()...

(2) Good point, I'll create a factory and extract this logic there.

@gsoldevila I can make getUnsecuredActionsClient() synchronous, you are correct that there doesn't seem to be a reason for it to be asynchronous, however, it uses core.savedObjects.createInternalRepository which is only available on SavedObjectsServiceStart, not on SavedObjectsServiceSetup, so I need to keep that function inside the start

Thanks @ymao1. I don't see anything wrong with having the EmailService available only at start time (and not on setup).

@cnasikas if this works for you, I'll remove it from the setup contract, and have it on the start contract as a property (rather than a Promise). We can always start like this, and then add it as a Promise on setup if the need arises.

@gsoldevila It works also for us. The cases client, which is used in our routes, is initialized on start.

@vadimkibana
(1) it will no longer be a Promise, although it will be available in the start contract only.
(2) I created a factory to instantiate the EmailService and extracted the initialization logic + error handling there.

@gsoldevila nice, LGTM, thx

vadimkibana · 2022-10-17T10:10:11Z

x-pack/plugins/notifications/server/plugin.ts

+ // TODO this must be defaulted to 'elastic-cloud-email' for cloud
+ if (!plugins.actions) {
+ this.email.doReject(`Error starting notification services: 'actions' plugin not available.`);
+ return { email: this.email };


nit: Early returns is a clean and nice pattern:

if (something) { return early; } return late;

But here it is a bit risky to use, especially as plugin classes are usually not tested. The reason being that once this plugin has more services, it will not be possible to use early returns in this manner and it will need to be refactored:

setup() { if (!plugins.actions) { this.email.doReject(`...`); return { email: this.email }; // BUG: "sms" service is missing. } // ... more code ... return { email: this.email, sms: this.sms, }; }

vadimkibana · 2022-10-17T10:20:09Z

x-pack/plugins/notifications/server/services/email.ts

+ to,
+ },
+ }));
+ return await this.actionsClient.bulkEnqueueExecution(this.requesterId, actions);


I was thinking we will execute the email action immediately, using the execute() method, (I hope that does not create a saved object), instead of "enqueueing", which creates a saved object.

Do we gain something by enqueueing an action?

Suggested change

return await this.actionsClient.bulkEnqueueExecution(this.requesterId, actions);

return await this.actionsClient.bulkExecute(this.requesterId, actions);

Added a comment about that here: #140743 (comment)

Following the discussion, it seems that there's agreement in queuing the task and executing asynchronously from task manager.

pgayvallet

Did not look at the changes of the actions plugin.

x-pack/plugins/notifications/README.md

pgayvallet · 2022-10-17T11:48:05Z

x-pack/plugins/notifications/README.md

+ const emailService = await notifications?.email;
+ emailService.sendPlainTextEmail({
+ to: 'foo@bar.com',
+ subject: 'Some subject',
+ message: 'Hello world!',
+ });


NIT: this example will actually NPE if notifications is not present.

Either emailService?.sendPlainTextEmail or set the dependency are required for the example.

pgayvallet · 2022-10-17T11:48:51Z

x-pack/plugins/notifications/README.md

+
+### Requirements
+
+- This plugin currently depends on the `'actions'` plugin, as it uses `Connectors` under the hood. Please make sure the `'actions'` plugin is included in your deployment.


Unnecessary point ihmo ( at least the Please make sure the 'actions' plugin is included in your deployment. part).

x-pack/plugins/notifications/common/lib/promise_utils.ts

pgayvallet · 2022-10-17T12:00:27Z

x-pack/plugins/notifications/server/plugin.ts

+ }
+
+ public setup(core: CoreSetup, plugins: NotificationsPluginSetupDeps) {
+ // TODO this must be defaulted to 'elastic-cloud-email' for cloud


In the cloud deployment template I'm guessing (hoping)?

pgayvallet · 2022-10-17T12:06:12Z

x-pack/plugins/notifications/server/services/email_service.ts

+ * 2.0.
+ */
+
+export interface IEmailService {


NIT: misleading naming. Rename this file types.ts and the email.ts file (containing the service) email_service.ts.

pgayvallet · 2022-10-17T12:06:46Z

x-pack/plugins/notifications/server/services/email_service.ts

+ sendPlainTextEmail(payload: PlainTextEmail): Promise<void>;
+}
+
+export interface PlainTextEmail extends Record<string, unknown> {


Why is that extending Record<string, unknown>?

It doesn't make much sense, and I don't remember why I added it on the first place.
I will remove it, thanks for spotting it!

…/unsecured-client

cnasikas

ResponseOps code LGTM. I created a PR on top of this PR to test sending an email when assigning a user to a case and is working as expected 🚀 .

pgayvallet

LGTM

pgayvallet · 2022-11-03T08:33:59Z

x-pack/plugins/notifications/server/config/connectors_email_config.ts

+export const config: PluginConfigDescriptor<ConnectorsEmailConfigType> = {
+ schema: configSchema,
+};


NIT: this descriptor declaration is duplicated in x-pack/plugins/notifications/server/config/config.ts.

(Also NIT/optional: ihmo these two files could be merged, not sure to see the value separating them?)

I wanted to have a "connectors specific part" so that we can more easily get rid of it if we ever change the underlying implementation. But I think it makes things unnecessarily complex. I'll merge both.

pgayvallet · 2022-11-03T08:43:26Z

x-pack/plugins/notifications/server/services/connectors_email_service.ts

+ ...(params.context?.relatedObjects?.length && {
+ relatedSavedObjects: params.context!.relatedObjects!.map(
+ ({ id, type, spaceId: namespace }) => ({ id, type, namespace })
+ ),


NIT: can be extracted outside of the map call.

pgayvallet · 2022-11-03T08:52:15Z

x-pack/plugins/notifications/server/services/connectors_email_service_provider.ts

+ return {
+ isEmailServiceAvailable: () => !!email,
+ getEmailService: () => {
+ if (email) return email;


NIT/optional: code style consistency

if (email) { return email; }

Even more NIT and optional: following the 'fail fast' logic, I would personally have inverted the statements

if(!email) { throw ...; } return email;

pgayvallet · 2022-11-03T08:53:27Z

x-pack/plugins/notifications/server/services/connectors_email_service_provider.ts

+ );
+ }
+
+ this.setupSuccessful = true;


NIT: no real impact, but I would have cleared this.setupError when we get there (but that implies to make that property optional and force cast ! when throwing the error in start)

Makes sense, we want the variables to have the right value at all times. I'll clear it to ''

pgayvallet · 2022-11-03T08:54:36Z

x-pack/plugins/notifications/server/services/connectors_email_service_provider.ts

+ email = new LicensedEmailService(
+ new ConnectorsEmailService(PLUGIN_ID, emailConnector, unsecuredActionsClient),
+ licensing.license$,
+ 'platinum',


NIT: I would extract that to a const

ymao1 · 2022-11-03T11:44:52Z

x-pack/plugins/notifications/server/services/connectors_email_service.ts

+ return {
+ id,
+ type,
+ namespace: spaceId,


While spaceId === namespace in most cases, it does not directly map to namespace in the case of the default space. For the default space, spaceId = default while namespace is undefined. The spaces service has a spaceIdToNamespace helper for the conversion, or you could update the typing to accept namespace and pass it through

Oh I wasn't aware of that! I thought it was a simple naming discrepancy. I can switch back to 'namespace' or use the converter. @cnasikas if that's fine with you I'll update the type and use namespace instead.

Yes, it is fine!

ymao1

LGTM!

kibana-ci · 2022-11-03T14:18:02Z

💚 Build Succeeded

Buildkite Build
Commit: 439b3e7

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
`notifications`	-	2	+2

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
`notifications`	-	1	+1

Unknown metric groups

API count

id	before	after	diff
`notifications`	-	2	+2

ESLint disabled in files

id	before	after	diff
`osquery`	1	2	+1

ESLint disabled line counts

id	before	after	diff
`enterpriseSearch`	19	21	+2
`fleet`	58	64	+6
`notifications`	-	4	+4
`osquery`	106	111	+5
`securitySolution`	440	446	+6
total			+23

Total ESLint disabled count

id	before	after	diff
`enterpriseSearch`	20	22	+2
`fleet`	66	72	+6
`notifications`	-	4	+4
`osquery`	107	113	+6
`securitySolution`	517	523	+6
total			+24

History

💔 Build #85037 failed 56f99c9
💔 Build #85007 failed f275913
💛 Build #84820 was flaky d6e46f5
💔 Build #84784 failed 091eb74
💔 Build #84624 failed 1467966

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@shanisagiv1

## Summary The PR adds the ability to notify users by email when assigned to a case. A user is: - Not notified if he/she assigns themselves - Notified if added as an assignee to a case - Not notified if removed from a case I did not add integration tests due to the complexity of simulating an email server. I added unit test coverage. If integration test coverage is needed we can add the tests on another PR. Depends on: #143303 Fixes: #142307 ## Email screenshot <img width="361" alt="Screenshot 2022-11-07 at 1 27 13 PM" src="https://user-images.githubusercontent.com/7871006/200299356-52c08515-4d43-49d6-bd47-3797b52f97e5.png"> @shanisagiv1 @lcawl What do you think about the content of the email (see screenshot)? ## Testing 1. Put the following in your `kibana.yml`: ``` notifications.connectors.default.email: 'mail-dev' xpack.actions.preconfigured: mail-dev: name: preconfigured-email-notification-maildev actionTypeId: .email config: service: other from: mlr-test-sink@elastic.co host: localhost port: 1025 secure: false hasAuth: false ``` 2. Install [`maildev`](https://www.npmjs.com/package/maildev): `npm install -g maildev` 3. Run `maildev`: `maildev` 4. Open MailDev's web interface (http://0.0.0.0:1080/) 5. Create a case and assign users. You should see the emails in the MailDev inbox. 6. Update the assignees of a case. You should see the emails in the MailDev inbox. Note: If you assign yourself you should not see an email. If you delete an assignee you should not see an email. ### Checklist Delete any items that are not applicable to this PR. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] This was checked for [cross-browser compatibility](https://www.elastic.co/support/matrix#matrix_browsers) ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ## Release notes Notify users by email when assigned to a case

ymao1 and others added 6 commits October 13, 2022 09:54

Adding unsecured actions client

2a93a37

Merge remote-tracking branch 'remotes/ymao/actions/unsecured-client' …

dc9829e

…into kbn-140743-notifications-api-mvp

Removing isESOCanEncrypt check

2fe5ce5

Only getting actions client when needed in executor

dbed0a8

Merge remote-tracking branch 'remotes/ymao/actions/unsecured-client' …

4af9bc6

…into kbn-140743-notifications-api-mvp

First draft

c3ce0b1

gsoldevila added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:AppServicesSv backport:skip This commit does not require backporting release_note:feature Makes this part of the condensed release notes v8.6.0 labels Oct 13, 2022

gsoldevila requested review from cnasikas, ymao1 and a team October 13, 2022 16:23

gsoldevila commented Oct 13, 2022

View reviewed changes

x-pack/plugins/notifications/server/services/email.ts Outdated Show resolved Hide resolved

gsoldevila changed the title ~~Add notifications plugin, containing basic email service~~ Add notifications plugin, offering basic email service Oct 14, 2022

ymao1 and others added 6 commits October 14, 2022 09:57

Changing to feature id allowlist. Adding unit tests

00c611d

Merge branch 'main' of https://github.com/elastic/kibana into actions…

b0fba11

…/unsecured-client

Removing execution id

baf051a

Cleanup

96b696f

Fixing unit tests

6cf7a3a

Merge remote-tracking branch 'remotes/ymao/actions/unsecured-client' …

74aa62d

…into kbn-140743-notifications-api-mvp

vadimkibana requested review from Dosant and vadimkibana October 17, 2022 09:12

Dosant reviewed Oct 17, 2022

View reviewed changes

vadimkibana reviewed Oct 17, 2022

View reviewed changes

pgayvallet reviewed Oct 17, 2022

View reviewed changes

ymao1 added 3 commits October 17, 2022 09:43

Merge branch 'main' of https://github.com/elastic/kibana into actions…

fa4a356

…/unsecured-client

Removing slack from allowlist

8865a80

Make getUnsecuredActionsClient synchronous

7c884ae

Fix TS error

9dbe577

ymao1 mentioned this pull request Oct 27, 2022

[Actions] relatedSavedObjects should allow multiple namespaces #144112

Closed

gsoldevila added 2 commits October 28, 2022 11:48

Support list of spaces for each related SO

0238877

Merge branch 'main' into kbn-140743-notifications-api-mvp

06ff938

gsoldevila requested a review from cnasikas October 28, 2022 11:57

cnasikas approved these changes Nov 1, 2022

View reviewed changes

cnasikas mentioned this pull request Nov 2, 2022

[Cases] Notify assignees when assigned to a case #144391

Merged

4 tasks

gsoldevila added 5 commits November 2, 2022 11:24

Accept single spaceId for related SOs. Add convenience mocks

dc4c9a6

Merge branch 'main' into kbn-140743-notifications-api-mvp

2654fee

Merge branch 'main' into kbn-140743-notifications-api-mvp

1467966

Merge branch 'main' into kbn-140743-notifications-api-mvp

091eb74

Fix CI types error

d6e46f5

vadimkibana approved these changes Nov 3, 2022

View reviewed changes

pgayvallet approved these changes Nov 3, 2022

View reviewed changes

gsoldevila added 2 commits November 3, 2022 11:06

Address PR remarks

8d026c5

Merge branch 'main' into kbn-140743-notifications-api-mvp

f275913

gsoldevila requested review from Dosant, pgayvallet and ymao1 and removed request for Dosant, ymao1 and pgayvallet November 3, 2022 10:33

Merge branch 'main' into kbn-140743-notifications-api-mvp

56f99c9

ymao1 reviewed Nov 3, 2022

View reviewed changes

gsoldevila added 2 commits November 3, 2022 13:45

Address PR remarks elastic#2

3aef92a

Merge branch 'main' into kbn-140743-notifications-api-mvp

439b3e7

ymao1 approved these changes Nov 3, 2022

View reviewed changes

gsoldevila merged commit 8881539 into elastic:main Nov 3, 2022


		1. Make sure `notifications` is in your `optionalPlugins` in the `kibana.json` file:

		```json5

	return await this.actionsClient.bulkEnqueueExecution(this.requesterId, actions);
	return await this.actionsClient.bulkExecute(this.requesterId, actions);


		### Requirements

		- This plugin currently depends on the `'actions'` plugin, as it uses `Connectors` under the hood. Please make sure the `'actions'` plugin is included in your deployment.

Add notifications plugin, offering basic email service #143303

Add notifications plugin, offering basic email service #143303

Conversation

gsoldevila commented Oct 13, 2022 • edited Loading

Dosant Oct 17, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vadimkibana left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vadimkibana Oct 17, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gsoldevila Oct 19, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vadimkibana Oct 17, 2022 • edited Loading

Choose a reason for hiding this comment

vadimkibana Oct 17, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gsoldevila Oct 19, 2022 • edited Loading

Choose a reason for hiding this comment

pgayvallet left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cnasikas left a comment

Choose a reason for hiding this comment

pgayvallet left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ymao1 left a comment

Choose a reason for hiding this comment

kibana-ci commented Nov 3, 2022

💚 Build Succeeded

Metrics [docs]

Public APIs missing comments

Public APIs missing exports

API count

ESLint disabled in files

ESLint disabled line counts

Total ESLint disabled count

History

gsoldevila commented Oct 13, 2022 •

edited

Loading

Dosant Oct 17, 2022 •

edited

Loading

vadimkibana left a comment •

edited

Loading

vadimkibana Oct 17, 2022 •

edited

Loading

gsoldevila Oct 19, 2022 •

edited

Loading

vadimkibana Oct 17, 2022 •

edited

Loading

vadimkibana Oct 17, 2022 •

edited

Loading

gsoldevila Oct 19, 2022 •

edited

Loading