Over the past few months I have been doing some administrative tidying and organization of our Shotgun Instance, clarifying field use, names and descriptions.
I have encountered a few things which are frustrating.
1. Entity “Visibility” by Role
In the Project > Tracking Settings menu: It is possible to set an Entity type to “hidden” for the Project. - This is a great option!
It will hide all web-UI access points (pages / links) in order to navigate to that Entity from within the project, but will not archive / remove / prevent API access to the Entity.
My issue with this feature is that it does not have any interaction with Permission Roles.
I want to set certain Entities to be visible only to Administration Permission Roles, but not to be visible to the average User.
2. Entity Field “Visibility” by Role
In cleaning up some depreciated fields (such as the “Smart Cut” fields on “Shot” Entities) these are pre-defined fields which were identified as depreciated in the developer documentation.
“Smart Cut Fields should be considered deprecated. Shotgun v7.0, introduced a new version of cut support.” - docs
The fields cannot be “deleted” / “archived” from the field list. - This doesn’t bother me, so long as I can effectively hide the fields to most permission roles.
This is possible, and I have made use of this.
However; I have discovered through trial and error that some Entity fields require all User Permission Role “See” (visibility) to be enabled in order to support integrated applications.
Example: RV Screening Room application requires:
Version.sg_movie_has_slate/Version.sg_frames_have_slate
These fields cannot be visually hidden in the Web UI without effectively disabling User login API access to query these fields, even though our studio has chosen not to make use of Version slate frames.
I would like an option to visually hide select Entity Fields from the Web UI for Permission Roles which have no need to see them, without losing API / code / application access. - This would help craft and streamline the user experience in the Web UI interface.
3. Shot Cut Fields
There are “System Fields” such as Shot.sg_cut_duration which are number fields.
This field has no system-defined relationship with the sg_cut_in or sg_cut_out fields.
Lacking a relationship means that a User would have to set Cut In / Cut Out and Cut Duration separately, in which case, there is a certainty of human error.
Admins cannot send this field to trash, and I’m reluctant to remove “See” (visibility) permission on this field for all roles due to the potential of this field being requires by other applications. (see above #2)
We have been employing a Shotgun Event Daemon to keep synchronicity between these three fields which is, in my opinion, an unnecessary process. - If fields such as these were initially set as calculated fields, then we wouldn’t have to manage them this way.
The only recourse I have at this point for a field such as this is to mangle the field display name, then create our own calculated field to represent Cut Duration - Frames ( {sg_cut_out} - {sg_cut_in} )
It is my belief that Entities, and their Fields can exist, have value, and be accessed through API access by ApiUser Entities as well as HumanUser entities without display visibility in the Web UI. (Based on a Permission Role setting )
Cheers,
David