Select to view content in your preferred language

Editor get useremail, required field and stop continuous editing

738
6
Jump to solution
10-31-2023 02:11 PM
LefterisKoumis
Frequent Contributor

I reposted this question and I wanted to repost it with additional questions.

I have this simple editing script that intends to:

1. collects the portal user and pre-populated the email field. If a portal user is not detected, then it should return "no email". Unfortunately the script it doesn't work in this standalone JS but it does work in map view.

2. requires a field, in this case the Phone Number.I have a different layout with the field element objects declared individually and it works. But I need the field elements as in this case to be scripted under the form template. I think there is a typo.

3. I don't know if there is a switch to turn it off, but after you create or edit a feature, it would be great to return the editor to its original state and stop the create/edit of other features.

https://codepen.io/lkoumis1/pen/VwgaGLX 

@ArnoFiva , @AnneFitz 

0 Kudos
2 Solutions

Accepted Solutions
AnneFitz
Esri Regular Contributor

Value expressions will only work if the field is not editable, so add editableExpression: false on your Email field and your expression should work. For me, it now returns "anonymous" - https://codepen.io/annefitz/pen/poGEevm?editors=1000

This sample also uses the GetUser script if you'd like to see an example in our documentation.

I don't know if there is a switch to turn it off, but after you create or edit a feature, it would be great to return the editor to its original state and stop the create/edit of other features.

Don't know if I fully understand what you're asking here, but you could update the editor's allowedWorkflows to disable the creation or editing of features.

View solution in original post

0 Kudos
HeatherGonzago
Esri Contributor

@LefterisKoumis  to clarify further on your questions,

* We do have it documented, it's just not as clear and easy to quickly find as I think it should be. The web map specification has a blurb about it at https://developers.arcgis.com/web-map-specification/objects/formFieldElement/, in addition, if you look at this sample https://developers.arcgis.com/javascript/latest/sample-code/widgets-featureform-async/ it has it written in the description. I think it should be easier to find so will add an additional notice in the actual API reference. Regarding the above referenced sample, take note that all field elements that reference a `valueExpression` have editable set to `false`. This is a requirement for working with valueExpressions. 

* When the `formInfo` was initially implemented, we did not have support for calculations. It was very basic. You could show fields or groupings of fields. The fields could be referenced and you could control whether or not you want to require or make them visible or editable with a simple boolean. This is where the original `editable` and `required`  fields were used. These properties were carried over from the legacy FieldConfig class that has since been removed in favor of using the FieldElement. With the advancements made in the form to support calculations for field visibility, editability, requirements, and value expressions, we decided to deprecate the older properties of `editable` and `required` in favor of working directly with their expression. We still honor the deprecated properties for those older maps created before this affect took place. Moving forward though, any new web maps that get written out with form configurations will reflect the expressions

Although you may be able to set editableExpression directly to false, it is not the tested and recommended way using a named expression. We recommend setting it to an actual expressionInfo which returns a value of false. I know that that can be cumbersome for small booleans, but just wanted to make sure you were aware of this if you notice any weird behavior.

* You asked about  "after you create or edit a feature, it would be great to return the editor to its original state and stop the create/edit of other features."  This is a result of some worfklow refactoring that needed to happen to support the feature to feature relationship editing. It does not break, but can be irksome if not expecting the UI update. If you click on the back arrow, it should take you to the initial state. We intend on addressing this for the next release.

I intend on getting this documentation cleaned up based on some recent feedback, this including removing the deprecated `editable` property on the FieldElement.

Thanks again for the input, and please reach out if you have any additional questions.

-Heather

View solution in original post

0 Kudos
6 Replies
AnneFitz
Esri Regular Contributor

Hi @LefterisKoumis - First of all, in your app you are currently just seeing the default form template because you have a typo on line 129 of your codepen - layernInfos should be layerInfos.

Secondly, GetUser will only return the user if someone is actively signed in, so your app will need to require user sign in if you want the Arcade GetUser function to work properly.

0 Kudos
LefterisKoumis
Frequent Contributor

