optionalFeature: respectDoNotDisturb

[erikng]

There might be a small group of admins who actually want to respect DND settings.

Unless this is trivial to implement, I won't be writing this feature, so I am marking this as help wanted

[redshirtdave]

I think this would be a very welcomed feature and I think this is good engineering personally. Be persistent in the messaging around updating, but clever programming to avoid pop ups at the wrong time. I know end users that respect this kind of approach to updates, but if it's a bad experience you've lost them.

Hope you get some help on this one!

[sphen13]

This would be fantastic - unfortunately my swift ability is fairly poor. maybe i can see how you can query if do not disturb is currently enabled or disabled?

[bartreardon]

This is as close as I got to getting it working. Works in macOS 11 but due to changes in the way DND is implemented in macOS 12 (essentially it's per app DND, not on or off) the DND state is not readable from the ncprefs plist. There may be a way to read state from icloud data as that's where focus settings seems to be stored but I'm yet to work that out.

import SystemConfiguration

func isDNDEnabled() -> Bool {
    // check for DND and return true if it is on
    // ** This function will not work under macOS 12 as at July 2021
    let consoleUser = SCDynamicStoreCopyConsoleUser(nil, nil , nil)
    let consoleUserHomeDir = FileManager.default.homeDirectory(forUser: consoleUser! as String)?.path ?? ""

    let ncprefsUrl = URL(
        fileURLWithPath: String("\(consoleUserHomeDir)/Library/Preferences/com.apple.ncprefs.plist")
    )

    do {
        let prefsList = try plistFromData(try Data(contentsOf: ncprefsUrl))
        let dndPrefsData = prefsList["dnd_prefs"] as! Data
        let dndPrefsList = try plistFromData(dndPrefsData)

        if let userPref = dndPrefsList["userPref"] as? [String:Any] {
            return userPref["enabled"] as! Bool
        }
    } catch {
        // prefs weren't readable. quit or do somethhing else here
        print("DND Prefs Not Available")
    }
    return false
}

[erikng]

Fun

[bartreardon]

I might have found a way to check focus mode under macOS 12 using the Intents framework and checking INFocusStatusCenter. https://developer.apple.com/documentation/sirikit/infocusstatus

requires adding the Communications Notifications entitlement and a config profile to pre-approve access to notification status. Will have a play with it over the weekend and see if I can't get something working.

I want to use this in my own app but as it's a CLI utility it appears I can't add the entitlement :(

[bartreardon]

Minor update to this - once Xcode supports the INFocusStatusCenter frameworks again (it was in xcode beta but taken out for the release) then adding DND should be trivial. There will be one method for macOS 11 and another for macOS 12+ but in testing it's been fairly reliable in determining focus/dnd state.

in terms of an implementation though, a question would be would you want it to honour DND by default or would you want it to continue the existing behaviour and make respecting DND an options to be enabled?

[dan-snelson]

Excellent find, @bartreardon.

IMHO, this feature should default to false (i.e., one would have to specifically enable DND features).

[bartreardon]

I made a proof of concept app that reports back DND status on macOS 11 and 12 https://github.com/bartreardon/infocus - waiting for the prod release of xcode 13 with these frameworks for macOS 12 included.

[erikng]

This should be optional and not default behavior. I don't believe in respecting DND Nudge/UMAD. UMAD takes it a step further and disables DND to ensure the DEP nag window shows up.

[jelockwood]

@erikng Has this feature now been incorporated? Having Nudge not trigger whilst apps like PowerPoint, Zoom, MS Teams, etc. are running would be hugely preferable. Otherwise I can see the company owner telling me to remove Nudge.

Note: If possible merely having such an app running would not cause Nudge to not trigger but only if a PowerPoint presentation is running or a video call is in progress. Since the macOS screensaver respects such behaviour clearly this is possible.

[bradtchapman]

@jelockwood @sphen13 @redshirtdave @erikng @dan-snelson @bartreardon

I'm combing the desert of issues for clues... and I would not recommend any option to respect Do-Not-Disturb for a couple of reasons:

1. Some people now have set up shortcuts to enable a "Focus" mode for work, which means that "Do Not Disturb" would be enabled in some form all the time. That would all but neuter Nudge.

2. You can already exempt Nudge from firing when certain apps are running (acceptableBundleIDs) e.g.: Zoom, WebEx, etc.

3. You can already exempt Nudge from firing when someone is presenting full screen, or when the camera is active, with the following keys: acceptableScreenSharingUsage or acceptableCameraUsage .

[erikng]

I have ran into an interesting set of issues supporting this.

The code was simple, but it requires an entitlement and that entitlement requires a provisioning profile. At some point, someone (unknown who atm) took com.github.macadmins.Nudge and I can no longer create a provisioning profile with this name.

There are two more potential paths about who could have this AppID

• Uber
• Clever Dev Ops owned by @natewalck

I'm hoping it's Uber because CDO's Developer ID expired and we would have to spend money just to potentially get a solution here.

So I'm re-opening https://github.com/macadmins/nudge/issues/453 and putting a warning out now: If I can't solve this, the only way to implement this code will be by changing the Bundle ID of Nudge.

[erikng]

I think for now I am going to close this. I tried just now with the io.macadmins.Nudge identifier and ran into even more problems here.

1. I need to register my mac with macadmins open source Apple ID. I think this creates a legal risk for myself, and macadmins org if I use my personal mac and even more legal risk if I use my work mac. This would mean I need to purchase a device to continue to work on Nudge and is personally a non-negotiable for me.
2. Even if I did purchase a mac, there are so many enterprise use cases that I have to continue to test that it would be a non-viable method to understand if I was breaking enterprise features
3. I don't know how this would impact GitHub CI/CD releases since you now have to register your device and these are ephemeral.

This feature just isn't work the headaches, legal liability and ramifications of this.

Blame Apple for not better supporting open source.