1.0.2

v1.0.2

Added

• Added a dynamic application overview to the initial Patch Helper dialog.
  • The applications displayed in the first window are now generated dynamically from policyJSON.
  • Each detected application is displayed with its application name and corresponding icon.
  • The list automatically reflects the applications that are actually pending for the current device.
  • Added compact list styling to provide a clearer table-like overview before the user starts the update process.

Improved

• Improved LaunchDaemon lifecycle handling for deferred updates.
• LaunchDaemon status is now determined using the actual launchd service state instead of only checking whether the plist exists.
• Added separate handling for:
  • LaunchDaemon plist exists
  • LaunchDaemon service is loaded
  • LaunchDaemon is fully ready
• Added automatic recovery when the LaunchDaemon plist exists but the service is not loaded.
• Replaced legacy launchctl load handling with launchctl bootstrap system.
• LaunchDaemon state is now verified using launchctl print system/<label>.

Fixed

• Fixed an issue where an existing LaunchDaemon plist was incorrectly considered a fully active LaunchDaemon.
• Fixed intermittent cases where the LaunchDaemon plist was not removed correctly after updates completed.
• Changed the LaunchDaemon cleanup order so the plist is removed before the service is booted out.
• Added verification that the LaunchDaemon plist was actually removed.
• Fixed failed LaunchDaemon loading leaving an orphaned plist behind.
• Improved handling of LaunchDaemon creation and loading failures.

Deferral Handling

• Deferrals now ensure that the LaunchDaemon is successfully created and loaded before the workflow exits.
• The LaunchDaemon is preserved when an update fails so the update workflow can run again.
• LaunchDaemon and deferral information are removed only after a successful update workflow or when no updates remain.
• Improved cleanup logic to prevent premature removal of the LaunchDaemon.

User Interface

Previously, the first Patch Helper window only displayed update information as text.

The first window now dynamically displays the applications that are scheduled for update as a compact application table/list, including:

• Application name
• Application icon
• Only applications relevant to the current update run

This provides the user with a clear overview of which applications will be updated before starting the installation.

Full Changelog: 1.0.0...1.0.2

1.0.0

Please carefully review the following changes before deploying this version of the script in Jamf Pro:

📌 Configuration Management Update

Script Management via Configuration Profile:The script is now managed through a configuration profile.

Pre-filled JSON:

Use PatchHelper_Settings_with_pre-filled_text.json to leverage pre-filled text entries.

Select desired text values from dropdown menus; edits can be made as necessary.

Manual JSON:

Alternatively, use PatchHelper_Settings.json if you prefer to set all text entries manually.

🔑 API Token Management

API Tokens via API Roles and Clients:API tokens must now be created using Jamf Pro’s "API Roles and Clients" feature.

Dedicated Jamf Pro user accounts for API access are no longer required.

🎨 Icons and Validation Checks

Centralized Icons:

Icons and validation checks are no longer defined within the script.

These are now provided via the profile file named icon_service.json.

Improved Reusability:

Centralizing icons simplifies updates and allows reuse across multiple scripts.

0.9.2: Update Patch_Helper.sh

Changes:

• New Variable:
  By adding the new variable $BundleID, the script now checks whether the affected application is running.

  • If the application is not running, it will be immediately executed via:

    /usr/local/bin/jamf policy -id "${PolicyID}" -forceNoRecon

  • If the application is running or $BundleID is empty, it will be added to the JSON and the user will be notified.

• Background Execution:
  If all applications that need patching are not running, all associated policies run in the background. In this case, no JSON file is created, and the user receives no notification.

  • If the LaunchDaemon was previously loaded for this process, it will be stopped and removed upon completion.

• Notifications:
  The user will only receive a notification if a patchable application requires user interaction.

Log Entries (example):

2025-01-10 08:35:39 - CHECK-FOR-UPDATES FUNCTION: The total number of updates is: 2
2025-01-10 08:35:39 - CHECK-FOR-UPDATES FUNCTION: Read the values for the LaunchDaemon.
2025-01-10 08:35:39 - CHECK-FOR-UPDATES FUNCTION: The update is carried out every hour.
2025-01-10 08:35:39 - BACKGROUND-UPDATER: The application: Firefox is not executed. The policy with the trigger: 279 is now executed.
2025-01-10 08:35:45 - BACKGROUND-CHECK: Remaining updates that could not be updated in the background: 1
2025-01-10 08:35:45 - BACKGROUND-CHECK: The following number of applications could be updated in the background: 1
2025-01-10 08:35:45 - BACKGROUND-CHECK: The following applications have been updated: Firefox
2025-01-10 08:35:45 - BACKGROUND-CHECK: The following applications could not be updated in the background: Microsoft Word

• The number of applications that have been updated in the background and their names are recorded in the log.

API Permissions:

• The “Read Policies” API permission is no longer required.
• The XML obtained from “Read Computers” is evaluated and written to a plist file. The individual IDs and names are then read from this plist.

0.9.1

Counter is changed as $Update_Count so that only the number of updates is displayed and no longer the number of all steps (incl. the update inventory)

Adaptation of the text output for the time interval

Patch-Helper 0.8

Update Patch_Helper.sh