Fixes https://github.com/elastic/kibana/issues/154657 (Also heatmap
layer has the same problem)
ILayer has 2 methods to determine loading state:
* isInitialDataLoadComplete
* isLayerLoading
When `isInitialDataLoadComplete` returns true for all layers, the map
signals that it's ready for reports to be captured. The root cause of
the problem is that the raster layer implementation did not provide an
`isInitialDataLoadComplete` implementation for tiled maplibre sources.
Therefore raster_tile_layer.ts would return true before all raster
images are loaded, allowing reporting to capture an image with missing
tiles.
Having `isInitialDataLoadComplete` and `isLayerLoading` and spreading
duplicate tiled implementations across layer classes contributed to the
problem.
PR:
* removes `isInitialDataLoadComplete` from ILayer interface (supports
long term goal of making ILayer simpler).
* updates `isLayerLoading` to signal loading when layer is not
initialized yet. This required calls to ensure layer is visible and
displayed at zoom level before calling `isLayerLoading`, since
`isLayerLoading` will now return true if no data has been loaded for a
layer.
* renames `areLayersLoaded` -> `isMapLoading` to be more symmetrical
with ILayer.isLayerLoading method name and return value.
<img width="400" alt="Screen Shot 2023-04-10 at 2 04 28 PM"
src="https://user-images.githubusercontent.com/373691/230987781-2dfc68b7-f9bb-4ba6-8ab3-aaff5ea36859.png">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Ref https://github.com/elastic/kibana/pull/154110
- Ensure we throw when the product versions API responds with an
unsuccessful status code
- Add tests for various success/failure cases around the agent versions
list build step.
cc @jen-huang
Closes https://github.com/elastic/kibana/issues/154326
## Summary
After the merge of https://github.com/elastic/kibana/pull/153226, when
creating/updating a Logstash output as default, the `Elastic Cloud agent
policy` preconfigured on Cloud gets reassigned to the "default" ES
policy instead than keeping the `Elastic Cloud internal output`.
<img width="1418" alt="Screenshot 2023-04-04 at 12 51 21"
src="https://user-images.githubusercontent.com/16084106/230112067-a2767d1a-1191-4877-8dec-546d1590e41f.png">
Tee bug is fixed by checking if any given fleet server policy is
`preconfigured` or if it has already an assigned `data_output_id`, in
which cases it doesn't get updated.
### Testing
- Create an ES output additional to the default one
- Create a preconfigured fleet server policy and make sure it has
`fleet-server` integration (this is to simulate the preconfigured cloud
policy)
- Assign the previous output to the preconfigured policy
- Now create a new `logstash` output and make it default
- Check that the preconfigured policy maintains the custom output
previously assigned
### 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
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Nicolas Chaulet <nicolas.chaulet@elastic.co>
## Summary
_Please review with [whitespace
ignore](https://github.com/elastic/kibana/pull/154612/files?diff=unified&w=1)!_
In #143097 the conditional for showing `Advanced options` was removed as
we introduced experimental indexing toggles which are always shown.
However in #148418 (8.7) we put the indexing toggles behind a feature
flag. This caused the `Advanced options` toggle to always be shown
regardless of there is any content underneath. I spotted this while
testing something unrelated.
This PR fixes that by adding a condition back that is based on
aggregating the conditionals of everything underneath (existence of
advanced vars, whether pipelines & mappings are shown, and if
experimental indexing toggles are enabled).
- Adds a `Filter fields` popover selector inspired by EUI's data grid
column picker to toggle inclusion of fields into grouping.
- Moves the `Group results` switch and the `Filter fields` popover on
the same level as the progress controls.
- Adapts the `explain_log_rate_spikes` API endpoint to support
retrieving a grouping update only.
- Hides the pagination footer for the results tables if there's less
results than the current page size.
- Refactors individual helpers to manage the `random_sampler`
aggregation into a single reusable wrapper. The helper's factory can be
supplied with either a sample probability right away or a document count
to generate a dynamic sample probability based on it.
- Applies random sampling to the main date histogram chart.
## Summary
Fixes https://github.com/elastic/kibana/issues/154035
This PR removes the saved objects client from the client-side code of
the Watcher plugin. It seems not to be used anywhere so the removal
should not cause any changes to the UI.
To test this PR, it should be enough to create/update/delete a couple of
simple and advanced watches.
Adds EUI theme props for zindex and reposition on scroll to the `select
type` and `controls` dashboard toolbar items so that they reposition
properly and don't overlap the header.
[Security Solution] Rule Details navigation breadcrumb for Deleted Rules
doesn't allow navigation back to Rules page when no previous alerts
exist
Resolves https://github.com/elastic/kibana/issues/149543
### Loom/Screenshot Demo
* **How to reproduce the issue:**
https://www.loom.com/share/7e4b59de092b44b8b248e3e3c5160882
* **Fix:** https://www.loom.com/share/c24bd15eb67841489c4f5ddc5cae6bad
---
This code was written and reviewed by GitStart Community. Growing future
engineers, one PR at a time.
---------
Co-authored-by: KlingerMatheus <klinger.matheus@gitstart.dev>
Co-authored-by: gitstart_bot <gitstart_bot@users.noreply.github.com>
Co-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>
Co-authored-by: LuisChiej <54555805+LuisChiej@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Security solution changed recently their alert tables to the alert table
provided by ResponseOps. For this reason, I removed the experimental
badge from the cases alerts table in the security solution and mark it
as GA.
### 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)
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/152140
## Summary
Updates the following functions in the Rules Client to re-use the API
key in context and avoid having the system invalidate them when no
longer in use:
- bulk_delete
- bulk_edit
- clone
- create
- delete
- update
- update_api_key
Also adds a new field to the rule SO to help determine when whether an
api key was created by a user or created by us.
### 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
### To verify
- Follow these
[instructions](https://www.elastic.co/guide/en/kibana/master/api-keys.html#create-api-key)
to create an api key. Make sure to copy your api key
- Run the following
```
curl -X POST "http://localhost:5601/api/alerting/rule/" -H 'Authorization: ApiKey ${API_KEY}' -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d'
{
"rule_type_id": "example.pattern",
"name": "pattern",
"schedule": {
"interval": "5s"
},
"actions": [
],
"consumer": "alerts",
"tags": [],
"notify_when": "onActionGroupChange",
"params": {
"patterns": {
"instA": " a - - a "
}
}
}'
```
- Verify that the request returns a rule
with`"api_key_created_by_user":true`
- Try this with the other rules clients functions listed above to verify
that you can manage alerting rules when authenticated with an api key
- Verify that `"api_key_created_by_user":false` when you remove the api
key header and add `-u ${USERNAME}:${PASSWORD}` to authenticate
This PR does some clean up and adds some validation.
Notable changes
- Removes unused operation code
- Adds check to ensure that only a single file can be contained in a
file attachment
- Adds some testing
- Modifies the LimitChecker to use the file service to determine how
many files are attached to a case
This commit fixes an issue introduced in
https://github.com/elastic/kibana/pull/142741 where the time bounds were
computed in an expression `time_scale` that can be run on both the
server and the client.
Computing time-related information on each side (server/client), means
that we need to align temporarily with the client timezone to make an
effective calculation.
This temporary alignment had a bug when executed on the client: the
the first time it gets completed, the restored timezone was the wrong
timezone, in particular, the function used to get the current configured
timezone `moment().zoneName()` return abbreviated zone names and in some
cases also non-unique abbreviations (see
https://momentjs.com/timezone/docs/#/using-timezones/formatting/) making
the restoration a bit difficult and problematic.
The fix instead did the following:
- replace the `moment().zoneName()` with `moment.defaultZone?.name` even
this is not typed, this property is exposed by moment [since years
now](2448cdcbe1/moment-timezone.js (L603))
and is the only way to get the `defaultZone` configured through the
`setDefault`.
- replace the try/catch/finally block with a more readable
implementation: using a "safe" implementation to update the timezone in
moment we can get rid of the try/catch and we can make it more linear.
fix#154309
The unit test was firstly tested with the old implementation (and it was
failing because the `zoneName` was returning `EDT` which is not a valid
IANA timezone and the timezone were set to `undefined`. With the new
implementation, it returns the specified timezone correctly. I haven't
tested the function itself because I don't know the internal details and
this is also out of the scope of the fix.
## Summary
Adjusts the `execute` response action output:
- File deletion notification is in yellow text on the Download button
component
- Execution Error output is not added if it's empty (only Execute
context and STDOUT would be shown)
- Execution Error output is expanded by default if it's included. Error
accordion will be positioned below the execution context accordion.
- Add some space between the download link and the rest of execution
accordions
- Zip file truncation is displayed in context under the output and error
accordions if applicable
- Execution output accordion is at the bottom
- current working directory text will say "Executed from: /path/path"
In addition:
- Endpoint Emulator CLI too was enhanced to recognize two additional
tokens in the action's `comment` that will impact the `execute` response
output:
- `EXECUTE:FAILURE` - will respond with an `execute` error output
- `EXECUTE:SUCCESS` - will respond with an `execute` success output
Fixes#150615Fixes#147944
## Summary
Takes care of wrapping and overflowing of panels on small screens or
when monitor test run flyout is open in push mode.
The PR addresses the Monitor Overview, Management, Monitor Details and Monitor Add/Edit
pages.
**Related to:** https://github.com/elastic/security-team/issues/6268
(internal)
## Summary
For each of our Saved Object types, we must:
1. Remove any SO field mappings with `index: false` (or `enabled:
false`, although a first pass was done in
https://github.com/elastic/kibana/pull/149102) from our SO `mappings`
declarations
2. Audit and remove any _unused_ SO fields to minimize our footprint
This PR addresses these two requirements for this `security-rule` saved
object type (prebuilt rule asset).
## Details
Specifically, the PR removes the `name` field from the mappings because:
- We don't filter, sort, search, or aggregate by it.
- We might need to do it in the future for our prebuilt rule
upgrade/installation workflows, but for now we're going to implement
filtering, sorting, and pagination on the client side, thus there's no
need for this mapping server-side.
<img width="1295" alt="Screenshot 2023-04-05 at 15 19 10"
src="https://user-images.githubusercontent.com/7359339/230094740-706a9a78-fec3-469e-a4ad-e8b7d7309c78.png">
Also, we may need to add more fields to this mapping in the future to
implement further improvements for the prebuilt rule installation,
upgrade, or deprecation workflows.
### Checklist
- [ ] [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] The unit test for SO mapping hashes has been updated.
- [ ] More tests will be added as part of
https://github.com/elastic/kibana/issues/148176 and
https://github.com/elastic/kibana/issues/148192
