Feature services have several access control levels and edit tracking capabilities that are useful when building collaborative editing applications.
- Editor permissions control whether users can add, delete, or modify features in the service. For example, you might allow editors the ability to add features but not modify or delete them.
- Editor tracking records who created or updated the features and when they did it. This is useful when accountability for the edits is required. An optional history tracking feature maintains information about changes to the features over time, allowing edits to be rolled back. This functionality can only be used with enterprise geodatabases; not databases.
- Ownership-based access control allows you to limit access to features based on who created them. For example, you can allow users to create and edit their own data while restricting them to only querying data created by others. This functionality can only be used with enterprise geodatabases; not databases.
The above features use tokens to record and check user names. Developers can force users to provide ArcGIS Server login credentials before using an application. The developers then use these credentials to obtain a token from ArcGIS Server. The token contains encrypted information about who is logging in and allows a user to work with features in the service according to his or her level of access.
You can use any or all of the above items of functionality when designing a service and its accompanying applications. Consider a web application in which users can report crimes in their community. Editor tracking could tell you who has been reporting crimes and when. With ownership-based access control, you can ensure that a crime reported by one citizen cannot be deleted by another citizen (such as the criminal). Finally, you could turn off the ability to modify existing crimes, allowing only additions and deletions.
Scenarios for feature service permissions and editor tracking
Below are a few more scenarios where a combination of editor permissions, editor tracking, and ownership-based access control would be useful in an application. These scenarios will help you understand how to set the best combination of properties on your feature service, based on the purpose of your application.
Volunteer only
In a volunteer only type of web application, all editors are anonymous volunteers. A web application allowing people to place a point on their current location might fit this description. In this scenario, the service should only expose Query and Create operations. Because the features won't be modified, tracking the creators of the data is not a priority. Editor tracking and history are not required either. The administrator could open the dataset in ArcGIS Pro if needed and delete unwanted features.
Authoritative only
In an authoritative only type of application, all users can edit any data, but the edits are tracked. An example of this type of application might allow people to collaborate on a digital tree inventory in their town. Volunteers could add, modify, or remove any tree from the database, but they must log in to the application to make edits.
In an authoritative only application, users can query the history of any feature to see who changed it and when. If needed, an administrator can roll back an edit. The most recent editor of each feature is tracked and stored in the database.
Volunteer and authoritative
You can use multiple feature services in an application where both volunteer and authoritative approaches need to be used. For example, suppose you're working on a team of biologists collecting wildlife information in a national park. Each of you is responsible for a study area, but you want to collaborate so that you can do analysis and publish findings about the entire park. You also want to collect pictures, videos, and comments from visitors to the park.
To manage the collection of this data, you might expose a habitat feature service, which is editable by the biologists only, and an observation point feature service, which is editable by all. The web application developer could write logic such that biologists who logged in would see both feature services, whereas anonymous users would see just the observation point feature service and perhaps an uneditable image of the habitat areas, drawn by the map service.