Allow special characters in an enum

[petersg83]

Fix #11703

Allow special characters in an enum.

REST: Nothing special
GraphQL: The enum input uses the normalized format (ex: if your enum value is démocratie then your GraphQL input should be democratie). The enum output will correctly be démocratie).

# request
mutation {
  createCountry(data: { enumField: democratie }) {
    data {
      id
      attributes {
        enumField
      }
    }
  }
}

# response
{
  "data": {
    "createCountry": {
      "data": {
        "id": "18",
        "attributes": {
          "enumField": "démocratie"
        }
      }
    }
  }
}

EDIT: after discussing it, the output will finally also be democratie

[codecov]

Codecov Report

Merging #12200 (96e41eb) into master (3700b15) will increase coverage by 0.01%.
The diff coverage is 80.00%.

@@            Coverage Diff             @@
##           master   #12200      +/-   ##
==========================================
+ Coverage   47.61%   47.62%   +0.01%     
==========================================
  Files         228      228              
  Lines        8515     8517       +2     
  Branches     1901     1901              
==========================================
+ Hits         4054     4056       +2     
  Misses       3666     3666              
  Partials      795      795              

Flag	Coverage Δ
front	?
unit	47.62% <80.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
packages/core/utils/lib/index.js	100.00% <ø> (ø)
...pe-builder/server/controllers/validation/common.js	66.66% <50.00%> (-0.84%)	⬇️
packages/core/utils/lib/string-formatting.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3700b15...96e41eb. Read the comment docs.

[iicdii]

Is there the specific reason you remove codes in this file? It reverts the fix in #12005

master

this PR

[petersg83]

Good eye :)
The input stays as an enum but the output is put as a string so special characters could be returned. I put an example in the PR description. Do you see a problem with that?

[iicdii]

I see, I just found that special characters are not supported in GraphQL specs..
http://spec.graphql.org/October2021/#note-46408

Names in GraphQL are limited to the Latin ASCII subset of SourceCharacter in order to support interoperation with as many other systems as possible.

I think there will be more advantages of using the string type than using the enum type :)

[petersg83]

Alright, thank you :)

[derrickmehaffy]

Was just about to ask if this is a good idea since we just had an issue that GraphQL was returning strings for enums.... 🤔 It would be nice to put this issue to bed honestly

[derrickmehaffy]

iicdii fixed this in #12005

[petersg83]

@iicdii considering that this PR only changes the output schema and not the input, do you think it would create problems for the usecases of people listed above? I'm not familiar with typescript. @Convly what do you think ?

[iicdii]

It's trade-off. It lose some benefit of autogenerating api documentation If you force to enum to be a string. Otherwise, you can't use special characters because of GraphQL spec.
I think the way to satisfy both sides is to give the user an option to use special characters or not. If user checked to use special chracters, enum types are shown as string. Otherwise, enum types are shown as enum, and the validation should be applied not to allow special characters.

[petersg83]

Thank you, it seems a reasonable proposition to put a config option for that. What do you think @alexandrebodin @Convly and @derrickmehaffy ?

[derrickmehaffy]

Makes sense to me, though I would advise by default we shouldn't allow it.

[petersg83]

After discussing internally, the field will be a graphql enum for both input and output. The pain point to not have special characters in the enum in the response will be handled in the future with a new type that would look like enum with a key/value system.

[derrickmehaffy]

After discussing internally, the field will be a graphql enum for both input and output. The pain point to not have special characters in the enum in the response will be handled in the future with a new type that would look like enum with a key/value system.

Indeed, I think this the better way going forward, enum are a special format type that's designed to be read by multiple types of languages: https://en.wikipedia.org/wiki/Enumerated_type

There are usually a lot of restrictions on the format of enumerations depending on the language but restricting chars is a common one.

[alexandrebodin]

I have been testing the PR but I get an issue with graphQL now I think.

When doing a query I get the normalized value in the response but I can only filter with the non-normalized value. I was expecting the 2 to be the same?

[petersg83]

It's a good question if it is an issue or not. By using the normalized values in filters, you prevent the user to use some operators (like contains and partially gt, lt...). But I understand why we would want that.

In any case it is already the actual behavior, so we can maybe handle this in another PR if needed?