1670: Show form hints

[f1sh1918]

Short description

Show error messages/hints to the user for the self service form

Proposed changes

• add error messages and validation for name input field (should this also apply to other projects? I think it makes sense)
• add validation to koblenz reference number
• adjust create card from self service error messages
• add error message and untouched state to data privacy acceptance
• restrict name field to latin characters to avoid breaking pdf generation

not included

• error handling for birthday extensions since not all requirements are clarified and the final implementation of the form field is not done yet (Improve the Geburtsdatum field in the card creation form #1672)
• final text adjustments (1650: Adjust self service texts #1748)

Side effects

• none

Testing

1. Name field: Test special characters, name length and name includes 2 strings with at least 2chars. The particular error message should be displayed
2. Check that the reference number does not include special chars except of "." Check the min(4) and max length (15). The particular error message should be displayed
3. Check the data privacy accepting field: now it has a untouched state and if unchecked there should be an error message display
4. Check that the card creation button is not disabled but clicking on it with some invalid fields will lead to proper error message
5. Check that card creation still works if you provide valid credentions
6. Check also card creation still works for nuernberg and bavaria

Resolved issues

Fixes: #1670

[steffenkleinle]

Tested on firefox, nice work :)

[ztefanie]

Looks already good. Some hints, especially the special char handling needs optimization, beside this it is fine.

Birthday field does not show a proper error message but only the box is outlined red, when e.g. entering 31.02.2003.

I am sorry for trying to be the worst user, but entering emojis is allowed but will break the app:

[f1sh1918]

Looks already good. Some hints, especially the special char handling needs optimization, beside this it is fine.

Birthday field does not show a proper error message but only the box is outlined red, when e.g. entering 31.02.2003.

I am sorry for trying to be the worst user, but entering emojis is allowed but will break the app:

I wrote in the ticket description what is not included.
Birthday field and hints is a separate ticket
Its fine to be the worst user :)
i updated the regex checks

[ztefanie]

Unfortunately this still does not catch unsupported chars, like arabic, cyrillic or greek letters. They will lead to unhandled errors

I would strongly recommend to only allow chars that can be handled by the app correctly, e.g. with this code (needs to dynamically use the font that is active, in my example i just used helvetica to show what i mean)

  const nameValid  = "stefanie test"
  const nameInvalid = "فف فف"

  const supportedCodePoints = helveticaFont.getCharacterSet();
  const supportedSet = new Set(supportedCodePoints);

  const isStringSupportedByFont = (input: string): boolean => {
    for (const char of input) {
      const codePoint = char.codePointAt(0)!;
      if (!supportedSet.has(codePoint)) {
        return false;
      }
    }
    return true;
  }

  console.log(isStringSupportedByFont(nameValid))
  console.log(isStringSupportedByFont(nameInvalid))

[ztefanie]

It is a lot shorted and easier to check if you use unicode ranges;
/(\u00a9|\u00ae|[\u2000-\u3300]|\ud83c[\ud000-\udfff]|\ud83d[\ud000-\udfff]|\ud83e[\ud000-\udfff])/g

Check e.g. this regex test cases someone build: https://regex101.com/r/0anB6Z/1

[ztefanie]

But i think we should only allow supported chars and not try to catch all forbidden ones

[f1sh1918]

this is solved by latin charset restriction

[ztefanie]

🔧 I think it would be nice if the function is not negated. "containsEmojis" to avoid double negation when being used and being more consistent with "containsSpecialChars"

[f1sh1918]

Unfortunately this still does not catch unsupported chars, like arabic, cyrillic or greek letters. They will lead to unhandled errors

I would strongly recommend to only allow chars that can be handled by the app correctly, e.g. with this code (needs to dynamically use the font that is active, in my example i just used helvetica to show what i mean)

  const nameValid  = "stefanie test"
  const nameInvalid = "فف فف"

  const supportedCodePoints = helveticaFont.getCharacterSet();
  const supportedSet = new Set(supportedCodePoints);

  const isStringSupportedByFont = (input: string): boolean => {
    for (const char of input) {
      const codePoint = char.codePointAt(0)!;
      if (!supportedSet.has(codePoint)) {
        return false;
      }
    }
    return true;
  }

  console.log(isStringSupportedByFont(nameValid))
  console.log(isStringSupportedByFont(nameInvalid))

The big question is how i do this with font faces in a web app?
I mean i can get the font as a string from the input field using ref but that really doesn't help me to get a data type where i can get a character set
I absolutely see your issue but every person that ever created a card or used any other form for sth official in germany knows that latin letters have to be used. The person has official papers that has to be shown and it can not be expected that any acceptance store can read arabic letters to verify the name
So i really don't see that the effort is valid to implement this @ztefanie

[f1sh1918]

I checked the implementation for that. To get the Charset we have to create a pdf doc (async) and then we would have pass that charset to all validation functions that means a lot of refactoring and this should be done in a separate issue that i created.
We also would have to adjust the csv import. We could provide the charset via hook. Lots of tests have to be adjusted
@ztefanie

[f1sh1918]

@ztefanie i added latin char restriction

[ztefanie]

looks good. tested an firefox