Partners cannot rename a template via fragment plugins #16804

Closed
opened 2026-01-31 05:23:31 +00:00 by claunia · 6 comments
Owner

Originally created by @didrocks on GitHub (Feb 18, 2022).

Windows Terminal version

No response

Windows build number

No response

Other Software

No response

Steps to reproduce

Ship a template fragment with something like:

"profiles": [
      {
        "updates": "{f184b75f-6c82-5ea5-9b3e-3203d66c5f82}",
        "name": "My new profile name",
      },
    ]
  }

Then restart the terminal to take the new fragment in account.

Expected Behavior

"My new profile name" should appear as the profile name

Actual Behavior

The old name still appears, "name" in case of "update" is discared.

The rationale here is to replace the generated named in WSL, which is using the registered WSL ID (Ubuntu2004LTS for instance) instead of the Display Name registered (and used as the tab name entry) like the more readable Ubuntu 20.04 LTS.
Other kind of entries are overridden by the fragment, but not the name one.

The workaround right now is to hide the generated template with hidden: true and add a whole new entry.

Originally created by @didrocks on GitHub (Feb 18, 2022). ### Windows Terminal version _No response_ ### Windows build number _No response_ ### Other Software _No response_ ### Steps to reproduce Ship a template fragment with something like: ``` "profiles": [ { "updates": "{f184b75f-6c82-5ea5-9b3e-3203d66c5f82}", "name": "My new profile name", }, ] } ``` Then restart the terminal to take the new fragment in account. ### Expected Behavior "My new profile name" should appear as the profile name ### Actual Behavior The old name still appears, "name" in case of "update" is discared. The rationale here is to replace the generated named in WSL, which is using the registered WSL ID (`Ubuntu2004LTS` for instance) instead of the Display Name registered (and used as the tab name entry) like the more readable `Ubuntu 20.04 LTS`. Other kind of entries are overridden by the fragment, but not the `name` one. The workaround right now is to hide the generated template with `hidden: true` and add a whole new entry.
Author
Owner

@zadjii-msft commented on GitHub (Feb 18, 2022):

Huh. It should be able to do that. Why doesn't that work? I bet this regressed in one of the many settings refactors over the last few months.

Thanks for filing this! Let's make sure to get this fixed.

@zadjii-msft commented on GitHub (Feb 18, 2022): Huh. It should be able to do that. Why doesn't that work? I bet this regressed in one of the many settings refactors over the last few months. Thanks for filing this! Let's make sure to get this fixed.
Author
Owner

@DHowett commented on GitHub (Feb 23, 2022):

/cc @lhecker for this one ;)

@DHowett commented on GitHub (Feb 23, 2022): /cc @lhecker for this one ;)
Author
Owner

@lhecker commented on GitHub (Feb 23, 2022):

I'll debug this issue starting next week. 🙂

@lhecker commented on GitHub (Feb 23, 2022): I'll debug this issue starting next week. 🙂
Author
Owner

@lhecker commented on GitHub (Mar 4, 2022):

The problem here is that fields in a user's settings.json take precedence over fragments. Since profiles are created and written with a "name" field, the "name" field in fragments usually has no effect. If you were to remove the "name" field from your settings.json this would work as expected.

What is unexpected however is that we don't respect such updates when the dynamic profile is first added. I'm going to submit a PR for that.

@lhecker commented on GitHub (Mar 4, 2022): The problem here is that fields in a user's settings.json take precedence over fragments. Since profiles are created and written with a "name" field, the "name" field in fragments usually has no effect. If you were to remove the "name" field from your settings.json this would work as expected. What is unexpected however is that we don't respect such updates when the dynamic profile is first added. I'm going to submit a PR for that.
Author
Owner

@ghost commented on GitHub (Apr 19, 2022):

:tada:This issue was addressed in #12627, which has now been successfully released as Windows Terminal v1.12.1098.🎉

Handy links:

@ghost commented on GitHub (Apr 19, 2022): :tada:This issue was addressed in #12627, which has now been successfully released as `Windows Terminal v1.12.1098`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.12.1098) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Author
Owner

@ghost commented on GitHub (Apr 19, 2022):

:tada:This issue was addressed in #12627, which has now been successfully released as Windows Terminal Preview v1.13.1098.🎉

Handy links:

@ghost commented on GitHub (Apr 19, 2022): :tada:This issue was addressed in #12627, which has now been successfully released as `Windows Terminal Preview v1.13.1098`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.13.1098) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#16804