Is there a workaround for the assistive access issue yet?

On Yosemite.
Got a bunch of scripts that I need to run from the script menu, various types of content in them.
I already realized that if I update a script file, it will need to be granted assistive access again. That’s annoying, but logical. The downside is that it doesn’t really work. Some of my scripts work just fine, but some always give the same error message. In Script Editor, everything runs fine. The more I dig into search engines on this problem, the more frustrating it seems because so much of the talk is around Mavericks or iOS related stuff, and every guide I find shows the Privacy tab in System Preferences, where you’re supposed to add the applications you want into the list. But in practice, it doesn’t matter whether I try to drag and drop my scripts into the list, or add them via the plus sign button below it, at the most I’m able to add maybe up to one script to the list, and then nothing happens if I try to add more. They just won’t appear.
The error message I get on run is:

Why is it referring to “Untitled” anyway? The files do have proper names.
On the accessibility list, I have at least the following items allowed: SystemUIServer, System Events, Script Editor, CoreServicesUIAgent, Automator. Something crucial missing there? Although as I said, trying to add new apps to the list doesn’t appear to work.

AppleScript: 176
Operating System: Mac OS X (10.10)

-1- If your scripts are saved as applications you must add them to the list displayed in the System Preference.

-2- I guess that you saved them as “Untitled.app” then renamed the file to fit your needs.
Doing that doesn’t change the contents of the embedded plist which contain
the Bundle identifier : com.apple.ScriptEditor.id.Untitled
and
the Bundle name : Untitled.

-3- I have no info about a possible limit upon the count of authorized applications but I would be surprised if it’s less than 256.

-4- I have some authorized applications which are triggered by symlinks whose name is slightly different than the real app. It’s the real app’s name which appear in the pane.

Yvan KOENIG running Sierra 10.12.0 in French (VALLAURIS, France) mercredi 12 octobre 2016 12:29:07

Please read my full message; In System Preferences > Security And Privacy > Privacy > Accessibility, if I try to add new apps to the list, they don’t appear into it. I’ve tried dragging and dropping, and, adding by clicking the “+” plus button below the list. The additions don’t come up. Is there a limit to how many items you can have in that list? I tried to remove some apps from it but it didn’t “free up space” and I still can’t seem to add things.
Sometimes I even get “Script Editor is not allowed assistive access”, but when I go to System Preferences, Script Editor is already in the list and it’s been checked. If it wasn’t, my scripts wouldn’t even run from Script Editor, but they do run from there just fine.

I guess that you saved them as "Untitled.app" then renamed the file to fit your needs.

I have this specific bunch of 36 scripts that have “similar but different” content, and all of them give the same error message “Untitled is not allowed assistive access.”. Because I was making a whole series of scripts, knowing it, I would never consider saving any of them to my hard disk with the name “Untitled” because it would’ve made managing of that project very difficult. I have renamed them in Finder after the first version and made many revisions, but their names as files on the disk have never been “Untitled”. Not to mention, they all can’t have been called “Untitled” simultaneously. “Untitled” is what a new Script Editor document is called by default before you save it as a file.

On renaming,

Doing that doesn't change the contents of the embedded plist which contain 
the Bundle identifier : com.apple.ScriptEditor.id.Untitled
and
the Bundle name : Untitled.

Oh I didn’t know about that naming conflict. Navigating to a .plist and opening it in TextEdit, Untitled is found there as you mention. I’ve never known about this because my other scripts haven’t faced the same error. (Not too familiar with plists) “ can I just edit the “Untitled” parts of the file to match the physical file name, is it safe?
I’m pretty sure that I won’t be renaming the actual files any more, but to make my scripts easier to identify in the script menu that sits in the top menu bar, I have a habit of storing actual files elsewhere, and making shortcuts of them into the script menu folder. My actual files can have messy names, but for the shortcuts in the menu bar, I may have shorter names and I usually add an emoji or two to the beginning of the name to make it easier to distinguish what the theme of each script might be. But a shortcut can safely be renamed, right? I would never type emoji characters to an original .app file name!

