Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default behavior of FormElement not supported in FieldMaps #2107

Open
ccone-pattern opened this issue Oct 14, 2024 · 1 comment
Open

Default behavior of FormElement not supported in FieldMaps #2107

ccone-pattern opened this issue Oct 14, 2024 · 1 comment
Assignees

Comments

@ccone-pattern
Copy link

ccone-pattern commented Oct 14, 2024

Is your feature request related to a problem? Please describe.
Yes.

When FormElements with no editableExpression contained in FormInfo.formElements are submitted via {Map}.content.update_layer, the update will post successfully. However, when opened in FieldMaps, the user is prompted with an ambiguous error message. In FieldMaps Designer, the "Editable" checkbox is populated, when the form is not actually editable.

image
Message seen when attempting to edit feature in Field Maps

image
State of form configuration GUI in Field Maps Designer - note "editable" checkbox, no other warnings here.

I spent several days triaging this issue on my end, and it wasn't until I used ArcGIS Assistant to compare the JSON in a map created manually with those created via python api that I realized editableExpression was not populated.

Upon explicitly defining editableExpression in my code that creates FormFieldElements, the form worked within Field Maps.
image
image

from arcgis.map import Map

def configure_date_form(field: dict, vizex: FormExpressionInfo=None):
    return FormFieldElement(
            fieldName=field["name"],
            label=field["alias"],
            inputType=FormDatetimePickerInput(includeTime=False),
            visibilityExpression=vizex.name,
            preserve_field_values_when_hidden=True,
            editableExpression="expr/system/true" # This should be instantiated by default, or handled by AGOL to default to true
            )

wm = Map()
for i, lyr in enumerate(wm.content.layers):
    ### Loop configure_date_form over date fields to create a list called "form_elements"
    ...
    form_info = FormInfo(formElements=form_elements, expressionInfos=expression_infos, preserveFieldValuesWhenHidden=True)
    wm.content.update_layer(i, form=form_info)

Describe the solution you'd like
FormElement object should initialize with a default editableExpression value.

Describe alternatives you've considered

  • Manual FieldMaps Designer - not appropriate here given high volume of FormElements we need to create

Additional context
I noticed default behavior of FormFieldElement with uninstantiated editableExpression is to set editable to true in AGOL json object. However I also noticed this editable attribute is not in the FormFieldElement dataclass, nor is it created by FieldMaps Designer. I am not familiar enough with the Forms rest endpoints to confirm if this should be valid, but if it is actually expecting editableExpression, not editable then this may be best categorized as a bug instead of a feature request.

arcgis-python-api version: 2.4.0
env: conda install -c esri arcgis arcgis-mapping
python: 3.12.7
os: Windows 64x

@nanaeaubry
Copy link
Contributor

@ccone-pattern Thanks for reporting this, it seems based on the dataclasses derived from the webmap specifications that the editable expression is part of a FormFieldElement as you correctly observed.

I will reach out to the team who works with this to get some clarity because the doc states: "A reference to an Arcade expression that returns a boolean value. When this expression evaluates to true, the element is editable. When the expression evaluates to false the element is not editable. If the referenced field is not editable, the editable expression is ignored and the element is not editable."

And we are not the ones setting the editable property in the json so that seems to be evaluated by AGOL.

Ill report back any updates

@nanaeaubry nanaeaubry self-assigned this Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants