## Summary
This PR reworks saved query privileges to rely solely on a single global
`savedQueryManagement` privilege, and eliminates app-specific overrides.
This change simplifies the security model for users, fixes bugginess in
the saved query management UI, and reduces code complexity associated
with maintaining two separate security mechanisms (app-specific
overrides and global saved query management privileges).
### Background
Saved queries allow users to store a combination of KQL or Lucene
queries, filters, and time filters to use across various applications in
Kibana. Access to saved query saved objects are currently granted by the
following feature privileges:
```json
[
"feature_discover.all",
"feature_dashboard.all",
"feature_savedQueryManagement.all",
"feature_maps.all",
"feature_savedObjectsManagement.all",
"feature_visualize.all"
]
```
There is also a saved query management UI within the Unified Search bar
shared by applications across Kibana:
<img
src="https://github.com/user-attachments/assets/e4a7539b-3dd4-4d47-9ff8-205281ef50e3"
width="500" />
The way access to this UI is managed in Kibana is currently confusing
and buggy:
- If a user has `feature_discover.all` and `feature_dashboard.all` they
will be able to load and save queries in Discover and Dashboard.
- If a user has `feature_discover.all` and `feature_dashboard.read` they
will be able to load queries in both Discover and Dashboard, but only
save queries in Discover (even though they have write access to the SO,
and API access). Instead they have to navigate to Discover to save a
query before navigating back to Dashboard to load it, making for a
confusing and frustrating UX.
- Access to the UI is even more confusing in apps not listed in the
above feature privileges (e.g. alerting, SLOs). Some of them chose to
check one of the above feature privileges, meaning users who otherwise
should have saved query access won't see the management UI if they don't
also have the exact feature privilege being checked. Other apps just
always show the management UI, leading to bugs and failures when users
without one of the above feature privileges attempt to save queries.
### Existing improvements
In v8.11.0, we introduced a new ["Saved Query
Management"](https://github.com/elastic/kibana/pull/166937) privilege,
allowing users to access saved queries across all of Kibana with a
single global privilege:
<img
src="https://github.com/user-attachments/assets/ccbe79a4-bd0b-4ed6-89c9-117cc1f99ee2"
width="600" />
When this privilege is added to a role, it solves the
`feature_discover.all` and `feature_dashboard.read` issue mentioned
above. However, it does not fix any of the mentioned issues for roles
without the new privilege. We have so far postponed further improvements
to avoid a breaking change.
### Approach
To fully resolve these issues and migrate to a single global privilege,
these changes have been made:
- Remove saved query SO access from all application feature privileges
and instead only allow access through the global saved query management
privilege.
- Stop relying on application feature privileges for toggling the saved
query management UI, and instead rely on the global privilege.
To implement this with minimal breaking changes, we've used the Kibana
privilege migration framework. This allows us to seamlessly migrate
existing roles containing feature privileges that currently provide
access to saved queries, ensuring they are assigned the global saved
query management privilege on upgrade.
As a result, we had to deprecate the following feature privileges,
replacing them with V2 privileges without saved query SO access:
```json
[
"feature_discover.all",
"feature_dashboard.all",
"feature_maps.all",
"feature_visualize.all"
]
```
Each area of code that currently relies on any of these feature
privileges had to be updated to instead access `feature_X_V2` instead
(as well as future code).
This PR still introduces a minor breaking change, since users who have
`feature_discover.all` and `feature_dashboard.read` are now able to save
queries in Dashboard after upgrade, but we believe this is a better UX
(and likely the expected one) and worth a small breaking change.
### Testing
- All existing privileges should continue to work as they do now,
including deprecated V1 feature privileges and customized serverless
privileges. There should be no changes for existing user roles apart
from the minor breaking change outlined above.
- Check that code changes in your area don't introduce breaking changes
to existing behaviour. Many of the changes are just updating client UI
capabilities code from `feature.privilege` to `feature_v2.privilege`,
which is backward compatible.
- The `savedQueryManagement` feature should now globally control access
to saved query management in Unified Search for all new user roles.
Regardless of privileges for Discover, Dashboard, Maps, or Visualize,
new user roles should follow this behaviour:
- If `savedQueryManagement` is `none`, the user cannot see or access the
saved query management UI or APIs.
- If `savedQueryManagement` is `read`, the user can load queries from
the UI and access read APIs, but cannot save queries from the UI or make
changes to queries through APIs.
- If `savedQueryManagement` is `all`, the user can both load and save
queries from the UI and through APIs.
### Checklist
- [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]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
- [ ] 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)
- [x] 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
- [x] 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)
### Identify risks
This PR risks introducing unintended breaking changes to user privileges
related to saved queries if the deprecated features have not been
properly migrated, and users could gain or lose access to saved query
management on upgrade. This would be bad if it happened, but not overly
severe since it wouldn't grant them access to any ES data they couldn't
previously access (only query saved objects). We have automated testing
in place to help ensure features have been migrated correctly, but the
scope of these changes are broad and touch many places in the codebase.
Additionally, the UI capabilities types are not very strict, and are
referenced with string paths in many places, which makes changing them
riskier than changing strictly typed code. A combination of regex
searches and temporarily modifying the `Capabilities` type to cause type
errors for deprecated privileges was used to identify references in
code. Reviewers should consider if there are any other ways that UI
capabilities can be referenced which were not addressed in this PR.
Our automated tests already help mitigate the risk, but it's important
that code owners thoroughly review the changes in their area and
consider if they could have unintended consequences. The Platform
Security team should also review this PR thoroughly, especially since
some changes were made to platform code around privilege handling. The
Data Discovery team will also manually test the behaviour when upgrading
existing user roles with deprecated feature privileges as part of 9.0
upgrade testing.
---------
Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
Co-authored-by: Matthias Wilhelm <ankertal@gmail.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
That way we can internally link to this beautiful section using
`<<angle-brackets-and-stuff>>`
---------
Co-authored-by: florent-leborgne <florent.leborgne@elastic.co>
This PR:
- updates navigation instructions to accommodate for the navigation
changes related to solution views.
- updates instructions for adding sample data to rely on the
integrations page instead of the home page, that only exists with the
classic solution view
- updates references to the home page to avoid confusing users using one
of the new solution views
Closes: https://github.com/elastic/platform-docs-team/issues/529
Closes: https://github.com/elastic/platform-docs-team/issues/540
## Summary
Closes: https://github.com/elastic/kibana/issues/169622
Field caps request caching - implement `stale-while-revalidate` cache
headers and etags with 304 responses as appropriate.
This PR accomplishes
- Adds 304 Not Modified to http server
- Adds refresh button to data view management that force refreshes field
list
- Adds `/internal/data_views/fields` endpoint which supports caching.
- This is necessary since `fields_for_wildcard` doesn't support caching
due to POST requests
- Adds `stale-while-revalidate` header directive UNLESS field list is
empty.
- Uses Vary header with hash of user id to force requests when user has
changed.
- Unchanged field list responses won't recreate data view field list
### How to test
1. Pop open the dev tools to the network tab and make sure 'Disable
cache' is unchecked. filter for 'fields' requests
2. Load more than one data set (sample data is fine)
3. Go to discover
4. Switch selected data views. Notice status code on first load vs
subsequent loads
5. Open a new window, notice loading from cache
6. Push document that changes field list. You'll need to wait for cache
to expire for it to load. The default is 5s.
7. Notice that field list loads after cache is old properly result in
304 response.
8. Set `data_views:cache_max_age`, shift reload. No field requests will
be cached.
#### Note on Safari
Safari doesn't support the `stale-while-revalidate` directive.
Additionally, the Safari dev console shows 304 responses as 200's. I
figured this out by adding console statements to the fields endpoint. As
best I can tell, Safari won't be performant on slow clusters but its
also no slower than it was before this PR. Safari does respect the
disabling of cache headers.
## Release note
Data View field list requests are now cached with a
`stale-while-revalidate` strategy. This means that after the initial
field list request, all subsequent requests return the cached response
which is very fast. If the cache is determined to be stale then the
cache will update in the background and new data will be available on
the next request.
This behavior can be modified via the `data_views:cache_max_age` Kibana
advanced setting. Setting it to zero will disable the cache. All other
values (in seconds) will be used to determine whether the cache is
stale. The default value is 5 seconds.
The field list can be manually updated via the refresh button in data
view management or a hard refresh with your browser.
Note for Safari: The `stale-while-revalidate` cache directive is
unsupported, therefore it makes additional requests. If this is
impacting Kibana performance then try Chrome or Firefox.
Data View Management
<img width="1064" alt="Screenshot 2024-01-09 at 1 36 20 PM"
src="f272c19f-81b4-4697-9303-b1f8f150e2b9">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
Co-authored-by: amyjtechwriter <61687663+amyjtechwriter@users.noreply.github.com>
Co-authored-by: Julia Rechkunova <julia.rechkunova@elastic.co>
Co-authored-by: Julia Rechkunova <julia.rechkunova@gmail.com>
## Summary
Two pages about ES|QL added to the Kibana guide. One page (titled ES|QL)
under the 'Kibana concepts' heading, which is an overview page. One page
added to the 'Discover' section (titled Try ES|QL) which is a short
tutorial.
Relates to:
[#244](https://github.com/elastic/platform-docs-team/issues/244)
---------
Co-authored-by: Abdon Pijpelink <abdon.pijpelink@elastic.co>
https://github.com/elastic/elasticsearch/pull/97865 expands
index-pattern expressions to include a cluster alias for purposes of
excluding an entire cluster from a cross-cluster search. This allows
users to put the minus sign in front of the cluster name
(`-cluster_one:*`). The advantage to this change is that it avoids
sending any network calls to that cluster. Compare this to the existing
syntax for excluding clusters, where the minus sign is in front of the
index name (`cluster_one:-*`). The older syntax has to send the request
to the remote cluster, which if it is down (and skip_unavailable=false),
will cause the search to fail.
This PR updates the docs to reflect the new syntax.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds documentation for:
- Drag and drop from Available Fields list
- Wildcards in field searches
- All sources and matching sources in Create Data View
## Summary
This PR updates the data view doc to include more information about
temporary data views.
Closes#144582
Co-authored-by: Kaarina Tungseth <kaarina.tungseth@elastic.co>
* [DOCS] Adds content on ad hoc data view
* [DOCS] Breaks data into two steps
* Update docs/concepts/data-views.asciidoc
Co-authored-by: Kaarina Tungseth <kaarina.tungseth@elastic.co>
* [DOCS] Tweaks message re: unsaved data views
Co-authored-by: Kaarina Tungseth <kaarina.tungseth@elastic.co>
* [DOCS] Fixes inconsistency with role management link
* Update docs/redirects.asciidoc
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
* [DOCS] Changes index pattern to data views in intro docs
* [DOCS] Updates image of data views UI
* [DOCS] Removes faulty sentence
* [DOCS] removes sentence about index patterns
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [data.search.autocomplete] Move autocomplete method to UI settings
* Use select rather than boolean
* Add ftue tour
* Make a select rather than text box
* Only show when focused and first time page is loaded
* Add docs link
* Reverse order of sections
* Update docs/concepts/index.asciidoc
Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com>
* Update docs/concepts/index.asciidoc
Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com>
* Docs updates
* setting
* telemetry
* Add links to docs
* Fix translations
* Fix failing test
* Fix test
* Fix tests
* Revert changes to querybar service
* Fix discover query
Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com>
Co-authored-by: Liza K <liza.katz@elastic.co>
* [DOCS] Updates screenshots to show new theme
* [DOCS] Updates more screenshots in Discover docs
* [DOCS] Updates screenshot for license management
* [DOCS] Attempt to make the screenshots more readable
