User Profile

OK, I tried using automator actions to add the variable to the wflow file. I tried with "Get Specified Text" which I had hoped would pass the value to "Set Value of Variable". Automator said the value of the variable versions was "1.21" which was good. But, in fact the value was not stored anywhere near the variable in the xml file. Instead there is a mass of UUID and RTF data sprinkled in many places. Anyway, I tried your code but, it produced an error: Can't get value of {identifier:"com.apple.Automator.Variable.Storage", |name|:"Version", UUID:"844A34DE-EEA4-48B1-B56C-4941A4510522"}.) So, I'll try another day. Thanks. p.s., I've just found the "variables" pane in Automator Library. Maybe I'll try that. cheers.

what are you doing that risks corrupting the workflow declaration file? I'm not sure what might happen but, I am wary of "3" because the raw workflow file contains a lot of XML code I don't understand. Option "4" seems less risky as long as Automator doesn't delete the file. Also, in AppleScript, it's a bit quicker to get the entire contents of the file rather in "3" which would require code which parses the content looking for the version number. I've done test code for both and found "4" a little bit easier.

I found the answer which was simple: open the Service in Automator and choose "Other" in the application drop down box to add other applications. I now have the Service restricted to 5 web browsers.

Thanks again. A VM is a bit much for me at present as it will have to be installed on a patched Mac – I don't have a Mac which is supported by Catalina.Anyway, I did another "tccutil reset all", deleted FFmpeg (from /usr/local/bin), created a new user, logged into that user, started the applet and UnZip installed FFmpeg without error. There was no request for permission to access the Desktop folder. Perhaps running on a patched Mac is changing how Catalina handles this situation especially as SIP is disabled. But, the Automation and Accessibility permissions are fully enforced and it would be odd for just one kind of permission not to be enforced, surely.One user definitely did have the "Files and Folders" permission dialog, they clicked on OK, and UnZip still caused the "Operation not permitted" error. That might be due to the shell commands not being blocked by the permission request (despite what Apple engineers said at the WWDC). Also, I've found that Accessibliity permission requests do not halt the applet which continues on to report an error because it can't use GUI scripting.Without being able to trigger the error on my Macs, I'll just take a couple of pokes into the dark: first will be to broaden the existing Try block to trap all errors and second, to issue a chmod on the downloaded Zip files to make sure the user has all the file permissions they need before Unzip runs.UPDATE 13/3/20: Also, have decided to download the zip file to usr/local/bin. That avoids the question of Catalina file and folder permissions all together.Cheers.

Update: Using tccutil I have reset all permissions on a test laptop (tccutil reset all) and specifically the Desktop folder access (tccutil reset SystemPolicyDesktopFolder). But, re-installing my applet does not trigger any folder access permission requests or errors with UnZip.I'd rather not have to create a VM for this at present. Is there another way to set up a Catalina install so that I can see all permission requests ?Thanks.[Many thanks for all this. Yes, that seems highly likely to be the cause. At least one user did have the error on a clean install. When run for the first time, the applet does generate a collection of Automation and Accessibility permission requests. But, I don't remember seeing any permission request regarding the Desktop or any file/folder access. I shall go through the WWDC session you've linked. I generally use tccutil to clear out permissions but a VM is much more rigorous.Cheers.]

Thanks. I might be able to find a better way of handling the requirement e.g. a browser-specific script.Cheers.