[ML][AI Connector] UX enhancements for editing fields in the AI Connector flyout#231037
Conversation
|
cc @joana-cps - can you confirm the design looks alright? 🙏 |
Looks good, just adding this here for visibility. Can we have the |
|
/ci |
|
Pinging @elastic/ml-ui (:ml) |
| import React, { useMemo, useState } from 'react'; | ||
| import { EuiButtonGroup, EuiFlexGroup, EuiFlexItem, EuiTitle } from '@elastic/eui'; | ||
| import { FormattedMessage } from '@kbn/i18n-react'; | ||
| import { ConfigEntryView } from '../../types/types'; |
| <> | ||
| {description}{' '} | ||
| <EuiLink | ||
| href="https://www.elastic.co/guide/en/elasticsearch/reference/current/inference-apis.html#default-enpoints" |
There was a problem hiding this comment.
is this at all in the docsLink service?
There was a problem hiding this comment.
Thanks for taking a look 🙏 It's not in the docsLink service. I did notice the url is wrong so I went ahead and updated it.
As this is the only link in the package and is only used for the internal provider, I'm not sure it's worth passing the whole service through. 🤔 Worth keeping an eye on as we update this code, though.
| ); | ||
|
|
||
| return ( | ||
| <EuiFlexGroup direction="column" data-test-subj="authentication-fields"> |
There was a problem hiding this comment.
super duper nit: Suggestion to titleCase data-test-subj so they are formatted consistently with the rest of Kibana. Potentially prefix with 'inferenceUI'? e.g. inferenceUIAuthenticationFields
There was a problem hiding this comment.
Never mind, just saw the test subjects for this plugin are in this format.
| <EuiTextColor color={euiTheme.colors.primary}> | ||
| <EuiTextColor | ||
| color={euiTheme.colors.primary} | ||
| data-test-subj="inference-endpoint-additional-options-button" |
There was a problem hiding this comment.
nitpick: Do we need to update options to settings` here too?
| requiredProviderFormFields={authenticationFormFields} | ||
| setRequiredProviderFormFields={setAuthenticationFormFields} |
| <EuiHorizontalRule margin="m" /> | ||
| </> | ||
| ) : null} | ||
| {/* ADDITIONAL OPTIONS */} |
There was a problem hiding this comment.
Do we need this part anymore? Optional fields are already handled.
There was a problem hiding this comment.
On a second thought, this might be the task_settings, I assume?
There was a problem hiding this comment.
Thanks for taking a look, @Samiul-TheSoccerFan 🙏
Yes, these is now the extra settings like, task type and the inference endpoint.
'More options' is now the optional config settings for the provider.
So we've got
Required and not sensitive - Settings
Optional and not sensitive - More Options
Sensitive - Auth settings
Additional options - Inference endpoint and task type
peteharverson
left a comment
There was a problem hiding this comment.
Tested locally (including serverless) and LGTM
|
@elasticmachine merge upstream |
| </h4> | ||
| </EuiTitle> | ||
| <EuiSpacer size="s" /> | ||
| {actionTypeModel?.id && actionTypeModel.id !== '.inference' ? ( |
There was a problem hiding this comment.
The generic connector form should not be aware of a specific connector ID or adjust its layout based on it. Such alterations are unsustainable and difficult to maintain.
With the planned work in #231016, do we actually need the current change?
If it’s really critical, we can consolidate this logic in one place and remove it once the issue above is resolved. There are already checks in formDeserializer and formSerializer for the .inference connector. Something like this would work:
// TODO remove when https://github.com/elastic/kibana/issues/231016 is resolved
const connectorOverrides = (connectorId: string) => {
switch(connectorId): {
case '.inference':
return : {
formDeserializer: ...
formSerializer: ...
shouldHideConnectorSettings: ...
}
}
}There was a problem hiding this comment.
Hm - good point! Yes, I think adding the overrides make sense - with the intention of being able to remove them once they are no longer needed. AFAIK there is planning also being done for allowing the connector framework to have connector-specific serializers so that should solve that issue, as well.
Will update 👍
There was a problem hiding this comment.
Thanks for the edits @alvarezmelissa87! I noticed that instead of returning callbacks for formDeserializer and formSerializer, you’re returning serialized and deserialized forms. This makes everything happen at once, whereas we usually handle these steps one at a time. It also makes the naming semantically confusing. Left a suggestion below, but otherwise LGTM
There was a problem hiding this comment.
Callbacks are a better idea 👍
Updated in 374211f
| const overrides = connectorOverrides(formData.actionTypeId, formData); | ||
| if (overrides?.formSerializer) { | ||
| return overrides.formSerializer; |
There was a problem hiding this comment.
Thanks for consolidating the overrides in one place! I noticed the code unnecessarily serializes and deserializes the form at once. My suggestion was to return a callback instead.
const overrides = connectorOverrides(formData.actionTypeId);
if (overrides?.formSerializer) {
return overrides.formSerializer(formData);There was a problem hiding this comment.
Good call - updated to be callbacks here 374211f
|
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
Page load bundle
Unknown metric groupsESLint disabled line counts
Total ESLint disabled count
History
|
…lastic#231037) ## Summary Related issue: elastic#226580 This PR updates the sections for the AI/Inference connector as described in the issue linked above. https://github.com/user-attachments/assets/0ab473a3-e444-4e02-a7e8-b522722247bf Multiple authentication fields: Addresses elastic#226588 <img width="630" height="875" alt="image" src="https://github.com/user-attachments/assets/fc66b51f-0699-42c7-9bba-f7ddff8b7e36" /> Elasticsearch on serverless with adaptive allocations: <img width="635" height="928" alt="image" src="https://github.com/user-attachments/assets/91217ee8-d7f0-4adf-a3e4-9731ab97ee08" /> ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] 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/src/platform/packages/shared/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [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 - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) - [ ] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Summary
Related issue: #226580
This PR updates the sections for the AI/Inference connector as described in the issue linked above.
AIConnectorSections.mov
Multiple authentication fields:
Addresses #226588
Elasticsearch on serverless with adaptive allocations:
Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
release_note:breakinglabel should be applied in these situations.release_note:*label is applied per the guidelinesbackport:*labels.