Munki 2: Cancelling a My Item that also has updates doesn't fully cancel the install

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Choose to install something that has at least one update_for in My Items.
2. Click Updates to perform a check run and let it find the additional update.
3. Either click Cancel back in the My Items view, or the X button in the 
Updates list to remove the original item chosen form the list.

What is the expected output? What do you see instead?

The original item is removed, but not the update. Closing and re-opening MSC 
still shows the pending update(s) the original item. If Update is clicked, both 
items are still installed.

It seems the original item is still properly kept out of the My Items list, 
however - so the only way to tell that this install happened is to browse to 
the original item and see the install state there. But this extra detail seems 
to just be a side effect of the original problem, which is that cancelling the 
install when there are additional updates found doesn't seem to fully cancel 
the queued install.

Another detail: if the desired install item has a 'requires' item and then this 
install is cancelled, the requires item also remains in the list with the 
update_for(s). However, a difference here is that if MSC is re-launched, the 
required item _is_ removed from the Updates list. If said item has both 
'requires' and 'update_for', the update_fors are the only things remaining in 
the list. But still, clicking "Update all" will install everything, both 
requires and update_for(s).

Munki versions:
core: 2.0.0.1963
admin: 2.0.0.1963
app: 4.0.1965
launchd: 2.0.0.1892

Original issue reported on code.google.com by t...@synthist.net on 27 Mar 2014 at 2:33

[GoogleCodeExporter]

This is part of a set of user interaction issues that come up when trying to 
emulate App Store-like behavior on top of the way Munki really operates 
behind-the-scenes.

In this case we need to differentiate between self-service items chosen for 
install or removal that have been processed by managedsoftwareupdate, and those 
that have not yet (and have only been modified in the GUI).

What would need to happen is this: user cancels the item (which has been 
processed by managedsoftwareupdate; that's why there are additional updates). 
MSC.app sees this and kicks off an update check session. This then has the 
jarring effect of replacing the list of pending and additional updates with the 
update status display. Once the update check is complete, the list of pending 
and available updates is updated. This could take a few seconds, or many 
minutes, especially if the admin has recently added a new managed_install or 
update that must be downloaded.

So I try not to kick off update check sessions until they are absolutely 
necessary; in this case, it does appear it's necessary.

Original comment by gregnea...@mac.com on 27 Mar 2014 at 3:21

[GoogleCodeExporter]

"If Update is clicked, both items are still installed."

Can you confirm this behavior? I have an optional item that requires another 
item. If I select the first item, after the update check, it shows both items. 
If I cancel the first item from the Pending Updates, then click "Update", a 
check is run first, and when it proceeds to install, neither item is installed.

Original comment by gregnea...@mac.com on 27 Mar 2014 at 5:09

[GoogleCodeExporter]

Having tried some more to reproduce what I originally described, I now see it's 
a narrower case than I thought. As you said, once "Update" is pressed and it 
does its check, neither item is installed, and for me this seems to go for 
items with either or both of 'requires' and 'update_for'.

I _can_ still reproduce it if I cancel the original item, and then close MSC. 
Upon re-opening, the update_for or required item is still in the list, only 
this time pressing Update starts installing all the items. I think in my 
original testing I was always closing/re-opening as an additional check, but it 
seems this is the actual issue. Hope that's clearer.

Original comment by t...@synthist.net on 27 Mar 2014 at 6:55

[GoogleCodeExporter]

This commit: https://code.google.com/p/munki/source/detail?r=41b5661d63dd 
should address this issue, though possibly in a too-heavy-weight way.

Original comment by gregnea...@mac.com on 1 Apr 2014 at 11:42

• Changed state: Fixed

[GoogleCodeExporter]

That does it. Thanks!

Original comment by t...@synthist.net on 3 Apr 2014 at 5:38