By the way, the computer that I originally created these scripts with had a sudden hard drive failure due to old age and I had to clone the OS to my new computer. That typically breaks functionality of some proper applications in the Applications folder, and I had to update all Finder file paths in my scripts that contain file paths referrals. Can this break Applescript .app files?

#1 It would help to unlock the lock protecting the pane. But maybe the added items are refused because their embedded name duplicate an already include item.

#2 I wrote about the undefined feature because I already faced it.
The best scheme would be :
open a script
cmd + shift + s to duplicate it
compile to be sure that everything is OK
save with the wanted name.

Yvan KOENIG running Sierra 10.12.0 in French (VALLAURIS, France) jeudi 13 octobre 2016 17:21:53

Obviously, I do start by clicking the lock and typing in my password, otherwise the list is greyed out and untouchable.
There are no items called “Untitled” or [the name of the applet that I’m trying to add] in the list.

To make the .plist business a bit less tedious albeit a bit more time consuming “ to learn something new and to not have to remake my aliases too “ I just wrote a script that corrects the name inconsistencies inside the .plist file of Applescript app. I’ll run my 36 scripts through it and report how it goes. Will then take a while to enable them in System Preferences one by one.

36 .app scripts.
Ran my plist script on them to correct the enclosed name data to match the file name. (Every file has the same pattern which is a word, space, and one number. In the plist, the space is replaced with a hyphen.)
Almost all of the scripts now prompt with the error message, but then offer System Preferences. I enter my password and enable the script that has automatically appeared to the list and is just waiting for approval. SO much clicking and typing the same thing over and over again, but a majority of them works now.

But it wasn’t so sweet for all:
Example 1: Error for not having access, but directs to System Preferences for granting access. However, this item isn’t found on the list so there’s nothing I could check. I run my .plist name corrector script on it again and suddenly the script starts working. However, it still isn’t visible anywhere on the list in System Preferences. I later run the script again, and it doesn’t work, gives an error, isn’t on the list.
Example 2: Error for not having access. The prompt to either guide the user to System Preferences or deny access doesn’t come up. Re-running the .plist corrector script multiple times doesn’t fix the problem. Opening these scripts and choosing “Export.” to recreate them, then deleting the old script files and emptying the trash doesn’t fix the problem either. They won’t show up on the list or ask for the user to enable access, the error message is all there is.
Examples 3, 4 and 5: Same as above, but later on they had appeared to the list on their own and I ticked the box to enable them. But the next time I opened System Preferences, they were missing from the list again, and the situation is back to what it was with Example 2: Not working.
Example 6: Same as Example 2, but exporting as a new file fixed the problem and the script ran successfully without even asking to enable assistive access. This item alphabetically sits at the top of the list. If I run the script, I get the error message and no suggestion to allow access. If I allow it manually because the item is in the list already, it doesn’t stick and reverts back to unchecked when I leave System Preferences.
Example 7: Same errors as for most. Later on it had appeared to the list on its own and for a while, acccess was ok. Running it again later, it gives the error message so its status is also back to the same as the ones above. It appears to be on the list and it’s checked, but doesn’t seem to matter.
Example 8: Often on the first run gives “File some object wasn’t found. iTunes got an error (-43).” When I run it again, it runs fine. Content-wise a similar structure with the rest of the scripts so I don’t understand why this one would get an error, and not even constantly.

But with the assistive access… Seriously, what’s the logic here? :frowning: Seems completely random to me at this point.

By the way: If I mouse over the plus and minus signs in the Accessibility tab underneath the list of apps that are allowed access, the hover captions are “Add a Bluetooth braille display” and “Remove the Bluetooth braille display”. What??? :lol:

If I described a “better scheme” it was not for the fun.
I was quite sure that simply editing the plist file wasn’t the correct answer.
Did you edited the two properties using “untitled” ?

Yvan KOENIG running Sierra 10.12.0 in French (VALLAURIS, France) vendredi 14 octobre 2016 11:17:44

