Ability to opt-out from `DetailDictMixin` on error processing

[sshishov]

Hi, we are using this library and at the same time we are using drf-standardized-errors.

With current implementation of errors (having DetailDictMixin mixin) we are getting the following errors:

{
    "type": "client_error",
    "errors": [
        {
            "code": "token_not_valid",
            "detail": "Given token not valid for any token type",
            "attr": "detail"
        },
        {
            "code": "token_not_valid",
            "detail": "token_not_valid",
            "attr": "code"
        },
        {
            "code": "token_not_valid",
            "detail": "AccessToken",
            "attr": "messages.0.token_class"
        },
        {
            "code": "token_not_valid",
            "detail": "access",
            "attr": "messages.0.token_type"
        },
        {
            "code": "token_not_valid",
            "detail": "Token is invalid or expired",
            "attr": "messages.0.message"
        }
    ]
}

It is completely off and to override this behavior we have to create custom errors for everything.

Would you mind to add the ability to OPT-OUT from "formatting DRF errors"? We can do it by adding some setting and based on this setting inside mixing we either pre-process the code or run super without pre-processing.

Very often different orgs using their own proprietary format and we should not force them to do it.

Best regards,
Sergei

[sshishov]

This request is to add the ability to avoid adding workarounds suggested here: #438

We should just rely on standard DRF errors by default and if someone need "fancy" errors, they should (maybe) OPT-IN for this, like settings.SIMPLE_JWT['FORMATTED_ERRORS'] = True

[Andrew-Chen-Wang]

Hi this is super late admittedly.

I agree, every org has their own ways of defining the error response message/json. But how do you recommend we approach it? A simple off switch still means someone else who doesn't use drf-standardized-errors but faces similar issue would need to modify the error messages.

Honestly, the better method instead of may actually be monkeypatching and writing a unit test to make sure the monkeypatch is correctly patching an existing Exception class.

What do you think? Monkeypatch or something else that can be acceptable as a PR?