Is this a regression?
Yes
Severity
🔴 Critical – blocks key functionality
Please provide the branch(es) you discovered this issue in
v93
Environment Details
Microsoft edge version 148.0.3967.54 , OIM version 9.3 v93-311513, Microsoft windows 11 Pro, Enviroment: Standard One Identity Web Portal (qer-app-portal), no custom UI modifications
Please provide a minimal set of steps to reproduce the issue
The issue is intermittent and configuration‑dependent, but the configuration itself is valid; regardless, the UI must never remain permanently blocked after initialization.
Steps to reproduce
- Deploy One Identity with a configuration where valid but non‑standard Person display/initialization data is used (configuration is supported and works in normal scenarios).
- Open the One Identity Web Portal and log in with a standard user.
- Occasionally after login, the page renders visually but remains completely non‑interactive.
- The UI is blocked by a persistent loading/busy overlay and requires a manual removal of the overlay to become usable.
Description
During web portal initialization, a handled frontend exception occurs while rendering a Person entity (e.g. during GetDisplay / GetColumn).
Although the exception is caught and the application continues, the UI remains permanently blocked because the busy/CDK overlay is never cleared.
This is not a configuration issue:
- All Person display patterns were corrected to remove InternalName.
- The UI renders correctly once the blocking overlay is manually removed.
- This proves that the application logic completes, but the busy state is not released.
- The root cause is that the frontend bootstrap/initialization logic sets a busy overlay (setBusy(true)), but does not guarantee cleanup (setBusy(false)) in all code paths (e.g. missing finally / finalize()).
Expected behavior:
Even if an initialization error occurs (caught or uncaught), the UI must always clear the busy overlay and remain interactive.
Suggested fix:
Ensure all initialization flows clear the busy state in a finally / finalize() block so the overlay is always removed.
This should be addressed in the product frontend, as configuration changes alone cannot prevent this UI freeze.
Describe what you expected to happen versus what actually happened
Expected behavior
After login, the web portal completes initialization and becomes fully interactive.
Actual behavior
After login, the page renders visually but remains completely non‑interactive due to a persistent loading/busy overlay that is never cleared. The UI can only be used after manually removing the blocking overlay.
Relevant logs or console output
TypeError: GetColumn("InternalName")
at GetDisplay
at Replace
during early web portal initialization.
A single Angular CDK overlay (cdk-overlay-pane / cdk-overlay-backdrop) remains active
after login, blocking all UI interaction until manually removed.Add a screenshot(s) if that helps illustrate the problem
Screenshot shows the web portal after login where the page is rendered,
but the UI remains non-interactive due to a persistent loading/busy overlay
after an initialization error.
Suggested Fix
Ensure that the web portal initialization/bootstrap logic always clears the loading/busy overlay, even when an exception occurs during initialization (caught or uncaught).
Specifically, any code path that sets the busy state (e.g. setBusy(true)) must guarantee cleanup via finally / finalize() so that the CDK overlay is always removed.
A handled initialization error must not leave the UI in a permanently blocked state.
Anything else?
This issue causes intermittent loss of usability for end users, which has led to user frustration as the web portal cannot be reliably used during affected sessions.
Before submitting...
Is this a regression?
Yes
Severity
🔴 Critical – blocks key functionality
Please provide the branch(es) you discovered this issue in
v93
Environment Details
Microsoft edge version 148.0.3967.54 , OIM version 9.3 v93-311513, Microsoft windows 11 Pro, Enviroment: Standard One Identity Web Portal (qer-app-portal), no custom UI modifications
Please provide a minimal set of steps to reproduce the issue
The issue is intermittent and configuration‑dependent, but the configuration itself is valid; regardless, the UI must never remain permanently blocked after initialization.
Steps to reproduce
Description
During web portal initialization, a handled frontend exception occurs while rendering a Person entity (e.g. during GetDisplay / GetColumn).
Although the exception is caught and the application continues, the UI remains permanently blocked because the busy/CDK overlay is never cleared.
This is not a configuration issue:
Expected behavior:
Even if an initialization error occurs (caught or uncaught), the UI must always clear the busy overlay and remain interactive.
Suggested fix:
Ensure all initialization flows clear the busy state in a finally / finalize() block so the overlay is always removed.
This should be addressed in the product frontend, as configuration changes alone cannot prevent this UI freeze.
Describe what you expected to happen versus what actually happened
Expected behavior
After login, the web portal completes initialization and becomes fully interactive.
Actual behavior
After login, the page renders visually but remains completely non‑interactive due to a persistent loading/busy overlay that is never cleared. The UI can only be used after manually removing the blocking overlay.
Relevant logs or console output
Add a screenshot(s) if that helps illustrate the problem
Screenshot shows the web portal after login where the page is rendered,
but the UI remains non-interactive due to a persistent loading/busy overlay
after an initialization error.
Suggested Fix
Ensure that the web portal initialization/bootstrap logic always clears the loading/busy overlay, even when an exception occurs during initialization (caught or uncaught).
Specifically, any code path that sets the busy state (e.g. setBusy(true)) must guarantee cleanup via finally / finalize() so that the CDK overlay is always removed.
A handled initialization error must not leave the UI in a permanently blocked state.
Anything else?
This issue causes intermittent loss of usability for end users, which has led to user frustration as the web portal cannot be reliably used during affected sessions.
Before submitting...