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.
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 🙇🏼
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.
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 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.
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.
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.
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.
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`.
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.
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
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.
Lots of work here, mostly because I didn't want to turn off the
`noImplicitAnyLet` lint. This PR tries its best to type all the untyped
lets biome complained about (Don't ask me how many hours that took or
how many lints that was >200...), which in the future will force test
authors to actually type their global variables setup in `beforeAll`.
---------
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
This changes the two interfaces IChangeRequest and
IChangeRequestSchedule to be union types instead of interfaces. It also
extracts the constituents of those union types into proper types
themselves (so that they can be used in function type signatures etc).
It also updates the type names.
This turned out to be more work than I had imagined, but I think the end
result pays off, giving us more type safety and control.
I wanted to use just `ChangeRequest` for the IChangeRequest type, but
that caused issues due to naming collisions with the `ChangeRequest`
component that we have, causing tests to fail. I've named it
`ChangeRequestType` as a potential solution, but suggestions are
welcome.
The relevant changes are in
`frontend/src/component/changeRequest/changeRequest.types.ts`.
Everything else is updated references and some necessary refactoring to
respect the new types.
This PR adds the new CR diagram (with schedule info) conditionally.
It'll only render for users who are exposed to scheduled CRs.
It also updates the text of the old version to make it all consistent
and adds a `aria-details` attribute to the SVG so that assistive tech
knows what it is.
New version
This PR removes warning on the project settings by always making sure we
have the project before rendering the settings and do a conditional
check on the featureLimit number field.
In `ExperimentalProjectTable.tsx`, changes have been made to the columns
configuration in order to handle column visibiilty. This includes adding
id property to every column. Logic responsible for dynamically adjusts
column visibility based on screen size was moved to new hook,
`useDefaultColumnVisibility`
New `<ColumnsMenu />` is using it's own list of elements instead of
inferring it from table columns definition. This component doesn't need
it's internal structure to depend on react-table and it's interface.
This PR fixes a couple of issues with the pagination bar:
* Fixes an issue where padding bottom would be broken due to disabling
padding on the parent container
* Remove padding on the entire table to create more space and remove
header bar border radius as per discussion with @nicolaesocaciu
This PR makes changes to how the project overview skeleton screen works.
Important changes:
- Add skeleton screens to missing elements, creating a more
comprehensive loading screen
- Split the page into different loading sections, so that we can load
the table when we fetch the next page without affecting the rest of the
page.
https://www.loom.com/share/e5d30dc897ac488ea80cfae11ffab646
Next steps:
* Hide bar if total is less than 25
* Add FE testing
https://linear.app/unleash/issue/SR-169/ticket-1107-project-feature-flag-limit-is-not-correctly-updatedFixes#5315, an issue where it would not be possible to set an empty
flag limit.
This also fixes the UI behavior: Before, when the flag limit field was
emptied, it would disappear from the UI.
I'm a bit unsure of the original intent of the `(data.defaultStickiness
!== undefined || data.featureLimit !== undefined)` condition. We're in
an update method, triggered by a PUT endpoint - I think it's safe to
assume that we'll always want to set these values to whatever they come
as, we just need to convert them to `null` in case they are not present
(i.e. `undefined`).
This PR reduces the overhead of making API calls on pages with heavy
renders. We forego loading states and default error handling in favor of
more speed by avoiding triggering multiple re-renders from the API call.
In ActionsCell.tsx file, 'Copy' with FileCopy icon is changed to 'Clone'
with 'LibraryAdd' icon as this feature is used to clone a new feature
from existing one. Upon copying the icon and text will change to 'Check'
icon with 'Copied!' for one sec and closes automatically.
To prepare for 5.6 GA,
I've done a find through both Frontend and Backend here to remove the
usages of the flag. Seems like the flag was only in use in the frontend.
@nunogois can you confirm?
We love all open-source Unleash users. in 2022 we built the [segment
capability](https://docs.getunleash.io/reference/segments) (v4.13) as an
enterprise feature, simplify life for our customers.
Now it is time to contribute it to the world 🌏
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This PR adds plausible metrics for feature naming patterns. The changes
are tracked whenever the form is submitted and the naming pattern has
changed. We track three different actions:
- added :: if there was no pattern before and now there is one
- removed :: if there was a pattern before and now there is none
- changed :: if there was a pattern before and now there is a different
one
The corresponding event type has been created in plausible.
This PR simplifies the flag naming tooltip considerably. It now only
contains an example of a pattern and what it will match. It also updates
the link in the form section description to point directly to a regex
cheat sheet instead of a general regex reference document.
There's a few reasons for doing this:
1. The text preceding the input already explains what the pattern does
and explains that it is a regex.
2. The text preceding the input also contains a link to a regex cheat
sheet (which is arguably a better place to explain regexes than a
tooltip).
3. The tooltip was very long. While a lot of the information there was
useful, it would also be hard to use. Imagine a user checking the
tooltip, scrolling all the way down, but accidentally moving the mouse a
bit and the tooltip disappearing. They would have to scroll all the way
down again. Or maybe they need to remember what it was they just looked
at. It would be more useful to have the information on a separate page.
4. The tooltip is not accessible by keyboard. This means that users who
use a keyboard to navigate the UI would not be able to scroll or
otherwise navigate the tooltip, potentially leaving them in the dark.
This PR adds:
* Generated types for useProjectDoraMetrics
* Mobile enhancements
* Tooltips
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
This PR updates the UI to reflect the changes to the implicit ^ and $
that we now add. The changes are:
1. Show input adornments for ^ and $ when you create a pattern.
2. Mention that ^ and $ are added implicitly in description.
3. Checks the example you provide against the pattern with added ^ and $
+ adds a test for that.
Points 1 and 2:
## Discussion point:
I have not touched the information about the pattern yet as the PR that
updates that is still in review (#4656), but it would be prudent to also
update that info to make it clearer. I can address that in a follow-up
PR.
While having a pattern when you have no example doesn't make a lot of
sense, it's a problem that you can't delete the example after deleting
the pattern: you previously had to remove the example before the
pattern.
This PR fixes that by always allowing you to update the example, even if
there is no pattern. Our server doesn't currently accept submitting an
example with no pattern, but we could allow that if we want to (and
probably just discard it on the back-end).
This PR also updates the validation of the example and the regex. There
were more unhandled edge cases previously where the validation would
disappear or be wrong. This should be fixed now. The new logic is that,
whenever you update the either the pattern or the example, we check:
- if you have an error in your pattern, no pattern, or no example, then
delete the example error if it exists
- have a well-formed pattern and an example then check if the example
matches the pattern and add/delete an error accordingly
This does have some consequences: editing the pattern can render your
example invalid. You'll also get immediate feedback instead of when you
switch focus. I think this is often a bad pattern (giving the user too
much negative feedback), but in terms of working with regexes, I think
it might be a good thing. We also give immediate feedback today, so I
don't think this is a regression.
Any thoughts are welcome.
This PR adds a feature naming pattern description to the project form.
It's rendered as a multi-line input field. The description is also
stored in the db.
This adapts most of @andreas-unleash's PR #4599 with some minor changes
(using description instead of prompt). Actually displaying this data to
the users will come in a later PR.
Does what it says on the tin, should help with cleaning up
https://github.com/Unleash/unleash/pull/4512 and respective schema
changes.
---------
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
When archiving or reviving feature toggles, when toggles disappear from
table, actions bar should also disappear.
<!-- Does it close an issue? Multiple? -->
Closes
https://linear.app/unleash/issue/1-1293/bulk-revive-modal-doesnt-go-away
Adds a first iteration of feature flag naming patterns. Currently behind a flag.
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
Co-authored-by: andreas-unleash <andreas@getunleash.ai>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
https://linear.app/unleash/issue/2-1128/change-the-api-to-support-adding-multiple-roles-to-a-usergroup-on-ahttps://linear.app/unleash/issue/2-1125/be-able-to-fetch-all-roles-for-a-user-in-a-projecthttps://linear.app/unleash/issue/2-1127/adapt-the-ui-to-be-able-to-do-a-multi-select-on-role-permissions-for
- Allows assigning project roles to groups with root roles
- Implements new methods that support assigning, editing, removing and
retrieving multiple project roles in project access, along with other
auxiliary methods
- Adds new events for updating and removing assigned roles
- Adapts `useProjectApi` to new methods that use new endpoints that
support multiple roles
- Adds the `multipleRoles` feature flag that controls the possibility of
selecting multiple roles on the UI
- Adapts `ProjectAccessAssign` to support multiple role, using the new
methods
- Adds a new `MultipleRoleSelect` component that allows you to select
multiple roles based on the `RoleSelect` component
- Adapts the `RoleCell` component to support either a single role or
multiple roles
- Updates the `access.spec.ts` Cypress e2e test to reflect our new logic
- Updates `access-service.e2e.test.ts` with tests covering the multiple
roles logic and covering some corner cases
- Updates `project-service.e2e.test.ts` to adapt to the new logic,
adding a test that covers adding access with `[roles], [groups],
[users]`
- Misc refactors and boy scouting
---------
Co-authored-by: David Leek <david@getunleash.io>
Co-authored-by: Mateusz Kwasniewski <kwasniewski.mateusz@gmail.com>
Co-authored-by: Nuno Góis <github@nunogois.com>
