normalise error messages

[allynt]

from Slack:

@marksmall:

These are the errors we get right now: not verified: {"user":{"email":"RoryMacGregor88@outlook.com","name":"None","username":"RoryMacGregor88@outlook.com"},"detail":["RoryMacGregor88@outlook.com is not verified"]} wrong email/password: {"non_field_errors":["Unable to log in with provided credentials."]} reset email/password correct: {"detail":"Password reset e-mail has been sent."} reset email/password incorrect: {"email":{"email":["The e-mail address is not assigned to any user account"]}} I would like to try to see if we can make these more generic e.g. [{ email: ['who@test.com', 'Email address not exist'] } [{ email: ['who@test.com', 'Email address not verified', 'who@test.com', 'Email address not approved']. password@ ['password', 'Too common a password'] } So, it would be an array, each item in the array would relate to a single field. any field error will be an array. Each item in this array will be the value submitted and it's corresponding error. Each field can have multiple errors at one time e.g. user not approved and not verified, for instance. How does this sound? Is it something I can do, rather than add it to your already large plate.

@allynt:

There are different kinds of errors. There are ones that are associated w/ invalid fields. And there are "higher-level" errors, like a user being unverified, or registration being closed. What you propose makes sense for field errors. But I would have to investigate how to insert non-field-errors into that sort of structure.

[allynt]

What you suggest will not be possible w/out a lot of hacky code. But I could do the following:

All error responses will have the following structure:

{ <field_name>: [<error1>, <error2>, <errorN>]}

and in the case of errors that don't quite map to a single field:

{ "non-field-errors": [<error1>, <error2>, <errorN>]}

Note, that I can replace non-field-errors w/ any old string (I had considered using detail)

[marksmall]

I guess my ideal structure would be:

{
    error: {
        <field_name>: [<error1>, <error2>],
       ...
    }
}

and, for non-field-errors:

{
    error: {
        details: [<error1>, <error2>]
    }
}

This would give us a near unified structure, while allowing for differences in the payload. If this isn't possible, what you suggest above seems fine too.

[allynt]

{
  "errors": {
      <field_name>: [<error1>, <error2>],
      "non_field_errors": [<error1>, <error2>]
   },
  "anything_else": "in_the_payload"
}

[allynt]

done in these 2 commits:

2d4d7829ba9f6843fd805f8d4d06c0752b4056b5:

• if registration is closed, returns an error rather than a redirect (it is actually a straightforward PermissionDenied error rather than some sort of clever method_decorator)
• got rid of the stupid rest_unused and rest_disabled endpoints
• fixed some (breaking) typos

34233a10bd5314c48c0c8e53c62d3b8b44ab77b1:

• normalised serializer/validation errors to consolidate errors; used the new ConsolidatedErrorsSerializerMixin from django-astrosat-core
• refactored verify email/password views
• added loads of tests