As a dev, I want to simplify the usage of sub_type in fertiscan

[k-allagbe]

Description

Context
Currently, the sub_type table is defined with fields type_fr and type_en as unique text columns. However, we never actually use type_fr in practice. The sub_type is being used more like an enum. After schema creation, we have to perform separate sub_type inserts to populate this table, which is necessary for the database design to be usable.

Problem Statement
The need to perform separate sub_type inserts after schema creation adds unnecessary complexity to our setup and deployment processes. This approach has several drawbacks:

• Increased Setup Complexity: Additional scripts or manual steps are required to insert initial data, which can be error-prone.
• Deployment Challenges: Ensuring that the inserts run in the correct order and environment adds overhead.
• Maintenance Overhead: Keeping track of initial data inserts complicates version control and collaboration.

By using an enum instead of a table for sub_type, we can simplify the schema and eliminate the need for post-creation data inserts.

Acceptance Criteria

• Evaluate the feasibility and benefits of replacing the sub_type table with an enum.
• Implement the enum to replace the sub_type table if it leads to simplification.
• Remove the need for separate sub_type inserts after schema creation.
• Ensure that existing functionality dependent on sub_type remains unaffected.

[Francois-Werbrouck]

I kinda disagree with that. We have a mandate of keeping our tools bilinguals. We should display the sub labels in French and English. Using the name stored in the DB is a good practice instead of hardcoding it in the FE.

We have not used the type_fr in the Json since the tool did not display a bilingual interface. We could find a way to utilize them to display all fields in both language.

I dont mind switching to an enumeration if it is feseable, however we should 100% keep the sub_type in both languages

[k-allagbe]

We should display the sub labels in French and English. Using the name stored in the DB is a good practice instead of hardcoding it in the FE.

Do you mean that in the inspection form we should then have ?:

    "cautions": {
        "locale": {"en":"", "fr":""}
        "en": [
            "Wash your hands after use.",
            "Keep away from children."
        ],
        "fr": [
            "Se laver les mains apr\u00e8s chaque utilisation.",
            "Garder hors de la port\u00e9e des enfants."
        ]
    },

Sure I'm down for it. What about the other fields though? inspection_comment, company, manufacturer...?

We have not used the type_fr in the Json since the tool did not display a bilingual interface.

If you mean the frontend, it does.

[Francois-Werbrouck]

I'm all for rethinking how the form looks to include both language in a more dynamic way. The thought behind having a table with all sub_labels type was for iterating over the active and non active types. Since the FE just iterate over the object this would allow for easilyadding and removing objects that are sub_labels

over the active and non active types.

We could also tweak the current architecture to include a boolean parameters and tweak the loops only for the active ones

[k-allagbe]

We'll need a bit of research on how locale data is usually handled. Postponing this.