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">
## 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>
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.
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>
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 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.
We get a flash of the Unleash scaffold when we first load the page. For
a brief moment, we display version 3 and then overwrite it with the
correct version. Looks kinda silly, we know we're in version 5.x so
let's just do that
This PR refactores the StrategyVariants component to be passed in from
the outside to the new form component. This allows us to pass in the
StrategyVariants with an "editable" property in the create form which we
use to determine the editable state of the name input field. If the
editable field is not passed in we keep the old behavior.
Notable changes:
* StrategyVariants is now passed in from the outside, allowing us to
define different props at call time
* Added tests for the new behavior, and for keeping the old behavior
(such as in edit strategy)
* Added tracking
## Problem
The ConstraintAccordionList component was used in multiple places:
* Playground
* Segment form
* StrategyExecution
* Change requests
* Create strategy
* Edit strategy
This is problematic because some of the views are just pure visual
representations, and other views allow you to interact with and edit the
constraints. This causes a situation where the visual representation
needs to be aware of the implementation details of editing and mutating
constraints. In addition the ConstraintAccordionList is not just a pure
rendering of the list, it also keeps internal state on when to show the
create button and optional headers. This is makes it hard to make
changes when stylings need to be subtly different across components.
## Solution
Taking on the full refactor for this is out of scope, but it's
unfortunate that the ConstraintAccordionList needs all this internal
state. For now I split out the list into it's own component called
ConstraintList. I gathered the functions needed for editing and mutating
the constraints in a reusable hook and isolated the version of the list
used in the new feature strategy edit / create components into it's own
component so that the changes in layout will not affect anything else.
Ideally we should try to move towards a future where the components
don't keep internal state like this but clear boundaries and purposes
for the use.
Show a warning about how deleting a strategy might mess up scheduled
change requests.
If there are change requests, list them. If there are no conflicts, show
nothing. If we don't know (because of no successful response from the
API), say that it might cause issues.
## About the changes
This feature allows our Enterprise customers to configure banners to be
displayed on their Unleash instance for all their users to see and
interact with. Previously known as "internal message banners".
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-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
Fixes a bug where the `UPDATE_PROJECT_SEGMENT` permission is not
respected, both on the UI and on the API. The original intention was
stated
[here](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
This was easy to fix on the UI, since we were simply missing the extra
permission on the button permission checks.
Unfortunately the API can be tricky. Our auth middleware tries to grab
the `project` information from either the params or body object, but our
`DELETE` method does not contain this information. There is no body and
the endpoint looks like `/admin/segments/:id`, only including the
segment id.
This means that, in the rbac middleware when we check the permissions,
we need to figure out if we're in such a scenario and fetch the project
information from the DB, which feels a bit hacky, but it's something
we're seemingly already doing for features, so at least it's somewhat
consistent.
Ideally what we could do is leave this API alone and create a separate
one for project segments, with endpoints where we would have project as
a param, like so:
`http://localhost:4242/api/admin/projects/:projectId/segments/1`.
This PR opts to go with the quick and hacky solution for now since this
is an issue we want to fix quickly, but this is something that we should
be aware of. I'm also unsure if we want to create a new API for project
segments. If we decide that we want a different solution I don't mind
either adapting this PR or creating a follow up.
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.
https://linear.app/unleash/issue/2-1531/rename-message-banners-to-banners
This renames "message banners" to "banners".
I also added support for external banners coming from a `banner` flag
instead of only `messageBanner` flag, so we can eventually migrate to
the new one in the future if we want.
This PR adds a splash screen for segments being open-sourced.
It looks like this:
## About the changes
I've more or less wholesale copied the demo dialog that @nunogois
implemented. I've put it in the `splash` directory for now (because
that's where it seemed most appropriate). The reason for straight
copying it instead of extending existing functionality is primarily that
this should be short-lived and deleted after the next release or so. So
isolating all the changes into a single directory seems like a good
idea.
## Discussion points
Because OSS installations don't connect to Unleash, we can't use feature
flags to control the rollout here. Instead, we must just assume that OSS
users will want to see it. If there is a better way we can control this,
that'd be great. I'd love to be able to use time constraints to not show
this after a certain date, for instance, but I don't think that's
something we can do right now?
The splash is also set to display on any page you're at when you first
load unleash. However, closing the dialog (either by closing or by
asking to see segments) will store that in localstorage, and you won't
be shown the dialog again.
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
https://linear.app/unleash/issue/2-1235/docs-slack-app-integration-documentation
This adds a new reference doc for the new Unleash Slack App integration
and marks the previous Slack integration as deprecated.
As a side-effect this PR also fixes an issue where we wouldn't be able
to delete tags with special characters.
---------
Co-authored-by: David Leek <david@getunleash.io>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
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 adds:
* Generated types for useProjectDoraMetrics
* Mobile enhancements
* Tooltips
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
## About the changes
Instead of this:
```ts
const { uiConfig } = useUiConfig();
const myFlag = Boolean(uiConfig?.flags?.myFlag)
```
we can have this:
```ts
const myFlag = useUiFlag("myFlag")
```
With the same type safety, less verbose and more purposeful code.
### Important files
- `frontend/src/hooks/useUiFlag.ts`
## Discussion points
Can we in the future share flags between frontend and backend? Right now
adding a new flag has to be done in 4 different places (backend flag
keys list, backend flags defaults config, backend experimental server
options, frontend type).
Most ergonomic option is to pull config directly from Unleash.
Issue, based on previous user feedback:
https://github.com/Unleash/unleash/issues/4565
Internal feature request document:
[docs.google.com/document/d/1Sx0q...](https://docs.google.com/document/d/1Sx0qKZXUVUCjuY5F4MOh1ieOM1A2_jE58zEA7jaM_1g/edit?usp=sharing)
Since `auth/{auth_type}/settings` is an Enterprise route, this prevents
404s when we try to use the hook to fetch auth settings in
non-Enterprise instances by using the conditional `useEnterpriseSWR`
hook.
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
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>
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
Adds projects user and group -usage information to the dialog shown when
user wants to delete a project role
<img width="670" alt="Skjermbilde 2023-08-10 kl 08 28 40"
src="https://github.com/Unleash/unleash/assets/707867/a1df961b-2d0f-419d-b9bf-fedef896a84e">
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
This PR sends segments to CR drafts when you use the `add to draft`
button.
It also adds the logic for which environment to pick.
Segments sent to the API are added to drafts, but not displayed in the
UI yet. CRs with only segment changes are also not listed in the table.
This'll be covered in upcoming work.