THank you for the response. As I mentioned on my post, I couldn't find the typo, but you did. Thank you. Now the required field is working. So, based on your feedback, even though the getuser script returns "no email" if no user is identified, nothing will be returned? By the way, I assigned temporarily, a user to the layer and the authentication prompted me for credentials. After I login, still the Email textbox was empty. Would be helpful if there are any examples available showing how the getuser script works on a standalone JS app. 

Lastly, do you have response for #3.

Again, thank you for your time.

0 Kudos
AnneFitz
Esri Regular Contributor

Value expressions will only work if the field is not editable, so add editableExpression: false on your Email field and your expression should work. For me, it now returns "anonymous" - https://codepen.io/annefitz/pen/poGEevm?editors=1000

This sample also uses the GetUser script if you'd like to see an example in our documentation.

I don't know if there is a switch to turn it off, but after you create or edit a feature, it would be great to return the editor to its original state and stop the create/edit of other features.

Don't know if I fully understand what you're asking here, but you could update the editor's allowedWorkflows to disable the creation or editing of features.

0 Kudos
LefterisKoumis
Frequent Contributor

Thank you Anne. It would be very helpful to have a note at the valueExpression documentation to state that value expression will only work if the field is not editable, or even better made the editable false by default.

https://developers.arcgis.com/javascript/latest/api-reference/esri-form-elements-FieldElement.html#v... 

As far for my question regarding turning  it off, sorry for the confusion. What I meant is that right after you create a feature, it returns to the creation mode again instead of returning to the initial screen. Attached is a short video to demo the issue. 

 

0 Kudos
HeatherGonzago
Esri Contributor

@LefterisKoumis  to clarify further on your questions,

* We do have it documented, it's just not as clear and easy to quickly find as I think it should be. The web map specification has a blurb about it at https://developers.arcgis.com/web-map-specification/objects/formFieldElement/, in addition, if you look at this sample https://developers.arcgis.com/javascript/latest/sample-code/widgets-featureform-async/ it has it written in the description. I think it should be easier to find so will add an additional notice in the actual API reference. Regarding the above referenced sample, take note that all field elements that reference a `valueExpression` have editable set to `false`. This is a requirement for working with valueExpressions. 

* When the `formInfo` was initially implemented, we did not have support for calculations. It was very basic. You could show fields or groupings of fields. The fields could be referenced and you could control whether or not you want to require or make them visible or editable with a simple boolean. This is where the original `editable` and `required`  fields were used. These properties were carried over from the legacy FieldConfig class that has since been removed in favor of using the FieldElement. With the advancements made in the form to support calculations for field visibility, editability, requirements, and value expressions, we decided to deprecate the older properties of `editable` and `required` in favor of working directly with their expression. We still honor the deprecated properties for those older maps created before this affect took place. Moving forward though, any new web maps that get written out with form configurations will reflect the expressions

Although you may be able to set editableExpression directly to false, it is not the tested and recommended way using a named expression. We recommend setting it to an actual expressionInfo which returns a value of false. I know that that can be cumbersome for small booleans, but just wanted to make sure you were aware of this if you notice any weird behavior.

* You asked about  "after you create or edit a feature, it would be great to return the editor to its original state and stop the create/edit of other features."  This is a result of some worfklow refactoring that needed to happen to support the feature to feature relationship editing. It does not break, but can be irksome if not expecting the UI update. If you click on the back arrow, it should take you to the initial state. We intend on addressing this for the next release.

I intend on getting this documentation cleaned up based on some recent feedback, this including removing the deprecated `editable` property on the FieldElement.

Thanks again for the input, and please reach out if you have any additional questions.

-Heather

0 Kudos
LefterisKoumis
Frequent Contributor

Thank you for taking the time to respond to my inquiry. I have one comment to add. It was actually suggested by another ESRI staff (not in the conversation) to actually use "false" instead of a named expression for the editableExpression. I will resort back to the latter. Kudos to you, @AnneFitz and all ArcGIS JS API team for the marvelous job you guys are doing.

0 Kudos