This PR introduces a configuration option (`authentication.demoAllowAdminLogin`) that allows you to log in as admin when using demo authentication. To do this, use the username `admin`.
## About the changes
The `admin` user currently cannot be accessed in `demo` authentication
mode, as the auth mode requires only an email to log in, and the admin
user is not created with an email. This change allows for logging in as
the admin user only if an `AUTH_DEMO_ALLOW_ADMIN_LOGIN` is set to `true`
(or the corresponding `authDemoAllowAdminLogin` config is enabled).
<!-- Does it close an issue? Multiple? -->
Closes#6398
### Important files
[demo-authentication.ts](https://github.com/Unleash/unleash/compare/main...00Chaotic:unleash:feat/allow_admin_login_using_demo_auth?expand=1#diff-c166f00f0a8ca4425236b3bcba40a8a3bd07a98d067495a0a092eec26866c9f1R25)
## Discussion points
Can continue discussion of [this
comment](https://github.com/Unleash/unleash/pull/6447#issuecomment-2042405647)
in this PR.
---------
Co-authored-by: Thomas Heartman <thomasheartman+github@gmail.com>
This PR removes the previous "my projects" filter in favor always
splitting projects, but showing both on the main screen.
To make it a bit easier to work with, it also moves the project group
component into its own file, causing some extra lines of code change. My
apologies 🙇🏼
## About the changes
Adds a summary card that sums up data usage for selected month, and for
Pro shows monthly quota and badge color according to monthly quota
This change adds filtering functionality to the project list filter
buttons.
In this case, "my projects" is defined as any project that is marked as
a favorite OR (inclusive or) that you are a part of, as defined by your
user profile.
Loading state for
- charts (placeholder data, animation)
- user stats - loading skeleton animation
- empty flags stats
- kept other "stat" widgets as-is, usually not visible
This PR adds the buttons (only UI, no functionality) to show either "all
projects" or "my projects".
The buttons use a styled button group and are hidden behind the new
`projectListFilterMyProjects` flag.
The button placement breaks with the previously established page header
pattern of having all actions moved to the right. To accommodate this
new placement, I created a new flex container in the header called
`leftActions`, which is essentially just a mirror of the normal actions.
I went with `leftActions` instead of `inlineStartActions` or something
similar because I think it's clearer, and I don't see us adapting
Unleash for different writing directions right now. We can always change
it later.
I have also slightly increased the end margin of the page header to
accommodate the new designs and to adjust the spacing before the
buttons. I adjusted the margin of the text instead of the padding of the
left actions because this will keep the spacing to the page header the
same on every page. Without it, we could end up in situations where the
spacing changes from page to page based on whether it has left actions
or not, which is probably undesirable.
## Still to do:
### Hover colors
~~Find out what the right hover color variable is. I'm using the light
mode hover color for now, which works well in both light and dark modes
(looks nice and is AAccessible), but it's not the same as the hover
color for other buttons in dark mode.~~
Fixed ☝🏼
### Small windows
Also worth noting: at around 500px, the layout shift starts to cause
problems and we end up with overlapping elements. How do we want to deal
with narrower screens? Today, the UI is pretty functional until we reach
about 250px. It would be nice to not increase that size.
The new version breaking at about 500px:
The old version breaking at about 250px:
### Margins
We also need to figure out how much space we want on smaller windows:
This change specifies the update type as `replace` for the
`useQueryParams` hook used to set table state.
Primarily, this prevents the column selection from being added to the
browser
history and more importantly prevents you from changing your config by
navigating through browser history.
However, this also affects other table state, such as changing sorting
order etc. These will also no longer be added to the browser history.
---
Bug description:
In the project flag table, you can select which env columns to show.
However, adding and removing these envs get added as steps in your
browser history. This means that if you add 3 envs, you:
1. have to go back three times to get back to the previous page
2. In doing so, you also inadvertently revert the choices you mean,
which can be confusing.
Steps to reproduce:
1. Navigate to the project screen
2. Use the column selector to add/remove projects. Notice that the URL
changes for each selection you make.
3. After making one or more changes, use the browser's
back-functionality. Notice that you stay on the same page but that the
selected envs (and the URL) change.
This adds replace: true to navigate on the create feature toggle screen
and create project screen. This will make it so you don't go back to the
form after you have created the resource, replacing the entry in the
history with the new url. We can do this in more places, but some of
them require a bit more thought. For example when creating a user, you
navigate from the admin screen to the user page, and then back to the
same screen. Adding `{ replace: true }` in this context makes it so that
when you press back you end up on the same screen, because it's recorded
twice in history.
Another discussion point:
* Would you expect the edit screens to also replace the history?
This PR changes the behavior of the project tables' environment columns
based on input from customers.
Up until now, you have been shown either the first project or the first
three projects in the list of the project's environment. The decision on
whether to show one or three is based on screen size. The breakpoint
appears to be about 1280px. Above that you get three, below it you get
one.
With this PR, we'll show you *all* environments by default, regardless
of screen size. However, that's just for the default values. If you
manually change column visibility, those changes will of course be
respected.
I've used a new package, `css-mediaquery`, to test that all screen sizes
show all envs.
Previously, the dummy data would persist when there is no data coming
from the API. This causes us to display dummy data in the dora metrics
table which is not correct. This PR fixes that by only showing the
loading features when we are actually loading.
Fills datasets that do not have all the datapoints with 0 so that every
line in the graph starts at the beginning and ends at the end of graph.
Closes #
[1-2256](https://linear.app/unleash/issue/1-2256/fill-the-data-with-0s-so-that-all-x-axis-labels-have-values)
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Co-authored-by: Tymoteusz Czech <2625371+Tymek@users.noreply.github.com>
API returns both value and values fields. Empty values array causes ui
to think constraint doesnt have a value
This PR checks if value field exists and is empty before returning check
on values and length
Converts `newContextFieldUI` release flag to
`disableShowContextFieldSelectionValues` kill switch.
The kill switch controls whether we show the value selection above the
search filed when > 100 values
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Currently the median time to production stat is showing the aggregated
median across all dates.
This pr changes the calculation to only use the last week summary like
the rest of the stat widgets.
<img width="1665" alt="Screenshot 2024-04-03 at 11 25 31"
src="https://github.com/Unleash/unleash/assets/104830839/c6869b48-99bd-4f5b-a25e-7e0e3a2dc9ef">
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Make the tooltip for project selection in the playground work properly
again. Right now, it doesn't work due to an error in react refs.
Because we wrap this in a tooltip in the Playground, we need to forward
the ref to the underlying component.
This follows the steps outlined in
https://mui.com/material-ui/guides/composition/#caveat-with-refs
Provides store method for retrieving traffic usage data based on
period parameter, and UI + ui hook with the new chart for displaying
traffic usage data spread out over selectable month.
In this PR we copied and adapted a plugin written by DX for highlighting
a column in the chart:
There are some minor improvements planned which will come in a separate
PR, reversing the order in legend and tooltip so the colors go from
light to dark, and adding a month -sum below the legend
## Discussion points
- Should any of this be extracted as a separate reusable component?
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
Preview (eye icon) on a segment in "targetting" when creating or editing
a strategy now corectly shows details of a segment.
Previously it was not showing constraints present in this segment
This PR fixes a bug where editing the default strategy would not refresh
the resource it was depending on to display the data. This also surfaces
another issue, which is that project settings is using data from the
getProjectOverview hook to display the default strategies in each
environment. This should be it's own resource, but that is beyond the
scope of this PR.
This change makes the tooltip still render values and headers that are
`N/A` (instead of not rendering them at all).
This makes the tooltip more consistent and predictable. At least to
me, it was confusing that some of the values were just hidden sometimes.
I've also added a test to make sure that the tooltip renders the N/A
values.
This is what it looks like now:
Various ui enhancements
Aggregates the time to production and metrics summary by averaging by
date across all projects to get the value. Creates a single dataset for
the aggregation. This makes theme behave like eg the Health chart
(showing aggregated graph when show all projects and per project when
not)
Gradient fill when all projects across all related charts
Attached recording with generated data for 3 months
https://github.com/Unleash/unleash/assets/104830839/7acd80a8-b799-4a35-9a2e-bf3798f56d32
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
This PR fixes these errors (that were showing up in the dev console) in
the insights pages:
- nesting a div within a p in the count header (flags, environments,
apps); instead flip the relationship and nest the p within the div
- missing keys in mapped components
- passing a boolean "scrolled" value to the underlying component (a div)
is invalid: instead, make it so that that prop is not passed
The only one of these that could have a visual impact is the first one
(p>div -> div>p), but it appears to be the same to me.
Here's before the change:
And here's after:
Ivar pointed out to me that this was intended as an enterprise only
feature. So this PR makes it an enterprise only feature. Conditionally
render the link in the normal user table, and use premium feature
component if you happen to hit the route and not be running on the
enterprise plan.
https://linear.app/unleash/issue/2-2022/improve-actions-validation
Improves our current actions form validation.
Empty actions are now ignored on the payload and we get errors in
actions where any of the required fields are empty.
Also refactored our current actions into a constant map that can be
shared across frontend and backend.
There was a typo in the original message, it said "Unleash Admin already
have" (either "admins already have," or "admin already has.")
Fixed it and improved the wording a little bit.
- style for headers in Insights dashboard and project selector
- fixed React element key issue in gauge chart
- fixed React attribute issue in Health stats
- active/inactive user stats from backend
This PR moves the CR specific logic out of the MultiActionButton and
generalises so that we can re-use it across the application. The CR
specific logic is moved into:
* ApplyButton.tsx
* ReviewButton.tsx
This fixes a bug where multi action button would be disabled if you
tried to apply an approved change request that you had created yourself.
This PR adds warning icons to the environment selector for environments
that have problems detected. However, because we don't have any way
detect problems yet, this PR only adds the icons and the infrastructure
to display them. They're always set to "not displayed" for now.
The icons have "problems detected" as accessible text.
It looks like this when you add them in (for every environment):
<img width="1137" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/c29bfa52-ddee-4b16-b3ac-5c1f8fcc326e">
In order to prevent users from being able to assign roles/permissions
they don't have, this PR adds a check that the user performing the
action either is Admin, Project owner or has the same role they are
trying to grant/add.
This addAccess method is only used from Enterprise, so there will be a
separate PR there, updating how we return the roles list for a user, so
that our frontend can only present the roles a user is actually allowed
to grant.
This adds the validation to the backend to ensure that even if the
frontend thinks we're allowed to add any role to any user here, the
backend can be smart enough to stop it.
We should still update frontend as well, so that it doesn't look like we
can add roles we won't be allowed to.
This PR adds an environment selector to the connected instances table,
using query parameters to store the environment selection.
I'm still using the old data to populate this, so it'll show you all
data when nothing is selected and only filtered data when you select an
env. There is no way to unselect an env at the moment: I'm not sure
that's something we'll need to do, so we'll handle that when we know.
I imagine in the future, we might update the component to make separate
calls per environments and a call to determine which envs are available,
but for now, this will do just fine.
<img width="848" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/ef7562d5-c0ab-48c6-ba43-7c0007719ab4">
This PR adds a new file "Application.tsx", which is analogous to the
existing Project.tsx file in that it contains the base layout for the
application page, as well as tabs pointing to sub pages. Currently, the
overview tab uses a paragraph with some fallback text, while the
connected instances table displays the instances table.
I have mostly copied the existing ApplicationEdit component and used
that as a base, assuming that we'll delete that component when we're
done with this.
<img width="1449" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/ac574a83-3cf4-4de5-a4de-188575074ecb">
This PR adds a first iteration of the connected instances table on a new
connected instances tab of the application page (hidden behind a flag).
As a first version, it only uses data that we currently return for each
application (so no "connected through" or "last synchronized").
It also uses the existing version of the application data and just
filters it for the "production" environment right now.
Adding query parameters (and potentially a new URL?) to the applications
page (to save state and fetch data) will be done in a follow-up. This
should lay the groundwork for adding a new API too.
<img width="1485" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/4fb68456-d0f5-4f82-9246-5333a273df9c">
## About the changes
This is a rough initial version as a PoC for a permission matrix.
This is only available after enabling the flag `userAccessUIEnabled`
that is set to true by default in local development.
The access was added to the users' admin page but could be embedded in
different contexts (e.g. when assigning a role to a user):
This is how the matrix looks like
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
The current approach uses adds an extra parameter to the components and
passes it through from the parent components. It's never a lot of
levels, so it feels alright, but it's feels like a bit of a code smell.
I wonder if it would make sense to use a context for each change
request? 🤔
Supersedes: https://github.com/Unleash/unleash/pull/6181
This PR updates the way we show deleted strategies in the CR UI. Instead
of showing just the strategy name and a diff on hover, we show the same
strategy config as we do for new and updated strategies.
This makes it easier to see what you have deleted.
In doing so, it also fixes two issues:
1. inconsistent border radius for segment changes listed. Due to an
override in `frontend/src/themes/theme.ts`, these would get a border
radius of `theme.shape.borderRadiusLarge` instead of
`theme.shape.borderRadiusMedium`. It does this by adding a class and
making the selector more specific.
2. The background was unset for the strategy rollout box and constraint
item boxes.
It looks like this:
<img width="728" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/7cba28ac-0454-444d-8cfa-f46543ccf2dc">
<img width="728" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/832be653-3def-4afc-b72f-36fcd76ad83d">
Or with more kinds of strategies:
<img width="454" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/f18e5482-7d2e-4cbd-8177-9de6dfb10307">
Note: I'm happy to isolate the color changes to a separate PR if that's
preferable.
Created a build script that generates orval schemas with automatic
cleanup. Also generating new ones.
1. yarn gen:api **(generates schemas)**
2. rm -rf src/openapi/apis **(remove apis)**
3. sed -i '1q' src/openapi/index.ts **(remove all rows except first)**
This PR adds showing of env variant conflicts in change requests.
This is a simple solution that only compares the total state of
variants. We *could* potentially do a modified version where we show
each and every variant as its own property. Because variants have to be
unique by name and because their names can't be changed after their
creation, we could create a map of variant name to their data.
<img width="1105" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/0c67f958-6c4e-453a-9791-0e132fb1f23e">
This PR adds an endpoint to Unleash that accepts an error message and
option error stack and logs it as an error. This allows us to leverage
errors in logs observability to catch UI errors consistently.
Considered a test, but this endpoint only accepts and logs input, so I'm
not sure how useful it would be.
React can sometimes be non-intuitive and behave erratically due to the
way it detects changes in hook dependencies.
This prevents infinite re-renders from `useIncomingWebhooks` by using a
static `DEFAULT_DATA` constant, so that its reference is always the
same, so no changes are detected when there are none.
Unrelated scouting, but this PR also removes an unneeded dependency in
the memoized columns in `ProjectActionsTable`.
Adds a new Inactive Users list component to admin/users for easier cleanup of users that are counted as inactive: No sign of activity (logins or api token usage) in the last 180 days.
---------
Co-authored-by: David Leek <david@getunleash.io>
Use React's context to track how many CRs are moved into their next
state with conflicts present.
This PR wraps environment change requests and change request overviews
in a change request plausible context that contains a
`willOverwriteStrategyChanges` property. This property is updated by the
diff calculation if there are any conflicts and then read by the
`changeState` function in the `useChangeRequestApi` hook.
As long as at least one of the strategies in the CR contain conflicts,
it will be marked as overwriting changes.
We had to make some updates to let the compiler know about the types and
fix an issue with nested objects not being compared as objects (instead
as strings), but this saves us a few lines and is hopefully more
readable.
The `FeatureToggleListTable` is nested directly within `PageContent`.
`PageContent` was cause for removing the skeleton from the table.
However, this is unnecessary because the table has its own loader that
manages the skeletons. Therefore, `PageContent` does not require a
loader.
This PR adds a 'change-request-conflict-created' event whenever someone
save a strategy update for a strategy that's used in either pending or
scheduled change requests.
Data for pending change requests will only be sent if change requests
are enabled. Data for scheduled change requests will be sent regardless.
Getting this data is somewhat involved, so I've extracted as much of the
logic into a separate file as possible.
The event re-uses the existing `change_request` metric and sends the
following data for each change request that we discover conflicts on:
```ts
{
state: ChangeRequestState,
changeRequest: string, // <unleash identifier>#<change request id>
action: 'edit-strategy',
eventType: 'conflict-created'
}
```
There's only one action for this for now, but we could expand this event
to things such as strategy deletion, feature archival, in the future.
That said, I'd be happy to take it out.
## Discussion points
### Has the strategy actually been updated?
This does not check whether a strategy has actually changed before
emitting the event, only that you save your strategy changes.
This assumes that most people will simply close the modal by
clicking/tapping outside it or using the escape key instead of pressing
save.
However, it will likely lead to some false positives. If we think that
is an issue, I would suggest adding a check that something in the
strategy has actually changed in a follow-up PR.
Added conflict count to CR metrics and CR id.
Something to think about:
There was idea that we can aggregate this data based on CR id, but CR id
is just a number from 0 to x. So it will not be unique across instances.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
Includes some small fixes and improvements to the actions table UI:
- Fix webhook icon not properly loading
- Make actions execution param names bold in the tooltip
- Make filters param names bold in the tooltip
Only triggers if there is any rows in client instances that have
sdk_version: unleash-edge with version < 17.0.0
The function that checks this memoizes the check for 10 minutes to avoid
scanning the client instances table too often.
This PR fixes a bug in the displayed value of the conflict list so that
it shows the value it would update to instead of the snapshot value.
In doing so, it updates the logic of the algorithm to:
1. if the snapshot value and the current value are the same, it's not a
conflict (it's an intended change)
2. If the snapshot value differs from the current value, it is a
conflict if and only if the value in the change differs from the current
value. Otherwise, it's not a conflict.
The new test cases are:
- it shows a diff for a property if the snapshot and live version differ
for that property and the changed value is different from the live
version
- it does not show a diff for a property if the live version and the
change have the same value, even if the snapshot differs from the live
version
- it does not show a diff for a property if the snapshot and the live
version are the same
I noticed some manual `hasAccess` usages in permission guards due to the
fact that `PermissionGuard` does not accept `project` and `environment`.
This PR adds this support to `PermissionGuard` so we can adapt these
`hasAccess` checks to use it instead, adding consistency and cleaning
things up.
This PR does not include these adaptations however, it only adds the
optional properties to the component. We can address these at a later
point.
Connected to [#5932](https://github.com/Unleash/unleash/pull/5932) -
This starts using the new permissions in addition to the old
UPDATE_PROJECT permission. That way, if you're happy with
UPDATE_PROJECT, you don't need to change.
However, you can now add more fine grained permissions for both READ and
WRITE operations.
This PR will allow us to use a feature flag with variants to control
whether or not we should show the comments field of the feedback form.
This will allow us to see whether we can increase feedback collection if
we reduce the load on the customer.
This changes the badge element to prefer spans instead of divs. The
primary difference between spans and divs is that spans are inline and
divs are block. Styling-wise, we override the display property anyway.
Semantically, most all of the badges are used inline instead of on
their own block level, so this change seems sensible. You can still
provide `div` as the `as` prop if you need to.
This PR adds the `key` property to the features cell component where it
renders lists of flags. This fixes a few rendering errors we've been
getting in the console.
