[C2] Improve terms & conditions DB structure #7172
Description
Since the addition of GDPR terms, we have stored them into the extra_field_values table, linked to the legal table.
This brings a serious issue in terms of management of translations, so we want to clean that up.
We do not need migrations. Terms & conditions (T&C) will most likely be updated when updating Chamilo 1 to Chamilo 2 anyway, and there is only one case we know of that already uses T&C in C2.
Instead of storing each GDPR clause in a distinct extra field, we want to use the type column in the legal table to store the type of section in the T&C.
The current type column only uses value 0, which is fine for the main (non-GDPR) section.
The other sections should range from type=1 to type=15 of privacy_terms (as defined in the extra_field table where item_type = 14 on a system where some conditions have already been registered):
| type | original extra field title | title in template | subtitle in template |
|---|---|---|---|
| 1 | privacy_terms_collection | Personal data collection | Why do we collect this data? |
| 2 | privacy_terms_recording | Personal data recording | Where do we record the data? (in which system, hosted where, accessible by which company that handles the servers, etc.) |
| 3 | privacy_terms_organization | Personal data organization | How is the data structured? To what extent does the organization of the data protect your security? ... Do you have established processes that ensure that a hacker will not be able to collect all the personal data on the first attempt? Are they encrypted? |
| 4 | privacy_terms_structure | Personal data structure | How is the data structured in this software? (one tab for all the data, it has some categorization / label, ...) |
| 5 | privacy_terms_conservation | Personal data conservation | How long do we save the data? Is there data that expires even though the account is still active? How much time do we keep the data after the last use of the system? |
| 6 | privacy_terms_adaptation | Personal data adaptation or modification | What changes can we make to the data? What changes can be made to the data without affecting the service? |
| 7 | privacy_terms_extraction | Personal data extraction | What do we extract data for (towards other internal processes) and which data is it? |
| 8 | privacy_terms_consultation | Personal data queries | Who can consult the personal data? For what purpose? |
| 9 | privacy_terms_usage | Personal data use | How and for what can we use the personal data? |
| 10 | privacy_terms_communication | Personal data communication and sharing | With whom can we share them? In what opportunities? Through what processes (safe or not)? |
| 11 | privacy_terms_interconnection | Personal data interconnection | Do we have another system with which Chamilo interacts? What is the interconnection process? What are the data pieces exchanged and in what way? |
| 12 | privacy_terms_limitation | Personal data limitation | What are the limits that we will always respect when using personal data? How far can we go? |
| 13 | privacy_terms_deletion | Personal data deletion | After how long do we erase the data? (event, last use, contract validity, etc.) What are the elimination processes?After how long do we erase the data? (event, last use, contract validity, etc.) What are the elimination processes? |
| 14 | privacy_terms_destruction | Personal data destruction | What happens if the data is destroyed as a result of a technical failure? (unauthorized deletion or loss of material, for example) |
| 15 | privacy_terms_profiling | Personal data profiling | For what purpose do we process personal data? Do we use it to filter the access users have to certain parts of our application? (negative or positive discrimination) |
When looking at a terms version page, we want to get all terms for this version in this language_id.
When we save the page, we save all terms with the same, new version number (even if the fields are empty).
When the user looks at the terms, he automatically gets the latest version of the terms for his/her language (except the page to see which terms he/she initially accepted).
From then on, we stop using extra fields for conditions, so in a future version we will just remove those extra fields (not right now until we have a migration for them).