The Idea:
Create a GP tool that allows a user to interrogate their enterprise geodatabase to see which users have access to which datasets, feature classes, and tables.
arcpy.management.CheckPrivileges(in_dataset) -> dict:
I'm not picky here, it could return a dictionary or some other kind of object with attributes. Regardless, the result of running this tool on a destination should return each user or role, and the rights associated with each. This would allow a geodatabase administrator to programmatically describe the state of permissions within an enterprise geodatabase. This level of information is currently only available by directly querying the database DBA-style or by laboriously clicking through the GUI for each and every database object to review permissions.
Context:
Within ArcPy, users have access to grant database privileges (view / edit) on datasets, feature classes, and tables. This GP tool allows for a programmatic way to implement privileges across an enterprise geodatabase. This is tool works great when the destination table is known, the user is known, and the intended privileges are known-- --i.e. you're given explicit instructions to add a particular user(s) with a set of privileges; however, this tool quickly becomes ineffective when the latter two items are unknown to the administrator.
Real World Example 1:
This argument is best crystallized by reviewing the AS_IS keyword of the View and Edit parameters of the arcpy.management.ChangePrivileges tool. Let's say we're looking to change some permissions for User X. We know that User X can currently access feature class roads but we're not sure at what level. We can make some assumptions, if they can access the feature class, then obviously they have view privileges. Cool, so let's use the AS_IS keyword within the View parameter
(Side bar: Probably. Maybe they're a member of a role that has view privileges? It doesn't matter, let's assume we're working with a known user here)
Alright, how about Edit privileges? So how do we find out this information? Within the GUI. Wait what? That's right. Open the GUI scroll down a permissions window, and if you have a bad memory you'll need a pen and paper to write it down.
Isn't there an alternative? Well, you could ask your DBA to fetch it for you, which seems to be the standard advice given in a few threads. Or if you have DBA tendencies but don't have access to the server itself you could use ArcSDESQLExecute, but we're running down a rabbit hole here anyway-- --why? Because the keywords in the View and Edit parameters don't really matter anyway. Your user have viewing privileges already? Just use GRANT. No errors given. What if you want to do something wacky like REVOKE view privileges but GRANT Edit Privileges? No errors given.
All of that to say, there's no real point in having an AS_IS keyword, when incorrectly using any of the keywords doesn't create errors-- --and there's even less of a point in doing it programmatically, when you'd have to check in the GUI to verify that data anyway.
Real World Example 2:
Let's say you've been tasked with overwriting a feature class that is used by a variety of users and roles. No problems. We'll just push the new data andddddd... ...all the permissions are gone. Okay, no worries. What were the permissions? Oh. Well. For that. We need the feature class and the previous permissions. Cue the database restore.
If ArcPy had the ability to interrogate permissions, that scenario would have gone something like this:
Without a check privileges tool you're pen and papering that information from the GUI or writing some DBA-level code as discussed above. Anyway, this seems like a fairly low-hanging quality of life improvement to make the ChangePrivileges() GP tool feel more whole.
https://community.esri.com/t5/python-questions/get-user-privileges/m-p/611702
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.