Set-TssSecret split into other commands?

[wsmelton]

I am finding that we have many endpoints to deal with on properties with secrets:

Field updates can be done in multiple ways:

• PUT /secrets/:id/fields/:slug
• PATCH /secrets/:id/general
• PUT /secrets/:id

While properties have a similar issue, but certain properties fall only under certain endpoints:

• PUT /secrets/:id - common properties (but not all)
• PATCH /secrets/:id/email - email properties sendEmailWhenChanged, sendEmailWhenHeartbeatFails, and sendEmailWhenViewed
• PATCH /secrets/:id/general - some general properties such as active, folder (this will move it to another folder), generateSshKeys, enableInheritSecretPolicy, site, and even template
• PATCH /secrets/:id/security-checkout - this one has checkOutChangePasswordEnabled, checkOutEnabled, and checkOutIntervalMinutes
• PATCH /secrets/:id/security-general - has doubleLockId, enableDoubleLock, hideLauncherPassword, proxyEnabled, requiresComment, and sessionRecordingEnabled

Having all of the above supported within just Set-TssSecret could be done, but it would involve expanding the parameter list a large bit. If I break it out into other commands to make the test more manageable it could also be considered whether to use a different verb (i.e., Update-TssSecret or Edit-TssSecret). Edit, may work better as it relates to the permission that is required as a minimum?

Each endpoint above also has varying output but from the perspective of the command itself, you generally will see commands that change or update data only return true or false to indicate they were successful or not.

So the option would be to either expand the command as-is to just have dozens of properties which give the advantage of discovering what can be set on a secret:

Examples if I kept this as one command:

# enables email when changed setting
Set-TssSecret -Session $session -Id 43 -EmailWhenChanged

# disables email when changed setting
Set-TssSecret -Session $session -Id 43 -EmailWhenChanged:$false

[wsmelton]

@thycotic-ps/professional-services @thycotic-ps/sales-engineers

Looking for input on anyone's thoughts.

Options:

• Keep this all as one command with a bunch of parameters? (👍🏻 )
• Split it into Edit-TssSecretField and Edit-TssSecretProperty (❤️ )

[jagger]

I'd rather have 1 really long command than have to call a number of cmdlets to change multiple things.

[wsmelton]

Ah, yeah...that's a good point toward ease of use.

[wsmelton]

Found a fairly clean way to do this and think it will be manageable. The test for this function will likely be one of the longest in the whole module 😆 😢

Some settings for secrets will be put in the Update command ( #14 ) even though they likely could be put in this one it seems fitting that the few settings that change the "state" go under the Update verb.