Zep 24 notif new model

[ChantyTaguan]

PR avec le nouveau modèle d'abonnement (issue #15 ). Deuxième essai après nettoyage par Andr0 + j'en ai profité pour pusher mes corrections de ce matin.

Je remets donc l'explication, en adaptant avec ce que j'ai fait ce matin (en gras).

Alors, on a donc la classe Subscription, qui contient tous les attributs d'un abonnement, qui sont les même qu'avant, à l'exception de type, qui disparait, et is_active qui est devenu active (au moment où j'ai renommé is_active, j'avais une bonne raison, mais au final, cette raison ne tient plus, peut-être qu'on devrait remettre is_active du coup...). <- J'ai remis is_active !

En plus des attributs, Subscription possèdent quelques méthodes qui permettent d'activer et désactiver l'abonnement (complètement, ou juste l'envoi d'email)

On a ensuite une série de classe qui hérite de Subscription, et qui représentent les différents types d'abonnement possibles :

• AnswerSubscription : abonnement aux réponses à un topic, article ou tuto. Je n'ai pas séparé ça en trois classes parce que ça ne semblait pas nécessaire, mais si à un moment dans le dev on se rend compte qu'il faut avoir un comportement différent selon qu'il s'agit des réponses à un sujet ou des commentaires sur un article/tuto, on peut bien sur ajouter 2/3 sous classes à AnswerSubscription
• UpdateTutorialSubscription : abonnement aux mises à jour d'un tuto. Je parle ici des modifications hors-ligne, donc faites par un co-auteur ou le staff
• UpdateArticleSubscription : idem pour les articles. J'ai séparé les articles et les tuto pour pouvoir récupéré l'url de la Notification correctement
• PublicationSubscription : abonnement aux mises en ligne d'une publication (article ou tuto)
• NewTopicSubscription : abonnement à un forum où un tag pour recevoir une notif en cas de nouveau topic.
• PingSubscription, qui hérite de AnswerSubscription mais qui n'est pas vraiment implémentée, qui est là surtout pour mémoire

Ces classes possèdent toutes deux méthodes statiques. L'annotation @staticmethod permettant de ne pas avoir "self" dans les paramètres.

• get_existing(profile, content) : récupère l'abonnement d'un membre à un contenu, renvoie None si le membre n'est pas abonné. Vu qu'on fait la requête sur la sous-classe, seul l'abonnement du type demandé est récupéré (puisqu'on peut être abonné à un même contenu de plusieurs manière différentes, chacune de ces manières correpsondant à une sous-classe)
• get_subscribers(content) : récupère tous les users qui ont un abonnement de ce type au contenu passé en paramètre

Ces classes possèdent en plus toutes la méthode send_notification qui utilise différent paramètres selon la sous-classe et qui envoie la notification au souscripteur de l'abonnement. L'implémentation de l'envoi d'email n'est pas encore faite, j'ai juste un début de code à ce propos dans AnswerSubscription.

Pour finir, la plupart elles définissent la méthode mark_notification_read(), qui comme sont nom l'indique, fait passer la notification de non-lue à lue. La plupart des classes ne prennent pas de paramètre pour cette méthode puisqu'en général, une seule notification non lue est possible par abonnement. NewTopicSubscription fait exception, et prend donc en paramètre le topic concerné.

Enfin, j'ai ajouté trois attributs à la classe Notification, qui sont initialisées dans send_notification et différent selon le type d'abonnement :

• url : url vers laquelle mène la notification
• sender : profil qui a déclenché la notification
• title : titre, c'est ce qui sera typiquement affiché dans la liste déroulante (titre du topic pour une répo,se ou un nouveau topic, titre de l'article pour une mise à jour ou un commentaire, ...)

Voilà, je pense que j'ai fait le tour :)

[GerardPaligot]

Si tu as besoin d'une PR de ma part pour quoi que ce soit, n'hésite surtout pas !

[ChantyTaguan]

Pfiou !

Bon:

• ajout de mixins pour factoriser send_notification() et mark_notification_as_read()
• ajout d'un manager pour factoriser get_existing() et get_subscribers()
• correction et ajustement des signaux utilisé
• ajout de tests et de doc

Les tests ne concernent que les forums pour l'instant, il est probable que tout ne fonctionne pas sur les articles et les tutos. En particulier, j'ai quelques difficultés avec les signaux custom. Je dois encore ajouter de la doc dans les modèles, là j'ai surtout commenté les signaux.

Mais je pense que la base est posée.

[GerardPaligot]

Bien, tu veux déjà une nouvelle relecture ou j'attends un peu ?

Bravo en tout cas !

[ChantyTaguan]

Tu peux y aller je pense.

[ChantyTaguan]

Bon, finalement ça m'énervait ces custom signals, donc j'ai corrigé (c'était tout con en fait...).

Du coup, cette fois, c'est vraiment bon ! Et là, dodo -__-

[GerardPaligot]

J'ai fais une rapide relecture avant d'aller me coucher et de ce que j'en vois, c'est nettement mieux. Bon boulot !

[GerardPaligot]

Comme d'habitude, si tu as besoin d'aide, n'hésite pas !

[ChantyTaguan]

J'ai pas eu énormément de temps depuis jeudi, mais j'ai quand même un peu nettoyé le code et enrichi les tests. Je vais essayer d'ici ce weekend de terminer le nettoyage du code qu'on puisse merger ici.

Je repasserai ensuite sur les issues pour mettre à jour ce qui doit l'être.

[GerardPaligot]

Je viens de voir un commit, ça donne quoi cette PR ? Elle bloque toute contribution vue son importance. :-°

[ChantyTaguan]

Avec le commit que je viens de faire, je pense que je pourrais merger. C'est sans doute pas parfait mais le model me semble maintenant suffisamment stable pour qu'on se base dessus pour le développement.

[GerardPaligot]

Je suis de ton avis. Pour moi c'est ok pour merge.

[GerardPaligot]

Congrats @ChantyTaguan pour le taff ! Est-ce que ça cloture des issues toute cette PR ?

[ChantyTaguan]

Je vais repasser sur toutes les issues (ce soir j'espère). Je ne sais pas si je vais pouvoir en fermer beaucoup, mais y en a certaines qui sont en tout cas partiellement résolues.