The `create` and `update` role methods used to blindly accept any
incoming permissions, but if the permissions don't exist in the
database, then the database would throw, yielding a 500 error to the
user.
To fix this, we can validate that all the permissions exist before we
try to add the incoming permissions.
The http error only manifests in enterprise, but the fix requires
modifying the access service. Therefore, I've added the tests to the
access service too, such that if you break something, then you don't
need to wait for it to propagate to enterprise.
---------
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
TypeScript throws `TS7056` because the schema object becomes too large
for the compiler to fully serialize when using deep literal inference.
Splitting the components object and explicitly reconstructing the type
prevents the error while preserving correct type inference.
Adds a test to ensure that the `getAll` method of the flag resolver
doesn't return the disabled variant if a flag is defined as a boolean in
the settings.
We have some places in the UI where we check `if
(uiConfig.flags.<flagname>) {...}`. If one of these flags were suddenly
returned as the disabled variant instead of `false`, then it'd be
impossible to turn it off.
As such, to maintain backwards compatibility and adhere to the principle
of least surprise, I'd like to add this test to ensure this doesn't
change going forward.
Fixes a bug / uncovered edge case in the flag resolver in Unleash:
If a local experiment was defined as false (the typical default value),
then that flag could only ever be returned as a boolean from the
`ui-config` endpoint. In other words, even if the external resolver has
a variant for that flag, the UI would never get the variant.
The fix is to not just check `isEnabled` for false flags, but instead:
- use `getVariant`
- then check `variant.enabled` (in which case we have a variant and can
return it)
- else check `variant.feature_enabled`, falling back to `isEnabled` only
if `feature_enabled` is null/undefined.
Updates the maintenance mode banner to accept string variants, allowing
for custom maintenance mode messages.
Because the banner is almost the same as the existing banner component
we have, we can simplify the impl and just reuse the existing banner
instead. The one difference is that the maintenance mode banner used to
be taller. However, after talking to UX, we agreed that the banner
should be the same size, anyway.
<img width="1552" height="120" alt="image"
src="https://github.com/user-attachments/assets/fc9dc8ad-26ba-411a-846e-a79e1b855f37"
/>
Configure the `maintenanceMode` flag type to be `boolean | Variant` and
update the env parsing to allow passing strings from the env.
The [first
impl](3bbfc9e681)
required you to set a full, variant -- stringified as json -- in the
env, but this is both error-prone and not very user friendly.
Additionally, the name of the variant isn't really important, and if
you're passing a string, you probably want it to be true.
As such, the [second
impl](c38357baa4)
updates the env parsing to read the full string value into a
pre-formatted variant if it's not parseable as a boolean.
As such, to set a custom message, you can now do:
```sh
UNLEASH_EXPERIMENTAL_MAINTENANCE_MODE='Custom message from plain env var string' yarn dev
```
With the [updates to the
UI](https://github.com/Unleash/unleash/pull/10961), it'll look a little
something like this:
<img width="388" height="64" alt="image"
src="https://github.com/user-attachments/assets/6b8a174b-d75f-4748-8f1a-1ad4ebce2073"
/>
## Rationale
This allows locking down Unleash instances with a custom message.
Previously, you'd have to use both maintenance mode and a custom banner
for this, but that requires more work to set properly and it shows two
banners, when you really only want the one.
Updates the flag resolver and other references to the unleash client's
deprecated `getDefaultVariant` to instead point to the `defaultVariant`
property instead, as described by the deprecation notice:
46bf068d26/src/variant.ts (L55-L60)
