UXP: Access to read/write status in productions

Hey Bruce! Thanks for responding. I’ve found that because Productions projects open in read-write by default, it that creates a real workflow risk on shared projects. In practice, we usually only want an editor to have read-write access in their own edit project, while shared media projects stay protected and are only opened in read-write by an assistant editor. It is far too easy for an editor to accidentally open a shared media project in read-write, make an unintended change, and disrupt the edit.

To work around that, we use a dummy .prlock file whose username is set to “Locked,” which effectively forces the project to stay unavailable for write access unless someone very intentionally unlocks it. The problem is that this workaround is manual and clumsy. When the AE needs to work in one of those projects, they have to reveal the file in Finder, rename the dummy .prlock switch the project to read-write, make their changes, save, switch back to read-only, and then restore the dummy lock file’s name. 

I built a small ExtendScript tool that streamlines this by checking the lock state. If the project is locked by the dummy “Locked” user, it temporarily renames that lock file and sets the project to read-write. If the current user already has the project in read-write, it switches the project back to read-only and restores the dummy lock if it exist, and if it doesn’t it creates a new one. If the lock belongs to anyone other than “Locked,” it does nothing, because that means a real user is actively using the project in read-write. 

Aside from all that, I like to keep projects locked as much as possible unless they need to be in read-write, and in a lot of my old extendscripts, I have this toggle lock built in so that when I run something, it will automatically unlock it, do what it needs to do, and re-lock the project. Even if you’re not using the hacky .prlock workaround, it’s handy to be able to do that.