Rejecting changes via the Version Differences tool? - e.g. a wrongly deleted feature

[KarlWilson]

When I run the "Version Differences" tool from the Data Reviewer toolbar and write the results to the Reviewer table, am I then able to reject specific changes?

Specifically, if somebody deletes the wrong feature in one version and then saves their edit, how do intercept this error before posting it to the DEFAULT version? I don't see any way of rejecting a delete with any of the Data Reviewer functionality, nor as part of the versioning reconcile / post process (especially since there are no conflicts).

Maybe I'm missing something obvious here? Any help would be appreciated!

[MichelleJohnson]

Hello Karl,

Data Reviewer does not have the ability to reject edits.  Core does have a tool that you can use to choose which edit to keep, Version Changes command.

Regards,
michellej.

[KarlWilson]

Thanks for your reply Michelle,

Core does have a tool that you can use to choose which edit to keep, Version Changes command.

Unfortunately the Version Changes tool is severely limited. You can only use it to look at the changes between versions, but you can't use it to actually review them, i.e. accept, reject or amend the changes.

When the Version Changes tool is run, results are presented in a window with separate maps that don�??t link to the main map display. If you need to change something, you need to find and re-select it in the main map display and edit it there. This is very cumbersome workflow. There is also no way of rejecting a delete that's been saved in an edit version, other than copying it back in again from the target version manually.

If you edit a feature in one version, and delete it in the other, the Conflicts dialog will let you choose which version to keep. So the mechanism effectively already exists to intervene and stop a feature being deleted, it just needs to be extended to cover non-conflict changes. The logical place to put this would be in the Version Changes tool, or to merge the functionality of Version Changes and Conflicts together.

There's an ArcGIS Idea here along these lines:
http://ideas.arcgis.com/ideaView?id=08730000000btEUAAY

[Kevin_MacLeod]

This hasn't changed since 10 years ago, at least from what I can see in Pro 3.3. I am surprised this was not in Arc since ArcView / ArcINFO 3.x. Multi user data review is not new nor unique to GIS.  Karl you put it perfectly. This should be in a simple to use as a user interface. When it comes to reviewing mission critical data the focus should be the data, not building the airplane while we fly it. And when there are dozens or hundreds of field editors, there will be some incoming bad data that needs to be screened out. There are a million ways we could create a workaround with Python, models, but it should be out of the box.  I'll ask the SDE team at UC this year about this workflow.

[Kevin_MacLeod]

It would also be great to accept/reject/modify edits in Differences between Child to Child. Before posting. Not child to parent, like it is now, but Child to Child.  Same Level.  Additionally, it would be great to post upwards to target only for certain layers and even more specifically, certain records based on SQL attribute query. For example if I check in edits from child 1 I don't necessarily want to overwrite them from Child 2. I see the Conflict Filter option and will experiment; hopefully that can exclude entire feature classes too.

As I delve in to versioning I am surprised at the lack of QA/QC review tooling. Maybe I'm missing something, I'm still just beginning to understand it.  The concept of multiple editors of data has been around since the 70s and since the advent of modern T-SQL in the 80s it would have been possible to implement QC tooling in ArcINFO.