Demandeur d’emploi : Empêcher l’édition de l’identité pivot pour les candidats identifiés par l’API Particulier [GEN-1380]#5749
Conversation
|
Je préparerai une recette jetable avec des belles données factices jeudi. |
|
Il manque le message expliquant pourquoi les champs ne sont pas modifiables non ? |
|
En effet, merci. C'était le plus facile alors je l'ai occulté 🫣 |
|
🥁 La recette jetable est prête ! 👉 Je veux tester cette PR ! |
ce6a55a to
87dc1c8
Compare
d5f7bb3 to
d99a013
Compare
|
@celine-m-s J’ai fait des fixups, je squasherai quand tu auras revu et sera d’accord :) |
|
C'est tout bon pour moi ! :) 🚀 |
|
Joffrey est sur le coup (via la recette jetable) ! |
ea41093 to
9d9d306
Compare
9d9d306 to
a4b5ce3
Compare
|
Je viens d’ajouter un commit a939b1d @celine-m-s L’idée est de bloquer l’édition des informations personnelles dès qu’un candidat est reconnu, peu importe s’il a un critère certifié. |
This denormalized field caches when a job seeker has been recognized by an external identity certifier. It means that person is known from trusted identity referential and their identity should not change. An upcoming migration will populate the field, and #5749 will rely on it.
When a job seeker identity is certified by an external source, populate this field to record when the certification occurred. This will be used for several purposes: 1. Centralize certification to make corresponding fields read only, and providing details to users 2. Prevent users from changing identities after the system has confirmed their eligibility (eg. BRSA on API Particulier) 3. Refresh certified identities once in a while 4. When the CNAV identity provider is available, the certified fields should depend on each user. Using a ManyToManyField with a through table will facilitate storing what fields have been certified. An upcoming migration will populate the field, and #5749 will rely on it.
When a job seeker identity is certified by an external source, populate this field to record when the certification occurred. This will be used for several purposes: 1. Centralize certification to make corresponding fields read only, and providing details to users 2. Prevent users from changing identities after the system has confirmed their eligibility (eg. BRSA on API Particulier) 3. Refresh certified identities once in a while 4. When the CNAV identity provider is available, the certified fields should depend on each user. Using a ManyToManyField with a through table will facilitate storing what fields have been certified. An upcoming migration will populate the field, and #5749 will rely on it.
When a job seeker identity is certified by an external source, populate this field to record when the certification occurred. This will be used for several purposes: 1. Centralize certification to make corresponding fields read only, and providing details to users 2. Prevent users from changing identities after the system has confirmed their eligibility (eg. BRSA on API Particulier) 3. Refresh certified identities once in a while 4. When the CNAV identity provider is available, the certified fields should depend on each user. Using a ManyToManyField with a through table will facilitate storing what fields have been certified. An upcoming migration will populate the field, and #5749 will rely on it.
When a job seeker identity is certified by an external source, populate this field to record when the certification occurred. This will be used for several purposes: 1. Centralize certification to make corresponding fields read only, and providing details to users 2. Prevent users from changing identities after the system has confirmed their eligibility (eg. BRSA on API Particulier) 3. Refresh certified identities once in a while 4. When the CNAV identity provider is available, the certified fields should depend on each user. Using a ManyToManyField with a through table will facilitate storing what fields have been certified. An upcoming migration will populate the field, and #5749 will rely on it.
When a job seeker identity is certified by an external source, populate this field to record when the certification occurred. This will be used for several purposes: 1. Centralize certification to make corresponding fields read only, and providing details to users 2. Prevent users from changing identities after the system has confirmed their eligibility (eg. BRSA on API Particulier) 3. Refresh certified identities once in a while 4. When the CNAV identity provider is available, the certified fields should depend on each user. Using a ManyToManyField with a through table will facilitate storing what fields have been certified. An upcoming migration will populate the field, and #5749 will rely on it.
7b2ac25 to
cf3764d
Compare
|
Je crois avoir pris en compte toute tes remarques avec les derniers fixups ? |
The birthdate was treated separately, and multiple code path had to act special case that field. A new code path would again have to special case that field: #5749 (comment) Instead, dispatch data from the SSO: - `sso_data_dict` comes from the SSO (excluding empty values) - `user_data_dict` stores User data - `jobseeker_data_dict` stores JobSeekerProfile data
The birthdate was treated separately, and multiple code path had to act special case that field. A new code path would again have to special case that field: #5749 (comment) Instead, dispatch data from the SSO: - `sso_data_dict` comes from the SSO (excluding empty values) - `user_data_dict` stores User data - `jobseeker_data_dict` stores JobSeekerProfile data
The birthdate was treated separately, and multiple code path had to act special case that field. A new code path would again have to special case that field: #5749 (comment) Instead, dispatch data from the SSO: - `sso_data_dict` comes from the SSO (excluding empty values) - `user_data_dict` stores User data - `jobseeker_data_dict` stores JobSeekerProfile data
The birthdate was treated separately, and multiple code path had to act special case that field. A new code path would again have to special case that field: #5749 (comment) Instead, dispatch data from the SSO: - `sso_data_dict` comes from the SSO (excluding empty values) - `user_data_dict` stores User data - `jobseeker_data_dict` stores JobSeekerProfile data
The birthdate was treated separately, and multiple code path had to act special case that field. A new code path would again have to special case that field: #5749 (comment) Instead, dispatch data from the SSO: - `sso_data_dict` comes from the SSO (excluding empty values) - `user_data_dict` stores User data - `jobseeker_data_dict` stores JobSeekerProfile data
The birthdate was treated separately, and multiple code path had to act special case that field. A new code path would again have to special case that field: #5749 (comment) Instead, dispatch data from the SSO: - `sso_data_dict` comes from the SSO (excluding empty values) - `user_data_dict` stores User data - `jobseeker_data_dict` stores JobSeekerProfile data
The birthdate was treated separately, and multiple code path had to act special case that field. A new code path would again have to special case that field: #5749 (comment) Instead, dispatch data from the SSO: - `sso_data_dict` comes from the SSO (excluding empty values) - `user_data_dict` stores User data - `jobseeker_data_dict` stores JobSeekerProfile data
280c141 to
f433486
Compare
The birthdate was treated separately, and multiple code path had to act special case that field. A new code path would again have to special case that field: #5749 (comment) Instead, dispatch data from the SSO: - `sso_data_dict` comes from the SSO (excluding empty values) - `user_data_dict` stores User data - `jobseeker_data_dict` stores JobSeekerProfile data
The birthdate was treated separately, and multiple code path had to act special case that field. A new code path would again have to special case that field: #5749 (comment) Instead, dispatch data from the SSO: - `sso_data_dict` comes from the SSO (excluding empty values) - `user_data_dict` stores User data - `jobseeker_data_dict` stores JobSeekerProfile data
950f353 to
30e6488
Compare
|
Je viens d’ajouter 30e6488, je vais le squash une fois qu’il sera relu. |
30e6488 to
1276648
Compare
| "fields_history_formatted", | ||
| ] | ||
| if obj: | ||
| readonly_fields.extend(obj.readonly_pii_fields()) |
There was a problem hiding this comment.
Django ne se plaint pas quand on lui fournit le nom d'un champ qui n'existe pas sur le modèle ? (birthdate pour User ou first_name pour JobSeekerProfile)
1276648 to
1a10198
Compare
The job seeker identity is used to certify eligibility against the API Particuliers. When eligibility is certified, the hire will be removed from siae evaluations. In order to prevent employers to reuse an identity for multiple job seekers, make sure the job seeker personal data is locked when their eligibility has been confirmed. Also, since the job seeker has been found in an external certification authority, make their fields read-only to increase the likelihood of success for next API particulier calls. To better show the dependency between read-only form fields and the API Particuliers, factor out the required fields for the API into constants that can be reused across the codebase.
1a10198 to
b61c356
Compare
🤔 Pourquoi ?
Les candidats dont l’identité a été reconnue par l’API particulier ne doivent plus pouvoir changer d’identité.
🏝️ Comment tester ?
Bien penser aux cas suivants :
💻 Captures d'écran
Details