feat(ui): enhance and refactor validation across UI components

[hdinia]

Summary

This pull request introduces a comprehensive set of validation utilities aimed at enhancing data integrity and security across our application. By implementing these utilities, we are centralizing our validation logic, thereby ensuring consistency and maintainability.
This PR not only adds new validation functions for strings and passwords but also refactors various sections of our codebase to utilize these new utilities.

Features

• String Validation: The validateString utility offers extensive validation capabilities, including checks for minimum and maximum length, allowance for special characters and spaces, and the option for case-sensitive comparison. It's designed to be flexible, accommodating a wide range of validation scenarios.
• Password Validation: With the validatePassword utility, we enforce strong security criteria for passwords, including requirements for lowercase and uppercase letters, digits, and special characters, along with configurable minimum and maximum length checks.
• Customizable Allowed Characters: The utilities support customization of allowed characters in string validation, enabling us to tailor the validation logic to specific needs.
• Refactoring for Consistency: We've refactored multiple parts of our codebase to use these new validation utilities, streamlining our approach to data validation.

Impacts

• Settings: Group and user creation workflows have been updated to incorporate the new validation logic. Special attention was given to password validation in user creation, adding a confirmation step and enhancing security checks.
• Binding Constraints: The creation now uses the new validation utilities for improved data integrity.
• Map: Areas, Layer, and District creation and modification processes have been refactored to use the new validation logic, ensuring consistency across these critical functionalities.
  Table Mode: The creation and modification of Tables are now more robust with the integration of the new validation utilities.
• Home: Variant creation has been updated to utilize the new string validation utility.
• Modelization: The creation, modification, and duplication of Thermal and Renewable Clusters, as well as Storage, have been refactored to incorporate the new validation logic, ensuring that data integrity is maintained across these functionalities.
• Xpansion: creation of candidates has been updated to utilize the new string validation utility.

[skamril]

Remove || undefined

[hdinia]

didn't notice the state is managed by react hook form, thanks !

[skamril]

function please

[skamril]

allowSpaces is checked twice

[hdinia]

generatePattern function, conditionally includes spaces in the allowed character set. This does not directly check if the input contains spaces but rather allows them in the validation process if allowSpaces is true.

[hdinia]

e.g. you can have a case where some special chars are needed but spaces forbidden, you need to make sure the validation regex don't allow spaces too

 validateString(v, {
                    existingValues: existingCandidates,
                    allowSpaces: false,
                    allowedChars: "&_*",
                  }),

[skamril]

allowSpecialChars and allowedChars can be fusioned:

allowSpecialChars?: boolean | string

If true, all special chars are allowed, if string, only the specified ones.

allowedChars name is confused.

[hdinia]

Don't know about this, 🤔 it's confusing to have one parameter handle 2 data types and use cases in my opinion.

While combining parameters might seem like a simplification, it can actually complicate usage and understanding, specific parameters can help separate concerns and have more granular control.

[skamril]

It is common to have parameters with mutilple types.

allowedChars is not clear because letters and digit are chars too.
And it's dependant of allowSpecialChars value.

 validateString(v, {
                    allowSpecialChars: true,
                    allowedChars: "&_*",
                  })

Becomes

 validateString(v, { allowSpecialChars: "&_*" })

---

 validateString(v, {
                    allowSpecialChars: true,
                    allowedChars: "&?*()'/.................", // add all special chars possible
                  })

Becomes

 validateString(v, { allowSpecialChars: true }) // all special chars possible

---

 validateString(v, {
                    allowSpecialChars: false,
                    allowedChars: "&?", // ignored
                  })

Becomes

 validateString(v, { allowSpecialChars: false })

[hdinia]

your example is not accurate it don't account default values allowSpecialChars: true is by default true allowing alphanum chars + default special chars set to "&()_-".

In general you don't need to allow all special characters this as no sense for validation purposes, where the goal is to restrict user inputs.

it's true that allowedChars name can be confusing thought.

I will think about this change if this not complicates the actual implementation it could simplify the special chars management 🤔

[hdinia]

Edit: the allowedChars parameter is now renamed specialChars for more clarity as you suggested, thanks.

I tried to merge the flag allowSpecialChars and specialChars parameter, but this change doesn't align with the original design, I don't want the possibility to allow all special characters for obvious raison, this is against the concept of validation, and can cause potential security risks.

So for now we have 2 possible cases:

• 1 Special chars blocked:

validateString(v, { allowSpecialChars: false })

OR

• 2 Only a specific set of special chars are allowed (by default "&()_-" to avoid repeating this common pattern all around):

validateString(v) // will allow only `"&()_-"` as special chars + alphanumeric pattern

and that can be adjusted as needed, e.g. for an email input:

validateString(v, { specialChars: "@" }) // will allow only `"@"` as special char + alphanumeric pattern

Note that we could pass an empty string to disable specialChars, and remove allowSpecialChars but it's confusing to me, a dedicated flag to separate concerns is better in my opinion

What do you think about that @skamril ?