Feature Request: Correct queueing of app labels.

[aaplguru]

ATM, app-auto-patch seems to process app labels even when there's no need to run updates against them. I.E. when apps are already installed and up to date.

I would like (and expect) labels not to be queued for further processing if they're already installed and are at the latest version. This saves on unnecessary downloads, doesn't hinder (please close your app) or confuse end-user ("Hey, I thought I was up to date, why does it keep updating?").

For example in testing this: In the discovery phase, Installomator logs show "No new version to install"(label: 1password8) and "No newer version" (label: zoom) when both apps are installed and up to date. There's no need to display them in the second dialog screen.

Related: the wording in first and second screen could be clearer: First dialog screen: There are (x) applications that require updates: --> Examining (x) applications for installation or update: Second dialog screen: Updating the following apps ... --> Installing or updating the following apps ...

Or something the like (non native English speaker here).

Thanks!

[TechTrekkie]

Hi @aaplguru, Do you have an example log you could attach? Do you happen to have those apps added to either the "required" or "optional" parameter in Jamf? If so, that would explain why they are being included even if there is no new version. Required will force the install regardless if the app exists or is at the latest version Optional will force the install only if the app already exists, but regardless if its at the latest version

There also may be a few apps where version detection does not work so they'll be included. Most of those have fixes submitted to Installomator that correct it, but they are behind on PR's at the moment so we're just waiting for that scripting to be updated

[aaplguru]

Happy to provide: xyz.techitout.aap.log installomator.log

policy screenshot:

as stated in initial message: look in installomator logfile at line 25 ("No new version to install") for 1password and line 75 ("No newer version") for zoom.

And: per screenshot: the labels are listed in the optional parameter section.

I realise the version detection of Installomater is a bit clunky. I may have an idea but it's only a rough outline in my head right now. When it materializes, I'll post a FR with info on that subject.

[TechTrekkie]

Sorry for taking so long to get back to this... Since 1Password and Zoom were in the Optional labels, they'll get added to the queue even if no updates are available. The only check for the Optional category is whether the app is installed. If those apps weren't installed, they wouldn't get added to the queue. Let me know if that makes sense. We're looking into adding another label category that would do what you intend to do: ignore all labels and have a specific set of apps to check if an update is needed. We're working on 3.0 at the moment and should have some more updates on that hopefully soon

[aaplguru]

What you say is absolutely correct and as expected. That's not the issue here. I would expect that an app that is installed and is at the latests version is dequeued for processing, delisted or whatever when the script runs through the second step; namely the actual updating / installing part. IMHO that's just a waste of resources (bandwidth, user time, etc).

(just forget about the optional label thing mentioned here, it's not part of the problem)

[aaplguru]

I have been thinking about app detection and version detection a bit more.

Can't you incorporate an option to use Jamf Pro's patch management to get latest app versions? Something like: In Jamf Pro, add apps for patchmanagement, then 1) get all patch management app names and latest versions via Jamf api 2) assemble the required and optional categories 3) get the app names for those entries 4) check if installed locally and what version. If different from version found in list at point 1, use installomator to update. If not installed locally, install app.

But to stay on course, this I should rather put in another feature request.