Munki2 - Adding items in "other updates available" processes straight away

[GoogleCodeExporter]

What steps will reproduce the problem?
on a  system with multiple "other updates available" adding each additional 
item processes the download immediately after adding to pending updates, after 
which the view is refreshed. 

What is the expected output? What do you see instead?
would rather be able to add all pending updates and not have them process until 
after "update all" is clicked.

What version of the Munki tools/InstallOSpkg tools are you using? On what
version of OS X?
MSC 4.0.2107
OS X 10.9

Please provide any additional information below.

Not sure if this is intended behaviour or not. Either way, it's an interruption 
to workflow that doesn't really need to happen, especially if it's a largish 
download on a slowish link.

Original issue reported on code.google.com by bart.rea...@gmail.com on 20 Jun 2014 at 1:32

[GoogleCodeExporter]

This is not a defect. It's an enhancement request.

I don't love the current implementation, but for now it was the only way to 
keep everything in-sync. Adding an available update might actually trigger 
several other updates (due to requires and update_for dependencies)

Update all actually installs the updates.

Munki needs to check for dependencies and also to download the installers, so 
clicking "Update now" before those are available could lead (and in testing) 
lead to odd situations.

We'll revisit and improve this behavior if possible in the future. Not willing 
to let the perfect be the enemy of the good.

Original comment by gregnea...@mac.com on 20 Jun 2014 at 1:38

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

> Adding an available update might actually trigger several other updates (due 
to requires and update_for dependencies)

This makes sense. As long as the behaviour is expected it can be documented.

Original comment by bart.rea...@gmail.com on 20 Jun 2014 at 1:46

[GoogleCodeExporter]

I've wanted this as well. Perhaps you could delay the check by 5-10 seconds 
rather than have an immediate trigger.

Original comment by eriknico...@gmail.com on 1 Aug 2014 at 12:34

[GoogleCodeExporter]

That seems like it would have the effect of making the application seem 
unresponsive: you click something, and nothing happens for 5 or 10 seconds. How 
does the user know something will happen eventually? Still, something like this 
might be a possibility.

Original comment by gregnea...@mac.com on 1 Aug 2014 at 1:35