search

robjschroeder / App-Auto-Patch

Auto patch management script via Dialog
https://techitout.xyz/app-auto-patch/
MIT License
109 stars 18 forks source link

Feature Request: depopulate labels from the plist when successfully installed #28

Open Apfelpom opened 9 months ago

Apfelpom commented 9 months ago

With the goal of inconveniencing stressed employees as little as possible with app updates, we consider running AppAutoPatch twice.

In the first run, we update all apps that are not open with the options interactiveMode="0" (completely silent), discover="true" and BLOCKING_PROCESS_ACTION="silent_fail". During the discover phase, the labels are written to the plist that Installomator runs.

The second pass is to update only the apps where Installomator aborted the installation because there would have been user interaction. This time, so that interactive patching can be started at the push of a button, we choose interactiveMode="1", discover="false", and BLOCKING_PROCESS_ACTION="prompt_user". But the plist still contains all labels, even the ones for which Installomator has applied the update.

Hence my suggestion to include an option that removes labels with "All done!" from the AppAutoPatch.plist. This way the second pass would only bother the user to install opened applications.

robjschroeder commented 8 months ago

Can you check out if the new deferrals and AAP-Activator script may help you out?

robjschroeder commented 7 months ago

@Apfelpom , with the latest version 2.0.3 there will be an additional check for the installed app version. For your workflow may I suggest to re-run discovery each time, you can set the interactiveMode to 1 so the user will only be presented with the apps that indeed need updates at the time of discovery. You can keep prompt_user as the blocking process since you can now pass in your own Installomator labels into a Jamf Pro Script parameter.

Apfelpom commented 5 months ago

The deferrals and the APP-Activator-script, as well as all additions since version 2 are great. Thank you all for your work! (and sorry to be late)

If, as you recommend, we do not perform discovery interactively and installation interactively, users will have to wait until the closed applications that do not require interaction are updated. Hence the idea of running AAP silently and a second time interactively when the user has really to take a decision and click a dialog.

Moreover we want the discovery phase to run as little as possible, as it takes up time and energy. During our first run of APP, all applications that are closed are updated without interaction. Open applications still need their update.

If we start AAP a second time without discovery and with interactiveMode 1, all already installed updates of closed applications are run through. This is fast, because Installomator determines the last version beforehand, but it takes more effort than necessary and on screen time.

Hence the desire to fully evaluate the results of the first run and obtain a list of applications that really need updating, which updates can be run interactively in a second run of AAP.

The https://github.com/robjschroeder/App-Auto-Patch/issues/48 issue shows that I'm not the only one who wants to run discovery and silent patching. I think it would also be an improvement for APP-Activator to know that after a silent run, the list of applications to be updated has been cleaned up, so that a new discovery or an interactive run is not necessary.

BTW: To speed up APP (significantly), I have been toying with the idea of reducing the list of Installomator labels to the actual list of our software. This could also be an option of APP to ignore Installomator labels of never installed software, provided APP has already run once.