Field Calculation using Arcade overwrites Creator and CreationDate fields?

1655
9
02-24-2021 10:33 AM
Labels (1)
PaulDohertyFEMA
New Contributor III

Update: 03/01/21 - Esri Support confirmed this is a defect. The reference number is #BUG-000137820 and its synopsis states, "Using Calculate Field with Arcade results in the Creator and Create Date being overwritten to that time/user."

2/25/21 - I opened a Support Ticket this morning Esri Case #02748861 and will post back here when we know more.

Real-world Problem: We wanted to add Census Tract IDs to existing points on a layer. 

Technical Problem: Using Arcade Field Calculation as per Calculate field values—ArcGIS Online Help | Documentation on an ArcGIS Online hosted feature layer updated the Creator and Creation Date fields. 

We expected it to update the Editor and Edit Date - but since we did not create or overwrite fields, we did not expect it to change the creation fields. This is problematic because we now lost the history of who created each point. 

Is this expected behavior or a defect? Should I open an Esri Support Case? 

I've tested this is in Firefox and Edge with ANY Arcade expression in a string field, even a simple one like = ' '. I've tested with both points and line features created using ArcGIS Online hosted feature layers.

PaulDohertyFEMA_0-1614191053594.png

PaulDohertyFEMA_2-1614191275322.png

 

PaulDohertyFEMA_1-1614191188503.png

 

p.s. this did not happen with an SQL expression when tested. 

@ArcGISOnline 

9 Replies
DavidPike
MVP Frequent Contributor

That certainly seems buggy.

XanderBakker
Esri Esteemed Contributor

Hi @PaulDohertyFEMA ,

I would definitely open a support case and have this logged. This is not supposed to happen (IMHO).

0 Kudos
JoeBorgione
MVP Emeritus

In this post, @pmckinney  mentions "Because we have editor tracking set, we are not able to use Arcade expressions" when discussing the use of SQL in AGOL field calculations.  

Is this correct?

@XanderBakker 

That should just about do it....
0 Kudos
AlixVezina
Esri Regular Contributor

@JoeBorgione That's right, if either of these options are enabled, you will not be able to run an Arcade calculation (SQL will still work though). 

AlixVezina_0-1614271512915.pngAlixVezina_1-1614271531577.png

 

0 Kudos
PaulDohertyFEMA
New Contributor III

Update: 03/01/21 - Esri Support confirmed this is a defect. The reference number is #BUG-000137820 and its synopsis states, "Using Calculate Field with Arcade results in the Creator and Create Date being overwritten to that time/user."

XanderBakker
Esri Esteemed Contributor

Hi @PaulDohertyFEMA , thanks for sharing. Hopefully, it will be fixed soon!

0 Kudos
kmsmikrud
Occasional Contributor III

Hi Paul,

Thanks for submitting this BUG and sharing. I had the same thing happen to me and it was so nerve wracking trying to figure out what happened. I filed a tech support case, but in the process we weren't able to reproduce the BUG, but I think it was now because we weren't using a layer that editor tracking enabled for our test.

This morning I had the same thing happen when I used an arcade expression to update a field in a view.

I am simply trying to use a field to symbolize by the number of attachments and was using arcade for the Photo Count field based on the ArcGIS Blog article.  In the process of using this on a feature layer from last year all the records then updated to myself as the Creator, Editor, and dates!!! This was really disturbing and luckily we had a local backup.

Get the number of attachments
Getting the total number of attachments per feature comes in handy when trying to identify what assets might be missing visual information, such as photos to support asset condition surveys.  The fastest way to get this information is to chain the new Attachments() function with the Count() function.

//returns the number of attachments per feature
Count(Attachments($feature))

I'm not sure if SQL can be used in get a feature count. Anyway thanks for the update and reporting the bug. AGOL has an incredible amount of bugs.

Thanks,

Kathy

0 Kudos
KateCarlson
Occasional Contributor

The BUG is still alive and well, as all who have posted here are likely aware.  It just presented itself to me, not that the CreationDate wasn't important when we first started collecting data, we just were not monitoring the field values and did not need to rely on it until recently. 

I do think it would be prudent for Esri to add a warning to the calc splash screen that if you use Arcade these field values will be changed to the current date, share a link to the bug description, and suggesting SQL in these instances. 

Kate

0 Kudos
KateCarlson
Occasional Contributor

Correction, bug fixed in the March 2022  update.

0 Kudos