Feature service with Ownership-Based Access enabled properly filters records based on ownership but does does not allow editing of owner's features.
Feature Service Operations Allowed: Create, Query, Update, Delete
Operations Allowed on Features Created by Other Users: None
Editing in ArcGIS Online Web Map ...
* Features are properly filtered to draw only those "owned" (Created) by user
* Can create new features, but cannot edit them once saved. New features properly save into Feature Class.
* Enabling Operations Allowed on Features Created by Other Users: Query shows all features in feature class.
* Enabling Operations Allowed on Features Created by Other Users: Update allows user to edit ALL features.
* Disabling Ownership-Based Access allows user to edit ALL features.
ArcGIS for Server 10.4.1 Feature Service (secured)
PostgreSQL 9.4.5 Enterprise Geodatabase (Registered with ArcServer Data Store), PostGIS 2.2 Enabled
Feature Class w/ Editor Tracking Enabled - User has Select, Insert, Update, Delete privileges
Database and Server authentication (matching usernames)
Feature Service added to ArcGIS Online with stored ArcServer credentials
ArcServer and EGDB are running on separate AWS EC2 instances.
Also tried adding GlobalIDs and enabling Archiving on Feature Class, no change in functionality.
It's odd that the features filter properly based on the username but do not properly allow editing.
Looking at the Feature Class's "Created_User" field... features created in ArcMap have UPPERCASE username, whereas those created through ArcGIS Online are lowercase. Find it hard to believe that the filter would be case insensitive and the edit filter case sensitive.
Is there another requirement for the feature service to properly identify the user's editable features?
Have I missing something about how the features need to be created?
Has anyone else had issues editing with ownership-based access? Any help would be appreciated.
Worked with tech support on this for several hours and was able to narrow the issue down to only occur when ArcServer credentials are STORED while adding the feature service url to ArcGIS Online as an item.
When the feature service url is added directly into a web map and the user provides appropriate ArcServer credentials, the user is able to edit the features they "own."
Same expected result when the feature service url is added to ArcGIS Online as an item and ArcServer credentials are NOT STORED. When user adds the feature layer to new map and supplies credentials, they can properly edit the features they own.
After trying all combinations of ownership-based access settings, Tech support suggested this was expected authentication behavior.
I disagree and would not expect the decision to Store/Not Store ArcServer credentials when adding a feature service to ArcGIS Online to affect functionality.
Anyone else encountered anything like this?
This is expected behavior because ownership based access control is predicated on the user that's logged into the service, not on the user that's logged into ArcGIS.com. When you store credentials with ArcGIS.com, the credentials used are always the credentials supplied when the service is added - it's how the service is accessed through the sharing proxy. I don't think this would happen with hosted feature services with either ArcGIS.com or Portal for ArcGIS.
Thanks Randall Williams, looks like I might have gotten a little loose in my use of the term "user" earlier.
Yes, I understand that the credentials to access the feature service are authenticated against our ArcGIS Server's Built-in User Store. This is a secured service so authentication with the Server is required to access the data.
The ArcGIS Online account(s) are simply a way to share access to the secure service with appropriate end users, without the need for them to enter a second login. We do not want to share DB or Server logins with end users. We also do not need to know exactly which end user created which record. So we actually do want multiple end users to access the service through ArcGIS Online with the same ArcGIS Server credentials (this is working as expected).
Ownership-based Access uses the Editor Tracking "created_user" field to determine the owner. The user name in this field determines the "owner" of each feature record. Any data that end users create is "owned" by the ArcGIS Server account they used to access the service. Our Enterprise GeoDatabase and ArcGIS Server "data owner" user accounts match exactly so that Editor Tracking will populate the "created_user" field consistently whether the feature is created in an ArcGIS Online Web Map or in ArcMap.
The ArcGIS Server Service's Feature Access Capabilities Settings determine what each user (owner and non-owner) can do with each feature record.
What we have confirmed is that Ownership-based Access...
1 - correctly identifies each "owner's" records (tested by disabling Query on Operations Allowed on Features Created by Other Users)
2 - correctly allows owner to only edit features they own when...
- service url is added to new web map and credentials are entered
- service url is added to ArcGIS Online as item and credentials are NOT STORED, item is added to new map and credentials are entered
3* - DOES NOT ALLOW "OWNER" TO EDIT THEIR OWN FEATURES WHEN SERVICE URL IS ADDED TO ARCGIS ONLINE AS ITEM AND CREDENTIALS ARE STORED
*Owners should be able to edit their own features either way, but edit is unavailable ONLY WHEN credentials are STORED.
It does not make sense that the same authentication (same login to same service on same ArcGIS Server) would produce different access to the "owner's" features based on the method of entry. Either way the service has to authenticate with the same ArcGIS Server using the same exact credentials. I would expect that storing the login would produce the same functionality as typing it in.
If anyone can, please explain why you would expect storing credentials to only achieve partial authentication and produce limited functionality.
**If this is actually intended authentication behavior then I would not expect the owner's features to be properly filtered by the Operations Allowed on Features Created by Other Users: Query option.
We have also using feature services and given them to our users for editing per purpose
not receive this error.
After reconcile you can change user id and name in parent data.
in our case its comes with ESRI user1 like that then we have replace this values with correct and accurate values.
Please check you database version and service security policy.