Alfred 4 and Mojave Permission Issue with icalBuddy workflow [Fixed 4.0.2 b1085]

[mikedvzo]

Alfred 4.0.1

Mac OS Mojave 10.14.5

I am able to duplicate the issue on 2 separate machines running 10.14.5 and with Alfred 4 however, everything works fine with Alfred 3.  

 

I have a workflow that was written by a friend in Python for Alfred 3 to query the Exchange Calendar and list the meeting invites and allow you to select one and join a WebEx meeting.  It is broken since upgrading to Alfred 4.  I tried doing some basic testing since it relies on iCalBuddy and when I try a simple BASH script in Alfred to output the Calendar entries in Alfred it fails.  However, all other generic arguments to iCalBuddy seem to work.  

 

The 1st  command in BASH shell script in Alfred outputs the version but the second fails to output the calendar entries.   Both work fine in Terminal

 

/usr/local/bin/icalBuddy -V
/usr/local/bin/icalBuddy calendars 2> /dev/null

 

I looked at my console logs and I believe there is a permission issue since it is happening on 2 machines and it is an Alfred 4 with Mojave issue specifically.   I receive the following log message every time I run the script from Alfred 4 but I am never prompted to allow Reminder access from Alfred.  Neither Alfred 4 or Alfred 3 has permissions to Reminders in Privacy settings however Alfred 3 works fine.  I believe there is a bug or compatibility issue with how Mojave is handling things different than previous versions of Mac OS.  

 

default    12:09:16.911791 -0400    tccd    Prompting for access to kTCCServiceReminders from /Applications/Alfred 4.app/Contents/MacOS/Alfred on behalf of /usr/local/Cellar/ical-buddy/1.8.10/bin/icalBuddy

[zerowidth]

Alfred 4.0.1

 Mac OS Mojave 10.14.5

 

I have a similar (private) workflow that calls iCalBuddy from a ruby script in a workflow. I'm seeing the same behavior (iCalBuddy prints "No calendars." to STDERR), and I see the same logs in console. The full logs:

 

info    12:13:15.037678 -0600    icalbuddy    Sending 0/7 synchronous to com.apple.tccd: request (0x7ff3cdd04020): <dictionary: 0x7ff3cdd04020> { count = 5, transaction: 0, voucher = 0x0, contents =
    "service" => <string: 0x7ff3cdd035b0> { length = 19, contents = "kTCCServiceCalendar" }
    "function" => <string: 0x7ff3cdd03560> { length = 16, contents = "TCCAccessRequest" }
    "preflight" => <bool: 0x7fff96b56bb8>: true
    "target_token" => <null: 0x7fff96b57420>: null-object
    "background_session" => <bool: 0x7fff96b56bd8>: false
}
info    12:13:15.047203 -0600    icalbuddy    Received synchronous reply <dictionary: 0x7ff3cf900b10> { count = 1, transaction: 0, voucher = 0x0, contents =
    "preflight_unknown" => <bool: 0x7fff96b56bb8>: true
}
info    12:13:15.047393 -0600    icalbuddy    Sending 0/7 synchronous to com.apple.tccd: request (0x7ff3cdc33550): <dictionary: 0x7ff3cdc33550> { count = 5, transaction: 0, voucher = 0x0, contents =
    "service" => <string: 0x7ff3cdc33660> { length = 20, contents = "kTCCServiceReminders" }
    "function" => <string: 0x7ff3cdc33610> { length = 16, contents = "TCCAccessRequest" }
    "preflight" => <bool: 0x7fff96b56bb8>: true
    "target_token" => <null: 0x7fff96b57420>: null-object
    "background_session" => <bool: 0x7fff96b56bd8>: false
}
info    12:13:15.056322 -0600    icalbuddy    Received synchronous reply <dictionary: 0x7ff3cdc339d0> { count = 1, transaction: 0, voucher = 0x0, contents =
    "preflight_unknown" => <bool: 0x7fff96b56bb8>: true
}
info    12:13:15.056485 -0600    icalbuddy    Sending 0/7 asynchronous to com.apple.tccd: request (0x7ff3cfb006f0): <dictionary: 0x7ff3cfb006f0> { count = 5, transaction: 0, voucher = 0x0, contents =
    "service" => <string: 0x7ff3cfb00ca0> { length = 19, contents = "kTCCServiceCalendar" }
    "function" => <string: 0x7ff3cfb00ae0> { length = 16, contents = "TCCAccessRequest" }
    "preflight" => <bool: 0x7fff96b56bd8>: false
    "target_token" => <null: 0x7fff96b57420>: null-object
    "background_session" => <bool: 0x7fff96b56bd8>: false
}
info    12:13:15.075116 -0600    tccd    AttributionChain: RESP:{ID: com.runningwithcrayons.Alfred, PID[635], auid: 501, euid: 501, responsible path: '/Applications/Alfred 4.app/Contents/MacOS/Alfred', binary path: '/Applications/Alfred 4.app/Contents/MacOS/Alfred'}, REQ:{ID: ??, PID[64524], auid: 501, euid: 501, binary path: '/usr/local/Cellar/ical-buddy/1.8.10/bin/icalBuddy'}
default    12:13:15.075194 -0600    tccd    Prompting for access to kTCCServiceCalendar from /Applications/Alfred 4.app/Contents/MacOS/Alfred on behalf of /usr/local/Cellar/ical-buddy/1.8.10/bin/icalBuddy
info    12:13:15.076150 -0600    icalbuddy    Received asynchronous reply <dictionary: 0x7ff3cdc336c0> { count = 0, transaction: 0, voucher = 0x7ff3cdc33a20, contents =
}
info    12:13:15.077629 -0600    opendirectoryd    PID: 64524, Client: 'icalBuddy', exited with 0 session(s), 0 node(s) and 0 active request(s)

 