Yes, I made name changes in two places inside the plist file. Now if I navigate into the resources inside the scripts that still aren’t working, I don’t see anything wrong with their plists, the names match. There must be something else that prevents those files from gaining access and making it to the list so I could even allow access for them.

Here’s the .app .plist name matcher script if someone finds it useful. Running this did work for the majority of those scripts.

---This script makes sure that the file name identifiers in the .plist file inside of an Applescript .app match the app file name that you see in Finder. 
---To use this script, first select the Applescript .app file in Finder. I mapped a keyboard shortcut to then run this script. You can perform this routine on ONE file at a time.
---The .plist file can't contain spaces. But if the .app name does, it's okay, because this script handles them appropriately by replacing any possible spaces with hyphens before modifying the .plist.
---Test this script first by saving a test Applescript .app file somewhere. Right-click the app and select "Show Package Contents". Navigate on until you find a file called "Info.plist". Drag it to Text Editor. See that values "CFBundleIdentifier" and "CFBundleName" contain the name of the script file that you have just saved. Now close the .plist file. In Finder, rename the Applescript .app. With the .app selected, run this script. Navigate to the .plist file again. The names should now match the new name.

-------------------------------------------------
# Get File Name, Strip off ".app"
-------------------------------------------------

tell application "Finder"
	set theItems to selection
	repeat with itemRef in theItems
		(get name of itemRef)
	end repeat
end tell
set NameLength to the number of characters of (get name of itemRef)
set ActualName to (NameLength - 4)
set ConvertedName to (characters 1 thru ActualName) of (get name of itemRef)

----Check if there's a need to convert spaces to slashes
set the NeedToSlash to ConvertedName as text
set the NeedToSlash to replace_chars(NeedToSlash, " ", "-")
on replace_chars(NeedToSlash, " ", "-")
	set AppleScript's text item delimiters to the " "
	set the item_list to every text item of NeedToSlash
	set AppleScript's text item delimiters to the "-"
	set NeedToSlash to the item_list as string
	set AppleScript's text item delimiters to ""
	return NeedToSlash
end replace_chars
set FileNameConversion to NeedToSlash

-------------------------------------------------
# Full path of selected items in Finder.
-------------------------------------------------
tell application "Finder"
	set FileToTrack to selection as alias list
end tell

if FileToTrack ≠ {} then
	repeat with i in FileToTrack
		set contents of i to POSIX path of (contents of i)
	end repeat
	set AppleScript's text item delimiters to linefeed
	set FileToTrack to FileToTrack as text
end if

-------------------------------------------------
# Construct plist file path
-------------------------------------------------
set ContentsPath to "Contents/Info.plist" as text
set plistFileAd to (FileToTrack & ContentsPath) as text

-------------------------------------------------
# Modify Plist "Name"
-------------------------------------------------
tell application "System Events"
	set plistFile to property list file plistFileAd
	tell plistFile
		set CFName to (get value of property list item "CFBundleName") as text
		set CFIdentifier to (get value of property list item "CFBundleIdentifier") as text
		set value of property list item "CFBundleName" to FileNameConversion
	end tell
end tell

-------------------------------------------------
# Modify Plist "Identifier"
-------------------------------------------------

set MainPath to "com.apple.ScriptEditor.id." as text
set NewIdentifier to (MainPath & FileNameConversion) as text
tell application "System Events"
	set plistFile to property list file plistFileAd
	tell plistFile
		set value of property list item "CFBundleIdentifier" to NewIdentifier
	end tell
end tell

I repeat that editing the plist file was probably not the correct scheme.
This is why I described carefully an other one.
You choose to edit the plist.
The system stores infos in so many areas that I’m not really surprised that you get bad results.

Try to apply what I describe to some scripts to see if with it you get a correct behavior.

Here is what I wrote :

The best scheme would be :
open a script
cmd + shift + s to duplicate it
compile to be sure that everything is OK
save with the wanted name.

Yvan KOENIG running Sierra 10.12.0 in French (VALLAURIS, France) vendredi 14 octobre 2016 16:38:30