Is there a way to limit which fields users have the ability to batch edit? For both geometry and attribute editing?
Or limit web maps to not be able to be opened in this app? (like Field Maps/Collector selection)
We make lots of maps/apps for our fielders and non traditional GIS users that we don't want to be able to edit any attribute in batch format. We limit them to batch editing through the widgets in Web Appbuilder (Hopefully Experience Builder when widget is released) that allows us to limit which fields they have access to in batch format. From what I can see, if a user has access to the web map and editing geometry add/delete as well as attribute editing is turned on then the user could open the webmap in this Web Editor and have access to batch delete, merge and batch edit all attributes.
At this time, there is no ability to limit or block users from using the batch attribute ability in Web Editor, whether for geometry or attribute updates.
Can you go into a bit of detail of your use case for limiting attributes to edit in the Batch Attribute Editor widget in WAB? What's a scenario where a user can edit the attributes for individual features but not batch features?
There's also no ability to limit the web map from being opened in Web Editor. If the user is a Creator user type then they will have access to Web Editor. Are your fielders and non traditional GIS users Creator user types?
Is ArcGIS Web Editor only available for Creator and above?
Our fielders typically do not have Creator licenses except a few field managers and a few that do some office QA/QC as well as assigning fielders to features. Users sometimes do as we make apps for small Municipal clients and some of them have to be admins on their accounts. We try to get as many people editing as possible by using the restrictions on what they can and can't edit. This get buy in from more municipal users. If they have the ability to batch edit and delete all features in maps they have edit access to it opens up a path to possible large scale data errors from users that aren't traditional GIS users. In the past they would have had to use ArcGIS Pro to do that which they didn't have installed.
Don't get me wrong, it is a great ability to have and glad it is there but I am worried about who has access to it. In the past, the ability for someone to open a web map and edit in there and see attributes they normally would not have write access to was not too much of a problem because they would have to individually edit each feature.
For WAB, we can limit which attributes users can see and edit at all as well as which they have access to for batch attribute. In general we would have several attributes that are read only and users don't have access to editing based on the web map (classic for WAB). For the batch attribute, it is only available through the batch attribute widget. With this widget we can limit which attribute field the users have the ability to batch attribute. That is a major QA feature we use to make sure data editors don't edit multiple features attributes we only want them editing at an individual level.
For instance in a tree editing app we may only give users the ability to batch edit a "year trimmed" field so they could not accidentally change all of the other attributes of a set of trees. All other values we would want them to individually select trees. Using those apps the user also is limited to only be able to edit certain fields.
Or we may create an app for a field manager to assign features to crew members. In that case an app is created that they can batch edit the features but the only attribute field they could batch edit is "Inspector Assigned" and "Status" field.
@MikeDahm Web Editor is only available for Creator and above, correct.
The ability to configure certain fields to not be available for batch editing isn't something that is being considered for the June release, but is something we're discussing. We'll discuss this and see how we can best handle it.
@CraigGillgrass , @MikeDahm I just want to tag onto the discussion re: limiting which attributes can be 'batch edited'
I just stumbled on Web Editor today in search for a batch attribute editing experience in a COTS app. I wish it were available in ExB. In my attempt to allow a simple interface for updating a Status field in a table, I configured a form in the web map for the table. Then when I tested it in web editor, I found there's a 20-feature limit to edit attributes with a configured form.
@MikeDahm this feels like a viable approach to limit the batch editable fields, assuming you don't need users to have both single feature attribute editing capabilities and batch feature attribute editing.
@CraigGillgrass any input on why the 20 feature limit for configured forms? is it to minimize performance issues with potential arcade expression/calculations?
We're working towards making batch attribute editing available in ExB, this is planned for the June release.
The February release is the first release of the functionality and we do plan further updates and improvements. Specifically, we are working to increase the limits in a future release in the June release.
For this first release, we're being conservative when a layer has forms authored, while we continue to optimize the experience. This is to ensure predictable performance regardless of form complexity. Batch updating forms that make use of FeatureSet functionality have the potential to degrade performance and the user experience especially if a form contains multiple arcade expressions that use FeatureSets. The 20 feature limit ensures that even when multiple users in an organization are performing batch editing with complex forms they have a consistent and responsive experience. The downside of this is, it impacts forms that don't use the FeatureSet functionality. That is part of what we're working on for the June release.
We appreciate the feedback and know this capability has been something people have been waiting to see for sometime. We made the decision to include in Web Editor, even with the limits, at this release based on that demand.
@DerekLutchko_LTC I understood that a form could be created to restrict the editing to what was in the form for a specific web map. This just doesn't replace a widget within apps created mostly for non-traditional GIS users to do repetitive tasks.
The bigger issues I see is that this app allows multi-editing on ANY webmap the user has access to. While most users don't access the webmaps and just access the apps they are made for. Previously, multi-editing was only allowed on the app side in a widget the owner could restrict to specific fields and layers. This opens it up to any editable layer in a webmap they have access too. So all the webmaps previously created for other apps or field maps they have access to now could be accessed and multi-edited in Web Editor. Some of the organizations we manage have a lot of webmaps for all sorts of tasks we now have to be worried could be multi-edited by an employee that finds this editor.
For Web Editor, there should be a check to allow a webmap to be opened in that app. Just like the check marks for allowing a webmap in Field Maps or Collector. It should be defaulted to OFF.
@MikeDahm I'd suggest adding this as an idea so others can weigh and vote on it. We don't have any plans to add this setting as of now; it's just not something we've heard many request for at this time.
If we were add it, I don't think we'd disable the toggle by default. That's not how Field Maps settings works and we'd want to stay consistent with Field Maps.
@CraigGillgrass I will do that, but I am going to guess you haven't heard it because people don't know much about it and don't know the security concerns it is now opening up.
@MikeDahm Kudoed your idea - i think that's a nice way to handle the concern
@CraigGillgrass Thanks for the explanation and the overall development. It's always tough for us - like to get the new capabilities, but never does everything out of the gate. Makes sense to take your approach. I am definitely looking forward to the capabilities being available in the summer release for ExB - that's our default for building apps. And I totally get the concer with performance and FeatureSet arcade expressions. I love them but they can really pull you into some quicksand.
Happy to provide the explanation @DerekLutchko_LTC it's going to be a bit of a process for us to find the right UI/UX for this that balances the productivity improvements that batch attribute update bring with the concern with performance and FeatureSet arcade expressions. This is something we're going to be re-evaluating as we work through it so we can land on the best experience.
@CraigGillgrass yeah, I get it. I'm a big fan of Arcade, but there's an inherent clash between capabilities and performance. It's a fine line to walk working with the ArcGIS components - I can only imagine what it means on the development side.
Thanks again - looking forward to seeing how you guys thread the needle.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
