Étant donné que ça casse des relations dans la BDD, on ne peut pas supprimer un compte qui a des contenus associés.
Il faut créer deux options :
tout supprimer
passer les contenus en Guest
Étant donné que ça casse des relations dans la BDD, on ne peut pas supprimer un compte qui a des contenus associés.
Il faut créer deux options :
- tout supprimer
- passer les contenus en `Guest`
Les programmes proposés peuvent être intéressant, même si le compte devient cancer.
Si on choisit de créer des lien vers l'un des sujet de l'utilisateur depuis un autre topic, on tombera sur un lien mort (mais il aurait pu nous aider), ce qui peut devenir désagréable.
Ainsi, si on le veut, on peut très bien personnaliser la page user de celui-ci en affichant : "Est mort au combat dans la lutte anti-modération." ?
Je propose en Guest pour plusieurs raisons :
* Les programmes proposés peuvent être intéressant, même si le compte devient cancer.
* Si on choisit de créer des lien vers l'un des sujet de l'utilisateur depuis un autre topic, on tombera sur un lien mort (mais il aurait pu nous aider), ce qui peut devenir désagréable.
Ainsi, si on le veut, on peut très bien personnaliser la page user de celui-ci en affichant : `"Est mort au combat dans la lutte anti-modération."` ?
Je pense que le RGPD nous oblige à donner l'option de tout supprimer. Je propose de mettre l'option sur la page de suppression de compte, en précisant bien que conserver les contenus ne conservera aucune information personnelle et en laissant sur Guest par défaut.
Je pense que le RGPD nous oblige à donner l'option de tout supprimer. Je propose de mettre l'option sur la page de suppression de compte, en précisant bien que conserver les contenus ne conservera aucune information personnelle et en laissant sur Guest par défaut.
Ma remarque n'était pas vraiment sur cette distinction (qui est correcte) mais sur les modification proposées du modèle hier dans #20 : on ne peut pas modifier la contrainte de clé étrangère sur author_id pour interdire les invités parce que ça ne permettrait pas d'implémenter cette fonctionnalité.
Ma remarque n'était pas vraiment sur cette distinction (qui est correcte) mais sur les modification proposées du modèle hier dans #20 : on ne peut pas modifier la contrainte de clé étrangère sur `author_id` pour interdire les invités parce que ça ne permettrait pas d'implémenter cette fonctionnalité.
À postériori du moins. On peut vouloir restreindre l'upload de programmes aux seuls membres.
Par contre en effet ça veut dire qu'ne faut pas surcharger la relation d'auteur dans Program.
Voilà c'est ça. Mais du coup il faut faire gaffe dans toutes les vues et opérations de manipulation de programmes qu'on peut être en train de jouer avec des invités.
> À postériori du moins. On peut vouloir restreindre l'upload de programmes aux seuls membres.
>
> Par contre en effet ça veut dire qu'ne faut pas surcharger la relation d'auteur dans Program.
Voilà c'est ça. Mais du coup il faut faire gaffe dans toutes les vues et opérations de manipulation de programmes qu'on peut être en train de jouer avec des invités.
Bah pourquoi on bloque le fait qu'un invité puisse créer un programme ? On dit que tous les Users peuvent créer un Programme, et ensuite dans la route, on vérifie que la personne actuelle est un membre. On évite les conflits et les administrateurs pourront toujours modifier les anciens programmes ?
Ou autre solution, on crée un compte bidon 'décharge' où on y met tout les topic et programmes d'une personne, et pour ses commentaires, on bascule en Guest ?
Bah pourquoi on bloque le fait qu'un invité puisse créer un programme ? On dit que tous les Users peuvent créer un Programme, et ensuite dans la route, on vérifie que la personne actuelle est un membre. On évite les conflits et les administrateurs pourront toujours modifier les anciens programmes ?
Ou autre solution, on crée un compte bidon 'décharge' où on y met tout les topic et programmes d'une personne, et pour ses commentaires, on bascule en Guest ?
on reste sur l'héritage de Post par Program, sans surcharger la propriété author
on restreint l'accès à la publication de programmes par les membres
si un compte est supprimé avec l'option de garder les contenus, on créé un Guest du même pseudo, et on lui attribue les contenus
J'ai rien compris, mais en gros :
- on reste sur l'héritage de Post par Program, sans surcharger la propriété `author`
- on restreint l'accès à la publication de programmes par les membres
- si un compte est supprimé avec l'option de garder les contenus, on créé un `Guest` du même pseudo, et on lui attribue les contenus
C'est ça. Pour le point 2, on passe par @login_required ou un truc du genre. Il faudra aussi valider lors de la soumission du formulaire parce qu'on aura besoin d'upcaster vers Member.
C'est ça. Pour le point 2, on passe par `@login_required` ou un truc du genre. Il faudra aussi valider lors de la soumission du formulaire parce qu'on aura besoin d'upcaster vers `Member`.
Pour information, on ne peut pas (genre absolument pas) faire db.session.delete() sur un objet complexe à cause de ses dépendances. J'ai commencé à implémenter sur les différents modèles une méthode .delete() qui supprime les sous-objets ou les références aux sous-objets.
C'était notamment nécessaire pour supprimer et recréer les forums. Dans ce cas, on supprime les messages, threads, topics récursivement.
Pour les utilisateurs, il faut faire pareil, mais c'est plus compliqué parce qu'il faut d'abord migrer les contenus (comme on en a discuté plus haut).
Pour information, on ne peut pas (genre absolument pas) faire `db.session.delete()` sur un objet complexe à cause de ses dépendances. J'ai commencé à implémenter sur les différents modèles une méthode `.delete()` qui supprime les sous-objets ou les références aux sous-objets.
C'était notamment nécessaire pour supprimer et recréer les forums. Dans ce cas, on supprime les messages, threads, topics récursivement.
Pour les utilisateurs, il faut faire pareil, mais c'est plus compliqué parce qu'il faut d'abord migrer les contenus (comme on en a discuté plus haut).
Le commit précédent ajoute quelques méthodes à Member pour gérer la suppression et migration des contenus :
generate_guest_name() donne un nom d'invité. Le format est<membre>_<numéro> où <numéro> commence à 0 et augmente jusqu'à ce qu'un nom disponible soit trouvé. J'ai imaginé <membre>_ mais ça me semble plus courant comme nom d'invité, et moins il y a de collisions plus c'est simple.
transfer_posts(self, other) transfère tous les posts : commentaires, topics, programmes pour l'instant.
delete_posts() supprime tous les posts (y compris les commentaires d'autres membres sur les fils possédés par le membre).
Et enfin delete() supprime tout le reste, comme d'hab. Donc la suppression c'est soit transfer_posts() soit delete_posts(), suivi de delete().
Le formulaire de suppression de compte a été modifié à la fois côté membre et côté admin. J'ai testé à peu près tous les cas (nom déjà utilisé, suppression par le membre, suppression par l'admin, commentaire anonymé, topic anonymé, commentaire externe supprimé par un topic supprimé, etc).
Le commit précédent ajoute quelques méthodes à `Member` pour gérer la suppression et migration des contenus :
* `generate_guest_name()` donne un nom d'invité. Le format est`<membre>_<numéro>` où `<numéro>` commence à 0 et augmente jusqu'à ce qu'un nom disponible soit trouvé. J'ai imaginé `<membre>_` mais ça me semble plus courant comme nom d'invité, et moins il y a de collisions plus c'est simple.
* `transfer_posts(self, other)` transfère tous les posts : commentaires, topics, programmes pour l'instant.
* `delete_posts()` supprime tous les posts (y compris les commentaires d'autres membres sur les fils possédés par le membre).
* Et enfin `delete()` supprime tout le reste, comme d'hab. Donc la suppression c'est soit `transfer_posts()` soit `delete_posts()`, suivi de `delete()`.
Le formulaire de suppression de compte a été modifié à la fois côté membre et côté admin. J'ai testé à peu près tous les cas (nom déjà utilisé, suppression par le membre, suppression par l'admin, commentaire anonymé, topic anonymé, commentaire externe supprimé par un topic supprimé, etc).
Étant donné que ça casse des relations dans la BDD, on ne peut pas supprimer un compte qui a des contenus associés.
Il faut créer deux options :
Guest
Je propose en Guest pour plusieurs raisons :
Ainsi, si on le veut, on peut très bien personnaliser la page user de celui-ci en affichant :
"Est mort au combat dans la lutte anti-modération."
?Je pense que le RGPD nous oblige à donner l'option de tout supprimer. Je propose de mettre l'option sur la page de suppression de compte, en précisant bien que conserver les contenus ne conservera aucune information personnelle et en laissant sur Guest par défaut.
Conséquence immédiate : un programme peut être posté par un invité.
Non, un programme peut avoir comme auteur un invité, mais ne peut pas être posté par un invité.
Ma remarque n'était pas vraiment sur cette distinction (qui est correcte) mais sur les modification proposées du modèle hier dans #20 : on ne peut pas modifier la contrainte de clé étrangère sur
author_id
pour interdire les invités parce que ça ne permettrait pas d'implémenter cette fonctionnalité.Et bien, c'est simple, on bloque l'accès au formulaire de post de programme aux Guests ?
Voilà c'est ça. Mais du coup il faut faire gaffe dans toutes les vues et opérations de manipulation de programmes qu'on peut être en train de jouer avec des invités.
Bah pourquoi on bloque le fait qu'un invité puisse créer un programme ? On dit que tous les Users peuvent créer un Programme, et ensuite dans la route, on vérifie que la personne actuelle est un membre. On évite les conflits et les administrateurs pourront toujours modifier les anciens programmes ?
Ou autre solution, on crée un compte bidon 'décharge' où on y met tout les topic et programmes d'une personne, et pour ses commentaires, on bascule en Guest ?
J'ai rien compris, mais en gros :
author
Guest
du même pseudo, et on lui attribue les contenusC'est ça. Pour le point 2, on passe par
@login_required
ou un truc du genre. Il faudra aussi valider lors de la soumission du formulaire parce qu'on aura besoin d'upcaster versMember
.Le
@login_required
s'applique lors duGET
et lors duPOST
. Donc pas besoin de checker à la main une fois de plus 😉Je mets ici les logs d'erreur, parce que ce n'est toujours pas corrigé
Edit: à priori ça n'a pas l'air d'être exactement la même erreur. À corriger tout de même.
Pour information, on ne peut pas (genre absolument pas) faire
db.session.delete()
sur un objet complexe à cause de ses dépendances. J'ai commencé à implémenter sur les différents modèles une méthode.delete()
qui supprime les sous-objets ou les références aux sous-objets.C'était notamment nécessaire pour supprimer et recréer les forums. Dans ce cas, on supprime les messages, threads, topics récursivement.
Pour les utilisateurs, il faut faire pareil, mais c'est plus compliqué parce qu'il faut d'abord migrer les contenus (comme on en a discuté plus haut).
Le commit précédent ajoute quelques méthodes à
Member
pour gérer la suppression et migration des contenus :generate_guest_name()
donne un nom d'invité. Le format est<membre>_<numéro>
où<numéro>
commence à 0 et augmente jusqu'à ce qu'un nom disponible soit trouvé. J'ai imaginé<membre>_
mais ça me semble plus courant comme nom d'invité, et moins il y a de collisions plus c'est simple.transfer_posts(self, other)
transfère tous les posts : commentaires, topics, programmes pour l'instant.delete_posts()
supprime tous les posts (y compris les commentaires d'autres membres sur les fils possédés par le membre).Et enfin
delete()
supprime tout le reste, comme d'hab. Donc la suppression c'est soittransfer_posts()
soitdelete_posts()
, suivi dedelete()
.Le formulaire de suppression de compte a été modifié à la fois côté membre et côté admin. J'ai testé à peu près tous les cas (nom déjà utilisé, suppression par le membre, suppression par l'admin, commentaire anonymé, topic anonymé, commentaire externe supprimé par un topic supprimé, etc).