wf: add user unlinking option to anonymise action (#71777) #27

pmarillonnet · 2023-01-11T16:07:03+01:00

pmarillonnet commented

2023-01-11 16:07:03 +01:00

No description provided.

fpeters commented

2023-01-12 09:23:08 +01:00

Je reprends de redmine :

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

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é".

Je reprends de redmine : > >> J'éviterais mark_anonymous_formdata, ou alors uniquement si le user_id correspond à l'utilisateur connecté. > > > 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é".

pmarillonnet commented

2023-01-12 09:28:25 +01:00

Je reprends de redmine :
[…]

Ah, lors de ma première lecture de cette remarque, j’ai vu ça comme une précision à la suite de mes interrogations sur mark_anonymous_formdata, pas comme une invitation à changer à nouveau le patch.
Le fait que tu reportes cette remarque ici me fait douter. Est-ce qu’il y a encore quelque chose de relatif à cette partie du patch et qu’il faudrait modifier ?

> Je reprends de redmine : > […] Ah, lors de ma première lecture de cette remarque, j’ai vu ça comme une précision à la suite de mes interrogations sur mark_anonymous_formdata, pas comme une invitation à changer à nouveau le patch. Le fait que tu reportes cette remarque ici me fait douter. Est-ce qu’il y a encore quelque chose de relatif à cette partie du patch et qu’il faudrait modifier ?

fpeters commented

2023-01-12 09:34:40 +01:00

Oui, si c'est l'usager attaché à la demande qui provoque l'anonymisation, il faut appeler mark_anonymous_formdata, qu'il ne se trouve pas ensuite sur une page accès interdit.

pmarillonnet commented

2023-01-12 09:40:52 +01:00

Oui, si c'est l'usager attaché à la demande qui provoque l'anonymisation, il faut appeler mark_anonymous_formdata, qu'il ne se trouve pas ensuite sur une page accès interdit.

Arf ok, mauvaise lecture de tes explications de ma part, j’imaginais cet éventuel comportement décrit, d’arrivée sur une page interdite, provoqué par un mark_anonymous_formdata indûment appelé dans cette déliaison, et non pas par son absence, mes excuses. Je revois ma copie.

> Oui, si c'est l'usager attaché à la demande qui provoque l'anonymisation, il faut appeler mark_anonymous_formdata, qu'il ne se trouve pas ensuite sur une page accès interdit. Arf ok, mauvaise lecture de tes explications de ma part, j’imaginais cet éventuel comportement décrit, d’arrivée sur une page interdite, provoqué par un mark_anonymous_formdata indûment appelé dans cette déliaison, et non pas par son absence, mes excuses. Je revois ma copie.

pmarillonnet commented

2023-01-30 10:16:03 +01:00

Et en fait, à y réfléchir ce matin dans le train, je n’arrive pas à concevoir ce que veut dire “l’usager qui provoque l’anonymisation”. Cette action d’anonymisation peut se dérouler à n’importe quel endroit du WF indépendamment de toute action d’un usager. Que veut dire “l’usager qui provoque l’anonymisation” dans ce cas général ?

Je ne pense pas que “si c'est l'usager attaché à la demande qui provoque l'anonymisation” puisse se traduire directement en “formdata.is_submitter(get_request().user)”, si ?

Bref, problème d’interface chaise-clavier de mon côté, c’est pas clair encore.

Et en fait, à y réfléchir ce matin dans le train, je n’arrive pas à concevoir ce que veut dire “l’usager qui provoque l’anonymisation”. Cette action d’anonymisation peut se dérouler à n’importe quel endroit du WF indépendamment de toute action d’un usager. Que veut dire “l’usager qui provoque l’anonymisation” dans ce cas général ? Je ne pense pas que “si c'est l'usager attaché à la demande qui provoque l'anonymisation” puisse se traduire directement en “formdata.is_submitter(get_request().user)”, si ? Bref, problème d’interface chaise-clavier de mon côté, c’est pas clair encore.

fpeters commented

2023-01-31 15:39:24 +01:00

Et en fait, à y réfléchir ce matin dans le train, je n’arrive pas à concevoir ce que veut dire “l’usager qui provoque l’anonymisation”. Cette action d’anonymisation peut se dérouler à n’importe quel endroit du WF indépendamment de toute action d’un usager. Que veut dire “l’usager qui provoque l’anonymisation” dans ce cas général ?

L'usager qui cliquerait sur sur sa demande cliquerait sur le bouton qui amènerait cette action à être exécutée.

Je ne pense pas que “si c'est l'usager attaché à la demande qui provoque l'anonymisation” puisse se traduire directement en “formdata.is_submitter(get_request().user)”, si ?

A priori si.

> Et en fait, à y réfléchir ce matin dans le train, je n’arrive pas à concevoir ce que veut dire “l’usager qui provoque l’anonymisation”. Cette action d’anonymisation peut se dérouler à n’importe quel endroit du WF indépendamment de toute action d’un usager. Que veut dire “l’usager qui provoque l’anonymisation” dans ce cas général ? L'usager qui cliquerait sur sur sa demande cliquerait sur le bouton qui amènerait cette action à être exécutée. > Je ne pense pas que “si c'est l'usager attaché à la demande qui provoque l'anonymisation” puisse se traduire directement en “formdata.is_submitter(get_request().user)”, si ? A priori si.

pmarillonnet force-pushed wip/71777-anonymize-action-unlink-option from be447c84c9 to 7b37aae066

2023-02-02 09:17:08 +01:00

Compare

pmarillonnet force-pushed wip/71777-anonymize-action-unlink-option from 7b37aae066 to b5a4650c46

2023-02-02 09:40:45 +01:00

Compare

pmarillonnet commented

2023-02-02 10:39:13 +01:00

Ok, c’est à jour dans la branche, avec le test qui va avec (paramètre pytest ´submitter_is_triggerer´ dans chacun des deux tests).

fpeters approved these changes 2023-02-06 13:32:40 +01:00

fpeters left a comment

Je suis plus à l'aise avec les tests qui font les vrais parcours, plutôt que cette simulation/vérification de session mais ok.

fpeters merged commit 47576f21dc into main

2023-02-10 09:15:48 +01:00

fpeters deleted branch wip/71777-anonymize-action-unlink-option

2023-02-10 09:15:48 +01:00

Sign in to join this conversation.

No reviewers

No Label

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: entrouvert/wcs#27