'ValidationError' object has no attribute 'error_dict'

[Данило Шеган]

When attempting to create a network using invalid CIDR, "maas" cli returns a bad error message: this certainly makes it harder to figure out what you did wrong when using MAAS CLI.

$ maas maas1 subnets create name=192.168.122.0/24 cidr=192.168.122.0.24
'ValidationError' object has no attribute 'error_dict'

(note how I mistyped cidr to be "192.168.122.0.24" instead of "/24").

This seems to be another instance of https://bugs.launchpad.net/maas/+bug/1299114 where Django can't take string for a ValidationError.

This is the full traceback in regiond.log: http://paste.ubuntu.com/24549238/.

I can easily "fix" this with http://paste.ubuntu.com/24549224/, however, grepping for ValidationError uncovers a whole number of occurrences where we just pass strings in (including in the same file), instead of the usually expected Django form.errors (though, any dict at least makes it work and return something readable).

[Mike Pontillo (mpontillo)]

I thought about approaching this one by monkey-patching the Django ValidationError to either assert when this happens or automatically correct for this, but it since that single-string arguments to ValidationError are appropriate in some contexts, that didn't work out.

The next best thing, I think, is to make sure that all our custom database fields (such as CIDRField) raise a ValidationError using a dictionary, with the name of the field passed in as well.

This is a bit confusing because in the same file we also have custom *form* fields, which derive from a different class hierarchy. In /those/ implementations, using the single-string argument to ValidationError seems to be okay (and there's no way to get the field name anyway, since by then you just have a label).

So more investigation is needed to determine if we have a problem with the form fields as well, but as a first pass I can at least fix the database fields to correctly raise ValidationError.

I also feel like the database fields need to be split out into a separate file from the form fields.

[Blake Rouse (blake-rouse)]

It is only a problem with custom FormFields. Django already does this correctly. Inside forms as long as the ValidationError is raised inside a clean method then Django knows what to do, eg.:

class ExForm(Form):

    def clean_myfield(self):
        raise ValidationError('My field')

form = ExForm(data=data)
form.is_valid()
form.errors == {
   'myfield': ['My field']
}

[Mike Pontillo (mpontillo)]

Thanks. I think you meant it'll only be a problem for custom database fields, since the form case is already covered (as you've shown). So I think the branch I proposed should cover it.