Better ShouldProcess Support - by Randy in Marin

Status : 


Sign in
to vote
ID 798394 Comments
Status Active Workarounds
Type Suggestion Repros 0
Opened 8/23/2013 6:37:29 PM
Access Restriction Public


Hi, I've been struggling with ShouldProcess trying to get it to work the way I want.  Some of the issues are within the same function.  Other issues are with how ShouldProcess works with nested function calls.  I would like to see ShouldProcess() updated to allow more options without changing it's default behavior.  

For behavior internal to a function, please allow us to specify the confirm impact level to use in each call to ShouldProcess.  If the level is not specified, it defaults to the ConfirmImpact level defined for the function.  This would allow a single function to support low, medium, and high risk activities at the same time.  For example, if a function deletes a log file (minor), restarts a service (medium?), and deletes a database (major?), the number of confirmations will depend upon the $ConfirmPreference level.  Currently, it's all or nothing depending upon the ConfirmImpact defined for the function.  

Closely related is WhatIf support.  Currently, a WhatIf message is displayed independent of the $ConfirmPreference level.  It might be nice to have the option to suppress some of the low level whatIf messages if there are many of them.  For example, if I had a function with 50 minor tasks and 2 majors tasks, it would be nice to have the option to suppress the WhatIf messages for just the "Low" tasks if the $ConfirmPreference is "Medium" or "High".  Please allow ShouldProcess to have an optional parameter for the WhatIf impact level.  If it is not specified, it uses the current behavior.  

When working with nested functions, ShouldProcess from each function is isolated.  A ShouldContinue response in one function does not apply to another function.  This can be good or bad.  Please provide a new cmdletbinding parameter that will allow a function to use the parent's ShouldProcess functionality.  I can use (Get-Variable pscmdlet -Scope 1).Value.ShouldProcess to access the ShouldProcess of the parent, but I don't like that.  The ConfirmImpact default of the function would need to override the parents default value when ShouldProcess is called from the nested function.  A "yes to all" or "no to all" then will apply all functions sharing the same base ShouldProcess object.

If a function is not nested, the "UseParentShouldProcess=$true" would have no effect and the default behavior would be used.  

When ShouldProcess can have multiple confirm impact levels in one function (or in a set of nested functions using one parent ShouldProcess), there is a danger that a "yes to all" to a low level impact item will approve future a high impact items.  The "yes to all" should track the impact of the highest item approved.  If a "yes to all" is given to a low impact delete log file item, it should not by default apply to the next high impact item to format the hard drive.  However, once the hard drive is formatted, no further confirmation is required.  Some means to reset the "yes to all" level would be helpful.  Providing an option to have any "yes to all", no matter the confirm impact level, apply to all items would be useful in some cases.  When using multiple impact levels, the default would be at most an elevation of 3 confirms from low, medium, to high.  (The current default is to require one "yes to all" confirm per function - at the very least.)

A "no to all" still applies to all items no matter what the confirm impact level.  
Sign in to post a comment.