Extracts the Avatar Group component into a `common` component and adds a
standard tooltip to all avatars.
Relates to linear issue 1-2606
This is a suggestion / proof of concept for how we can solve it. While I
think we can merge this as is, I'd also be happy to take any discussions
on other ways to approach it etc.
## Why are these changes made together?
Because extracting the avatar group without adding the new tooltip data
made the existing tooltip misbehave (it'd show up in the top left of the
screen, not synced to the avatar in any way).
I probably could have (and still can if you think it's prudent) split it
out such that the avatar gets a standardized tooltip first (and disable
it for the group card avatars), and split out the avatars in a
follow-up. Happy to do that if you think it's better.
## What does this mean?
It used to be that we had no consistent way of dealing with avatars and
tooltips. Some places had them, some places didn't. This change makes it
so that all avatars that we can show tooltips for will get the same
tooltip.
Previously, we had at least 4 different ways of dealing with tooltips:
- The HTML tooltip (that would be standardized with this PR) in the
project flags table
- The "title" that you'd get on your user avatar
- The group card list tooltip
- And sometimes you'd get nothing at all
with this change, we'll always show the same kind of tooltip if we can:
## What goes in the tooltip?
We use the `UserAvatar` component for a fair few different things and I
didn't want to extract separate components for all the different use
cases. Instead, I wanted to get an overview over what we use it for and
what is relevant info to show.
I found all the places we used it and tried to form an opinion.
This tooltip will work with a user's email, name, username, and id. If
there is no user (such as for empty avatars and avatars displaying only
"+n" for remaining members), we show no tooltip.
Following the example set by the group card avatars, we'll try to use
email or username (in that order) as the main bit of text. If the user
has an email or a username and also a name, the name will be used as
secondary text.
If the user does not have an email or username, but has a name, we'll
use the name as the main text.
If the user does not have an email, a username, or a name, we'll try to
show "User ID: N" if they have an id.
If they do not have a username, a name, an email, or an ID, we bail out
and show nothing.
## Why can you disable the tooltip?
In some cases, you might want to disable the tooltip because you have
more information to feed into it. An example of that is in the project
flags table, where we want to show more information in cases where the
user is 'unknown':
## Additional fixes
This PR also adds a few lines of CSS to fix a minor avatar layout bug.
Before:
After:
Adds placeholder filter buttons (that don't work at all) yet to the
three event logs.
Flag logs get to choose to and from dates, created by, and event type.
Project logs get all that flag logs get + a filter for flag.
The global log gets all project log filters + a project filter.
There's still work to be done to add data to createdBy, eventType, to
hook it up to the API, and to finalize the layout, but I wanted to get a
rough outline in to iterate on later. The eventType icon will also need
to be decided on.
This PR fixes a minor visual issue where the "favorite project" button's
hover outline would get cut off due to its container having `overflow:
hidden`.
The overflow value was introduced in
[#7575](https://github.com/Unleash/unleash/pull/7575) as way to handle
long project names. We didn't discover the hover issue back then because
it's not apparent unless you hover the fav star.
I found the solution in the CSS-tricks post [Preventing a Grid
Blowout](https://css-tricks.com/preventing-a-grid-blowout/). To quote
the article, the reason this works is that:
> the minimum width of a grid column is auto. (The same is true for flex
items, by the way.)
>
> And since auto is entirely based on content, we can say it is
“indefinitely” sized, its dimensions flex. If we were to put an explicit
width on the column, like 50% or 400px, then we would say it is
“definitely” sized.
>
> To apply our fix, we need to make sure that there is the column has a
definite minimum width instead of auto.
Before:
After:
Additionally, I've removed a duplicate declaration of font size,
removing the deprecated version.
This change fixes a bug where editors were suddenly unable to create
flags. The issue is that the new project creation dialog used a
permission button, but didn't supply the project ID.
This PR updates the text used to describe the different fields used in
the new creation dialog.
It also removes a redundant aria attribute (that MUI already handles).
This change prevents long project names from blowing the form out of
proportion.
To do so, it:
1. sets `whitespace: no-wrap` on the button labels. Judging by the other
styles, this was the intention all along, but it didn't really come up
until now.
2. It also sets the label width for projects to 30ch,so that you'll get
to see quite a bit of the project name before it gets cut off.
It would be possible to set a dynamic width for this button based on the
longest project name, but I'm not sure it adds much value, so I'm
leaning towards keeping it simple.
Here's what the dynamic width would look like:
``` tsx
const projectButtonLabelWidth = useMemo(() => {
const longestProjectName = projects.reduce(
(prev: number, type: { name: string }) =>
prev >= type.name.length ? prev : type.name.length,
0,
);
return `${Math.min(longestProjectName, 30)}ch`;
}, [projects]);
```
What it looks like:
This PR makes the config dropdown list generic over its values, so that
you can pass stuff that isn't strings.
It also updates the existing impression data button to use booleans
instead.
This change makes it so that we show the name of the project that is
selected on the selection button instead of the ID. There is a chance
that the name is not unique, but I'm willing to take that risk (plus
it's how we do it today).
I've used a useMemo for this, because we have to scan through a list
to find the right project. Sure, it's always a small list (less than
500 items, I should think), but still nice to avoid doing it every
render. Happy to remove it if you think it obfuscates something.
We *could* also use a `useState` hook and initialize it with the right
value, update when it changes, but I actually think this is a better
option (requires less code and less "remember to update this when that
changes").
This change wraps the project selection option in the
CreateFeatureDialog in a conditional that hides it when Unleash is
OSS.
OSS doesn't have access to the project creation API, so there's no
point in showing this.
This fix validates the project name when you blur the field in the new
project form. The only instances where it'll be wrong is if you have
just whitespace or an empty string, but you'll be notified immediately.
Also removes some unused variables and parameters that I found.
This change makes it so that all form input labels start with a
capital letter, regardless of the data we use to generate them.
Also fixes a leftover toggle -> flag renaming.
This PR extracts the dialog form that we created for the new project
form into a shared component in the `common` folder.
Most of the code has been lifted and shifted, but there's been some
minor adjustments along the way. The main file is
`frontend/src/component/common/DialogFormTemplate/DialogFormTemplate.tsx`.
Everything else is just cleanup.
Add ability to format format event as Markdown in generic webhooks,
similar to Datadog integration.
Closes https://github.com/Unleash/unleash/issues/7646
Co-authored-by: Nuno Góis <github@nunogois.com>
https://linear.app/unleash/issue/2-2469/keep-the-latest-event-for-each-integration-configuration
This makes it so we keep the latest event for each integration
configuration, along with the previous logic of keeping the latest 100
events of the last 2 hours.
This should be a cheap nice-to-have, since now we can always know what
the latest integration event looked like for each integration
configuration. This will tie-in nicely with the next task of making the
latest integration event state visible in the integration card.
Also improved the clarity of the auto-deletion explanation in the modal.
This PR adds the UI part of feature flag collaborators. Collaborators are hidden on windows smaller than size XL because we're not sure how to deal with them in those cases yet.
The limit card says to contact cs@getunleash if you're at the limits,
but we probably don't want to show that to OSS customers (it's not
terrible, just not very helpful), so let's hide it for OSS.
Instead, we'll ask them to try the community slack.
Screenie:
This PR fixes a minor visual glitch where the initial Unleash load might
display a jumping loading icon. The reason was that the initial
redirect's loader wasn't marked as a fullscreen loader.
This PR updates the tooltips for the health chart to also include
information on how healthy flags there are. The user could make this
calculation themselves before, but it'd require them to subtract the sum
of stale and potentially stale flags from the total. This makes it so
that they don't have to do the calculation.
I've also included a bar for the healthy flags in the overview, so that
it's easier to see how large a portion it is compared to the others.
Also: clean up some uses of the now-deprecated VFC.
Same as the OIDC changes we merged yesterday, this makes the frontend
ready for disabling SAML configuration page, if the SAML_ environment
variables are set.
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
Previously, when the result box was loading, it returned projects and
menu items first. After the feature search response came back, it also
showed the features, but this made the component jump around too much.
Now, everything is shown when the feature result comes back, reducing
the jumping around.
This PR fixes a bug where we wouldn't update the `useFeatureSearch`
hook's cached `total` value if the new total was `0`. The reason this
failed is that we would only update it if `data?.total`. Because `0` is
a falsy value, the check would fail.
This PR adds the first version of the resource limit documentation. It
also corrects the link in the `Limit` component.
In addition to the new limits from the soft limits project, I've also
added the limits from the signals project.
## Discussion points
I've set the Pro resource limits to projects and envs to the same value
as on the [plans & pricing](https://www.getunleash.io/pricing) page
instead of the actual hard soft limit. I think that makes messaging
easier and more consistent.
However, this does present us with a bit of a problem. Because we've
been pretty consistent at saying "no, you can't have more projects" for
Pro. But we're saying it's easy to change (when in actuality the limit
isn't enforced 💁🏼 )
## Screenie
It looks a little bit like this (but check the files or preview for the
actual text content)
We'll store hashes for the last 5 passwords, fetch them all for the user
wanting to change their password, and make sure the password does not
verify against any of the 5 stored hashes.
Includes some password-related UI/UX improvements and refactors. Also
some fixes related to reset password rate limiting (instead of an
unhandled exception), and token expiration on error.
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
This PR disables the "create feature flag" button when you've reached
the limits.
This one is a little more complex than the other UI limits, because we
also have to take into account the project feature limit. I've tried to
touch as little as possible, but I _have_ extracted the calculation of
both limits into a single hook.
This change reverts the changes related to the button in particular
that were introduced in #7500. The button is now always enabled, and
the actual resource warning and creation blocking happens in the form,
courtesy of #7548.
Currently, if the location changes, it does not update the active item.
I added useEffect to update the active item.
This is required when the user navigates via the command menu.
This PR activates the limit for API token creation in both the global
API token window and in the project-level API token tab.
Because the same button is used in two places, I encapsulated the
fetching of flags and resource limits within the button. I can be
convinced to pass the current API token count and the limit as
arguments, but I think this is the right solution for this case.
This PR updates the Unleash UI to use the new environment limit.
As it turns out, we already had an environment limit in the UI, but it
was hardcoded (luckily, its value is the same as the new default value
🥳).
In addition to the existing places this limit was used, it also disables
the "new environment" button if you've reached the limit. Because this
limit already exists, I don't think we need a flag for it. The only
change is that you can't click a button (that should be a link!) that
takes you to a page you can't do anything on.
Previously, clearing the SWR cache cleared all entries. Now you can
configure the cache size.
1. This makes the search more fluid. Previously, if you went back and
forth on pages, you were always sent to the loading state.
2. This also solves the issue where the command bar search cleared the
cache for all other searches.
3. Additionally, it addresses the problem where the global search
cleared the cache for project search.
Start tracking plausible events
1. Log the search keywords that returned 0 results
2. Track all clicks, based on source(search/recents/pages), type etc.
Now the search hook is inside another component, so we do not get
searches without search query.
Also we had 2 state variable handing the search query. Removed one of
them.
This PR removes the last two flags related to the project managament
improvements project, making the new project creation form GA.
In doing so, we can also delete the old project creation form (or at
least the page, the form is still in use in the project settings).
Fix project role assignment for users with `ADMIN` permission, even if
they don't have the Admin root role. This happens when e.g. users
inherit the `ADMIN` permission from a group root role, but are not
Admins themselves.
---------
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
This change takes the rendering of the new project form component and
puts in a child component of the project list, thereby
significantly speeding up the time it takes to render the form if you
have lots of projects (about to 10x for 50 projects on my machine).
The reason it was so slow before was that the open state of the form
component was stored in the project list component. This meant that
whenever you wanted to open or close the form, you'd have to rerender
the entire project list.
This change abstracts that process into the new ProjectCreationButton
component. This component takes care of checking the feature flag for
whether to render the dialog or to send the user to the old form, and
takes care of state management for the dialog.
Because this is a child component of the project list, it does not
cause rerenders of the entire project list.
Previously since query params were changing by global search, and
menubar was also altering them, they were conflicting. Menubar does not
need query params as state. So using search hook directly.
Now searching works in command bar
1. Currently piggybacking on the search hook, but I think it is not fast
enough, and also it is using the query params as the global search. This
causes some weird behaviour in UI. This probably means we will create
separate endpoint for this.
This PR disables the filtering capability in the front end for unknown
users.
Modifying the back end to support filtering for unknown users is not
something we want to do yet. It's possible, but it requires adding a lot
of special cases to the handling code (refer to [PR
#7359](https://github.com/Unleash/unleash/pull/7359)), which we'd like
to avoid if possible. To avoid annoying cases where the filtering
doesn't work as expected and breaks user expectations, we're disabling
the filtering capability for unknown users in the front end.
We can consider whether to enable back-end results for unknown in the future if we get
user feedback that it's important.
This PR works by changing the avatar cell component. When the user has
id 0 (and is therefore unknown), we:
- set aria-disabled to true. This alerts users with assistive tech that
the button is disabled, but it doesn't take it out of the tab order, so
it's not mysteriously missing.
- change the tooltip text, telling users that they can't filter by
unknown users.
- disable the avatar callback function, so clicking on the avatar
doesn't do anything.
The accompanying tests assert this functionality.
I considered also updating the screen reader text, but I think that
would add more confusion or be more information than the user needs.
According to MDN's article on the [aria-disabled
attribute](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled):
> [the aria-disabled] declaration will inform people using assistive
technologies, such as screen readers, that such elements are not meant
to be editable or otherwise operable.
**Upgrade to React v18 for Unleash v6. Here's why I think it's a good
time to do it:**
- Command Bar project: We've begun work on the command bar project, and
there's a fantastic library we want to use. However, it requires React
v18 support.
- Straightforward Upgrade: I took a look at the upgrade guide
https://react.dev/blog/2022/03/08/react-18-upgrade-guide and it seems
fairly straightforward. In fact, I was able to get React v18 running
with minimal changes in just 10 minutes!
- Dropping IE Support: React v18 no longer supports Internet Explorer
(IE), which is no longer supported by Microsoft as of June 15, 2022.
Upgrading to v18 in v6 would be a good way to align with this change.
TS updates:
* FC children has to be explicit:
https://stackoverflow.com/questions/71788254/react-18-typescript-children-fc
* forcing version 18 types in resolutions:
https://sentry.io/answers/type-is-not-assignable-to-type-reactnode/
Test updates:
* fixing SWR issue that we have always had but it manifests more in new
React (https://github.com/vercel/swr/issues/2373)
---------
Co-authored-by: kwasniew <kwasniewski.mateusz@gmail.com>
This PR lets you filter by flag creator by interacting with the user's
avatar.
Additionally, I've switched the custom popover for the standard tooltip
that we use elsewhere in the table. This gives the table a more cohesive
feel. As such, I have also deleted the component created in a previous
PR, because it's no longer in use anywhere.
It now looks like this (when tabbed to; notice the focus ring):
What the title says. There are input values that are whitespace
sensitive, so this will trim clientId and entity field, preventing the
form from sending leading or trailing whitespace. Will make a PR on
enterprise as well to trim on the backend as well.
This PR fixes a bug where if you navigated to the projects page via the
menu, scrolled down, and hovered over a project's avatars, you'd be
scrolled to the top of the page when you moused off the avatar.
Turns out this issue was also in the group cards. It seems to be that
the popover attempts to restore focus back to where you where, which, if
you navigated via the menu, is at the top of the page. Because these
popovers don't have any focusable content, we can disable that
functionality.
Additionally, I've disabled the scroll lock when the popover is open.
The scroll lock made it impossible to scroll when one of the popovers is
open, which is confusing as a user.
This change adds information about the project modes to the new
project creation form, using the tooltip for project creation modes.
In doing so, it updates the config button tooltip to accept extra
elements and adds styling for them.
What it looks like:
## a11y issues
This solution does present one problem: the popover doesn't get focus,
so it's impossible for you to scroll with only a keyboard. However, this
is something that's present in Unleash already, and not something that I
think would be easily solvable, so I don't think this is when we should
solve it.
1. Only suggest to create a tag value if the input is more than two
characters after trimming.
2. Ignore trailing and leading whitespace when considering which
autocomplete options to show
This PR changes the project screen by calling the main tab "flags"
instead of "overview". There isn't really an overview available on that
tab anymore, only a list of flags.
This PR removes the flag for the new project card design, making it GA.
It also removes deprecated components and updates one reference (in the
groups card) to the new components instead.
This PR removes all the feature flags related to the project list split
and updates the snapshot.
Now the project list will always contain "my projects" and "other
projects"
We have an issue that if you open up Insights, the Time to Production
chart was showing nothing because it was taking the median across all
projects. You might have many new or empty projects where the median was
0 (no data).
For example, the median from [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.7, 50.3, 140] was 0.
Now, we will remove the 0 values to have a more reasonable median.
This change fixes a bug where we would show the list of segments as
changed (causing a conflict) if their order wasn't the same in the
change as in the original.
By sorting the segments before comparing them, we can avoid this issue.
To avoid modifying the objects that are passed in (in case that has
knock-on effects anywhere), we copy the objects. And because `toSorted`
"only" has about 89% coverage now, I chose to use `sort` and spread the
arrays instead.
This PR hides horizontal overflow in the dialog.
The pop-up docs that we have on small windows was causing a tiny bit of
overflow, giving us an annoying (and pretty useless) horizontal
scrollbar. We can hide that scrollbar by hiding horizontal overflow.
This PR contains a few fixes for button designs on small screens for the
new project form.
It makes all buttons (config and actions) full-width and addresses some
sizing stuff.
It also caps the width of the stickiness button on non-small screens to
avoid shifting.
This PR implements some initial cleanup work for the new project
creation dialog.
The primary focus here is to remove unused props and to use the same
logic for the configuration buttons regardless of the content (mode,
stickiness, envs, change requests).
This PR allows you to configure change requests for all environments
when no environments are enabled explicitly. This is the default state
of the form and makes it so that you can configure CRs even if you want
all envs enabled.
Additionally, it preserves the case where you configure CRs for an
environment and then disable all envs.
This is logic only. It's not available in the UI yet.
## About the changes
Summing on Billing page got a little wonky after changing how the
summing worked when the estimation flag is off. This attempts to return
it to previous way of showing numbers when flag is off
If you go directly to the billing page it will not add user calculations
to the total. If you however interact with the UI, like change tabs back
and forth, it will suddenly show the correct sum:
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
This change makes it so that the button for change request
environments reads correctly when:
1. You have no envs configured: "Configure change requests"
2. One env configured: "1 environment configured"
3. More than one env configured: "`n` environments configured"
This change makes the CR button wider when you have environments
selected, reducing the difference between "no environments" and "envs
configured" states, thereby reducing the difference in the layout.
This PR contains two small UI improvements for the new project creation
form:
1. Wrap the action buttons when necessary (so that they don't become
unavailable when the window gets narrow enough.)
2. Make the change request table scrollable horizontally, so that it can
still be configured on narrow windows.
---------
Co-authored-by: sjaanus <sellinjaanus@gmail.com>
This PR addresses several related fixes to the new project creation
dialog to prevent unnecessary growing and shifting:
- use a fixed width for the guidance sidebar
- use a fixed height for the guidance code snippet
- use a fixed height for the mobile guidance
- use a fixed width for the mode selector button
- cap description height
This is a little tricky because we don't want the changes for the dialog
to affect other forms. As such, I've added some new options you can use
when you create the guidance components / sidebar.
This PR is part of #4380 - Remove legacy `/api/feature` endpoint.
## About the changes
### Frontend
- Removes the useFeatures hook
- Removes the part of StrategyView that displays features using this
strategy (not been working since v4.4)
- Removes 2 unused features entries from routes
### Backend
- Removes the /api/admin/features endpoint
- Moves a couple of non-feature related tests (auth etc) to use
/admin/projects endpoint instead
- Removes a test that was directly related to the removed endpoint
- Moves a couple of tests to the projects/features endpoint
- Reworks some tests to fetch features from projects features endpoint
and strategies from project strategies
This PR adds accessible descriptions to the dropdown widgets in the new
project creation form. The description is the same as we show in the
background
We have this very specific edge case in the new project form
dropdowns. It only occurs for the single-select lists and only if you
select an item via search.
When the search input is non-empty, you can use enter to select the
first item in the list.
For some reason, this also triggers a click on the underlying button
that opens the dropdown (I'm guessing this is to do with an underlying
focus).
To work around it, we create a variable that prevents you from opening
the dropdown if it is true. We set it to 'true' when you close it (for
single-selects), but also set single-millisecond timeout that sets it
to false thereafter.
This is much to short for the user to notice anything, but it prevents
the browser from noticing the click.
Adds icons to sidebar documentation and removes the link when you can't
interact with it.
I'm a little concerned that this won't be very accessible at the moment,
because we don't announce that anything has changed (i.e. there's no way
to find out that the text has changed if you can't see it), and the text
isn't labeled as describing anything. (this is being addressed in #7110
)
There's a few caveats to this:
1. we don't set a min height at the moment. I've avoided this because we
use the sidebar a number of other places and I wanted to touch as little
as possible. This means we can still get height adjustments
2. The new project icon doesn't have the same proportions as the mui
icons. This adds some additional jank. We should probably look at this,
though.
I've marked the project creation dialog as "compact", so that it's only
as tall as it needs to be.
However, by default, compact forms don't scroll because they have
overflow set to hidden. This is a problem on very short windows. To get
around this, I've set overflow to unset on compact forms.
I've also removed `min-height: 0` which has some weird side effects on
the centered dialog. Instead, I'm setting `min-height` to `unset` if
it's compact.
This task also uncovered some inconsistencies and some borders that only
show up sometimes, so I've removed them too.
I realized that, in an oversight, the form now shows and sends project
CR config, even if the new form isn't active. The API just ignores it if
it doesn't understand it, so it's not very harmful, but it's better if
we don't send it at all. This PR does that.
It does not actually test that change request info isn't included (but
it does test ID inclusion). This is because:
- change request info is only included if we're enterprise. The rendered
version of the hook isn't by default.
- Setting up module mocking and making it work seems like a lot of work
for a small gain, considering we're probably going to be removing the
old form anyway.
- I've tested it locally.
Also adds some testing for the hook related to name validation and
payload creation
At first, I was creating a new component, Project Banner, which was 90%
of the old banner and 10% new code, but it did not feel right. The
current banner is actually smart enough to be used in any container. So
now, I have moved the outdated SDK banner to the project level.
I like the simplicity of the change.
Instead of using the `required` attribute, we manually make it
required. This is indicated visually by red error text if the value is
empty (or whitespace only). To indicate to screen readers that it is
required, we add the `aria-required` attribute.
We didn't previously validate if the name
was whitespace only.
Also: if no envs are selected, indicate that all will be included
This prevents this form value from ever being invalid.
It seems the code that was copied was copied from before we changed
the validation logic, so it wouldn't submit. This fixes that to remove
any ID validation in the new form.
1. Added new schema and tests
2. Controller also accepts the data
3. Also sending fake data from frontend currently
Next steps, implement service/store layer and frontend
This fixes the case when a customer have thousands of strategies causing
the react UI to crash. We still consider it incorrect to use that amount
of strategies and this is more a workaround to help the customer out of
a crashing state.
We put it behind a flag called `manyStrategiesPagination` and plan to
only enable it for the customer in trouble.
This PR adds some tests around how project envs and change request envs
interact in the new project form. It tests that:
1. If you remove an env from the project setup, that env is also removed
from the change request list.
2. If you try to enable CRs for an env that isn't enabled, nothing
happens.
This PR adds the ability to configure CRs when creating a project.
The design is unfinished, and the code certainly needs cleanup, but I'd
like to get this into sandbox so we can look at it.
Things that still need to be done:
1. What do we do about this button when the user has no environments
selected? As a rough draft, I've disabled it. However, we should make it
possible to navigate to and give you an explanation why it was disabled,
e.g. "You have no project environments selected. Please select at least
one project environment.".
2. The form design is not done: the width should be constant and not
jumpy the way it is now. Also, the search field is too wide.
3. I've made the desicion that if you deselect a project env, we also
remove that env from your CR config it it's in there.
4. Potential improvement: if you enable and then disable CRs for an env,
we *could* probably store the data in between, so that if you set
required approvers 5 and then disabled it, it'd still be 5 when you
re-enabled it. That sounds like a good user experience. We should also
be able to extend that to adding/removing environments from project
envs.
This PR is a combination of two PRs:
This PR adds a functioning environment selection button to the new project creation form. Selected environments are added to the payload and to the API preview.
The implementation is mostly lifted from the existing FilterItem component we have for search filters. However, our need here is less complex, so I've removed some of the things we don't need. There is still more cleanup to be done, however, but I'd like to implement the rest of the submenus first, to see what we really do need in the end.
---
This PR adds support for stickiness and project mode in the new project
creation form.
Achieve this, it does a few things:
1. Moves `resolveStickinessOptions` from
`frontend/src/component/feature/StrategyTypes/FlexibleStrategy/StickinessSelect/StickinessSelect.tsx`
and into a separate hook. This component was used by the old project
creation form. Because the new form has a different input, but needs the
same option, moved that code into a reusable hook.
2. It adds functioning buttons for project stickiness and mode.
3. It adds labels to the search inputs for the dropdowns. Inputs *must*
have labels to meet a11y requirements. However, the designs don't have
labels, so we can hide them visually. Though that leads to another issue
(refer to the screen shot below).
4. It updates the `SelectionButton` component to handle both single- and
multiselect cases. It instead exports these two subcomponents. These are
currently in one file, but I'll split them out into their separate files
in a later PR.
As a side effect of working with the selection buttons, it also improves
how we handle keyboard interaction for these buttons.
Here's what it looks like for single-select lists. Notice the missing
part of the input's border around the top (where the label *would* be if
we showed it). We should figure out how best to handle it. I've done
like this for now, but we can sort it out later.
This test is breaking right now because it tests a date picker, week 21
is approaching, and `findByText` only expects a single element. Checking
that we have *at least* one element fixes that breakage and I don't
think it should cause any issues.
Of course, that means that right now, this test would also pass even if
the expected button wasn't there, but it would stop passing in about
four weeks time.
This PR allows very simple project creation. You can add a name and
description. The ID is generated for you at the moment (we'll fix this
later). Nothing else works, but the project is created successfully.
This PR adds a very rough first implementation of the look of the new
project form. *It is not final and does not work yet*.
The important part here is that the layout is roughly right (we'll
adjust spacing etc later) and that we've got all the basic elements
present.
I'll hook it up to actually work in an upcoming PR.
The missing icon, text alignment, etc, will also be solved later.
Add a flag to enable/disable the new UI for project creation.
This flag is separate from the impl on the back end so that we can
enable one without the other (but uses flag dependencies in Unleash, so
that we can never enable the new UI without the new back end).
I have not set the flag to `true` in server startup because the form
doesn't work yet, so it's a manual step for now.
- Adds support for the configuration option for SCIM taking over control
of users and groups
- Moves SCIM settings into SSO config pages (OIDC and SAML). SCIM
registers a callback to be invoked when saving in a parent SSO config
page
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>