Edited June 4, 2019 by zerowidth
add os/alfred version

[Andrew]

Nothing has changed in this regard between Alfred 3 and Alfred 4, so I'm not sure why you'd be seeing a behavioural change, but I've added a note to look into making sure macOS is aware of Alfred wanting Calendar / Reminders access when necessary  

 

Cheers,

Andrew

[mikedvzo]

Thanks Andrew, as a note Alfred 4 has access to Calendars in Privacy but not Reminders and iCalbuddy queries both the Calendar and Reminders DB.  Also when deanishe was helping in the other post he noted that in 10.13 the test workflow I posted prompted Mac OS to grant permissions to Reminders when it called iCalbuddy.  

 

[Andrew]

Both Alfred 3 and Alfred 4 don't include the info.plist entries NSRemindersUsageDescription and NSCalendarsUsageDescription which are a prerequisite for macOS to be able to show the request dialog. This could be why you aren't seeing the reminders dialog when you see the log message:

default    12:09:16.911791 -0400    tccd    Prompting for access to kTCCServiceReminders from /Applications/Alfred 4.app/Contents/MacOS/Alfred on behalf of /usr/local/Cellar/ical-buddy/1.8.10/bin/icalBuddy

I'm going to add these in to 4.0.2 to see if that fixes the issue for you in the short term, and I've added a ticket to add buttons to Alfred's Permissions sheet to officially request access to these using EventKit.

 

Cheers,

Andrew

[Andrew]

@mikedvzo @zerowidth could you please update to the 4.0.2 pre-release and let me know if macOS now requests the relevant Reminders / Calendar access for Alfred when required?

[mikedvzo]

Problem Solved.  I was prompted to allow Alfred 4 access to Reminders and now everything works as expected.  

 

Thank you so much Andrew for the quick turn around.

 

Is there a way to donate to Alfred Mega Supporter License after the fact? I would like to do so. I can not imagine life without Alfred  

[Andrew]

@mikedvzo no probs, glad it's sorted!

 

At this point, we only offer the "legendary" tipped upgrade at the point of converting a pre v4 mega to a post v4 mega... but at some point, we'll look into v4 mega to v4 legendary too  

 

Cheers,

Andrew

[zerowidth]

⚡Fixed for me too! Thank you so much!

[luckman212]

I'm on 4.0.2 now - Does a section need to be added to this dialog to specifically request Calendar access?

 

[mikedvzo]

No Calendar and Reminder access will be prompted by Mac OS permissions when you run a work flow that needs access to Calendar or Reminders.  At that point you need to say yes and grant access to Alfred.  It will then show up here.  You can run this simple workflow and it will request access but you need to download and install iCalbuddy.

 

https://www.dropbox.com/s/pnx2xgm987nmii6/TEST.alfredworkflow?dl=0

 

 

[drgrib]

I'm using a Swift script I wrote myself, not icalBuddy. I would really prefer it be added here. Is there a simple workaround for now?

 

Alfred is not prompting for calendar permissions when the Swift script is denied access in a bash call.

 

On 6/7/2019 at 2:14 PM, luckman212 said:

I'm on 4.0.2 now - Does a section need to be added to this dialog to specifically request Calendar access?

 

 

Edited July 30, 2022 by drgrib

[drgrib]

I ended up downloading this workflow and getting it to ask for permissions:

https://github.com/rknightuk/alfred-workflows/tree/main/workflows/agenda

 

But I really think adding this to the permission page would be way more user friendly.

[drgrib]

For anyone else trying to get this working with your own Swift scripts and apps, adding this to the beginning should update your program to ask for permissions within Alfred:

 

import EventKit
import Foundation

// get calendar store
let store = EKEventStore()

// ask for permissions
store.requestAccess(to: .event) { (granted, error) in
    if let error = error {
       print(error)
       exit(0)
    }
    if !granted {
       exit(0)
    }
}