7

I have the following AppleScript which toggles the scroll direction on the trackpad:

tell application "System Preferences"
    activate
    set current pane to pane "com.apple.preference.trackpad"
end tell

tell application "System Events"
    tell process "System Preferences"
        click radio button "Scroll & Zoom" of tab group 1 of window "Trackpad"
        click checkbox 1 of tab group 1 of window "Trackpad"
    end tell
end tell

tell application "System Preferences"
    quit
end tell

This script runs without issues when the "play" button in Automator is used to execute it. However, when I make a service that runs it and assigned a keyboard shortcut to the service, it fails to run via the keyboard shortcut.

Wrapping it in a try block with some error reporting yields the following:

Automator Runner is not allowed assistive access.

Error number-1728

enter image description here

I found Automator Runner.app and gave it assistive access using the instructions found here.

It now appears with a checked box in the list of applications with assistive access:

enter image description here

However, the issue persists. I continue to get the same message notifying me that Automator Runner is not allowed assistive access. when trying to run the script using the keyboard command of the service that runs the script.


Update

I just succeeded at implementing this alternative script to accomplish the same thing, but it also only works when Automator has focus and has the same issue when it does not:

tell application "System Preferences"
    reveal anchor "trackpadTab" of pane "com.apple.preference.trackpad"
end tell
tell application "System Events" to tell process "System Preferences"
    click checkbox 1 of tab group 1 of window 1
end tell
quit application "System Preferences"
  • 1728 is object not found, so maybe try simplifying until you identify the un-found object or access error. – Tetsujin Sep 7 '14 at 19:15
  • @Tetsujin Any guidance you can provide in how this is done would be much appreciated. – Keyslinger Sep 7 '14 at 20:18
  • to get some formatting, I'll have to do this as an 'answer' but it's still only 'troubleshooting' not a true solution... – Tetsujin Sep 7 '14 at 20:19
  • It appears another user ran into a similar issue here which is as-yet unresolved: apple.stackexchange.com/questions/93567/… – Keyslinger Sep 7 '14 at 23:13
  • I don't have Automator listed there in Privacy tab so I can't enable it :/// Any ideas? – davidhq May 23 '15 at 14:43
3

Important note regarding AppleScript actions in Automator workflows.
Hopefully this helps others who are looking for a fix.

Assistive Access

If your script uses things like tell application "System Events" to get UI data from app windows or send virtual keystrokes, etc, then it'll require "assistive access".

This may be called different things in different versions of Mac OS, but can generally be found in System Preferences > Security & Privacy > Privacy > Accessibility, under "Allow the apps below to control your computer".

Enabling assistive access for the Automator and Script Editor applications will allow your workflows and scripts to run from those tools, but not when saved as standalone apps. In theory, enabling access for any app should also let it talk to System Events.

Problem with AppleScripts run from Automator Actions

But as many have discovered, Automator often has issues creating apps that can be granted assistive access, when such apps contain AppleScript code. Not to mention the fact that services cannot be granted such permissions at all, since they aren't apps.

Workaround

However, you can build standalone AppleScript apps from the Script Editor application instead, and grant them assistive access without issue.

You can then run such apps as part of an Automator or shell workflow, like this:

AppleScript action in Automator

do shell script "osascript -e 'tell application \"My Granted App Name\" to activate'"

Shell Script
(can also be from an Automator action)

osascript -e 'tell application "My Granted App Name" to activate'

This also works for creating services in Automator. Just have your service run the permission-granted app, rather than trying to add permission-requiring code to the service itself.

Note that the tell app call doesn't require the ".app" extension, or even a path. If you have many apps with the same name, there should be a way to get the app by its bundle identifier, etc.

Other IDEs

I'm not sure if this is a problem specific to Automator, since I haven't tried calling fancy AppleScripts from apps built with tools other than that and Script Editor. Either way, the above should work for other IDEs/compilers/etc. as well.

Re-Building your App

In most cases, editing and re-building a granted app requires it be re-granted access. So it helps to test everything well in Automator/Script Editor before you build the standalone app, to save you the trouble. If your script is called by a larger project you routinely recompile, it's best to turn that script into its own app to grant it access once, and run the app from your larger project. At least until the larger project is finalized.

For apps used by multiple scripts, you could keep them in a consistent spot like a custom /Applications/Tools/Scripts folder. However, remember that any third-party code can launch apps and thus activate your potentially sensitive scripts. It's important to consider security implications when creating code that using assistive access.

When Re-Granting Doesn't Work

There are times when re-granting a rebuilt app doesn't "take". In such cases, renaming the app and re-adding it via System Preferences usually solves this. You should be able to re-name the app back to its original at a later time. This is a bug with how Assistive Access caches its list of apps, and the filename and/or path are involved somehow. If anyone knows how to clear this cache, please add a comment; it would be very helpful.

1

I suspect you may not really have a problem that could be "debugged".
Read this Guide from macosxautomation.com on how to have applets that don't permanently keep their "permission" to run, be accepted by Mac OS X.

Trick is to install a special ResourceRules-ignoring-Scripts.plist that you sign and register your app(let) into. (But read the WARNING on this web page!)

Reason is, some apps save information "into themselves" and therefore won't be identical/ recognized next time they run.

(But anyway: even if the Guide's advice does NOT help you, it still might be of interest to others ...)

1

I know this is an old question, but I was facing this issue just now and I managed to work around it, so I thought I would post an answer.

I'd read elsewhere that adding Automator Runner.app to the Privacy/Accessibility pane of System Preferences would not prevent the error, so I didn't try it, but what did work for me was pasting the entire workflow into a new "Application" workflow document. I saved that in the same location as the service and then I created a new "Service" workflow that only did 1 thing: run the new application I had just created.

I then added that application to the Privacy/Accessibility pane of System Preferences. Now, when I run the service, I do not get the permissions error.

  • What version of OS X/macOS are you running? – user3439894 Jul 31 '18 at 16:46
  • It's macOS 10.13.6. – hepcat72 Aug 1 '18 at 17:07
0

Not an answer, but...
To attempt to debug, I would deconstruct the script to its components, so roughly split to only

tell application "System Preferences"
activate
set current pane to pane "com.apple.preference.trackpad"
end tell

& test for any error

Then add

tell application "System Events"
    tell process "System Preferences"
         click radio button "Scroll & Zoom" of tab group 1 of window "Trackpad"
    end tell
end tell

check again

& onward until you find the fail point

One possibility would be to reverse sys events & sys prefs in your current running order, but that's just a shot in the dark.

Hopefully, someone with better applescript chops than I will provide a better solution.

  • Thanks so much for your continued input! The first tell block runs without causing the error. It emerges when the System Events and System Preferences block is added in. – Keyslinger Sep 7 '14 at 21:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .