Project

General

Profile

Development #71777

wf: ajout d’une option à l’action d’anonymisation pour effectuer la déliaison avec l’usager

Added by Paul Marillonnet 2 months ago. Updated about 6 hours ago.

Status:
Solution validée
Priority:
Normal
Target version:
-
Start date:
28 November 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

Toujours le cas d’usage de la gestion des personnes morales, où la perte d’un mandat engendre la perte de la visibilité de l’usager sur les demandes précédemment soumises.
Une première piste d’ajout d’une action de déliaison (#69120) avait été creusée pour finalement être écartée. On tablerait maintenant plutôt sur l’ajout d’une option à l’action existante d’anonymisation.


Files


Related issues

Related to w.c.s. - Development #69120: wf: action de déliaison de l’usager demandeur avec la demande soumiseRejeté15 September 2022

Actions

History

#2

Updated by Paul Marillonnet 2 months ago

  • Related to Development #69120: wf: action de déliaison de l’usager demandeur avec la demande soumise added
#3

Updated by Paul Marillonnet 2 months ago

  • Assignee set to Paul Marillonnet
#4

Updated by Paul Marillonnet 2 months ago

  • Status changed from Nouveau to En cours

Je commence à regarder.

#5

Updated by Paul Marillonnet 2 months ago

Presque une copie carbone de #69120, rien à ajouter de ce côté ci.

Niveau UI ça rajoute une case à cocher dans l’action d’anonymisation qui jusque là n’avait pas d’option (voir la capture).

#6

Updated by Frédéric Péters about 2 months ago

+            if not formdata.user_id:
+                error = _('No user linked to form.')
+                if isinstance(formdata.formdef, CardDef):
+                    error = _('No user linked to card.')
+                get_publisher().record_error(
+                    error,
+                    formdata=formdata,
+                    status_item=self,
+                )
+                return

J'éliminerais totalement ça dans l'idée de la démarche qui peut également être complétée de manière anonyme et qui va se blinder d'erreurs ici, sauf à indiquer en plus une condition pour ne pas lancer l'"anonymisation" si form_user n'est pas positionné.

+        if ('unlink_user') in parameters:

Curieusement ni block ni pylint ne réagit à ces parenthèses ?

+                tab=('error', _('Error while trying to unlink user')),

Ça m'a l'air sorti de nulle part et pas souhaité.

#7

Updated by Paul Marillonnet about 2 months ago

Frédéric Péters a écrit :

J'éliminerais totalement ça dans l'idée de la démarche qui peut également être complétée de manière anonyme et qui va se blinder d'erreurs ici, sauf à indiquer en plus une condition pour ne pas lancer l'"anonymisation" si form_user n'est pas positionné.

Ok, pas de condition en plus, je vais juste virer ça.

Curieusement ni block ni pylint ne réagit à ces parenthèses ?

C’est corrigé.

Ça m'a l'air sorti de nulle part et pas souhaité.

Étrange, ça devait traîner dans la branche, et j’ai dû le retirer avant de faire le format-patch mais sans pousser à nouveau, c’était pas dans le patche que j’avais soumis ici.

Nouvelle version à jour.

#8

Updated by Frédéric Péters about 2 months ago

Je modifierais unlink_user pour ne rien faire si user_id est vide.

J'éviterais mark_anonymous_formdata, ou alors uniquement si le user_id correspond à l'utilisateur connecté.

#9

Updated by Paul Marillonnet about 2 months ago

Ok, dans unlink_user() je ne fais quelque chose que if self.user_id:.

J’ai retiré l’appel à mark_anonymous_formdata, ça me paraissait pertinent au moment d’écrire le patch, mais à relire une nouvelle fois le code de wcs.sessions, ce n’est plus si clair (en particulier je ne comprends pas ta remarque i.e. la pertinence d’appeler cette fonction par rapport au fait que le user_id corresponde à l’usager connecté).

#10

Updated by Frédéric Péters about 2 months ago

J’ai retiré l’appel à mark_anonymous_formdata, ça me paraissait pertinent au moment d’écrire le patch, mais à relire une nouvelle fois le code de wcs.sessions, ce n’est plus si clair (en particulier je ne comprends pas ta remarque i.e. la pertinence d’appeler cette fonction par rapport au fait que le user_id corresponde à l’usager connecté).

Le mark_anonymous_formdata permet à l'usager connecté d'accéder à une demande alors qu'il n'en est pas marqué l'auteur (typiquement après avoir saisi une demande sans être loggué, ou après avoir utilisé le code de suivi).

Pour prendre le cas de la saisie d'un formulaire d'évaluation "anonyme" par un usager connecté, on y aurait en première action du workflow cette anonymisation, et donc l'usager va saisir puis être envoyé sur /demande/123 mais là ça pourrait lui dire "accès refusé".

Cela étant, dans wcs/forms/root.py, dans submitted(), les choses sont faites dans un tel ordre que ça va passer :

            url = filled.perform_workflow(event='frontoffice-created')

        if not filled.user_id:
            get_session().mark_anonymous_formdata(filled)

mais c'est uniquement pour le cas où l'anonymisation se fait directement; si jamais c'était plus loin dans le workflow, par une action déclenchée par l'usager, il tomberait sur une erreur "accès refusé".

#11

Updated by Frédéric Péters 28 days ago

On devrait sans doute aussi retirer l'éventuel code de suivi (même s'il y a une action explicite pour retirer le code de suivi, je pense qu'elle risque trop souvent d'être oubliée)

#12

Updated by Thomas Noël 28 days ago

Frédéric Péters a écrit :

On devrait sans doute aussi retirer l'éventuel code de suivi (même s'il y a une action explicite pour retirer le code de suivi, je pense qu'elle risque trop souvent d'être oubliée)

Ok, et le préciser alors dans le help_text

If checked, this action will only unlink user from the form/card.

qui deviendrait

If checked, this action will only unlink user from the form/card. Tracking code will also be removed.
#13

Updated by Gitea (Bot) Gitea 26 days ago

Paul Marillonnet (pmarillonnet) a ouvert une pull request sur Gitea concernant cette demande :

#14

Updated by Paul Marillonnet 25 days ago

Merci pour ces précisions. J’ai poussé une branche à jour, qui contient le retrait du code de suivi, et ai créé pour l’occasion une PR gitea, puisque qu’on a basculé sur ce mode de revue du code entre temps.

#15

Updated by Gitea (Bot) Gitea about 6 hours ago

  • Status changed from Solution proposée to Solution validée

Frédéric Péters (fpeters) a approuvé une pull request sur Gitea concernant cette demande :

Also available in: Atom PDF