starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

[Epic] Admin-specific customizations #15049

New Issue
Open
opened 2026-01-31 04:27:00 +00:00 by claunia · 2 comments
claunia commented 2026-01-31 04:27:00 +00:00
Owner
Copy Link

Originally created by @DHowett on GitHub (Sep 1, 2021).

written and maintained by @carlos-zamora & @zadjii-msft

For quite some time now, we've gotten requests for admin-specific customizations. The first being to have an "appearance config" for an elevated session. However, we stopped working on that when we hit the following problem: how do we determine which appearance config to choose when a user is in an elevated session and also has an unfocused appearance config?

Over time, we've gotten more requests with similar situations (not necessarily limited to appearance config). This epic tracks these requests:

zadjii-msft notes:
Nexus of weird elevate:true bugs:

User stories

  • I want the Terminal to have a different set of profiles in the dropdown when running elevated (vs regularly)
  • I want a different defaultProfile when running elevated
  • I want to use a different profile.defaults block when running elevated
  • I want a profile to have a different appearance when running elevated
  • I want the Terminal itself to have a different theme when running elevated

Open questions

  • Is this prone to a combinatiorial explosion of situational settings? YES IT IS
    • Would there ever be a case for like, {container}DefaultProfile? (like UWP? this is an intentionally dumb example)
    • How would (focused, unfocused) x (elevated, unelevated) appearances work? That's already 4 different states.
    • (focused, unfocused) x (elevated, unelevated) x (light, dark) x (readonly, not) x (connections alive, dead)
  • Should these all be in the base settings file, or a separate settings file?
    • IE, should we have
      • elevatedTheme, elevatedDefaultProfile, profiles.elevatedDefaults OR
      • admin-settings.json
    • Should there be a entirely separate globals block for elevated settings, ala #9992?

Other Admin QoL issues

Originally created by @DHowett on GitHub (Sep 1, 2021). _written and maintained by @carlos-zamora & @zadjii-msft_ For quite some time now, we've gotten requests for admin-specific customizations. The first being to have an "appearance config" for an elevated session. However, we stopped working on that when we hit the following problem: how do we determine which appearance config to choose when a user is in an elevated session and also has an unfocused appearance config? Over time, we've gotten more requests with similar situations (not necessarily limited to appearance config). This epic tracks these requests: - Themes: https://github.com/microsoft/terminal/issues/8311 - Appearance Config: https://github.com/microsoft/terminal/issues/3246 - Dropdown Customization: https://github.com/microsoft/terminal/issues/3637 <hr> _zadjii-msft notes:_ Nexus of weird `elevate:true` bugs: * #14932 * #13596 * #14442 * #13929 * #14799 - Discussion idea that might help here: What if we just restored both the admin and the unelevated one, when we first launch either? So when the terminal relaunches, it immediately brings back the _old_ admin state. Then, launching a _new_ admin profile will just work as expected - either an old admin window exists (whatever, that's fine) or it doesn't (that's fine too) - Trick would be clearing out the old admin state IF there's an unelevated window still hanging around (and I'm not sure admin can find that out) <hr> ### User stories * I want the Terminal to have a different set of profiles in the dropdown when running elevated (vs regularly) * I want a different defaultProfile when running elevated * I want to use a different `profile.defaults` block when running elevated * I want a profile to have a different `appearance` when running elevated * I want the Terminal itself to have a different `theme` when running elevated ### Open questions * Is this prone to a combinatiorial explosion of situational settings? YES IT IS * Would there ever be a case for like, `{container}DefaultProfile`? (like UWP? this is an intentionally dumb example) * How would (focused, unfocused) x (elevated, unelevated) _appearances_ work? That's already 4 different states. * (focused, unfocused) x (elevated, unelevated) x (light, dark) x (readonly, not) x (connections alive, dead) * <sub>#16554</sub> * https://github.com/microsoft/terminal/issues/17780#issuecomment-2643208323 * * Should these all be in the base settings file, or a separate settings file? * IE, should we have * `elevatedTheme`, `elevatedDefaultProfile`, `profiles.elevatedDefaults` OR * `admin-settings.json` * Should there be a entirely separate `globals` block for elevated settings, ala #9992? <hr> Other Admin QoL issues * #15391 "Run as Admin" (where the admin account != your current user account) uses the settings from the admin account, not your own. * #14517 * #12985 * #4459 * #13284
claunia added the Area-SettingsProduct-TerminalIssue-Scenario labels 2026-01-31 04:27:00 +00:00
claunia commented 2026-01-31 04:27:01 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Feb 2, 2023):

We definitely need a spec for this. One fairly extreme idea I had was to introduce an admin-settings.json.

  • if admin-settings.json exists, load that. Otherwise, use settings.json.
  • settings UI modifies the loaded JSON
  • when "import JSON" is eventually a feature in the settings UI, it'll be easier to migrate settings from one settings.json to another

I'm down for a more clever solution, but it seems like users want a completely customizable experience between their elevated prompt and non-elevated prompt. So might as well enable that experience? Especially since loading a different JSON would be trivial.

@carlos-zamora commented on GitHub (Feb 2, 2023): We definitely need a spec for this. One fairly extreme idea I had was to introduce an `admin-settings.json`. - if `admin-settings.json` exists, load that. Otherwise, use `settings.json`. - settings UI modifies the loaded JSON - when "import JSON" is eventually a feature in the settings UI, it'll be easier to migrate settings from one settings.json to another I'm down for a more clever solution, but it seems like users want a completely customizable experience between their elevated prompt and non-elevated prompt. So might as well enable that experience? Especially since loading a different JSON would be trivial.
claunia commented 2026-01-31 04:27:02 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 15, 2024):

idea

"showWhenElevated": false | (true | "both") | "only"

  • false: don't show a profile when elevated
  • true / "both": show this profile both when elevated and when running normally
  • only: Only show this profile when we're running elevated

Then just screw it with the appearance config on the existing profile - just have two different profiles.
Maybe when Dustin gets the itch to do separate appearance vs "task"s, then the two profiles could have different appearances, but the same "task".

this has been thoughts with Luca, who has kept me up since 3am

@zadjii-msft commented on GitHub (Nov 15, 2024): idea `"showWhenElevated": false | (true | "both") | "only"` * false: don't show a profile when elevated * true / "both": show this profile both when elevated and when running normally * only: Only show this profile when we're running elevated Then just screw it with the appearance config on the existing profile - just have two different profiles. Maybe when Dustin gets the itch to do separate appearance vs "task"s, then the two profiles could have different appearances, but the same "task". _this has been thoughts with Luca, who has kept me up since 3am_
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Settings Issue-Scenario Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#15049
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?