Hello,
We have an EB app with a couple of edit widgets between two web maps. For editing, we want users to be able to add, delete, update only the attributes of a few layers NOT the geometry. I have the settings for one of these layers as shown below. However, in the app when I click on a polygon it has the pop-up for the polygon but also the polygon is selected (second screenshot) below allowing the polygon to be moved, resized...etc.? We need it enabled for editing but only to allow related table records to be added. How do we disable geometry edits while still allowing new related records? When I turn off editing altogether for the polygon layer we lose the ability to add related records. Are we missing a setting?
Thanks in advance!
Kathy
Are you testing as a non-owner, non-administrator?
In map viewer and most apps you'll often have greater editing privileges than others if you are the feature layer owner or have admin privileges to edit features owned by other users regardless of settings. It's a bit of a pain during the design and testing process.
Thanks for the insight and I hadn't thought of it showing differently depending on the user logged in. I am one of the administrators but not the data owner and the app isn't a public app so I'm not even sure actually how to fully test then. One of the users is the data owner, but we will have one of the other AGOL users test and see what they see. Although the data owner also doesn't want to accidentally modify the geometry either so I hope that isn't the case.
I'll update once they test. Thanks for the response!
a bit of a pain
That's putting it lightly 😅
This would be my guess as well. I think I have an Idea somewhere since this behaviour persists into prod last I checked. "No" should mean "no" IMO.
Ex.
You can configurate it as you needed.
Best,
Faiez
Update:
We are still having the issue of the polygon layer despite in the edit widget layer configuration having none of the options selected for 'Add records, delete records, update records' so in theory for this polygon layer nothing should be able to be edited. However the polygons still select on the map and a user can move them/change the geometry. We have tested this with different users including a non administrator or data owner and they can still change the polygon.
We simply want to select a polygon and have the ability to add a related record. If I remove the polygon from the edit widget layers then the ability to add a related record is lost.
I will file a tech support case on this, but I'm not seeing a setting and I thought the user as an administrator/data owner was it, but apparently not the full culprit.
Thanks,
Kathy
We are facing exactly the same issue here, do you find any solution for this?
Thanks!
Hello @makitahideki ,
The conclusion of the tech support case was the following Bug Number: BUG-000173986
Tech support was able to replicate on their side.
What I did learn for the one of the web maps is I did not have the form in the source web map completely configured for the related records as far as adding a related record. In this case the edit widget was honoring the web map form settings even though in EB it wouldn't allow us to view the layers to configure edit settings in the second web map with an edit widget.
As far as the geometry allowing edits despite being disabled as I understand it is a user permissions/level feature so if you are an admin or own the data by default you can change geometry. However a creator/member of a group should in theory not be able to edit geometry.
I'm not sure that answers your question or helps but that is the latest info I had.
Thanks,
Kathy
Having this issue too! It's very frustrating as there seems to be no way to enable related table editing without simultaneously having geometry editing available in the edit widget - even with geometry editing turned off in the hosted feature layer settings. Don't have views enabled, so the bug mentioned above goes beyond issues with views. Related record editing is only possible using "Interact with a Map widget" with related records turned on, instead of just using attribute only editing - perhaps this behavior is something else ESRI needs to look into further.