munki and https://github.com/MagerValp/LoginLog LoginLog are doing it.

https://code.google.com/p/munki/source/browse/code/Managed%20Software%20Update/MSUStatusWindowController.py#136
https://github.com/MagerValp/LoginLog/blob/master/LoginLog/LLLogWindowController.py#L61

The window-displaying code in the application must explicitly do the right thing at the loginwindow in order to become visible.

I recall reading some of the threads on the munki Google discussion board about what needed to be done to get their apps working over the login window when Mavericks came out. I ran across them when searching for a way to get cocoaDialog to do the same.
So although its certainly possible based on the code examples above from Greg, it seems only a code rework of cocoaDialog will make it happen, at least in any reliable way. Which goes back to my concern over relying on it for this. The code hasn't been touched in 2+ years now, and was last tested fully on 10.6.
Not being a developer myself I would have no clue on how to integrate the python code into cocoaDialog. It almost makes me want to dive in and learn some development so I can actually help make improvements to it and keep this thing alive a bit longer. If my other personal commitments weren't what they are, I would seriously do that.

One of the developers for cocoaDialog (Mark Carver) is actually responsive to questions posted on the github page. You may want to post a question about it there. When I asked something about an issue I was seeing he actually responded in a matter of minutes. Though no work is being done on it anymore, they are paying attention to questions on the product. Worth a shot to see if they have any input.

Thanks @mm2270.

I've tried to re-compile (to code sign & sandbox) it on 10.9, but there is a lot of deprecated Objective-C code that needs to be replaced & I have no idea what to replace it with.

@jwojda - Patchoo follows a couple of rules to minimise recons. Casper OOTB bugs me since most times you install something, you've have to run a recon on every policy to make sure your smart groups are up to date. Lots of installs, lots of recons (and too much time)

The rules are:

Cache Pkg... User prompted? Defer ---> Recon ---> Exit Install Install req restart? No --- > Recon ----> Exit Flag for Recon Restart patchoo Startup ---> Recon --- Exit

All of these workflows means we can minimise recons and ensure computers land in the correct smart groups. If there are new changes to pkg cache, and users just dismiss a prompt, we skip a recon.

The reason we recon on startup is in case of an Apple update that requires a restart. It is not a good idea to recon after we install a point update and haven't restarted yet.

StartupPolicy is overkill, but I figure it might do something else later down the line.

As for limiting your 10.9 clients whilst we resolve the cocoadialog at logout issue. Setup your core policies like in docs
https://github.com/patchoo/patchoo/blob/master/docs/setup_core_policies.md

and use the smart group patchooAllCleints to limit
https://github.com/patchoo/patchoo/blob/master/docs/setup_core_smart_groups.md

That way the core patchoo trigger won't fire the update chain, and the logout and every120 won't fire reminders on these Macs.

Thanks @gregneagle ! This is awesome info.

Perhaps we need to compile on 10.6 on an older version of Xcode. This is getting over my head. There is a newer fork here, and perhaps we need to make some changes within the appcontroller around here... https://github.com/cooljeanius/cocoadialog/blob/master/Source/AppController.m#L217

I've committed a workaround for this problem to the dev branch. Please test it out if you can.
https://github.com/patchoo/patchoo/tree/dev

Using a "fauxLogout" - quit all apps, unload finder and dock, then perform installations. This means cocoaDialog can run on 10.9/10.10 as it's running in a user session still ... (also updated catalogURL handling for patchoo.sh and asucatalogst.sh).

In your "fauxLogout" mode, what happens if your code (or JAMF's) crashes? If your code isn't running any longer to reload the Finder or Dock or do a "real" logout or restart, how does the user get a working machine back? Hard power cycle?

I don't know that it was meant to be a full on fix so much as a stop-gap to get things functional. But you do bring up a valid point.

Greg does make a valid point. I know its meant as a workaround, but it seems a little risky to me. Its only my opinion, but it might be better to leave out that functionality, or code it so it skips it for 10.9+ until a more solid fix can be worked in.
(That said, it is in the dev branch, so its not like its being promoted as "the way" forward)

And as a sort of counter argument, regular logouts/reboots can also hang on occasion, so there's always a risk of a system getting "stuck" during updates like this and requiring a hard power cycle.

I agree entirely. It's urgly... I don't have a better solution to solving it immediately since it's reliance on cocoaDialog.

It certainly could fire a helper process that handles the unload, waits for install, then reload and subsequent logout. Shouldn't be much extra work.

Thoughts?

I was actually giving this some thought and experimentation this afternoon. @loceee][/url - shoot me an email offline at mm2270 at me dot com. I put something together that you may be able to use which, while still far from perfect, doesn't involve unloading the Dock and/or Finder, yet removes the ability for the logged in user to interact with anything while the installs are taking place and cocoaDialog is up on screen. I would guess this is pretty much the end goal, right? I can explain what I have together further and send you the code to see what you think.

We've cooked up another method.. Using ARD LockScreen (thanks @mm2270 !) ..

... but again should anything fall over, it leaves the Mac in a borked state.

Hmmm, to address that concern really the only thing I've got is spawning a watch process that ensures a logout once that installprocess completes (successfully or otherwise).

About to commit to dev... fauxLogout is spawned, waits for install process to finish, then it reloads finder and dock and logs out.

If we end up with something going wrong during installation, this should mean we get back to normal and log the use out to address that concern.

Testing it more... but this workaround solves the issue on 10.9/10.10

In all honesty there is major gaps around error handling all thoughout patchoo, but I will focus on that once I've got functionality nailed.

0.9931 incorporates this slightly ugly but functional workaround! thanks @mm2270 !

We now have 10.9 (& 10.10) functionality restored. http://www.rehrehreh.com/files/patchoo-v9931.html

@loceee Ever since updating to 0.9931 I've been seeing this message during zzz-patchooLogout with our 10.9.3 Macs.

Script result: patchoo 0.9931 --logout - Thu Jun 26 18:05:28 /Library/Application Support/JAMF/tmp/0patchoo.sh: line 1065: displayatlogout: command not found patchoo: jamf is running a recon...

Any thoughts?

Tracked it here ... https://github.com/patchoo/patchoo/issues/30, investigating.

and should be fixed on latest commit.

Sorry if this is a really stupid question, but will patchoo be able to work with dmg's?

Sorry if this is a really stupid question, but will patchoo be able to work with dmg's?

@dwest Patchoo works great with dmg's from my experience.