1
0
mirror of https://github.com/Unleash/unleash.git synced 2024-12-22 19:07:54 +01:00
Commit Graph

43 Commits

Author SHA1 Message Date
Thomas Heartman
24e9cf7c8f
feat: add "edit" link to playground strategies (#4027)
This change adds an "edit" link to all playground strategies when they
are returned from the API, allowing the user to jump directly to the
evaluated strategy edit screen.

This change applies to both old and new strategies, so it should even
work in the old playground.

This does not use this information in the frontend yet.

## Discussion points:

Should "links" be an object or a singular string? I know the
notifications service uses just "link", but using an object will make
it easier to potentially add more actions in the future (such as
"enable"/"disable", maybe?)

Do we need to supply basePath? I noticed that the notifications links
only ever use an empty string for base path, so it might not be
necessary and can potentially be left out.

## Changes

I've implemented the link building in a new view model file. Inspecting
the output after the result is fully ready requires some gnarly
introspection and mapping, but it's tested.

Further, I've done a little bit of work to stop the playground service
using the schema types directly as the schema types now contain extra
information.

This PR also updates the `urlFriendlyString` arbitrary to not produce
strings that contain only periods. This causes issues when parsing URLs
(and is also something we struggle with in the UI).
2023-06-22 07:19:35 +00:00
Mateusz Kwasniewski
ffed4e78b0
feat: configurable playground limit (#4047) 2023-06-22 08:46:13 +02:00
Thomas Heartman
80a2e1b93f
fix: reject API admin tokens when importing features (#4016)
This PR fixes an issue where trying to use an admin token to import
features via the API resulted in a 500 (due to missing properties).

The solution is to catch when the user is using and admin token in the
controller, throw a 400, and tell them to use personal access tokens or
service accounts.

The PR includes a new test file for this specific use case. We don't
really test these cases many other places, so it seemed the logical
choice.
2023-06-20 12:57:59 +00:00
Mateusz Kwasniewski
a0862cfc10
feat: Query complexity validation (#4017) 2023-06-20 14:28:02 +02:00
Jaanus Sellin
9c8651879f
fix: filter out usage for export (#4006) 2023-06-19 13:42:55 +03:00
Nuno Góis
bb026c0ba1
feat: custom root roles (#3975)
## About the changes
Implements custom root roles, encompassing a lot of different areas of
the project, and slightly refactoring the current roles logic. It
includes quite a clean up.

This feature itself is behind a flag: `customRootRoles`

This feature covers root roles in:
 - Users;
 - Service Accounts;
 - Groups;

Apologies in advance. I may have gotten a bit carried away 🙈 

### Roles

We now have a new admin tab called "Roles" where we can see all root
roles and manage custom ones. We are not allowed to edit or remove
*predefined* roles.

![image](https://github.com/Unleash/unleash/assets/14320932/1ad8695c-8c3f-440d-ac32-39746720d588)
This meant slightly pushing away the existing roles to `project-roles`
instead. One idea we want to explore in the future is to unify both
types of roles in the UI instead of having 2 separate tabs. This
includes modernizing project roles to fit more into our current design
and decisions.

Hovering the permissions cell expands detailed information about the
role:

![image](https://github.com/Unleash/unleash/assets/14320932/81c4aae7-8b4d-4cb4-92d1-8f1bc3ef1f2a)

### Create and edit role

Here's how the role form looks like (create / edit):

![image](https://github.com/Unleash/unleash/assets/14320932/85baec29-bb10-48c5-a207-b3e9a8de838a)
Here I categorized permissions so it's easier to visualize and manage
from a UX perspective.

I'm using the same endpoint as before. I tried to unify the logic and
get rid of the `projectRole` specific hooks. What distinguishes custom
root roles from custom project roles is the extra `root-custom` type we
see on the payload. By default we assume `custom` (custom project role)
instead, which should help in terms of backwards compatibility.

### Delete role

When we delete a custom role we try to help the end user make an
informed decision by listing all the entities which currently use this
custom root role:

![image](https://github.com/Unleash/unleash/assets/14320932/352ed529-76be-47a8-88da-5e924fb191d4)
~~As mentioned in the screenshot, when deleting a custom role, we demote
all entities associated with it to the predefined `Viewer` role.~~
**EDIT**: Apparently we currently block this from the API
(access-service deleteRole) with a message:

![image](https://github.com/Unleash/unleash/assets/14320932/82a8e50f-8dc5-4c18-a2ba-54e2ae91b91c)
What should the correct behavior be?

### Role selector

I added a new easy-to-use role selector component that is present in:
 - Users 

![image](https://github.com/Unleash/unleash/assets/14320932/76953139-7fb6-437e-b3fa-ace1d9187674)
 - Service Accounts

![image](https://github.com/Unleash/unleash/assets/14320932/2b80bd55-9abb-4883-b715-15650ae752ea)
- Groups

![image](https://github.com/Unleash/unleash/assets/14320932/ab438f7c-2245-4779-b157-2da1689fe402)

### Role description

I also added a new role description component that you can see below the
dropdown in the selector component, but it's also used to better
describe each role in the respective tables:

![image](https://github.com/Unleash/unleash/assets/14320932/a3eecac1-2a34-4500-a68c-e3f62ebfa782)

I'm not listing all the permissions of predefined roles. Those simply
show the description in the tooltip:

![image](https://github.com/Unleash/unleash/assets/14320932/7e5b2948-45f0-4472-8311-bf533409ba6c)

### Role badge

Groups is a bit different, since it uses a list of cards, so I added yet
another component - Role badge:

![image](https://github.com/Unleash/unleash/assets/14320932/1d62c3db-072a-4c97-b86f-1d8ebdd3523e)

I'm using this same component on the profile tab:

![image](https://github.com/Unleash/unleash/assets/14320932/214272db-a828-444e-8846-4f39b9456bc6)

## Discussion points
- Are we being defensive enough with the use of the flag? Should we
cover more?
 - Are we breaking backwards compatibility in any way?
 - What should we do when removing a role? Block or demote?
- Maybe some existing permission-related issues will surface with this
change: Are we being specific enough with our permissions? A lot of
places are simply checking for `ADMIN`;
- We may want to get rid of the API roles coupling we have with the
users and SAs and instead use the new hooks (e.g. `useRoles`)
explicitly;
 - We should update the docs;
- Maybe we could allow the user to add a custom role directly from the
role selector component;

---------

Co-authored-by: Gastón Fournier <gaston@getunleash.io>
2023-06-14 14:40:40 +01:00
Mateusz Kwasniewski
8bddbd80f6
feat: advanced playground openapi (#3972) 2023-06-14 11:05:08 +02:00
Mateusz Kwasniewski
edd67f7046
test: advanced playground (#3968) 2023-06-14 08:23:36 +02:00
Mateusz Kwasniewski
555f77463d
feat: draft branch playground evaluation (#3967) 2023-06-13 13:56:26 +02:00
Mateusz Kwasniewski
7d69750f3b
refactor: Extract playground steps (#3966) 2023-06-13 11:26:10 +02:00
Mateusz Kwasniewski
32ae15741c
refactor: read project ids in memory (#3965) 2023-06-13 10:12:14 +02:00
Mateusz Kwasniewski
7b8b6bceaf
feat: walking skeleton of the advanced playground (#3949) 2023-06-12 11:01:52 +02:00
Mateusz Kwasniewski
0101491a83
refactor: playground in feature oriented architecture (#3942) 2023-06-09 12:55:54 +02:00
Jaanus Sellin
ec6e4d70b5
feat: context field usage backend (#3921) 2023-06-09 12:00:17 +03:00
Jaanus Sellin
0efaa346c4
feat: usage on context fields in list (#3906) 2023-06-06 13:59:41 +03:00
Jaanus Sellin
f73d36fda3
feat: add usage of segment in list (#3853) 2023-05-26 14:37:00 +03:00
Ivar Conradi Østhus
6c5df9f2c7
feat: improve frontend config freshness to < 1s (#3749)
This PR reuses the revision Id information from the "optimal 304 for
server SDKs" to improve the freshness of the frontend API config data.

In addition it allows us to reduce the polling (and eventually remove it
when we are confident).

---------

Co-authored-by: Gastón Fournier <gaston@getunleash.io>
2023-05-12 17:52:11 +00:00
Thomas Heartman
9943179393
Clean up old errors (#3633)
This PR attempts to improve the error handling introduced in #3607.

## About the changes

## **tl;dr:**
- Make `UnleashError` constructor protected
- Make all custom errors inherit from `UnleashError`.
- Add tests to ensure that all special error cases include their
relevant data
- Remove `PasswordMismatchError` and `BadRequestError`. These don't
exist.
- Add a few new error types: `ContentTypeError`, `NotImplementedError`,
`UnauthorizedError`
- Remove the `...rest` parameter from error constructor
- Add an unexported `GenericUnleashError` class
- Move OpenAPI conversion function to `BadDataError` clas
- Remove explicit `Error.captureStackTrace`. This is done automatically.
- Extract `getPropFromString` function and add tests

### **In a more verbose fashion**

The main thing is that all our internal errors now inherit
from`UnleashError`. This allows us to simplify the `UnleashError`
constructor and error handling in general while still giving us the
extra benefits we added to that class. However, it _does_ also mean that
I've had to update **all** existing error classes.

The constructor for `UnleashError` is now protected and all places that
called that constructor directly have been updated. Because the base
error isn't available anymore, I've added three new errors to cover use
cases that we didn't already have covered: `NotImplementedError`,
`UnauthorizedError`, `ContentTypeError`. This is to stay consistent in
how we report errors to the user.

There is also an internal class, `GenericUnleashError` that inherits
from the base error. This class is only used in conversions for cases
where we don't know what the error is. It is not exported.

In making all the errors inherit, I've also removed the `...rest`
parameter from the `UnleashError` constructor. We don't need this
anymore.

Following on from the fixes with missing properties in #3638, I have
added tests for all errors that contain extra data.

Some of the error names that were originally used when creating the list
don't exist in the backend. `BadRequestError` and
`PasswordMismatchError` have been removed.

The `BadDataError` class now contains the conversion code for OpenAPI
validation errors. In doing so, I extracted and tested the
`getPropFromString` function.

### Main files

Due to the nature of the changes, there's a lot of files to look at. So
to make it easier to know where to turn your attention:

The changes in `api-error.ts` contain the main changes: protected
constructor, removal of OpenAPI conversion (moved into `BadDataError`.

`api-error.test.ts` contains tests to make sure that errors work as
expected.

Aside from `get-prop-from-string.ts` and the tests, everything else is
just the required updates to go through with the changes.

## Discussion points

I've gone for inheritance of the Error type over composition. This is in
large part because throwing actual Error instances instead of just
objects is preferable (because they collect stack traces, for instance).
However, it's quite possible that we could solve the same thing in a
more elegant fashion using composition.

## For later / suggestions for further improvements

The `api-error` files still contain a lot of code. I think it might be
beneficial to break each Error into a separate folder that includes the
error, its tests, and its schema (if required). It would help decouple
it a bit.

We don't currently expose the schema anywhere, so it's not available in
the openapi spec. We should look at exposing it too.

Finally, it would be good to go through each individual error message
and update each one to be as helpful as possible.
2023-05-11 11:10:57 +02:00
Mateusz Kwasniewski
108e15940e
fix: don't create duplicate tags on import (#3688) 2023-05-04 22:19:00 +02:00
Mateusz Kwasniewski
116db8f6d1
feat: promote toggles script (#3639) 2023-04-28 09:08:12 +02:00
Mateusz Kwasniewski
70a8ab4c47
feat: export by tags (#3635) 2023-04-27 10:22:14 +02:00
Thomas Heartman
596d7543e5
chore: remove @ts-ignore-error (#3629) 2023-04-26 17:08:55 +02:00
Thomas Heartman
0613ee0bd9
fix: add truth checks to a number of jest tests. (#3627) 2023-04-26 14:24:09 +02:00
Christopher Kolstad
1fdf68eeec
task: removes deprecated feature api (#3609)
### What
We've had this marked as deprecated through our v4, this PR removes it.

### Worth noting
This updates the deprecation notices with removal notices in the
documentation as well.

### Considerations
The tags API is still located under
/api/admin/features/{featureName}/tags. It should be moved to
/api/admin/projects/{project}/features/{featureName}/tags. I vote we do
that in a separate PR, we'd probably also need to deprecate the existing
tags endpoints for v5 and remove in v6. We could use 308s to signify
that they are moved.

---------

Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
2023-04-26 10:45:00 +02:00
Thomas Heartman
2765ae2c70
feat: unify error responses (#3607)
This PR implements the first version of a suggested unification (and
documentation) of the errors that we return from the API today.

The goal is for this to be the first step towards the error type defined
in this internal [linear
task](https://linear.app/unleash/issue/1-629/define-the-error-type
'Define the new API error type').

## The state of things today

As things stand, we currently have no (or **very** little) documentation
of the errors that are returned from the API. We mention error codes,
but never what the errors may contain.

Second, there is no specified format for errors, so what they return is
arbitrary, and based on ... Who knows? As a result, we have multiple
different errors returned by the API depending on what operation you're
trying to do. What's more, with OpenAPI validation in the mix, it's
absolutely possible for you to get two completely different error
objects for operations to the same endpoint.

Third, the errors we do return are usually pretty vague and don't really
provide any real help to the user. "You don't have the right
permissions". Great. Well what permissions do I need? And how would I
know? "BadDataError". Sick. Why is it bad?

... You get it.

## What we want to achieve

The ultimate goal is for error messages to serve both humans and
machines. When the user provides bad data, we should tell them what
parts of the data are bad and what they can do to fix it. When they
don't have the right permissions, we should tell them what permissions
they need.

Additionally, it would be nice if we could provide an ID for each error
instance, so that you (or an admin) can look through the logs and locate
he incident.

## What's included in **this** PR?

This PR does not aim to implement everything above. It's not intended to
magically fix everything. Its goal is to implement the necessary
**breaking** changes, so that they can be included in v5. Changing error
messages is a slightly grayer area than changing APIs directly, but
changing the format is definitely something I'd consider breaking.

So this PR:

- defines a minimal version of the error type defined in the [API error
definition linear
task](https://linear.app/unleash/issue/1-629/define-the-error-type).
- aims to catch all errors we return today and wrap them in the error
type
-   updates tests to match the new expectations.

An important point: because we are cutting v5 very soon and because work
for this wasn't started until last week, the code here isn't necessarily
very polished. But it doesn't need to be. The internals can be as messy
as we want, as long as the API surface is stable.

That said, I'm very open to feedback about design and code completeness,
etc, but this has intentionally been done quickly.

Please also see my inline comments on the changes for more specific
details.

### Proposed follow-ups

As mentioned, this is the first step to implementing the error type. The
public API error type only exposes `id`, `name`, and `message`. This is
barely any more than most of the previous messages, but they are now all
using the same format. Any additional properties, such as `suggestion`,
`help`, `documentationLink` etc can be added as features without
breaking the current format. This is an intentional limitation of this
PR.

Regarding additional properties: there are some error responses that
must contain extra properties. Some of these are documented in the types
of the new error constructor, but not all. This includes `path` and
`type` properties on 401 errors, `details` on validation errors, and
more.

Also, because it was put together quickly, I don't yet know exactly how
we (as developers) would **prefer** to use these new error messages
within the code, so the internal API (the new type, name, etc), is just
a suggestion. This can evolve naturally over time if (based on feedback
and experience) without changing the public API.

## Returning multiple errors

Most of the time when we return errors today, we only return a single
error (even if many things are wrong). AJV, the OpenAPI integration we
use does have a setting that allows it to return all errors in a request
instead of a single one. I suggest we turn that on, but that we do it in
a separate PR (because it updates a number of other snapshots).

When returning errors that point to `details`, the objects in the
`details` now contain a new `description` property. This "deprecates"
the `message` property. Due to our general deprecation policy, this
should be kept around for another full major and can be removed in v6.

```json
{
  "name": "BadDataError",
  "message": "Something went wrong. Check the `details` property for more information."
  "details": [{
    "message": "The .params property must be an object. You provided an array.",
    "description": "The .params property must be an object. You provided an array.",
  }]
}
```
2023-04-25 13:40:46 +00:00
Mateusz Kwasniewski
f1133556bd
refactor: switching to new stats calculations (#3477) 2023-04-10 09:50:39 +02:00
Jaanus Sellin
99bcd7ca5c
feat: add import export flag (#3411) 2023-03-29 09:19:33 +03:00
Mateusz Kwasniewski
2caab45801
feat: disallow clone toggle on change request enabled (#3383) 2023-03-27 13:21:50 +02:00
Mateusz Kwasniewski
9abe859e60
chore: remove export import flag (#3371) 2023-03-27 12:31:19 +02:00
Mateusz Kwasniewski
ab913228ca
refactor: read model for change request access checking (#3380) 2023-03-24 14:31:43 +01:00
Gastón Fournier
a79a76f497
refactor: test composition and other error codes (#3348)
## About the changes
Small refactor to showcase how to use [composition to validate different
aspects of the
response](https://github.com/Unleash/unleash/pull/3348/files#diff-ee4c1bd501b1195162b7a85ed6be348a665288f871abc8e74f64d94361213f9eR361-R367)
and checking [different status
codes](https://github.com/Unleash/unleash/pull/3348/files#diff-4044a5da3280ef76960bbffd5f36eccb395ac319fe58c4d59ef68a878cbb1a5dR95)
2023-03-23 16:31:05 +01:00
Gastón Fournier
af42347a7b
chore: PoC test API helper (DRY) (#3342)
## About the changes
New way of centralizing API calls while doing E2E tests to avoid repeating ourselves.
2023-03-20 10:27:19 +01:00
Gastón Fournier
7a9ea22eed
feat: project-specific segments tests and fixes (#3339)
## About the changes
- Refactored some E2E tests to use our APIs
- Added test cases for project-specific segments
- Added validation to check a project can access a specific segment
- Fixed an OpenAPI schema that was missing segments

## Discussion points
https://github.com/Unleash/unleash/pull/3339/files#r1140008992
2023-03-17 12:43:34 +01:00
Mateusz Kwasniewski
1064dfa40c
feat: project mode (#3334) 2023-03-16 15:29:52 +01:00
Mateusz Kwasniewski
481a7bc45c
fix: Missing export (#3327) 2023-03-15 17:10:36 +01:00
Mateusz Kwasniewski
ce0543c951
feat: Create project service di (#3326) 2023-03-15 16:46:41 +01:00
Gastón Fournier
1d0bc833b3
chore: refactor segments to stop depending on the implementation (#3315)
## About the changes
- Introducing ISegmentService interface to decouple from the actual
implementation
- Moving UpsertSegmentSchema to OSS to be able to use types
- Added comments where our code is coupled with segments just to
highlight and have a conversation about some use cases if needed, but
they can be removed before merging
- Removed segment service from some project features as it was not used
2023-03-15 14:58:19 +01:00
Gastón Fournier
98d462db27
chore: add a new project column to segments table (#3263)
## About the changes
Adds a migration and persistence layer with a new column
`segment_project_id` to bind a segment to a project.
2023-03-07 14:56:20 +01:00
Mateusz Kwasniewski
e15aa9795a
feat: shared event emitter (#3241) 2023-03-02 09:52:19 +01:00
Mateusz Kwasniewski
ad588fd0d2
fix: pass shared event store (#3233) 2023-03-01 14:09:52 +01:00
Gastón Fournier
90e4054c90
docs: update documentation around permissions for variants (#3195)
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
2023-02-28 14:06:24 +01:00
Mateusz Kwasniewski
909d709089
fix: db type (#3180) 2023-02-22 11:15:46 +01:00
Mateusz Kwasniewski
3800877be1
feat: drop full- for import/validate (#3168) 2023-02-21 10:15:57 +01:00