Let administrators perform field calculations without invoking editor tracking

[Bud]

Using an AGOL or enterprise geodatabase layer:

Allow GIS administrators to perform field calculations in Pro without invoking editor tracking.

This question from @RobertAnderson3 explains it well: Is there a way to do a Bulk Attribute Update and avoid updating the LastEdited Editor Tracking Infor...

@Marisa_Kordecki said:

[Temporarily disabling editor tracking]...is not my ideal solution as the inspectors make edits to the data anytime over their work day and work week, meaning that turning it off would stop tracking of anything they happened to edit during that same time.

And here is a related enterprise geodatabase question from @EstherSmith_Dev : ApplyEdits without firing immediate attribute rules and editor tracking, is it possible?

With enterprise geodatabases, as a last resort, we could likely use a SQL UPDATE query via a SQL client instead of a Field Calculation—if the data isn't versioned; the SQL UPDATE query wouldn't invoke editor tracking. But that doesn't help us with AGOL data or versioned enterprise geodatabase data. Or with file geodatabases.

[SSWoodward]

If this Idea is specific to ArcGIS Online, it would be better suited to that specific Ideas board.  

ArcGIS online hosted layers are not stored in a geodatabase.  Can you let me know if this is specific to AGOL?

[Bud]

@SSWoodward I edited the question so that it's generic to both AGOL and geodatabase layers.

Would Geoprocessing be a more suitable label?

[RobertAnderson3]

My specific situation is with an ArcGIS Online Hosted Feature layer, I'm going to do the data edits in Pro however as it's easier for a bulk edit.

The ability to not track certain edits that are done to all or a large amount of the features in a layer would apply to both hosted feature layers and layers stored in geodatabases I think. This is why I cross posted it between the AGOL and Pro forums, I wasn't really sure which place made more sense since my data is online, but the workflow is in Pro, and data COULD be in a geodatabase.

Some processes will touch on every point, updating the last edited, whether or not it really made a change, which can lose the more relevant information of when did it actually get directly updated last and by who.

I think I will be able to get away with the temporarily turning off the editor tracking if I do it outside of the typical work hours for the users, but agree with Marisa that it's not always a feasible strategy.

As I said on my original post, I understand the limitations and why this may not be a great strategy technical side wise, but it seems like it could be a useful one in certain situations so I wanted to see if it was a possibility.

[SSWoodward]

@Bud Geodatabases is the correct exchange for editor tracking in geodatabases.  AGOL would be the correct place to request this ability for ArcGIS Online hosted data. I've pinged the AGOL team internally on this so that can see it.  The status of this Idea will reflect the status of this functionality for geodatabases specifically. 

@RobertAnderson3  You are correct there is no out of the box way to have editor tracking ignore edits made by an admin. If data is edited, the editor is recorded.  Whether its a feature layer in ArcGIS Online, or a feature class in a geodatabase.

Turning off editor tracking before performing something like this is an option if you didn't want to overwrite the edit history. 

The point @Bud raises about versioned data specifically is interesting, because editor tracking is a requirement for branch versioned data, so without also unregistering the data as versioned, turning off editor tracking on geodatabase feature classes is not an option.

[RobertAnderson3]

@SSWoodward Thank you for the feedback!

I tried the turn off editor tracking strategy for my hosted feature layers last night and it worked properly, I was concerned as it's Survey123 layers and if there's going to be oddities, it's with stuff in that app.

Turning off editor tracking, editing, then turning editor tracking back on worked as expected to prevent this bulk edit from being tracked, which was nice to see and good to know for the future.

The versioned data in a database definitely adds more challenge to the idea, but could be an interesting idea, if it could be done from default or something.

I'm just thinking of our address point layer where a process we run sets the dates on all of the points the same, so editor tracking really doesn't serve much purpose there. (I forget what exactly the process is, I would have to get more details from our addressing coordinator next week)

[Bud]

I wonder if it is possible to edit versioned data by running a SQL UPDATE statement on the versioned database view (multiversion view)? Since database views can be used to edit data in tables in some cases (Oracle).

[IvicaSkender1]

This is a very interesting proposal, indeed. We had issues with editor tracking when rapid field inspections of structures after the earthquake engaged field teams with ArcGIS Pro Collector / Field Maps (in AGOL, thanks to Esri DRP). Simultaneously the data quality team was correcting the address placement errors and other issues, and admins did the bulk Calculate Field operations for some missing or incorrect fields that were not enforced otherwise. The building damage level was a key discriminator in receiving government aid so you can imagine the level of pressure field engineers were subjected to from house owners and various stakeholders to alter data in their "favor". It was of essence to know the last editor if some of them misused the access to change the assessment in order to secure up to a few thousand Euro immediate help in material, services or cash. However, any QA/QC edit or bulk calculate would run over the editor tracking information and we would have to make our way through archive backups hoping to find relevant information there.

My thinking is more towards a kind of a geoprocessing tool that would un-share the feature layer to the field editing group and stop the editor tracking. Maybe we could do it ourselves using Data Pipelines now. Then admin and/or bulk edits and then the reverse tool - start editor tracking and share with the field editing group.

[SSWoodward]

@Bud,  That would not be a supported workflow. Branch Version data must be edited through the feature service. We have some pretty smart users that make many things possible that are not supported, however it is not advised.

@IvicaSkender1 That's a very interesting use case.  Thank you for sharing.