[Feature Request] JamfPatchUploader only update the definition (add/link the pkg), but not create a patch policy?

[mikaellofgren]

Is it possible to have JamfPatchUploader only update the definition (add/link the pkg), but not create a patch policy?
I can get it to work if I can create patch template xml file with an exclusion computer group, that doesn’t exist and it will throw an error Error: Unable to match excluded computer group
Then I can use only one patch def named “Name Latest” and then manually change Target Version when I’m ready with the testings.

Thanks!

<computer_groups>
<computer_group>
<name>If this value is set the if will fail and dont create a patchdefination</name>
</computer_group>
</computer_groups>
<users/>
<buildings/>
<departments/>
<network_segments/>
<ibeacons/>
</exclusions>

[grahampugh]

Paging @Marschelloss - I'm still not a Patch user, so I don't know if this makes sense!

[Marschelloss]

Sorry for the late reply @grahampugh & @mikaellofgren . Currently in bed with a cold :(

The patching workflows of folks differ a lot, so most requests make sense in some way :D The same 'result' could be archived for example by creating disabled patches for each version, and only enabling them after testing. But this would result in many patch definitions and multiple enabled patches. At least when you don't disable the old ones (Jamf only deploys the latest enabled patch. So if you had multiple enabled ones, only the 'most current' one would trigger. But this is a rather undocumented behaviour I just noticed. So maybe better not rely on it).

Changing the code to just deploy the versions, and not patches would be no problem. We could simply skip the last part, if no patch template was provided. This way we wouldn't break any existing workflows.

What's you opinion @grahampugh on this change? Could write it up next week, if you want.

[grahampugh]

@Marschelloss sounds good to me. As I said, I'm not a Patch user so I don't really study all the use cases. So long as it's working for existing folks, then adding this new functionality should be fine 👍

[mikaellofgren]

@Marschelloss Get well! And I guess that you add this feature as a parameter/option to the processor like no-patch or something. Let me know if you want something to be tested.
Right now we using the patchuploader to create a disabled patch with the latest version, which we delete and only apply the new version to the "default" ongoing patch.

[Marschelloss]

Hi @grahampugh and @mikaellofgren ,

I created a pull request which would enable this behavior. A new variable/parameter/option was not needed. If no template is provided, simply no patch policy get's created: #88

I didn't need to change a lot, so no further testing is needed. But of course you can try my fork if you want test it yourself.

Cheers

[mikaellofgren]

@Marschelloss I did a quick test and it seems to work perfectly. Thanks!