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; } } }

Attribute rule error message that doesn't undo previous attribute edits?

TerriWaddell1

Hello,

Bear with me, Arcade is WAY over my knowledge level and this has been a struggle.

We have some fields in a feature class that must never be NULL/empty. We will be editing in ArcGIS Pro 3.0, not a service and whatnot. Basically I'm editing directly in the attribute table on an existing feature, and I may enter data in many fields in that feature's row, tabbing between each. I want an error to come up if somebody accidentally empties out the contents of this field.

I have come up with the code below for one field, and it's working, BUT, when the error pops up, it undoes any other edits made to that same row in the table, even though nothing was wrong with them/they didn't break rules. This will have staff fuming, so I need a nice/less sledgehammer way to have it flag an error but not undo other typing in other fields. I have tried the code below as both constraint and calculation types and still have the same hard error regardless of which rule type I use.

if (IsEmpty($feature.DisplayName) == True){
return {"errorMessage":"DisplayName must not be NULL"
}
}

Can anybody suggest more gentle way to handle errors?

Huge thanks!

Encontre mais publicações marcadas com

Accepted answers

JohannesLindner

You could try a Calculation Rule like this:

// Calculation Attribute Rule
// field: DisplayName
// triggers: Insert, Update

if(IsEmpty($feature.DisplayName)) {
    // When you're inserting without DisplayName, return a default value
    if($editcontext.editType == "INSERT") {
        return "Default Name"
    }
    // When you delete the value during editing, restore the previous value
    if($editcontext.editType == "UPDATE") {
        return $originalfeature.DisplayName
    }
}
// When DisplayName has a value, just return that
return $feature.DisplayName

This rule will ensure that there is at least a default value in DisplayName, but the editor won't get feedback that something went wrong.

All comments

RhettZufelt

One thing, you are missing the curly brackets encompasing the reurn after:

if($editcontext.editType == "INSERT")

TerriWaddell1

Sorry if this chain is going too long, I'm hoping somebody else will find this information useful down the road.

First, I tried turning off the INSERT trigger on the rule, then removed the INSERT section from the code. All was well except that there were now no error flags when I created a new feature and forgot to enter a value into display name.

Next, I turned the INSERT trigger back on for the rule, and modified the code to return an error message if the DisplayName was NULL. This seems to break everything - - due to the error message, I'm unable to add the missing DisplayName into the attributes pane. It won't let me access the attributes in the pane because the feature hasn't been completed, and it cannot be completed because the attribute is missing. Clearly I'm missing something obvious here but can't seem to grasp it. On insert, I just want it to let me finish creating the feature and then go into to the attributes pane so I can enter everything else. I don't mind that pane nagging me that this field can't be NULL. So where am I going wrong here?

Here is my modified version of your code:

// Calculation Attribute Rule
// field: DisplayName
// triggers: Insert, Update

if(IsEmpty($feature.DisplayName)) {
     //When you're inserting without DisplayName, return an error
     if($editcontext.editType == "INSERT") 
          return {"errorMessage":"DisplayName must not be NULL"
     }
    // When you delete the value during editing, restore the previous value
    if($editcontext.editType == "UPDATE") {
        return $originalfeature.DisplayName
    }
}
// When DisplayName has a value, just return that
return $feature.DisplayName

Thanks again!

JohannesLindner

Of course you can just let it trigger on update and remove the insert part. Be aware that this will let invalid inserts through.

Alternatively, you can return your original error message instead of a default value. This way, invaliud inserts will be rejected. Of course, this will also reset all values in the other fields, when you're editing in the table, not the pane.

TerriWaddell1

Johannes,

Thanks for that code, it was a bit advanced for me at first but I can now follow it and right now it's working, and I'll definitely use it elsewhere!

I think the main problem is that the Attribute Table (where I was originally editing) handles the errors differently from the Attributes pane (which Hussein showed in his comment). After talking with staff, we've all agreed that we'll just edit from the pane moving forward and that solves most of our problems for this and future attribute rules as I come up with them.

In your code where you have the INSERT option, do you think it would be okay for me to not include that and set the calculation rule to only trigger on Update? The reason I ask is that we don't have default value for these "must not be empty" fields. If I put in the return something like "Hey dummy, don't forget to edit me!" there is no guarantee that we'll actually notice the crazy text if we're doing fast data entry and not really watching the screen. I can have another calculation that looks for the dummy text, but then I have to write more rules to check for that, so just checking for NULL seems easier. Thoughts?

HusseinNasser2

As long as your rule is NOT excluded from client evaluation (there is a checkbox on the rule, leave it unchecked) and you have auto apply turn off (which is the default) then the attribute editor should not rollback the changes and will give the user the ability to fix their mistake. This means that edits are not sent to the database and processed locally in the attribute editor pane.

your rule should also have return true; at the end otherwise it will always fail.

JohannesLindner

You could try a Calculation Rule like this:

// Calculation Attribute Rule
// field: DisplayName
// triggers: Insert, Update

if(IsEmpty($feature.DisplayName)) {
    // When you're inserting without DisplayName, return a default value
    if($editcontext.editType == "INSERT") {
        return "Default Name"
    }
    // When you delete the value during editing, restore the previous value
    if($editcontext.editType == "UPDATE") {
        return $originalfeature.DisplayName
    }
}
// When DisplayName has a value, just return that
return $feature.DisplayName

This rule will ensure that there is at least a default value in DisplayName, but the editor won't get feedback that something went wrong.

DavidSolari

Validation Rules are your best bet here, this won't catch errors in process but you can have someone make their edits in a temporary version and then QA it before posting back. You should also double-check that these fields are non-null down to the database level, that way you avoid one source of error (although that won't stop empty strings and such)

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.