Permet la désinscription #1400
Permet la désinscription #1400
Conversation
| @transaction.atomic | ||
| def unregister(request): | ||
| """allow members to unregister""" | ||
| anonymous = get_object_or_404(User, username="anonymous") |
There was a problem hiding this comment.
je pense qu'il faudrait plutot que le nom de l'utilisateur anonyme soit dans une variable contenu de le setting. Ainsi, même ne dev, on peut facilement tester la fonctionnalité.
There was a problem hiding this comment.
je voyais plutôt une fixture à charger dès le départ. De toute façon il va falloir passer par là, je pense. (idem pour external)
There was a problem hiding this comment.
La fixture ne résoud pas le problème. Si demain on décide que l'utilisateur anonyme ne s'appelle pas ainsi, il faudrait pouvoir le modifier sans devoir modifier le code.
There was a problem hiding this comment.
D'autant plus que l'utilisateur s'appelle Anonyme et qu'il existe déjà en prod (on l'a réservé avec Eskimon pour éviter les surprises)
| message.save() | ||
| for topic in Topic.objects.filter(author = request.user): | ||
| topic.author = anonymous | ||
| topic.save() |
There was a problem hiding this comment.
problème d'indentation par ici
|
Plus généralement, il faudrait en plus :
|
| # Constant for anonymisation | ||
|
|
||
| ANONYMOUS_USER_PK = 5 | ||
| EXTERNAL_USER_PK = 6 |
There was a problem hiding this comment.
pour rester cohérent avec le formalisme des users paramétrés, il serait préférable de renseigner des username dans le settings et non des clés. cf le cas de l'utilisateur bot qui envoi les MP
There was a problem hiding this comment.
je modifierai ça plus tard
|
De manière générale aussi, il faudrait des tests associés à une feature aussi sensible. |
- Pour les galeries des tutos non publiés, elles doivent être supprimées. En effet, plus personne n'y sera rattaché (même pas auteur externe) et leurs tutos respectifs sont viré du disque dur. Du coup il faut les virer aussi pour éviter les données fantôme. - Pour les MP. Prenons le cas d'un MP a trois personnes, A, B et C. Ils s’échangent tous plein de MP dans un fil à tout les trois. Si B quitte le site, A et C doivent pouvoir continuer le MP sans le perdre. Donc un membre partant doit juste quitter le MP sans qu'il soit supprimé.
…into desinscription Conflicts: zds/member/views.py
|
OK, je pense qu'on a un problème : là tout de suite cette PR est cassée, et les dernières informations que j'ai donnent ceci :
L'avant-dernière ligne de mon extrait parle de corriger l'issue #1468. Que les choses soient bien claire : cette correction n'a absolument rien à faire sur cette PR, qui est déjà monstrueuse et ultra-sensible ! Je rappelle à tout hasard que cette PR est importante parce que :
Il est donc totalement exclus d'alourdir encore cette PR en rajoutant des corrections qui n'y sont pas strictement attachées, quand bien même ces corrections paraîtraient triviales. D'autre part, d'après ce que je comprends de l'historique Git, la PR corrective de #1468 est basée sur Ce qu'il y a à faire maintenant
|
|
Sinon, j'ai une proposition "alternative" : vu l’ampleur de la tâche, vu qu'il faudra a un moment ou un autre repasser dev dedans, vu qu'il y a encore un peu de front à faire, je propose de créer une branche dédiée à cette feature sur le dépot principal du zds (et non plus chez artragis) puis ensuite de faire un "cherrypick" de la branche d'artragis vers cette nouvelle branche principale. L'avantage, c'est qu'on peut alors appliquer le zestflow sur cette branche dédiée (PR, QA et tout ça) puis ensuite, quand c'est ok, merger la branche en entier et non plus une PR qui commence à prendre une ampleur démesurée. (à noter que dans mon souvenir, le zestflow prévoyais ce genre de cas pour la mise en place de ZEP et autres features de grandes tailles, en tout cas, c'est le cas dans le git flow, je n'arrive plus à retrouver une discution qui énonce que c'est également le cas dans le Zestflow) EDIT: ça n'empêche qu'on aura surement besoin d'un sacrifice de poulet pour mener a bien la tâche. |
|
Personnellement, dès demain matin, comme je serai au calme, je ferai une PR basée sur la v1.1 avec tout ce qui a été fait aujourd'hui et sans le problème amené par @Alex-D . (merci pour tout mec) Cela réglera aussi le problème de l'historique qui était assez foireux car j'avais parfois des typo, parfois des incompréhensions, parfois des choses non faites etc. Donc, voilà je refais tout demain (08/09/2014) matin. |
Sur |
|
il est 22h30 et la france vient de se prendre un but con. Désolé,
|
|
Alors, vu que je suis visiblement encore le problème, alors qu'il suffisait très clairement de faire un mais qu'il a été préféré de faire un rebase, outil non adéquat dans cette situation, je me propose de faire le gros rebase + compatibilité avec la branche Donc voilà, je m'y met et dès que j'ai un truc qui me semble bien, je crée une branche sur le repo zds directement et la PR qui va bien. Il s'agit typiquement du cas où c'est une grosse feature et le fait que ce soit sur le repo d'un des devs limite les possibilités. Keep calm, des bisous, et à plus tard. /me lance le git rebase de la mort numéro 2. |
Très, très, très (mais vraiment très, j'ai les logs) objectivement, artragis et Eskimon on essayé, avec le résultat que ... Ben ça n'as pas marché ^^ (vraiment). Du coup, quand on laisse des devs qui métrisent pas git tenter de rattraper tout ça (et c'est pas une critique, j'en fait partie), ben ça emplois le bazooka pour tuer la mouche. Bim.
Me disais bien que ma proposition n'était pas folle ^^ |
arf :/ C'est bizarre, je viens de le faire et ça fonctionne. C'est pas bien grave, je nettoie tout ça petit à petit, j'arrive à un résultat plutôt satisfaisant là :) |
descirption fonctionnelle
côté front
côté back
La désinscription entraîne :