On Ayon, I would like to know how to allow a producer to create a project, without allowing him to access technical parts of the Web App (because producers are non-technical people, they should not modify Anatomy templates, Applications, addons, plugins, etc…).
It seems Access level “User” forbids both, and Access level “Manager” allows both, so I’m stuck.
Hi @Yul and thanks for opening up this topic. We need more feedback here and are happy to iterate on the options.
What you are asking for is indeed not supported at the moment.
Access levels are designed to create a very strict differentiation on a system level. They are in place mostly for the high level server safety and stability. We’re expecting that these will loosely match to
Artist → User
Production and Supes → Manager
Developers, Sysops, Admins → Admin
User : Cannot access settings and manage other users. Manager: Can access settings and manage other users Admin can on top of that:
execute onboarding
create/manage bundles
install addons, create/update dependency packages and installers
create/change attributes
edit settings of system addons
connect to YnputConnect
spawn / manage services
restart the server
manage secrets
create admins
Access Groups, on the other hand are designed to be granular, configurable and we’ll be expanding on what they can actually affect in further releases. We are totally planning to add settings and anatomy permissions. The general infrastructure for it is already there, at least to make it possible to hide the full settings or even their parts from various users, but to finalize it we’ll need to go through a lot of testing and it is not planned for 1.0 release. It won’t be too long after the initial production release though. we have it high up on the radar.
This is great, forcing me to finally put a lot of this in writing in prep for final documentation, so thanks for digging :).
guest is for now a bit experimental, but the ultimate goal is allowing guest users to join your server, be able to access certain projects and see the work, but not see other users for privacy reasons. We haven’t fully explored where we can take that, but it will slowly evolve to a type of account you could give to freelancers, directors, clients and so on.
I would like to add some more information about the kind of granularity we would need to have a “Producer” user.
A producer would be :
-Allowed to create projects.
-Allowed to set the Access Group of a user for a project (so that the user can see the project).
-Not allowed to access any technical parts of the Web App (because producers are non-technical people, they should not modify Anatomy templates, settings, etc…)
the way Ayon works is that we are working on features requested by clients under active support. This way we can ensure sustainable development. If you need some specific feature please consider becoming a client so we can prioritize your request.
I am wondering how other studios deal with this in Ayon.
I see 3 possibilities :
-All their producers are very technical, and they obey when they are asked to not touch the settings.
-All creations of projects are executed by their TDs.
-They have coded an external tool so that producers can create Ayon projects without any possibility for them to touch any Ayon settings (we are evaluating this solution).
As far as I know, we have addons for external production trackers e.g. ftrack and (flow)shotgrid. these addons may help for the purpose you have discussed in the post.
About the current status of user access levels and permissions: They are developed to serve particular production cases which are only limited to the studios’s team including external collaborators (guest user).
About your question: I was able to understand it in two ways:
Are there any workarounds or set settings in some specific way to achieve the producer role ? (IDK)
Could I make a feature request to add the producer role ? (you need to be a client)
Asking for best practices and sharing expertise about how to share the work with producers or a studio client worth another dedicated post on forums.
Also, I’d like to thank you for initiating a discussion that help community exchange experience.
No need to make a feature request, Milan said it already exists, in his message last october (it’s the second post on this thread). Here is a quote of Milan :
Access Groups , on the other hand are designed to be granular, configurable and we’ll be expanding on what they can actually affect in further releases. We are totally planning to add settings and anatomy permissions. The general infrastructure for it is already there, at least to make it possible to hide the full settings or even their parts from various users, but to finalize it we’ll need to go through a lot of testing and it is not planned for 1.0 release. It won’t be too long after the initial production release though. we have it high up on the radar.
In the meantime, If I code something on my side as a workaround, I will share the code here, in case it helps someone else.