## About the changes
When deleting a user we set the email to null and deleted_at to the
current date, there's no case where email is set and deleted_at is also
set.
We found some situations where this happens, specifically when SAML and
SCIM are used in conjunction
## About the changes
Having SCIM enabled with SAML and auto-create can generate issues with
each protocol stepping into the other protocol's toes.
This PR adds protection to avoid updating SCIM-managed users with SAML
data (cause SCIM will override this data later).
It also adds a new method in the store to check if we have cases where
deleted_at is set but the email is not cleared, and there's no delete
event in the audit log (we've found one case, and we believe it might be
related to interoperability issues between SAML and SCIM)
This PR cleans up the addConfiguration flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10627
## 🧹 AI Flag Cleanup Summary
This change removes the `addConfiguration` feature flag. The feature was
discarded, so this cleanup reverts the UI to its state before the
`addConfiguration` flag was introduced. The primary change is in the
strategy
menu, where the single "Add configuration" button is removed and the
original
"Use template," "Add strategy," and "More" buttons are restored.
### 🚮 Removed
- **Flag Definitions**
- `addConfiguration` flag from `experimental.ts` on the backend.
- `addConfiguration` flag from `uiConfig.ts` on the frontend.
- `addConfiguration: true` from the `server-dev.ts` config.
- **UI Components & Logic**
- The conditional rendering in `FeatureStrategyMenu.tsx` that showed an
"Add
configuration" button.
- The `useUiFlag('addConfiguration')` hook call and its import from
`FeatureStrategyMenu.tsx`.
### 🛠 Kept
- **UI Components & Logic**
- The original set of buttons in `FeatureStrategyMenu.tsx`: "Use
template",
"Add strategy", and a "More strategies" icon button. This was the code
path for
when the flag was disabled.
### 📝 Why
The `addConfiguration` feature flag was marked as completed with the
outcome
"discarded". This cleanup removes the flag and all related code,
preserving only
the intended code path, which is the UI behavior from before the flag
was
introduced.
---------
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 reportUnknownFlags flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10595
## 🧹 AI Flag Cleanup Summary
This change removes the `reportUnknownFlags` feature flag and makes its
functionality a permanent part of the application. The "Unknown flags"
feature
is now always enabled.
### 🚮 Removed
- **Flag Definitions**
- Removed `reportUnknownFlags` from `IFlagKey` and `UiFlags` types.
- Removed `reportUnknownFlags` from the experimental flags configuration
in `src/lib/types/experimental.ts`.
- Removed the flag from development and test configurations
(`src/server-dev.ts`, `unknown-flags.e2e.test.ts`).
- **Conditional Logic**
- Removed conditional checks for `reportUnknownFlags` in backend
services
(`UnknownFlagsService`, `ClientMetricsServiceV2`) and API controllers
(`UnknownFlagsController`).
- Removed `useUiFlag('reportUnknownFlags')` and related conditional
rendering from frontend components (`UnknownFlagsTable`,
`FeatureToggleListTable`). The UI elements are now always visible.
- Modified the `useUnknownFlags` hook to always fetch data.
### 🛠 Kept
- **Core Functionality**
- The feature to report and display unknown flags is now always active.
- The "Unknown flags" link is now permanently visible on the feature
flags
overview page.
- Backend logic for processing and storing unknown flags is now always
executed.
### 📝 Why
The `reportUnknownFlags` feature flag was marked as completed with the
feature
being kept. This cleanup removes the flag and its associated conditional
logic,
simplifying the code and making the unknown flags reporting a permanent
feature.
---------
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 etagByEnv flag. These changes were automatically
generated by AI and should be reviewed carefully.
Fixes#10556
## 🧹 AI Flag Cleanup Summary
This change removes the `etagByEnv` feature flag and makes its
functionality
permanent. This modifies the ETag generation for client API requests to
be
environment-specific, improving caching efficiency. The cleanup involved
removing the flag definition, updating the controller logic to
permanently use
the environment-specific ETag calculation, and refactoring the
corresponding E2E
tests to only cover the enabled behavior.
### 🚮 Removed
- **Flag Definition**
- The `etagByEnv` flag from `IFlagKey` in
`src/lib/types/experimental.ts`.
- **Conditional Logic**
- The check for the `etagByEnv` flag in `calculateMeta` method in
`src/lib/features/client-feature-toggles/client-feature-toggle.controller.ts`.
- **Tests**
- Test cases in `src/test/e2e/api/client/feature.optimal304.e2e.test.ts`
that
covered the disabled state of the `etagByEnv` flag.
### 🛠 Kept
- **Environment-Specific ETags**
- The behavior of generating environment-specific ETags is now the
default and
only behavior.
- **Tests**
- E2E tests verifying the functionality of environment-specific ETags
have
been retained and simplified.
### 📝 Why
The `etagByEnv` feature has been successfully rolled out and validated.
By
removing the feature flag and associated conditional logic, we simplify
the
codebase, reduce complexity, and make it easier to maintain. This change
makes
the improved ETag generation strategy a permanent part of the system.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
This PR cleans up the debugEtag flag. These changes were automatically
generated by AI and should be reviewed carefully.
Fixes#10557
## 🧹 AI Flag Cleanup Summary
This removes the `debugEtag` feature flag from the codebase. This flag
was used
to enable additional logging for debugging ETag generation for the
client
features endpoint.
### 🚮 Removed
- **Flag Definition**
- The `debugEtag` flag from the `IFlagKey` type in
`src/lib/types/experimental.ts`.
- **Conditional Logging**
- Removed logging statements guarded by the `debugEtag` flag in
`client-feature-toggle.controller.ts` and
`configuration-revision-service.ts`.
### 🛠 Kept
- **Default Behavior**
- The existing code paths for when the flag was disabled, which is now
the
only behavior.
### 📝 Why
The `debugEtag` flag was marked as completed with the outcome
"discarded". The
debugging functionality it provided is no longer needed. This change
removes the
dead code associated with the flag, simplifying the codebase.
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
## About the changes
In the previous fix: https://github.com/Unleash/unleash/pull/10543, we
made sure client token types were displayed in the UI. Here, we're also
making sure that the Backend token types are displayed as well.
1. A test validates that if a backend token exists in the db it will be
returned in the API response.
2. The UI has been adapted to also consider backend token types
Internally token types are still identified as CLIENT, therefore when we
filter the ones we're allowed to see, we should still consider them as
CLIENT tokens not BACKEND tokens. This is internal until we can fully
remove CLIENT with the next major.
This PR cleans up the releasePlans flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10536
## 🧹 AI Flag Cleanup Summary
The `releasePlans` feature flag has been removed, making the feature
permanently
available for Enterprise customers. All conditional logic and checks
related to
this flag have been removed from the codebase.
This change ensures that Release Plans are an integral part of the
Unleash
Enterprise offering.
### 🚮 Removed
- **Flag Definitions**
- `releasePlans` flag from `experimental.ts` in the backend.
- `releasePlans` flag from `uiConfig.ts` in the frontend.
- `releasePlans` flag from `server-dev.ts` development config.
- **Conditional Logic**
- Removed checks for `releasePlansEnabled` in components and hooks,
including
`ReleaseManagement.tsx`, `FeatureStrategyMenu.tsx`, and
`NewInUnleash.tsx`.
- Removed `useUiFlag('releasePlans')` calls from all frontend files.
- Removed the `flag: 'releasePlans'` property from route definitions in
`routes.ts`.
### 🛠 Kept
- **Feature Functionality**
- All UI and logic related to Release Plans and Release Templates are
now
unconditionally enabled for Enterprise users.
### 📝 Why
The `releasePlans` feature has been successfully rolled out and is now a
stable
part of the product. This cleanup removes the artık feature flag to
simplify the
codebase and reduce complexity.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Nuno Góis <github@nunogois.com>
