JavaScript edit widget behavior

[ronaldmcfarlane]

Using ArcGIS Server & Portal 10.3.1, WAB Developer 1.2.

I am making the transition from Flex to JavaScript (JS), so am relatively new.  Using the Edit WIdget in Flex, I can restrict edits of data (entity & attribute) to the creator (e.g. if you created it, you can edit it but no one else can).  You can create the data in one session and come back to it later and edit its attributes, location, add attachments or even delete your items. 

Now in JS WAB Dev. I added the Edit widget and in the map application I can create new data, edit it, add attachments or delete it in the current session, but as soon as I leave it and come back I can only delete it (but not edit the attributes, add attachments nor move its location).  I'm using the stock out of the box Edit widget, without modification.  Is this the expected behavior in this JS widget or am I doing something wrong?  Is there a better edit widget out there?

[ronaldmcfarlane]

I am using ArcGIS Server & Portal 10.3.1, WAB Developer 1.2 and IIs Windows authentication (the server is not federated).  I created a new from scratch pair of editable datasets, published them to Server, pulled them into Portal and generated a map using WAB.  If I leave everything public all is fine, I can create, edit attributes, move features and delete. 

If I enable Editor Tracking in ArcCatalog and publish the datasets with "Ownership based access" checked and allow others to just query the dataset, I can do all as before as long as I retain selection of the feature.  If I unselect the feature and come back to it, I can not move it.  If I refresh the web page, I can only delete the feature.

[ColeAndrews]

After you add features in the app, what user name does the editor tracking field?

[ronaldmcfarlane]

domain\myname

[ronaldmcfarlane]

More behavior information:  I created a second set of data/mxds/services/service folder/portal map/ WAB map.  Taking it from no restriction to most restrictive, I registered the dataset as versioned, turned on editor tracking, set the server from public to private and then enabled ownership based upon access control.  At each point I republished and check behavior in Portal/WAB/JS Map application.  At each step editing functioned as it should until enabling ownership; at that point it won't let me edit the feature nor attributes.  The behavior is the same across all three interfaces.  It is correctly capturing my domain/login name when populating the record.

[ronaldmcfarlane]

Working with ESRI, they identified a bug using Web Tier authentication, so at their recommendation I changed to GIS Server authentication.  I have differing behaviors now depending on if the map is public or private and if it is running in Portal or as a Javascript web app, built with the Web App Builder. 

If the features are public and the map or app is public it all works as advertised in Portal or web app.

If the features are private and the Portal map is restricted it all works as advertised in Portal.

If the features are private and the Portal map is restricted and it is published using web app builder (either through Portal or developer), when opened via web app, it will let me edit/move my own features and won't let me move or edit others'; however it will let me delete anyone's features.  It appears to be a bug in the "Edit" widget because the Portal instance of the map works as it should, only after publishing, via app builder, and using the "Edit" widget does it allow deletions of anyone's features.

[ronaldmcfarlane]

ESRI has confirmed a defect in the "Edit" widget that allows the deletion of anyone's data when in restricted mode, and will log it as such.

Further clarification of an "Edit" widget behavior: When you move the location of a feature, but leave its attributes unchanged, it sometimes snaps back to where it was moved from.  However if you edit its attributes, the changed values are retained and the feature stays where you moved it to.  ​They are looking in to this as well.  Will respond back when I know more.

[ronaldmcfarlane]

ESRI confirms both behaviors are bugs:

Reference Number: BUG-000091934

Synopsis: Different user's are able to delete features which are not owned by them even when Ownership-based access control on features is enabled and delete operation is unchecked for Operations allowed on features created by other users.

Fix Date/Version: Not yet documented

Reference Number: BUG-000091935

Synopsis: Updating geometry of a newly added feature when no changes are made to attributes of the feature does not get honored and the initial geometry of the feature is retained in the feature layer with ownership-based access control on features is enabled on the feature service.

Fix Date/Version: Not yet documented

[ronaldmcfarlane]

I have several messages out to various ESRI staff trying to find out if either bug has been addressed in 10.4.  So far no response.  Will update when I know more.