What are the rules when copying/pasting a feature into a different feature layer, using the Editor widget?
Hi @Bud ,
1. Does a destination text field need to be as long (or longer) than the source field? Will the destination field be blank if it is shorter than the source field? Related: Copy Features for Experience Builder.
Yes, the destination text field needs to be as long or longer than the source field, otherwise the attribute value will not be pasted.
2. Under what conditions would the Paste button in a different feature layer be available? (not be greyed out)
Here are the conditions under which the Copy button will be grayed out:
Here are the conditions under which the Paste buttons will be grayed out:
Rules are the same as the functionality in Web Editor: Copy and paste features—ArcGIS Web Editor | Documentation
Thanks @AlixVezina.
I don't think either of these points applies to my case. I'm able to paste using a template, but not using the plain Paste button.
Note: The destination layer doesn't have all the fields from the source layer. And some of the destination text fields are shorter than the source fields.
Do you know why the Paste button is greyed out in this case?
Edit: I'm using two separate Editor widgets, both open at the same time.
@Bud Please would you be able to describe in detail the workflow of how you're using the to Edit widgets together?
I'll send a screen recording video in a private message that shows what I'm doing.
But in summary, I have a Survey123 layer containing survey submissions of Indigenous artifact points. A staff member will review each survey point using Editor Widget #1 and edit the status field to be "Approved" if the Indigenous artifact is deemed valid, so that it's symbolized differently on the map and the user knows it's already been reviewed. Then they'll copy the feature.
Then, using Editor Widget #2, they'll paste the feature into a different External Map layer. And make edits to the attributes, as they likely need some cleanup/refining. This layer is served up to the public in a web map on a public web page.
As mentioned, both Editor Widgets are always open, with the idea that it's more intuitive for non-GIS users.
The reason we have two separate layers is: We want to keep a copy of the original raw/unedited survey submission for future reference.
Hi @Bud , thank you for sharing. Copying a feature using one Edit widget and then Pasting it using another Edit widget is not a workflow we are currently supporting.
If this is something you require, please submit an enhancement request via Esri Support. Thank you!
@AlixVezina might find this quirk/gotcha interesting:
AGOL Idea: Consistent default text field length in AGOL and Survey123
Survey123 Designer text fields are 255 characters long, but a new text field from scratch in AGOL is 256 characters long. This idea is to make the default text field length in AGOL and Survey123 consistent.
One annoying thing about this quirk is that a 255-char Survey123 field gets flagged by the Feature Compare > Schema only geoprocessing tool in ArcGIS Pro as having a different length from a 256-char manually created field.
That's a nuisance, because in this case, 255 vs. 256 isn't important to me. I'm copying features from a Survey123 feature layer into a manually created feature layer using the editor widget in Experience Builder."...the destination text field needs to be as long or longer than the source field, otherwise the attribute value will not be pasted."
In this case, pasting from 255 to 256 isn't a problem; the value will get pasted without issue. It's only if it were the other way arround, 256 to 255, that would be a problem.
So yeah, it's too bad that these rows are being flagged as having different field lengths, when they were meant to be exactly the same.
This quirk would be a bigger problem if I were copying from 256 to 255. In that case, the copy/paste feature functionality in the Experience Builder editor widget would fail. I'd need to lengthen all the 255 fields to 256 (or shorten the 256 fields to 255), which would quite a pain:
- Create new fields
- Field calculate the values
- Delete old fields
- Fix all the broken field dependencies (somtimes using the same field name is not enough; the web map dependency still breaks)