I don't know how fine-grained the permissions framework is at the moment, but we've had a request for artists to be able to change the status of notes that *they* created (by which I think I mean created by any user from the "Artist" permissions group), whilst still being barred from updating the status of notes created by producers.
**Note: attachment added for Romey's comment below
Funny, I was just gearing up to post about this myself Andy.
I echo the need for artists to change certain statuses--at very least for entities they have created (more on that below).
I am also hoping for more granular permissions structure. Ideally I'd like the permissions schema described by Don (https://shotgunsoftware.zendesk.com/forums/32075/entries/21624) editable on two levels:
However, there is something else I'd encourage you guys to think about: not all statuses are equal. For example:
So there is an ever finer level of granularity here: certain statuses are off-limits to certain permission groups, even if they are permitted to edit the "status" field.
I can live without this latter request, but I'm hoping that more granular permissions are in the offing. For now I am probably going to make all of my staff "Managers" since the "Artist" group is pretty restrictive for my purposes.
Our current framework has the hooks to do these permissions (edit entities that you created & permission to only select specific options from a list). It's just the admin UI to make and mange your own permissions at this level that we're worried about. I have a half baked set of screens I'm still iterating on that I'll post soon for our discussion.
Has anyone seen a permission management UI that is done really well AND includes loads of options like we're discussing here? I'm hoping for simple but powerful, and I really want to avoid a mind numbing disaster that is crazy confusing.
Pliny, I'm curious about forking a user from a permission group (template). Would it be desirable to just duplicate a permission group and then tweak it? Or do you really want individuals with their own forked permissions? We'd have to make dang sure the UI was clear enough to make that apparent. I can imagine that getting pretty confusing.
totally agree with John re the need to allow some status values to be set but not others that are essentially review signoff indicators
fine for this to be handled at group level though
here artists would be expected to update status information on their assigned tasks/assets/shots etc but only directors should be able to mark them as final and only producers or coordinators should be able to mark them as client approved
Don, you may be correct that it would get very confusing. So if I understand you correctly, you'd rather keep permissions grouped-based and have admins create new groups for permission tweaks? This could get a little confusing too. For example, I use "group" for other purposes than just permissions. For example, I may create a query that shows me all open tasks assigned to members of the "Post Production" group. So if I create a group called "Post Production 2", that query breaks. If I assign a user to multiple groups, how are the permission sets merged?
is the simple answer to that, just to keep departmental groupings asnd permission groupings seperate - ie two seperate group types?
I know you guys have the hooks and that is great. But just like the preferences its important to expose those hooks into a UI that works. On that note I started to build one. I haven't had the time to build the back end that sends that data. At first glance the hooks seemed complicated and seemed like they needed to be integrated into the API rather than ssh commands. My first suggestions would be to build upon the API3 to include the commands necessary to set permissions so that we can actually build tools for shotgun in the same manner we are used to with the API.
Also it might be a good idea to think about a specific user such as admin that would have permission based contextual menus for the field pages. This way they could add and remove permissions from the UI per field without having to write some crazy QT UI that communicates directly to the Shotgun server via ssh commands that need to query every field in order to expose some user interface that may or may not cover the full gamete of permissions.
I have a screen grab of the UI we mocked up. The Zendesk used to allow us to upload images. It seems liek this option has been turned off. If you can turn the image upload option back on I can upload a sample UI.
-Romey
Hey Romey,
Zendesk doesn't allow uploading images in comments, only in the main post. This is a request we have open with them but for now you can email it to me and I'll post it on the original post if you like.
cheers,
kp
Don: "Has anyone seen a permission management UI that is done really well AND includes loads of options like we're discussing here?"
Me: nope, we want you to build it of course!
Seriously though, this is something I keep turning over in my head. I understand that it may be simpler to base your permissions on templates instead of having it per-user; however, some of the feature requests--notably the original post in this thread, and my immediate follow-up--would seem to require user-level granularity.
How much of that granularity gets exposed to the UI is another question. I for one certainly wouldn't mind a giant page with 1,000 checkboxes--assuming of course that this type of "meta" page was populated by initial permissions templates and tweaked only when necessary.
So, I would still see a layer of permissions based on a group template. And another layer based on project access. In addition, automatic permission tweaks such as what Andy suggests: Artist A creates a task; he might have additional permissions for this one task. But underneath it all I'd want all the knobs and buttons.
I know this is stuff I will need at some point. OK, I'll go think up a few real-world scenarios and get back.
I'd say forget the per-user permissions and just focus on adjusting permissions on groups. If you need one person to have a special set of permissions, make a group that includes just that person. Added advantage with that is if that person moves on to another role or leaves the company, the person who replaces them can just be added to the existing group instead of modifying all the perms on each user each time.
Maybe the existing Groups entity could have a toggle to either use default permissions based on the user's Perm group (admin, mgr or artist), or to have an overriding set of custom permissions. If a user was part of multiple groups with conflicting permissions, they get the superset - they can do everything either group is allowed to do.
Hey Don/KP
Can you guys update the docs on some of these new permissions hooks, like the one you mentioned about being able to restrict editing based on who created the entity? Are these the latest ones to look at?
https://wiki.shotgunsoftware.com/support/user_documentation/permissions
I have all sorts of wacky permissions rules that I get asked to put in place (and in all honesty, that I want too), so I'm curious to know what the new hotness hooks are, as I may want to put more into use here. A UI would be fabulous (I know Amanda would totally heart this), but in the meantime it's still worth it for us to keep editing them by hand...
Ryan.
my 2p:
allow admins to create new permissions group templates (with UI with checkboxes or whatever)
each user is assigned a group - overall groups control main permission setting
add a new tab to the user pages with a new sub-entity type called 'permissions' (only admins can access this by default)
now you can add specific permissions as needed to the new user group (eg almost like adding new tasks to an entity) if you need any specific permission to be different from the default type supplied by the template group - this way you only have to deal with whats different from your groups rather than redefining everything
those who are happy to use groups can never use this
I was actually thinking that maybe even the groups should work that way - but I guess you need at Least 2 default groups setup from the start - users and admins:
any new group is essentially passed on of these two as a base and then you can also just add exceptions to these
uses inherit their group permission exceptions but these are overidden by any local exception
these permission exceptions would work like tasks or note - ie add a new one, link to something or other then add a property that controls the relationship between the linked entity and the user - this would seem consistent with how shotgun works with other things? - you could even add a new option like add note or add task that would allow you to add a new exception to any entity...
Any update on this?
This would be extremely helpful for our pipeline too, specially the ability to let people assigned to a task change it to certain statuses, and combined with this another feature request (https://shotgunsoftware.zendesk.com/forums/31278/entries/25769) would be a dream come true. We have 3D projects that span from 3 days long to a couple of months (and just a few longer), and all of our staff is usually working on several projects, producers and directors sometimes on 6 projects at the same time. So, for everyone being sending notes to inform others about changes (and Managers updating statuses) working in so many projects is inefficient and can let to a dissaster or delays because human errors.
I insist on this because we don't have API access neither fancy ssh to set up our own tool to play with this permission hooks.
-Doc.
I've been in the permissions framework and am finding myself able to do MOST things I'd want to do and can see how within the framework some new permission rules would let me do all of it (a see_pages style rule would be great, but for it to work for what I'd want the query would have to be able to match on what project and folders a page is in), the biggest problem I run into other than not having a GUI is that each user only gets on permission group. As the system gets used more I expect to find myself having to create and maintain way to many permission groups because every time there is a special case where somebody wants a PA to help them edit some data that was restricted, I need to copy a role and extend the PA's permissions with just enough for them to do what they want. That is a maintenance issue and it annoys the person asking for the PA's help and the PA who can't help out like they'd want until I figure out the setup that gets them up and running. And once that role is created, I now have to make sure I update it with each change wanted to the permissions sets that the new set is based off of.
I would LOVE it if you guys could save me from that fate.
In terms of UIs I've seen that does this kind of thing well, I've only seen ones for filesystem based ACLs that I like, Eiciel is nice:
http://rofi.roger-ferrer.org/eiciel/?s=5
The problem here is that you aren't matching against something simple like a directory or file, you are matching against the results of a query that returns a set of matching objects. A separate interface to define those things (Something that lets me build up an entity that represents the results of 'entities of type CustomEntity02 where field type is 'Foo' and call that 'Foo_Widgets') and then an interface that lets me map user groups to permission on those things (Let members of ProdMgmt have see/create/delete/read/write permissions on that) would make my life MUCH easier. That way as people get added to the 'ProdMgmt' group, they get ProdMgmt rights. Your system of more specific rules overriding less specific rules should work well when it comes to merging rule sets, although I could see something like a priority on a permission rule that lets you override that to make more general overrides to specific access a little easier.
Whew, sorry for the long post. This is definitely something I think could use some attention.
As for the ability to be able to keep artists from marking status as final, that isn't something that fits into most of the frameworks I've seen talked about. The thing that I've seen that would let you enforce access like that is oracle's db triggers:
http://download.oracle.com/docs/cd/E11882_01/appdev.112/e10472/triggers.htm#LNPLS020
But that's a completely different beast.
I'd love to know how you guys are thinking about implementing this stuff. It would definitely be GREAT.
-r
