[pull] main from elastic:main #690
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
…tions` (#184918) Minor change to rename `knowledgeBaseInstructions` to `userInstructions`. The fact that userinstructions are currently stored in knowledge base is an implementation details and shouldn't leak through.
## 📓 Summary I found a couple of heavy components which could be dynamically exported and reduce the load bundle for the plugin by ~50kb. Co-authored-by: Marco Antonio Ghiani <[email protected]>
## 📓 Summary Closes #184735 These changes move the control actions on the Logs Explorer data grid rows to the left for more visual consistency with Discover. <img width="2394" alt="Screenshot 2024-06-05 at 12 53 45" src="https://github.com/elastic/kibana/assets/34506779/80c36bce-739e-4dbd-89de-fda58095da89"> --------- Co-authored-by: Marco Antonio Ghiani <[email protected]>
…ta view (#184740) - Closes #181430 ## Summary Before: <img width="1628" alt="Screenshot 2024-06-04 at 15 03 49" src="https://github.com/elastic/kibana/assets/1415710/f1f5e82a-350d-47ef-b54e-cb48267ae2cd"> After: <img width="1630" alt="Screenshot 2024-06-04 at 15 03 13" src="https://github.com/elastic/kibana/assets/1415710/1cf5ce94-2e88-4a56-8d65-e4fab1f90f7b"> For testing: Create a user with full access to Discover (but without configuring index privileges) and navigate to the default `/discover` route <img width="1057" alt="Screenshot 2024-06-04 at 15 16 17" src="https://github.com/elastic/kibana/assets/1415710/3134f294-0e69-4f87-a235-8da780690913">
- Closes #184379 ## Summary This PR brings back the logic which was edited in #169548 This should allow to reset the saved breakdown field with rather an empty string as `undefined` seems to be ignored. ### Checklist - [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
…184945) ## Summary Added resolution for `[email protected]` version to point to elastic fork.
## Summary Fixes #173771 Use saved data view id instead of index pattern where it's available. Inject runtime mappings from the dataview into transform. - [ ] Go to Discover and add a runtime field to the data view (this is only available in Discover) - [ ] Make sure filtering works based on the data view We are not supporting "scripted fields" from the Index Management DataView editor. --------- Co-authored-by: Kibana Machine <[email protected]>
…eature flags (#184996) ## Summary Skip Policy Details cy test on MKI due to feature flags are not supported.
…ng (#184797) ## Summary * Refresh risk score index after persisting risk score * Schedule the risk score transform after calculating the risk score for a single entity * Update transform config * Add `delay: 0s` * Add `managed` and `managed_by` metadata * Add `version` metadata (used by the migration) * Add `unattended: true` * Create a transform migration ## How to test it? ### Migration 1. Install risk engine on an old version 2. Upgrade version 3. Add new alerts with new host and user 4. Run the risk engine (you can wait or force it to run by switching the flag on/off) 5. Open the explore page (user|host)/risk-tab and check if the new user|host is present ### New installation 1. Install risk engine on an empty cluster 3. Add new alerts with new host and user 4. Run the risk engine (you can wait or force it to run by switching the flag on/off) 5. Open the explore page (user|host)/risk-tab and check if the new user|host is present ### Checklist Delete any items that are not applicable to this PR. - [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
Create the Investigate plugin (naming TBD). Part of #183293, splitting up the work in several PRs. The investigate plugin is mostly a registry to allow plugins to register their widgets without creating dependency issues. --------- Co-authored-by: kibanamachine <[email protected]>
#184348) **Resolves: elastic/security-team#9516 ## Summary As a part of Serverless API reference documentation effort we need to have an ability to produce independent Serverless and ESS OpenAPI specification (OAS) bundles. This PR addresses this issue by adding a new custom property `x-labels` (applicable to OAS operation objects) representing an array of strings and bundling configuration option to exclude anything marked with specific labels. ## How does it work? Added functionality allows to mark **OAS operation object** (objects defined under an API endpoint path as a HTTP method like `get`, `post` and etc) with arbitrary labels by using `x-labels` custom property like in an example below ```yaml paths: /api/some_path: get: x-labels: - label1 - label2 ``` This labelling **DOESN'T** change produced bundle by itself. It's required to use bundler's `includeLabels` option to include API endpoint operation object(s). `includeLabels` accepts a list of labels. An operation object is included when it has a label matching labels passed to `includeLabels`. In mathematical terms operation object's labels set intersects with `includeLabels`. ## How to use it for producing separate Serverless and ESS bundles? - Mark OAS operation objects (HTTP methods like `get` or `post`) with `x-labels` custom property. An example below has all operation objects under `/api/some_path` path labeled with `ess` label as well as operation objects under `/api/another_path` path. On top of that `GET /api/another_path` has `serverless` label as well. ```yaml ... paths: /api/some_path: get: x-labels: [ess] ... post: x-labels: [ess] ... /api/another_path: get: x-labels: [ess, serverless] ... post: x-labels: [ess] ... ... ``` - Configure bundler with bundling options to include specific labels. `options.includeLabels` is responsible for including document nodes labeled with specific labels. You need two bundler invocations with different `options.includeLabels` values like below ```js bundle({ // (1) ... options: { includeLabels: ['serverless'], }, }); bundle({ // (2) ... options: { includeLabels: ['ess'], }, }); ``` It will produce two following bundles (1) for Serverless ```yaml ... paths: /api/another_path: get: ... ... ``` and (2) for ESS ```yaml ... paths: /api/some_path: get: ... post: ... /api/another_path: get: ... post: ... ... ``` You may notice (2) has everything included since each operation object is labeled with `ess` label.
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )