Zep 24 notif new model

[ChantyTaguan]

Issue #15

[GerardPaligot]

Il y a beaucoup de changements, les diffs git sont un peu pénible à comprendre. Tu saurais nous expliquer les grands changements ?

Je vois que tu as créé des sous classes et que tu les utilises à différents endroits pour faire les différentes souscriptions mais je vois aussi beaucoup de conditions qui n'existait pas avant et des méthodes statiques (d'ailleurs, qu'apporte en plus l'annotation ?).

[ChantyTaguan]

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 disaparait, 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...).

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 définissent la méthode mark_notification_read(), qui comme sont nom l'indique, fait passer la notification de non-lue à lue. Les classes d'abonnement qui ne définissent pas cette méthode (y en a qu'une : NewTopicSubscription), c'est parce qu'elles peuvent avoir plusieurs notifications non-lues au même moment. Ce cas est traité avec le signal "topic_read" qui récupère directement les notifications concernées pour les mettre à "lues".

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 :)