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.
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)
This PR cleans up the lifecycleGraphs flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10941
## 🧹 AI Flag Cleanup Summary
This change removes the `lifecycleGraphs` feature flag and makes the
associated
feature permanently available. The lifecycle graphs on the insights page
are now
enabled for all Enterprise users.
### 🚮 Removed
- **Configuration**
- `lifecycleGraphs` flag definition from `IFlagKey` and `flags` object
in
`src/lib/types/experimental.ts`.
- `lifecycleGraphs` flag from `UiFlags` in
`frontend/src/interfaces/uiConfig.ts`.
- `lifecycleGraphs: true` from `src/server-dev.ts` development config.
- **UI**
- The `useUiFlag('lifecycleGraphs')` hook call and associated
conditional
rendering logic in `PerformanceInsights.tsx`.
### 🛠 Kept
- **UI**
- The "New flags in production" and "Flags archived vs flags created"
widgets
are now always shown for Enterprise instances on the Performance
Insights page.
### 📝 Why
The `lifecycleGraphs` feature flag has been fully rolled out and is now
considered a permanent part of the application. This cleanup removes the
obsolete flag and its related conditional logic to simplify the
codebase.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This PR cleans up the newStrategyModal flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10911🧹 AI Flag Cleanup Summary
This change removes the newStrategyModal feature flag, making the new
"Add
strategy" modal the default and only experience for adding strategies to
a
feature.
I've removed the flag checks and the legacy code paths for the old
strategy
menu. The FeatureStrategyMenu component is now simplified to only render
the new
modal experience. I have also removed the flag from backend
configurations and
frontend interfaces.
🚮 Removed
• Feature Flag: newStrategyModal flag definition and configuration from
experimental.ts, server-dev.ts, and uiConfig.ts.
• Conditional Logic: All checks for the newStrategyModal flag in
FeatureStrategyMenu.tsx.
• Legacy Components: The old strategy menu
(LegacyFeatureStrategyMenuCards) and
related dialogs (LegacyReleasePlanReviewDialog) have been removed from
FeatureStrategyMenu.tsx.
• Unused Code: Unused state variables, functions
(openDefaultStrategyCreationModal, openReleasePlans), and imports
related to
the legacy strategy menu have been cleaned up.
🛠 Kept
• New "Add strategy" modal: The new modal for adding strategies is now
the only
implementation. Its user experience is preserved and made default.
📝 Why
The newStrategyModal feature has been completed, and the decision was to
keep
the new user experience. This cleanup removes the complexity of
maintaining two
different UI paths for adding strategies, making the code cleaner and
easier to
maintain.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Nuno Góis <github@nunogois.com>
This PR cleans up the newUiConfigService flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10909
## 🧹 AI Flag Cleanup Summary
This PR removes the `newUiConfigService` feature flag and makes its
functionality permanent. The `UiConfigController` now exclusively uses
the
`UiConfigService` to generate the UI configuration, removing the old,
now-dead
code path.
As a result of this change, several services that were only used in the
old
implementation have been removed from `UiConfigController`, along with
their
associated types and imports, simplifying the controller significantly.
### 🚮 Removed
- **Flag Definitions**
- `newUiConfigService` flag definition from
`src/lib/types/experimental.ts`.
- Development override for `newUiConfigService` in `src/server-dev.ts`.
- **Conditional Logic**
- The `if` block checking for `newUiConfigService` in
`UiConfigController.getUiConfig`.
- **Dead Code**
- The legacy implementation of building the UI config object inside
`UiConfigController`.
- Several unused service dependencies (`VersionService`,
`SettingService`,
`EmailService`, `SessionService`, `MaintenanceService`) and
`IFlagResolver` from
`UiConfigController`.
### 🛠 Kept
- **New `getUiConfig` implementation**
- The `UiConfigController.getUiConfig` method now solely relies on
`UiConfigService` to fetch the UI configuration.
### 📝 Why
The `newUiConfigService` feature flag was fully rolled out and marked as
completed. This cleanup removes the flag and the legacy code path,
simplifying
the `UiConfigController` and making the new UI config service the
standard way
of providing UI configuration.
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
## About the changes
This adds the ability to disable custom strategy creation and editing by
using two env variables: `UNLEASH_DISABLE_CUSTOM_STRATEGY_CREATION` and
`UNLEASH_DISABLE_CUSTOM_STRATEGY_EDITING`.
Fixes: #9593
This could be useful if you want to remove the ability to create new
custom strategies and rely on the built-in ones
## About the changes
This introduces a new endpoint to allow users to check for readiness of
Unleash to serve traffic, in particular validating that the DB is up.
It's an opt-in feature that has to be enabled with the environment
variable `CHECK_DB_ON_READY=true` or via the configuration option
`checkDbOnReady`.
Closes#10742
This PR cleans up the originMiddlewareRequestLogging flag. These changes
were automatically generated by AI and should be reviewed carefully.
Fixes#10863
## 🧹 AI Flag Cleanup Summary
This change removes the `originMiddlewareRequestLogging` feature flag
and its
associated code. The flag's outcome was to be discarded, so the logging
it
controlled has been removed from `originMiddleware`.
### 🚮 Removed
- **Flag Definition**
- Removed `originMiddlewareRequestLogging` from the `IFlagKey` type in
`src/lib/types/experimental.ts`.
- Removed the flag from the development server configuration in
`src/server-dev.ts`.
- **Logic**
- Removed the conditional logging of API requests from
`originMiddleware`.
- **Tests**
- Removed the test case for API request logging in
`origin-middleware.test.ts`.
- Removed the flag setup from the test configuration.
### 🛠 Kept
- **Core functionality**
- The core logic of the `originMiddleware` for emitting `REQUEST_ORIGIN`
metric events for UI and API requests remains unchanged.
### 📝 Why
The `originMiddlewareRequestLogging` feature flag was completed and its
outcome
was 'discarded'. This cleanup removes the flag and the now-dead code
related to
it, simplifying the middleware and tests.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
