Fantastical is the calendar I use also, fwiw.
This is what a copied event from Fantastical has on the clipboard over here
May 26, 2019 at 7:00 PM - 7:30 PM Daily Task Planning This is a note
I use Fantastical, but I’d suggest that rather than try to support everyone’s favorite calendar that supporting .ics import might be more cost efficient? AFAIK, Calendar, BusyCal, Fantastical and any other calendar worth its salt export in the .ics format. (Not drag-out. Export.)
If you’re having trouble dragging events from your Calendar to Tinderbox 8.0.2, try this
- Quit Tinderbox
- Open System Preference
- Select Privacy and Security
- Go to the Privacy pane
- Choose Calendars
- Tinderbox 8 may already be checked. If it is, uncheck it.
- Now, recheck Tinderbox 8
This may help convince the system that you’ve granted permission
Tinderbox doesn’t show up in the list, and there doesn’t seem to be a method to add it. Frustrating.
If you move Tinderbox 8.0.2 to your application folder and run it, it should ask for permission either on launch or when you drag an event from Calendar.app to Tinderbox.
If that doesn’t happen, you may need to reset privacy permissions. Sigh
Having hit this, I guess the issue is the permissions are there to keep us users safe. So, if they do get into a wrong state, making it too easy for the user to fix it themselves nixes the security. It’s a shame Apple haven’t thought of a way to do some form of verified fix (perhaps via the app) as my experience across the many apps is that Apple have done a poor job of ensuring privacy setting requests don’t get lost behind other window or give warning/feedback that you have (unintentionally) not correctly completed the privacy request.
Perhaps OS 10.15 will get better at the underpinnings.
For the time being, I guess, we’ll have (following @mwra’s last post) to live with it.
Nonetheless, it’s surprising that after resetting the privacy permissions, apps like Fantastical, for instance, always (successfully) re-request the respective permission.
Do you think @eastgate that the maker of Fantastical, flexibits, could offer some help on this?
Privacy permissions in the macOS privacy database, are reset using
This is an extremely powerful command. It takes effect immediately and there is no undo and no way to restore.
A few months ago, to resolve a privacy permissions issue with another app (nothing to do with Tinderbox) I accidentally reset the entire privacy database. I spent the next two months carefully replying to macOS “do you want…” requests.
Be careful not to use this incorrectly.
tccutil(1) BSD General Commands Manual tccutil(1) NAME tccutil -- manage the privacy database SYNOPSIS tccutil command service [bundle_id] DESCRIPTION The tccutil command manages the privacy database, which stores decisions the user has made about whether apps may access personal data. One command is current supported: reset Reset all decisions for the specified service, causing apps to prompt again the next time they access the ser- vice. If a bundle identifier is specified, the service will be reset for that bundle only. EXAMPLES To reset all decisions about whether apps may access the address book: tccutil reset AddressBook tccutil reset All com.apple.Terminal Darwin April 3, 2012 Darwin
Thanks for the pointer on
tccutil. However, still no joy dragging a Calendar event into Tinderbox (StartDate
'never') after stumbling about in Terminal like this.
It would seem I need to do something differently. But what?
“Tinderbox 8” is not the bundle ID. I believe this is:
Resetting “Calendar” does not reset other app’s access to Calendar, it resets Calendar’s access to other apps.
@PaulWalters, thanks for that pointer to
tccutil - and the warning. As, my only need for Calendar files is for testing, I think I’ll watch from the sidelines for now. I see the OS designers intent here, of security/privacy, but I do thing it puts the poor app designer in a difficult place as they are the most likely person held to blame by we users. I hope @sumnerg gets things working - eventually!
No luck, but perhaps someone will come along and tell me what I’ve done wrong…
Meanwhile, the AppleScript upthread works here. A potential example, with more to come in the the future, of AppleScript actually doing something useful rather than just creating extra work.
You probably need to run this with admin privileges, or sudo.
There’s a good deal of discussion about an underlying Mojave bug that reports “Failed to reset database”. See https://agenda.community/t/can-t-integrate-with-calendar-app/4184/9 and https://bitsplitting.org/2018/07/11/reauthorizing-automation-in-mojave/ .
@sumnerg since there is an assumption that the issue you see is related to something in the privacy database, an interesting validation would be to create a new user account on your machine and see if dragging from Calendar to Tinderbox 8 causes a request to that user to grant permission. If not, then it might not be a privacy permissions issue that you’re seeing.
sudo and also tried setting up new user account. When I did I am not asked to grant permission when I drag an event from Calendar to Tinderbox. The way I’ve been testing “whether it works” is to drag an event from Calendar into Tinderbox and then check
StartDate in the note, which is always
never. I’ve been assuming that having a date in
StartDate is the expected result. Maybe I should be looking at something else?
on MacOS 10.14.5 (18F132)
Actually, this turns out not to be the case.
When you drag a calendar item to another program, Calendar puts several different things on the pasteboard. One is a textual representation of the item — that’s what TextEdit sees.
But there are various other bits of information. One, the com.apple.iCal.pasteboard.event, contains (among other things), the unique identifier that Calendar maintains to identify the event. We then used Apple’s EventKit framework to request fuller information about the event.
Starting with Mojave, the first time an application asks for an event, the system asks you for permission. This helps prevent miscreants from stealing your calendar surreptitiously. If you say “no”, subsequent attempts to get information fail forever. If you say “yes”. the system won’t ask again, either.
Starting with Tinderbox 8, we identify Tinderbox to the system to say, “we might ask you for calendar information, so please be ready to confirm.” That’s now (mostly) required, though in the Tinderbox 7.x era is was only required for applications in the Apple Store.
Now, two problems arise.
If you decline permission once, that’s remembered indefinitely and there’s no good way to tell your machine that you’ve changed your mind. To do that, you need to use tccutil from the command line.
What happens if the master file of permissions is corrupted on your machine? In that case, you can neither get permission nor can you reset permission. This is a rare bug, but I suspect that’s what has happened to @sumnerg. Nobody seems to know the solution to this.
There’s also the possibility, of course, that we’re asking for the event in the wrong way — a way that works most of the time but fails in some situations and @sumnerg happens to have that situation. It doesn’t see very likely, but of course we’ve seen some wild bugs before — bugs that only happen on Tuesdays, stuff like that.
Thanks, once again for a glimpse behind the curtain where things lack the solidity they have front of house.
This sounds like someone at 1 Infinite Loop forgot to ask “What’s the worst that could possibly happen…”. @sumnerg seems to have fallen into the Kafka-esque result of such careful (lack of) planning.
This reminds me of Bartosz Milewski writing about Beauvais cathedral, the late appearance of mathematical methods in engineering, and the remarkable amount of structure that the medieval builders were often (between catastrophic collapses) able to keep vertical, without being quite sure how.
(See under ‘Beauvais’ in https://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/)
IME any organisation of scale, anywhere…