Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for custom profiles when running as admin vs user #3637

Open
tmmuessig opened this issue Nov 20, 2019 · 10 comments
Open

Allow for custom profiles when running as admin vs user #3637

tmmuessig opened this issue Nov 20, 2019 · 10 comments
Labels
Area-Settings Issues related to settings and customizability, for console or terminal Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal.
Milestone

Comments

@tmmuessig
Copy link

Description of the new feature/enhancement

Having the ability to create different profiles, can be a great visual clue as to what you are doing, or where you are doing it at, e.g dev vs production. The same can be said about running as an administrator vs a regular user. As an admin I can potentially make damaging changes to a system, while as a normal user, I would not have the permissions. Having the ability to not only customize a profile, but have a separate profile that would load when it is detected that I launched the terminal as administrator would be a handy visual clue that I can do something potentially destructive. A red background for admin, or a green background as a user for example.

Proposed technical implementation details (optional)

Add the ability to create a different profile section for running the terminal when I right click and select "Run As Administrator" vs just normally launching the Terminal as a normal user.

@tmmuessig tmmuessig added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Nov 20, 2019
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Nov 20, 2019
@zadjii-msft
Copy link
Member

This I shockingly don't hate.

We'd need some way to convey that this profile is only visible when elevated (or only visible when un-elevated). Further, this setting would need to be clear that it's not running the profile as admin, just that it's only visible when the Terminal is elevated.

I know Sublime Text has the notion of context for keybindings, where you can define some arbitrary queries for when keybindings apply. Maybe a similar style could be applied? Though that does seem like overkill for a feature that really only has three states.

Related: #632 (but not a dupe)

@zadjii-msft zadjii-msft added Area-Settings Issues related to settings and customizability, for console or terminal Product-Terminal The new Windows Terminal. labels Nov 20, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Nov 20, 2019
@zadjii-msft zadjii-msft added this to the Terminal Backlog milestone Nov 20, 2019
@DHowett-MSFT DHowett-MSFT removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Nov 21, 2019
@evankanderson
Copy link

(I was just looking for this today, wanted to add a +1)

@tmmuessig
Copy link
Author

@zadjii-msft - Has there been any update (thought, consideration, testing) to this?

@ianabrown
Copy link

If we're trying to gather requirements for this that feel like they'd fit within the existing setup, I'd request:

  • in addition to the existing "defaultProfile" setting, we introduce an "defaultProfileWhenElevated" (optional and terminal will use defaultProfile if this not specified?)
  • in addition to the "defaults" in "profiles" that apply to all profiles, also have a "defaultsWhenElevated"

Somewhat selfishly, these two would satisfy what I'd want from this feature - in my case, I'd go for a red tab color and a default profile of Powershell when elevated, but command prompt and normal tab color when not - but it also seems like it might address the requirements of the OP too?

@tmmuessig
Copy link
Author

@ianabrown - This absolutely would fit my requirements, and I love the idea of the defaultsWhenElevated "section" of the configuration. That way I can keep 99% of my settings (tab color, background, fonts, etc.), but only change those settings if 1. I am running as Admin, and 2, only if the defaultsWhenElevated are configured.

The way I see it is as follows:

Launch Terminal as Admin

  • Tab color is set to green (defaultProfile)
  • Background image is set to custom wallpaper (defaultProfile
  • Terminal detects that I am running as admin and checks for a defaultProfileWhenElevated
    • If that exists
    • Change Tab color to red (defaultProfileWhenElevated)
    • Change background wallpaper to admin customized wallpaper (defaultProfileWhenElevated)
        "defaults": {
            // Put settings here that you want to apply to all profiles
            "fontFace": "Cascadia Code PL",
            "fontSize": 10,
            "padding": "8, 8, 8, 8",
            "cursorShape": "bar",
            "backgroundImage": "ms-appdata:///Local/NonAdminWallpaper.jpg",
        },
        "defaultsWhenElevated": {
            // Put settings here that you want to apply while running as admin. Settings here will override any defaults defined
            "backgroundImage": "ms-appdata:///Local/AdminWallpaper.jpg",
            "tabColor":"Red"
        },

@0xabu
Copy link

0xabu commented Jan 26, 2022

IMO this is more important now that Win11's Win+X A launches Windows Terminal in admin mode and not PowerShell/CMD. At a minimum, maybe we could just have a different defaultProfile when elevated?

(My default profile is a WSL shell, but for elevation I almost always want something native.)

@zadjii-msft
Copy link
Member

zadjii-msft commented Jan 27, 2022

That's actually a really good point. Here's my showerthought spec for this, which I'm thinking is the most minimal way we could do this

<pseudo-spec>

Two settings changes:

  • elevatedDefaultProfile: The default profile when running as admin. This falls back to defaultProfile.
  • profile.hidden: changed to accept flags: ["none", "unelevated", "elevated", "all"], where true is none and false is all. So, you could hide profiles from one instance or the other.

I reopened #8311 for tracking scheme and other settings changes to existing profiles, since that wasn't really addressed in #8455. I may type these bits up as an addendum to that spec.

What I'd be "afraid" of is the same problem from #8345 where there's a combinatorial explosion of flags, but that's actually mitigated a bit by these just being flags, and not "keys that are basically sets of flags"

Warning
Yea we rejected that spec. It wasn't comprehensive enough.

@tmmuessig
Copy link
Author

@zadjii-msft - Just wondering if there has been any more consideration for implementing this?

@zadjii-msft
Copy link
Member

zadjii-msft commented Jan 25, 2023

Not really. It's still just kinda parked on the backlog - we'd definitely accept it as a community contribution. Alas, I don't think we're about to get to this any time soon.

I'll tag it up for discussion to see if the rest of the team is cool with the pseudo-spec I posted above. If there's consensus, I can write up a walkthrough of what I'd do to implement this.

May want to xref #13929 when we have that discussion.

Note: for discussion
We add the above two settings.
At least the profile.hidden changes seems easier. The elevatedDefaultProfile one is still suspect to the combinatorial problem. For example: #13284. That's another variable.

Discussion conclusion: the tiny little spec there was definitely not sufficient. We'll come up with something more wholistic through #11111

@zadjii-msft zadjii-msft added the Needs-Discussion Something that requires a team discussion before we can proceed label Jan 25, 2023
@carlos-zamora carlos-zamora removed the Needs-Discussion Something that requires a team discussion before we can proceed label Feb 22, 2023
@michael-hawker
Copy link

I liked @carlos-zamora idea mentioned in #11111 where there's just a completely separate config json file for admin mode. Maybe there could just be another setting toggle to enable that behavior?

Then there's just two independent settings files, one used for non-admin and one for admin. Then users can just customize all their settings when Terminal is elevated? They'll basically just work in isolation. Maybe there's some infobar if the setting it turned on that reminds them when terminal is elevated that the settings are for elevated only?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Settings Issues related to settings and customizability, for console or terminal Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal.
Projects
None yet
Development

No branches or pull requests

8 participants