feat: hide CIRA in profile when disabled on the server#3445
Conversation
83e32b4 to
d1571a0
Compare
There was a problem hiding this comment.
Pull request overview
This PR updates the Profile Detail UI to hide the CIRA connection mode when the server reports CIRA is disabled (enterprise mode), and adds/extends unit tests to validate the expected behavior.
Changes:
- Wrap the CIRA connection-mode UI in a
ciraEnabled()gate so the option is not rendered when disabled. - Simplify the CIRA config selector rendering (removing the previous “disabled but referenced” read-only/warning path).
- Add unit tests covering enterprise CIRA disabled/enabled/error behavior and basic DOM visibility expectations.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| src/app/profiles/profile-detail/profile-detail.component.html | Conditionally renders the CIRA connection-mode UI based on ciraEnabled() and simplifies the CIRA config UI. |
| src/app/profiles/profile-detail/profile-detail.component.spec.ts | Adds tests for enterprise CIRA feature gating and introduces a helper to recreate the component after toggling environment.cloud. |
ff9cead to
16a256b
Compare
b2b1c4d to
447e445
Compare
447e445 to
190d5fa
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 17 out of 17 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
src/app/profiles/profile-detail/profile-detail.component.ts:294
- In enterprise mode before
getFeatures()resolves,setConnectionMode()can setconnectionModeto CIRA (because!ciraAvailabilityResolved()is true) while the template hides the CIRA radio entirely (@if (ciraEnabled())). This can leave the radio-group with no visible selection and still allow a user to submit a CIRA-based profile before feature availability is known (a race where a CIRA-disabled server could receive a CIRA update if the user saves quickly).
Consider either (a) blocking submit / disabling the Save button while CIRA availability is unresolved and the form is in CIRA mode, or (b) rendering a disabled “CIRA (loading…)” option until availability resolves so the selection stays visible but not actionable until the server response arrives.
setConnectionMode(data: Profile): void {
const canUseCira = this.ciraEnabled() || !this.ciraAvailabilityResolved()
if (data.tlsMode != null && data.tlsMode > 0) {
this.profileForm.controls.connectionMode.setValue(this.connectionMode.tls)
} else if (data.ciraConfigName != null && canUseCira) {
this.profileForm.controls.connectionMode.setValue(this.connectionMode.cira)
} else {
this.profileForm.controls.connectionMode.setValue(this.connectionMode.direct)
}
This pull request refines the handling of the CIRA (Cloud Internet Remote Access) feature in the profile management UI, improving both the user experience and code maintainability. The main changes ensure that CIRA options only appear when available, prevent users from selecting CIRA when it's disabled, and clean up related UI and translation strings. The test suite is expanded to cover these scenarios.
CIRA feature handling and UI improvements:
profile-detail.component.htmlare now only shown if CIRA is enabled, preventing users from selecting or viewing CIRA options when the feature is unavailable. The fallback logic ensures profiles referencing CIRA automatically switch to a supported mode if CIRA is disabled.Logic and state management:
Introduced a new
ciraAvailabilityResolvedsignal to track when the server's CIRA feature status is known, preventing premature changes to profile forms before the server response arrives.Test coverage:
Added and updated tests in
profile-detail.component.spec.tsto verify correct behavior when CIRA is enabled, disabled, or the feature status is pending, including automatic fallback logic and UI visibility.Translation cleanup:
Removed unused translation strings related to CIRA being disabled from all localization files, as the warning and inline notes are no longer shown in the UI.
PR Checklist
What are you changing?
Anything the reviewer should know when reviewing this PR?
If the there are associated PRs in other repositories, please link them here (i.e. device-management-toolkit/repo#365 )