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

Before rejecting an edit because of constraint violation, allow user to correct the violation(s).

Matt-Goodman

Currently, if a user attempts an edit (i.e. creating a new feature) that violates a constraint rule, the edit is rejected outright with an error explaining why it was rejected.

Instead, the dialog should warn the user of the constraint violation and allow them to either (a) continue editing the feature to correct the violation or (b) discard the edit.

Example 1: the user painstakingly digitizes a detailed lake shoreline perimeter based on aerial imagery, but when they finish the edit they receive an error message based on a constraint requiring that the lake name must not be <Null>. Instead of discarding the editor's sketch, the user has the opportunity to enter the lake name attribute and then again try to commit the edit to the database.

Example 2: some editing workflows mean that it's easiest for editors to simple copy/paste an existing feature (effectively just duplicating it) and then change one or two attributes. However, a constraint rule prohibiting certain duplicate attributes would not allow the user to paste (create) the feature; it would just discard the edit. Instead the user should be able to paste (create) the feature and then receive a warning that the certain attribute has violated the 'no duplicates' constraint, forcing them to change the attribute in the new feature before the edit is committed.

Encontre mais publicações marcadas com

Editing

Closed

Status: Closed

Comentários

jcarlson

Those might be good situations for a Validation rule to simply flag the bad attributes / edits rather than prohibit them entirely. As long as you have a good QA / QC process to actually review and correct errors, I find Validation rules to be much easier to work with.

Of course, we're working with database branches where we get to review things before they hit our public maps. If you're editing live data, I could see certain types of edits that you'd want to block. But those "no duplicates" and "no nulls" situations don't really seem serious enough to warrant a Constraint.

Matt-Goodman

@jcarlson - that was my first thought too, but the technical workshop presenters from Esri (at the UC) correctly pointed out that the workflow for the user would be significantly more streamlined with this enhancement: allowing users to create & commit good data from the start and not requiring a revisit.

jcarlson

@Matt-Goodman It's entirely dependent upon the particular workflows your users perform, though. In the examples you gave, it doesn't seem streamlined at all, but rather a hindrance to effective work. I'd rather revisit a single attribute than re-do an entire edit.

There are other ways around this, too. For example, not having a null name field. If you use a properly configured feature template, you could prompt users for the value before they even begin sketching the feature. I guess if you're going to use constraints, then those boundaries just need to be really well-conveyed to the editors in advance.

Scott_Harris

@Matt-Goodman We actually do retain the sketch when a constraint rule is violated:

Are you using ArcGIS Pro as the editing client? If so, which version? Any more details you can provide will help us get this Idea to the right team?

Thanks,

Scott

Scott_Harris

Closing this until we get further clarification. As it's written, this is already offered.

Participe da Conversa

Faça login para publicar, seguir conteúdo e mais. Novo aqui? Registre-se gratuitamente.