Can we override the Choose Workspace dialog and set the workspace programmatically?

[Jeff-Reinhart]

Working on a custom ArcGIS Pro Configuration / Add-in. We need to constrain editing to only versioned datasets in a particular geodatabase. Users also need an edit session. They need to be able to stop editing and not save edits. Short transactions would not work well for our user base. In pursuit of this, we have changed Options | Editing | Session | “Enable and disable editing from the Edit tab” to True and have set “single workspace edit session” via

ApplicationOptions.EditingOptions.EnableEditingFromEditTab = true;

When the user starts editing, they are prompted with the Choose Workspace dialog (even if there is only one workspace to choose from). If we know the workspace the user will be editing, the user should not need to go through the extra step of picking the workspace. Is there a way to override the Choose Workspace dialog and set the workspace for the user via the code? I have not found a way to specify a default workspace in the UI and searching the docs for an override has not turned up an answer.

[NarelleChedzey · Accepted solution]

Hi Jeff, 

Unfortunately we do not have this capability in the Editing API at this point  We do have an issue in our backlog for this work and will be addressing it for the 3.6 release. 

Narelle

[Jeff-Reinhart]

Thanks, @NarelleChedzey, good to have that confirmed.

[JeffMatson]

We have a similar requirement to constrain editing to a named version.  Here's a sample that listens to the MapMemberPropertiesChanged event, specifically for when a user interacts with the List By Editing tab of the Contents pane.  (This isn't shown in the sample below, but FixEditability() should also be called as soon as the Map is ready when the project opens.) 

Hopefully the 3.6 release makes this workaround unnecessary.

 private static bool m_bEditabilityHandled = false;
 private Module1()
 {
     MapMemberPropertiesChangedEvent.Subscribe(OnMapMemberPropertiesChanged);
 }
 private static void OnMapMemberPropertiesChanged(MapMemberPropertiesChangedEventArgs args)
 {
     if (m_bEditabilityHandled == false)
     {
         foreach (var v in args.EventHints)
         {
             Debug.WriteLine(v.ToString());
             try
             {
                 if (v.ToString().ToUpper() == "EDITABILITY")
                 {
                     FixEditability();
                 }
             }
             catch (Exception ex) { }
         }
     }
 }

 private static void FixEditability()
 {
     m_bEditabilityHandled = true;
     try
     {
         var activeMap = MapView.Active.Map;
         var lstLayers = activeMap.GetLayersAsFlattenedList().OfType<FeatureLayer>();
         foreach (var l in lstLayers)
         {
             if (l != null)
             {
                 try
                 {
                     Table t = l.GetTable();
                     Geodatabase gdb = t.GetDatastore() as Geodatabase;
                     if (gdb.GetGeodatabaseType() == GeodatabaseType.RemoteDatabase)
                     {
                         var gdbConnProps = (DatabaseConnectionProperties)gdb.GetConnector();
                         if (gdbConnProps != null)
                         {
                             string v = gdbConnProps.Version.ToString();
                             if (string.IsNullOrEmpty(v) || v.ToUpper() == "SDE.DEFAULT")
                             {
                                 BasicFeatureLayer bfl = l as BasicFeatureLayer;
                                 bfl.SetEditable(false);
                             }
                         }
                     }
                 }
                 catch (Exception ex) { }
             }
         }
     }
     catch (Exception ex) { }
     finally { m_bEditabilityHandled = false; }
 }

[Jeff-Reinhart]

Thanks for this. It does prevent the user from being able to edit the layers that we set IsEditable to false.

I was hoping that setting BasicFeatureLayer.SetEditable(false) would mean that the layer would not be included in the Choose Workspace dialog. That is not the case. Layers with IsEditable set to false are still included and the user can still choose to edit that source. It will cost us some time and effort to explain this to our users. Looking forward to a fix.

[Jeff-Reinhart]

Setting our non-versioned datasets as IsEditable false brings in another problem. If the user picks the non-versioned workspace in the Choose Workspace dialog by accident, stops editing, and then starts editing on the versioned workspace, edits will fail on the versioned data. The project has to be closed and opened again to be able to have a functional edit session on the versioned data. I have not been able to pin down why yet. The generic error message is no help. Any ideas would be appreciated.

[Scott_Harris]

@Jeff-Reinhart 

1. What is the error that you are getting?
2. Where is the data?
   • Is it in the same geodatabase?
   • Is it in the same feature dataset?

[Jeff-Reinhart]

1. Error message: "Edit operation failed. This layer's workspace is read only."

2. The data is in a Postgres SDE.

• Yes, the versioned and non-versioned data are in the same SDE geodatabase.
• The non-versioned data is in the root of the SDE geodatabase. Some of the versioned data is in the root, some is in a feature dataset.

It is likely also important to know that I am enabling and disabling the edit session via:

Project.Current.SetIsEditingEnabledAsync()

If I run the same steps via the Edit tab | Enable Editing button, the error does not occur.

I have tried using the button directly as described here, but I need await, so I have not been able to implement that suggestion.

[Scott_Harris]

Thanks for that info @Jeff-Reinhart 

Regarding the error: "Edit operation failed. This layer's workspace is read only.":

• Where do you see it?
• Somewhere in the UI?
• Or is this error returned when you make edits using the SDK?
• Also, which version of ArcGIS Pro / SDK are you using?

[Jeff-Reinhart]

The edit op error fires after attempting to edit any versioned SDE data.

Version is 3.3.0.

I have taken another approach to protect against users accidentally editing the non-versioned data than what @JeffMatson shared. I have created a Postgres user and granted rights to each dataset (full rights on versioned, select only on non-versioned).  The previous configuration had a user with all rights to both versioned and non-versioned datasets.

With layers pointing to this user and with not programmatically changing the editability on the layers, the edit op error no longer fires after starting/stopping the edit session on the non-versioned dataset and then starting on the versioned dataset. Appropriate errors about edit operations failing when the wrong workspace is chosen are also firing as expected.

(The above strikethrough was edited out - the situation is more complicated. Expected errors do NOT occur if using EditOperation.Callback().)

Long story short – seems better to use database role level permissions than to rely on versioned/non-versioned for editing rights.

Still would LOVE for our users to not have to go the extra step of picking the workspace in the first place. Looking forward to seeing this in 3.6.