I even grep’d (as root) my entire boot volume looking for my app bundle ID and did not find anything relevant. So wherever Apple hid this, it’s well hidden (must be system-wide because a fresh account did not fix my problem).
Tho I never solved the mystery of why Christian’s MBS example project (with those 2 lines of code at the top) works, and one of my projects from 2 days ago works, but not even a fresh project with just those 2 lines works any more, I did finally find a workaround:
I save my applescript as a plain text file then invoke it from a shell using osascript. You get the security dlog once per new build, then the OS leaves you alone and just executes the scripts. Works under High Sierra, and wait for it, Mojave too. The only problem with the latter, is speed: ridiculously slow compared to HS even for the simplest scripts. I’m the sure the OS is doing something very important during those 10 seconds (every time). At least it’s usable.
BTW, tccutil reset All com.apple.Terminal gave an error, I tried tccutil reset All, and this did not solve anything.
a) You need to codesign your app.
b) You need to set com.apple.security.automation.apple-events in the entitlements for the hardened runtime to yes.
c) You will want to keep a built app around so that macOS doesn’t forget.
And it still doesn’t work for my test application. Insert curse word here. It must be a problem with codesign/entitlements.
Thx Beatrix. I will look into.
And just now, here is the most absurd OS msg I just got from my app, pertaining to this topic:
ImageTrak wants access to control ImageTrak. Allowing control will provide access to documents and data in ImageTrak, and to perform actions within that app.
Lemme just look up this error message : “No overview available”.
huh, lemme just look up the API : “No overview available”.
Lemme look at the header file : /* Mac OS X 10.8 and later, the target of the AppleEvent does not allow this sender to execute this event */
Which implies that Numbers is refusing your script… I didn’t even know that this is possible, but what is possible, is that the API and errormessage have changed, without the docs being updated, and so this is most likely a red herring.
'alf 'our later…
So… When it fails, open this URL x-apple.systempreferences:com.apple.preference.security?Privacy_Automation
Look for the name of your application, and look underneath it to see if Numbers is checked, if not select it and then things should work… He says…
Believe me it’s the first thing I looked at: my app was there, Numbers was under it, checked as it should be. And Christian’s two liner returned the error I posted when I pasted his 2 lines into a new test project…except when I ran his example project with the same 2 lines of code, which ran fine. go figure. Of course the bundle ID’s differ, so that must be the reason, but God help me if I can find where to fix or reset this (none of this happens under High Sierra, it just works).
Bottom line, for whoever needs this, the following works:
Save your script as a plain txt file then:
dim s as new Shell
dim cmd as string = "osascript shell/path/to/myScriptFile.txt anyOptionalParams myScriptMayNeed"
s.Execute(cmd)
This prompts you for permission the first time, then leaves you alone. Unlike High Sierra, under Mojave unfortunately this is unbelievably slow, taking 5-10 sec to execute the most trivial script, every time. Usable, but barely under Mojave
So it turns out, that while this is the recommend way of resetting the settings, on Mojave the ability to reset per application is actually broken and supposedly fixed with Catalina. I was able to use “tccutil reset AppleEvents” to blast them all.
Yes this makes a difference as does the debug app being code signing, while testing I was asked every single time, once I’d added an App Wrapper script to code sign the application during debuggin, I was only asked once. No codesign, back to being asked every single time.
There doesn’t appear to be a way to figure out what bundle identifiers are attached to what applications, in fact, this tccutil only appears to reset certain parameters. Security through obscurity, frustration and pain. Even figuring out what names to use to reset or for the showURL command isn’t easy. In the link I shared above, I had to experiment as it’s NOT actually listed!
I personally would recommend calling Apple Script via NSAppleScript as this way you’ll get an error dictionary, with message, code and such. So if it fails you’re able to report to the user why it failed and in the case of this security system, you can tell the user that they need to select the application in the list and call showURL to take them there.
I’ve seen some people recommend doing a check first and if it fails, you disable that function/option. I disagree with this, as users (I’m as guilty) sometimes don’t connect the dots, leaving them with features that don’t work and they don’t know why.
[quote=490699:@Peter Stys] it just works[/quote] Is no longer a motto throw about by Apple, instead they use things like “what happens on your iPhone stays on your iPhone”, Unless you use iCloud, and then it’s available to certain governments.
So I tried this, like this (the script is a simple one-liner telling Numbers to close all windows without save):
dim error as Dictionary
dim n as new NSAppleScriptMBS(scriptFile, error)
dim p as NSAppleEventDescriptorMBS = n.execute(Error)
and simply get:
“Not authorized to send Apple events to Numbers.”
And the whole process simply fails. And my app is clearly listed in system prefs > automation with Numbers properly checked under it. This is simply terribly broken and Apple doesn’t seem to give a crap about it.
Just a thought: are you sure there’s not another, old, copy of your app staying somewhere on your disk?
When I dealt with such problems in the past, I sometimes could solve the issue by making sure the app referred in System Preferences was the expected bundle (sometimes, an older version at some other place was targeted by the OS).
A very good point I hadn’t thought of. Admittedly, sometimes when I dbl-click a document the OS launches a copy of an app from my TM bkup (I saw this the other day), or a build from within my xojo project folder. So do I have to delete all 1000 bkup copies from my TM volume? Wouldn’t it be nice if one could add/delete an app from Privacy > Automation like from Accessibility, or at least see which copy the OS thinks it’s allowing? But no.
Ok, next I’d make sure there’s not another copy of the application on mounted volumes (and unmount most volumes you don’t need during the test).
If you find another copy laying around, you don’t have to get rid of it (either move it to another volume which you then unmount or compress the app and delete it (and empty the trash)). Either way, you make sure there’s not another app having the same bundle ID (com.yourcompany,product) on mounted disks.
At that point, I’m not sure a restart or rebuild of some MacOS component could help (I don’t recall having done that in my prior cases).
Once you’re sure there’s no copy of your app available on mounted volumes, you know the OS can’t deal with a wrong version.
When I tested for those issues, it was mostly a matter of making other versions unavailable to the OS and then tweaking with System Preferences (removing or unchecking references to the app in Privacy tab and re-adding or re-checking them). I’m not sure it worked every time, though, but definitively more than not.
And finally, restore the versions you may have moved to another volume or unarchive them.
Also, have you tried on a new OS install? You can simply partition your internal HD and install a new copy of the OS, or install the OS in a virtual machine. Then, first see whether the problem is there too. If it isn’t, you may customise it until you find a pattern for the issue.
All good suggestions Arnaud, thanks, tried this, stripped all other copies of my app, checked/unchecked, same error.
In fact, this Mojave install is only a few days old (but was Migration Assistant’ed from my High Sierra volume), and precipitated these issues immediately, hence my flaming at apple on this thread
I can run AppleScript to Excel and Numbers on Mojave without problems.
I set the plist and the entitlements that I copy in the app and use to hard sign the app.
I have the feeling everyone gets different results about that.
For me, AppleEvents usually work in the debugged and compiled apps, but it’s once they are code signed and notarised that AppleEvents stop working, albeit having set the NS thing in the plist and not using the app store/sandbox.
I guess everyone can tell his/her experiences, but it may not help anyone else if it’s so different for everyone The better way to address issues concerning security behaviours in 10.14/10.15 like these, IMO, is to track them/try them otherwise and hunt and test various ways until you found the pattern that corresponds to your own issue. Many others can say it works here (but not on other parts) or it doesn’t work for me (but your other problem isn’t appearing on my side) but I’m afraid that’s not reliable across configurations.
You are not alone in your feelings that Apple doesn’t care anymore. Almost everyone in my social media circles (even my peers) feel this way. But don’t worry, in a couple of weeks, we’ll get some new emoji “That you’re just going to love”, and everything will be forgiven.
Have we tried “tccutil reset AppleEvents” To blast all the AppleEvent settings? It will mean you have to approve every single app again. If you have System Preferences open when you do this, you know it worked because all the automation listings disappear.
I just want to add, that I’ve just worked with another Xojo developer regarding a very similar problem. Removing the code to test to see if the application has permission, and simply executing the Apple Script worked. Appears that it may be giving false negatives.
