Add new feature Issue: Enum -> enum list transformed into key: value intead of just key for models.IntegerChoices and models.TextChoices

[IvanSaldikov]

Please, extend you app with the following:

plumbing.py

....
def build_choice_field(field):
    init_choices: dict = field.choices
    ...

    if field.allow_blank:
        choices.append('')
    if field.allow_null:
        choices.append(None)

    if isinstance(init_choices, dict):
    choices = []
    for key, value in init_choices.items():
        choices.append(f'{str(key)}: {value}')

    ....

This will add new feature:
Enum -> enum list transformed into key: value intead of just key for models.IntegerChoices and models.TextChoices choices classes

This will very be helpful when viewing the Enum parameters in Swagger and Redoc. Thank you!

[tfranzel]

Hi @IvanSaldoZ, I absolutely get where you are coming from. Unfortunately, your solution might look acceptable in Swagger, but is ultimately broken by design. Swagger would create invalid example values and code generators would likely also be broken. As per specification, your custom string would be interpreted as the actual enum value, which is of course incorrect.

Essentially this has been an open issue in OpenAPI and JSON Schema for years now. Anything we would come up with would be a hack with little to no support in the tooling ecosystem.

Duplicate of #337, proposal PR #403

Upstream isuses: OAI/OpenAPI-Specification#681

[IvanSaldikov]

Hi, @tfranzel, thank you for your reply. Very sad to hear that. Acutally in my case Swagger and Redoc works fine with this tweak (hack). Maybe if the flow will go further and the yaml file will be proccessed by another software - it will be broken. But not in my case. Is it possible to implement this feature with the flag something like "ENUM_KEY_VAL_ENABLED_NON_SAFE" is equal to False by default. And those who wants to use this tweak will use it, but the rest programmers will dont even know about it and nothing will be broken. You will really, i mean REALLY help to a lot of managers, frontenders, QAs and of course backenders with their daily work if something like this will be in the package. Thank you!

[tfranzel]

Hey @IvanSaldoZ, I hear you. Given we already have a big set of complicated settings, I would rather not add this. But mainly because this "feature" violates OpenAPI 3 in several ways, even it other tools tolerate it. At this point we do not intend to ship options that produce an invalid OpenAPI 3 schema.

I would recommend for you to write a postprocessing hook that does this transformation: https://drf-spectacular.readthedocs.io/en/latest/customization.html#step-6-postprocessing-hooks