## About the changes
According to our docs, we only support up to 1 decimal place for
weights. This is to use integers to represent the percentages (we divide
them by 10) and supporting more decimals results in bad maths due to
floating point arithmetics.
This PRs adds Frontend and Backend validations to enforce this
restriction
Closes#2222
## Discussion points
Should we reconsider supporting more decimal places, that door remains
open, but for now we'll just adhere to our documentation because that
change would require some development.
## About the changes
To avoid showing too much data in the traffic screen, limit the number
of results to `topk`.
## Discussion points
Top 10 is a rule of thumb, but maybe we could do top 25. Until we gather
more data, I believe this should be good enough
## What
This change updates some places in the docs where we use the terms
"login" and "logout" incorrectly.
A "login" is a noun, typically referring to the set of credentials you
need to _log in_ to a service. The verb form, the act of signing in, is
written in two words: to "log in".
A similar logic applies to "logout" and "log out", although I don't find
the term "logout" in my dictionary. However, I think it makes sense to
talk about "logout requests" (and I see references to logout in other
services and documentation), so I'm happy to use that as a noun.
Regardless, the act of logging out is to "log out".
Today we have two functions that wrap our paths with the subpath. Since
all of our customers are hosted on a subpath, such as /eubb1001, we need
to account for this path when building API paths and asset paths.
These functions could be smarter, we could, for example detect if we
have already added the base path and ignore it if it already exists.
**This PR implements this and adds 2 capabilities:**
1. If there is list of paths that need to be joined and one is subset of
another, it is removed.
2. All duplicate paths in the list are removed
## About the changes
This PR improves our queries to Prometheus (instead of making multiple queries do only one) and improves the UI and the code.
The reports aggregate all HTTP methods (GET, POST, PUT, DELETE, OPTIONS, HEAD and PATCH) without distinction under the same "endpoint" (a relative path inside unleash up to a certain depth)
Co-authored-by: Nuno Góis <nuno@getunleash.ai>
Adds lazy loading to the network routes, so we end up with smaller
chunks in the build.
Also adds a `start:prod` script that can prove useful to test the chunk
loading behaviour locally.
## What
We've already added the backend for this. This is the initial work for
drawing a chart for instance traffic in the frontend. It requires the environment variable `PROMETHEUS_API` set to a valid prometheus-query-language (promql) supported backend, such as Prometheus itself or Victoria Metrics. Besides, at the moment we're hiding this functionality behind the flag `UNLEASH_EXPERIMENTAL_NETWORK_VIEW` which has to be set to true
Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
Co-authored-by: Gastón Fournier <gaston@getunleash.ai>
In this PR we remove the general SettingService cache, as it will not
work across multiple horizontal unleash instances, events are not
published across.
We also fix the CORS origin to:
- Access-Control-Allow-Origin set to "*" if no Origin is configured
- Access-Control-Allow-Origin set to "*" if any Origin is configured to
"*"
- - Access-Control-Allow-Origin set to array and have the "cors"
middleware to return an exact match on the user provided Origin.
Co-authored-by: Fredrik Oseberg <fredrik.no@gmail.com>
https://linear.app/unleash/issue/2-514/fix-issues-with-conditionally-hidden-table-columns
This upgrades the old `useHiddenColumns` to a new
`useConditionallyHiddenColumns`. This implementation covers some issues
and edge cases, and should hopefully be the standard way of achieving
responsive visibility for table columns from now on.
Some of these issues included incorrectly showing/hiding table columns,
whether when resizing the window or at page load, even when the proper
conditions were met to toggle their visibility.
This PR adapts the tables that were already using `useHiddenColumns` to
use the new approach.
I'll create a new PR after this one to adapt our other existing tables
to use this new approach as well.
