nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Copy Features only copies editable attributes

Andrew-Bowne

I have a point feature class that has several attributes where some are editable and some are not. I have found that only editable attributes are copied when using Copy Features. Does anyone else have this issue as well? There are some attributes like Asset Type and Site that I do not want to be editable (so users don't accidentally edit this important information) but would like it to be carried over when copying a feature.

Is this something that is by-design? Or am I missing something?

Find more posts tagged with

Accepted answers

KevinBurke

Hi @Andrew-Bowne ,

Thank you for the feedback.

Yes you're correct, this is as-designed behavior to only copy over the values from editable attribute fields that are within the popup of the source feature and are also editable in the target feature.

The main reason for this behavior is due to the fact that because read-only fields by their very nature are not editable, even during manual (non-Copy) editing workflows, that the Copy process follows this same logic to prevent copying over and adding values to read-only fields for target features.

This also applies to hidden fields as well. i.e. those fields that were hidden from the editable popup display during the popup configuration. Therefore the fields for the source and target features needs to be editable and visible to support copying the values between them.

Thank you.

- Kevin

Venom.png

Storage1.PNG

All comments

jfisher

This behavior seems to have changed now. I believe I'm seeing all attributes copied now, whether they are in the form or not! Does anyone know if the expected behavior is documented somewhere?

Andrew_Wolff

@KevinBurke I agree with the justification. The target (new feature) of the copy attributes should have those attributes in the popup as well as allow editing of those fields. However this makes no sense for the source feature. There is no likely intent to edit those attributes, if there were users would likely not be creating new features.

In our case we are creating events on existing assets. Think of a leaking valve, out of service hydrant or watermain break. These events are created in a hosted feature layer as part of our current operations picture. I would be great to automatically pull the asset Id or label as well as other attributes as part of that event feature. In no case is anyone editing the read only assets that form the base in the map.

A. Wolff

Andrew-Bowne

Hi @KevinBurke ,

Thanks for the clarification. This makes sense and I do see the logic in the as-designed process. In my workflow we only want to expose a small subset of fields for editing while retaining the default values of some of the other fields. This would help keep the popup less cluttered and only allow the end user to focus on collecting only a few fields of data.

Here is our use case:

User is collecting (or copying from existing features) interior electrical assets. For this task they are collecting only Emergency Lights. The edit template for the feature class already has default values set for Asset Type (Emergency Light), Floor(<Floor ID>), Building(<BuildingID>), Responsible Party (Engineering), etc. These attributes we do not want the user to edit but we do want retained. What we do want them to edit is: Make, Model, Serial Number, Panel, Circuit. Those all are configured properly and work as expected. When a user creates a new feature, the default attributes (asset type, building, floor) are populated behind the scenes since they are defined in the editing template. When a user copies an existing feature (helpful when you have a space with several of the same emergency lights), only the editable attributes are carried over and not the default attributes from the source feature or from the editing template.

It sounds like we will have to expose these fields and hope that the user stays away from them!

Thank You,

Andrew