Allow option to merge, or parameters to allow external merging

[RamblingCookieMonster]

Hiyo!

In some cases, one might simply want to set, or add a property to an existing configuration. As is, Export-Configuration simply overwrites everything.

I don't see an option to manually merge - if we import-configuration to get current properties, we have no control over what scope, so it seems awkward to assume we can let the winner of import-configuration override the specific scope a user selects. Maybe I'm not thinking it through though.

I see two potential workarounds:

• Allow something like a -Merge switch on the export, which reads the current config, and adds / updates properties as needed
• Allow specifying the scope on Import-Configuration

Both might come in handy depending on your scenario and desire for abstraction.

Cheers!

[scrthq]

Hey Warren - I have a fork that does this actually, need to push my most recent update and submit a PR, just need to sanity check that what I've added won't break existing use cases of Configuration

[Jaykul]

It sounds useful to be able to set a single setting at a specific level ...

As a general case, I don't think I want to support importing a specific layer. Other than this particular scenario of exporting to a specific layer, what's a use case where you'd want to import just one layer and ignore settings at other layers?

What I'd rather do is provide an Update-Configuration wrapper for Update-Metadata, in the same way that:

• Export-Configuration combines Get-StoragePath and wraps Export-Metadata
• Import-Configuration combines Get-StoragePath and wraps Import-Metadata

Update-Metadata updates a single value in a PowerShell metadata file, so if we added an Update-Configuration with a -Scope parameter, would that work for your case?

[scrthq]

Importing a single layer in my case makes managing multi-level configs easier; things tend to get a little messy when with stacking layers due to the complexity of my configs. I leverage the layers to differentiate accessibility to each config only but tend to have module configs which need multiple sub configs at each layer. This also allows me to test and validate a specific layer's config that another user, i.e. a system account, would be using (i.e. Machine) without having to move/replace my User level personal config.

Sample config on my end for a single layer (module functions handles selecting the ConfigName after the layer's imported):

@{
  work = @{
    Preference = 'CustomerID'
    P12KeyPath = 'C:\Access\PSGoogle.p12'
    AppEmail = '[email protected]'
    CustomerID = 'C12348938'
    AdminEmail = '[email protected]'
    Domain = 'domain1.com'
    ServiceAccountClientID = '89723478923459782134789'
  }
  DefaultConfig = 'work'
  personal = @{
    AdminEmail = '[email protected]'
    Domain = 'domain2.com'
    Preference = 'CustomerID'
    CustomerID = '09876123'
    P12KeyPath = 'C:\Access\pers_key.p12'
    AppEmail = '[email protected]'
    ServiceAccountClientID = '329862349862398623986'
  }
  serviceaccount = @{
    Preference = 'CustomerID'
    P12KeyPath = 'C:\Access\keyname_for_this.p12'
    AppEmail = '[email protected]'
    CustomerID = '12345678'
    AdminEmail = '[email protected]'
    Domain = 'domain2.com'
    ServiceAccountClientID = '1234567890123456789'
  }
}

[Jaykul]

I think the main thing I want is for Update-Metadata to support adding fields that aren't there, and then maybe incorporate that into Configuration as:

Update-Configuration -Scope User -KeyName work.AdminEmail -Value nate@newdomain.com