[ResponseOps][Connectors] Move create connector button in Management

[guskovaue]

Issue: #188189

Here "create connector" button should be moved to the header (top right) for consistency with Rules and Cases page.

How to check:

So it should looks like this on Connectors tab:

And like this (without Create connector button) on tab Logs:

Create connector flyout should open when Create connector button will be pushed.

Also good to check if edit flyout will open when edit a connector.

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[guskovaue]

@elasticmachine merge upstream

[adcoelho]

I tested and it's working as expected.

Left some small comments 👍

[adcoelho]

nit:

Suggested change

	expect(createFirstActionButton).toBeEnabled();
	userEvent.click(createFirstActionButton);
	expect(setAddFlyoutVisibility).toBeCalled();
	userEvent.click(createFirstActionButton);
	await waitFor(() => {
	expect(setAddFlyoutVisibility).toBeCalled();
	});

Two minor things that I would do differently based on the flaky tests we had in the past:

1. no need to check if the button is enabled when we are clicking it anyway in the next line.
2. better to wrap the expect(function).toBeCalled() in a waitFor block for a longer timeout.

[adcoelho]

Suggested change

beforeEach(() => {});

[adcoelho]

Suggested change

	path: `/logs`,
	path: '/logs',

[adcoelho]

Suggested change

	await waitFor(() => {
	expect(screen.queryByRole('button', { name: 'Create connector' })).not.toBeInTheDocument();
	});
	expect(screen.queryByRole('button', { name: 'Create connector' })).not.toBeInTheDocument();

I don't think you need the waitFor in this case.

[guskovaue]

@adcoelho I had doubts here. I render the component. So should wait until it will be render. Everywhere I used find in the same situation. But here I cannot because if queryBy, so I used waitFor to follow the same logic.
So you do not think I need for render to happened? How does it work?

[adcoelho]

So should wait until it will be render. Everywhere I used find in the same situation. But here I cannot because if queryBy, so I used waitFor to follow the same logic.
So you do not think I need for render to happened? How does it work?

I am not sure I understand what you are trying to say 😅 but all waitFor does is run the callback you pass it until it either does not throw or a timeout happens.

In your test, the condition expect(screen.queryByRole('button', ...)).not.toBeInTheDocument(); will never throw because the button is not there so it is pointless to have the waitFor.

As a side note, I don't think "waiting for render" as you said applies. The documentation as an example where getBy is used and no waitFor is there to "wait for render".

test('renders a message', () => {
  const {asFragment, getByText} = render(<Greeting />)
  expect(getByText('Hello, world!')).toBeInTheDocument()

It is useful if you have lots of async stuff going on that you need to wait for before something happens but it doesn't mean nothing rendered.

[adcoelho]

Why the last commit adding getBy instead of findBy? that part looked fine.

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: f6deeb3

Failed CI Steps

• FTR Configs #9

Test Failures

• [job] [logs] FTR Configs #9 / console app misc console behavior keyboard shortcuts open documentation should open documentation when Ctrl+/ is pressed

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
triggersActionsUi	1.6MB	1.6MB	-16.4KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
triggersActionsUi	120.9KB	120.9KB	+6.0B

Unknown metric groups

ESLint disabled line counts

id	before	after	diff
triggersActionsUi	125	127	+2

Total ESLint disabled count

id	before	after	diff
triggersActionsUi	131	133	+2

History

• 💔 Build #227706 failed a077119751dd23dfae7808f27be9c6a1a0d96f4b
• 💔 Build #227648 failed ce762bdc3569882d4417788f8bfc2b76281d9a92
• 💚 Build #227605 succeeded 308ffc7
• 💔 Build #227594 failed fe8db3b5bb5c312ff0ab983a0b288b25577dfef8
• 💔 Build #227540 failed 7ef21c011abacceceef9f5408cb6bf91be966918
• 💔 Build #227409 failed 2311f56

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

cc @guskovaue