Latest Contributions by GIS_Spellblade

ArcPy should have a function that allows a user to create an .aprx (ArcGIS Pro project). ^^^ That's the idea. ^^^   Right now, we're in something of a chicken / egg situation.     Egg: I want to automate some ArcGIS Pro things     Chicken: Great. You just need to use an existing project.     Egg: What if I want to automate the project creation?     Chicken: Nah. You don't want that mate. Just have something already there.   These Python questions both ask about the existence of a function to create an .aprx: ArcPy function to create new project - Esri Community Solved: Arcpy function for creating a new ArcGIS Project i... - Esri Community And in both instances, the solution is some flavor of: yeah sure, you just need to have this thing that already exists to make it work. Cue slow-blink meme. Could we imagine a world where, say, Python couldn't generate a new file? No. I mean, I can't. And what I mean to say, with this very belabored point, is, file handling and I/O is a standard part of any flavor of computer programming. It is basic functionality and expected.  Can ArcPy implement this very standard pattern? ... View more

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: grab the permissions from the dataset overwrite the dataset reimplement the permissions from the dataset 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 https://community.esri.com/t5/data-management-questions/auditing-tools-for-sde-users-and-privileges/... https://community.esri.com/t5/data-management-questions/best-practices-with-granting-privileges-and/... ... View more

Some Context: We recently ran into an issue in our shop where we unexpectedly learned, at ArcGIS Enterprise 11.1, that shared services enable schema locking with no option to disable it. The result is that we had to change our service from shared to dedicated, fairly minor change that took us a bit of time to figure out since this is not readily apparent. Based on this community post (https://community.esri.com/t5/arcgis-enterprise-ideas/disable-schema-locking-on-shared-services/idc-p/1503118#M3839) we were relieved to find out that shared services will have the option to disable schema locking at the next LTS ArcGIS Enterprise 11.3. However, that option is global; meaning all shared services must either be schema locking or not schema locking within your enterprise. The Idea: Instead of requiring a deployment to put all their metaphorical eggs in one basket, and because this is a binary choice, this idea is to implement two pools of shared services. One that has schema locking enabled and the other pool with schema locking disabled. This will allow organizations the flexibility to put schema-sensitive applications (like field editing) into a shared pool and schema-insensitive applications (hot take: everything else) into a separate shared pool. The other benefit, is that it will be readily apparent which shared services are schema-locked and which ones are not. This way no one has to make the hard choice to implement a one-sized fits all approach when there are two legitimate, concurrent strategies that an enterprise should consider; shared services for all! @TanuHoque  ... View more