List By Editing Defaults All Layers On

[sarahtocco]

I'm currently running into issues with edit sessions.  Unlike ArcMap, where you had to choose which layers you wanted to edit, ArcGIS Pro defaults every layer in a project to be editable.  As this makes it easy for a single user, multiple users of a project that want to edit separate layers can potentially lock each other out of editing depending on who started editing first.  Does ESRI have intentions to default the List by Editing layers checked off?  Otherwise, I have to go to each individual low level user to have them turn off the layers they don't want to edit each time we start a new project or add a new layer. This could save me a lot of headaches if they could learn how to get in the practice of choosing what layer they want to edit instead of it being automatically available for them to edit at anytime and that could only happen if they were defaulted off for editing. 

Does anyone have solutions or workflows (besides versioning) to suggest?  

[MichaelVolz]

What is the datasource for the data?

[sarahtocco]

the geodatabase within the Pro project

[KoryKramer]

Is the concern that one user working in a project containing layers from the project geodatabase will automatically be locking out other users from editing just because the layers are editable by default?

Because if a user isn't actively making edits, there are no locks on the data.  By default, the data is editable, but not locking other users from editing.  

Now, if user A starts editing layer A on one machine, and user B tries to edit layer A (coming from the same project geodatabase) on a different machine, yes, the data will be locked (as it should be, and as it would be if you were in the same scenario in ArcMap).  But just because user A has the project open containing layer A and layer A is editable, that alone doesn't prevent user B from editing.  Once user B starts editing layer A, a lock is placed on the datasource and user A wouldn't be able to edit until the lock is removed.

See: File geodatabases and locking—Manage file geodatabases | ArcGIS Desktop 

Given that, how do you manage editing in ArcMap where you have multiple editors trying to edit in the same file gdb at the same time?  

If there really is a need for multiple editors editing the same datasource at the same time, then file gdb isn't the right solution.

[sarahtocco]

So should I be using shapefiles instead?  The nature of our workflow is to silo each individual project so that when we have completed it, we know where we left off if we ever come back to it.  I'm in a fast paced environment and most projects are worked on and then moved on from within months. We use domains and extended field names very often. Low level users want freedom to create and edit as they please but don't have full understanding of the database structure.  We have an SDE set up but I'm very hesitant to introduce that into the workflow without complete understanding of editing capabilities/limitations. Also, If I put every feature class we work on in SDE it would become increasingly cluttered with data we don't want to store there.  We use it for registered data web services. What is my best option?  Thanks. 

[KoryKramer]

If you use domains you can't use shapefiles.  There are many limitations to using shapefiles: Geoprocessing considerations for shapefile output—Appendices | ArcGIS Desktop 

The real question is, do you need multiple people to be editing the same feature classes simultaneously (concurrently)?  If so, file geodatabase doesn't support that.  

But if you just need different people to be editing different feature classes (either standalone, or in different feature datasets, noting from the help sent previously that file geodatabases lock at the feature dataset level) in the same file geodatabase at the same time, you could probably make that work, it would just take some organizational rule-making as to who edits what and when.

[sarahtocco]

Yes, sorry for not addressing earlier, I understand now that it is a lock on the geodatabase and not the files in the map turned on to edit.  Perhaps creating a 'secret" geodatabase inside the project for me to edit my data layers would be a partial solution. However, if user A edits a feature class and say we want to switch editing over to me, would user A just need to save edits and uncheck it in the list by editing tab to unlock it?  Or would they need to close out the project like I've been having them do?

I realized after starting this thread I have more than one problem.  The other would be needing to edit the same feature class in 2 or more simultaneous sessions by different users. I am hesitant to introduce versioning until I've had a chance to fully understand it before passing on knowledge to beginner users. Our projects move so fast it almost might be easier to split the feature class out and merge later. Your help is greatly appreciated.  Thanks!

[JohnJones]

As soon as a user saves or discards their edits the lock is released and another client can edit (no need to close the project).  For performance reasons, we cache edibility of layers / datasources so the incoming app may need to open the editing status window or the editing view to the contents pane to refresh this cached state so other controls can observe the lock that was preventing them from editing has been released (as both file gdb & shapefiles are single user solutions this isn't as expected as for enterprise geodatabases).  Particularly if they had previously tried to edit while the first user was still editing and thus got a message that the layer isn't editable (failure to upgrade the lock).

[Scott_Harris]

Hi Sarah,

Please check out these Ideas and upvote and add your use case.

ArcGIS Pro - Edit Session 

Option "Make newly added layers editable by default" should be "opt-in" (the default as "disabled") 

-Scott

[sarahtocco]

YES! Thank you, this answers my prayers.  Some things are better defaulted off.  Please consider this in future development!