Skip to content

Transition away from using DS.Errors for inline-validations #6451

@acburdine

Description

@acburdine

Something I discovered during debugging #6207 is that the DS.Errors object in usage by the ValidationEngine mixin (see here) is actually shared between all models/controllers/components/etc. that use the ValidationEngine mixin.

Surprisingly, this hasn't caused any odd validation messages to pop up yet; however, it is currently breaking tests in #6207, and is not really good practice.

There was talk of converting the inline errors mechanism to one based on https://github.com/offirgolan/ember-cp-validations, and that can possibly included with the fix to this issue.

This also goes with #6431.

Update: DS.Errors now throws deprecations when an inline-validation occurs because it is intended to no longer change the model state when manually modified (which we are doing in our inline-validations implementation). We don't rely on the model state being changed to prevent saving, but it still throws deprecations, and it might actually be helpful to rely on model state in order to simplify some error messaging.

Metadata

Metadata

Assignees

No one assigned

    Labels

    affects:adminAnything relating to Ghost Admin

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions