When using the openWhenFinished key to trigger a post-onboarding cleanup policy via a Jamf Self Service URL scheme, the Self Service application launches into the foreground. If the triggered policy runs a script designed to remove Setup Checklist, the user sees the Self Service UI open and display a progress tile right as their onboarding concludes. It would be ideal to avoid this so the handoff to the desktop remains completely seamless.
It would be helpful to have a mechanism to pass an option or flag to openWhenFinished so that the target application, binary path, or URL scheme can be triggered in a hidden or background state, similar to running open -g or open -j on macOS.
This could potentially be implemented by introducing a secondary boolean key alongside the main execution path:
XML
<key>openWhenFinished</key>
<string>jamfselfservice://content?entity=policy&id=123&action=execute</string>
<key>openWhenFinishedHidden</key>
<true/>
Alternatively, openWhenFinished could accept an optional dictionary structure to accommodate advanced execution parameters:
XML
<key>openWhenFinished</key>
<dict>
<key>path</key>
<string>jamfselfservice://content?entity=policy&id=123&action=execute</string>
<key>hide</key>
<true/>
</dict>
Running an uninstallation process inside the updateStatusScript hook of the final step does not quite meet this need. Because Setup Checklist evaluates within the standard user context, it does not have the administrative privileges required to modify or remove system-level launch agents, receipts, or root-protected directories. The process needs to be passed back to the root Jamf binary via Self Service to complete successfully.
Allowing the final action to execute invisibly would provide a very clean handoff. The onboarding interface closes and any final administrative cleanup happens entirely behind the scenes, keeping the end-user experience clear of unexpected application windows.
When using the openWhenFinished key to trigger a post-onboarding cleanup policy via a Jamf Self Service URL scheme, the Self Service application launches into the foreground. If the triggered policy runs a script designed to remove Setup Checklist, the user sees the Self Service UI open and display a progress tile right as their onboarding concludes. It would be ideal to avoid this so the handoff to the desktop remains completely seamless.
It would be helpful to have a mechanism to pass an option or flag to openWhenFinished so that the target application, binary path, or URL scheme can be triggered in a hidden or background state, similar to running open -g or open -j on macOS.
This could potentially be implemented by introducing a secondary boolean key alongside the main execution path:
XML
Alternatively, openWhenFinished could accept an optional dictionary structure to accommodate advanced execution parameters:
XML
Running an uninstallation process inside the updateStatusScript hook of the final step does not quite meet this need. Because Setup Checklist evaluates within the standard user context, it does not have the administrative privileges required to modify or remove system-level launch agents, receipts, or root-protected directories. The process needs to be passed back to the root Jamf binary via Self Service to complete successfully.
Allowing the final action to execute invisibly would provide a very clean handoff. The onboarding interface closes and any final administrative cleanup happens entirely behind the scenes, keeping the end-user experience clear of unexpected application windows.