Modèles de commentaires et de notifications #18
Loading…
Reference in a new issue
No description provided.
Delete branch "Aufinal/communication_models"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
En plus du changement du
.gitignore
qui ne suit désormais plus les*.pyc
voici les modifications apportés par cette MR.Modification mineures dans les modèles déjà présents
amount
àEquipementRemark
pour indiquer le nombre d'équipement concerné par cette remarque.verbose_name
.Nouvelles dépendances
Gestion des souscriptions aux notifications
Placé dans l'application
communication
, les modèlesUserSubscription
etGroupSubscription
permettent de sauvegarder les souscriptions par utilisateur et groupe.Pour autoriser la souscription à des instances de modèle, celui-ci doit hériter du mixin
SubscriptionMixin
.Gestion des instances de modèles optionnellement relatives à un événement
Les modèles dont les instances peuvent être spécifiques à un événement ou de niveau "root" (c'est à dire non-spécifique) héritent du mixin
EventSpecificMixin
.Voilà voilà,
@lstephan @narmanli @delobell
changed the description
added 1 commit
6f158638
- Various bugfixesCompare with previous version
Si je comprends bien,
Notifying
n'est pas supposée être utilisée tel quel mais doit être implémentée par une sous classe (et c'est probablement le cas deCommentable
aussi ?). Je pense qu'elles devraient abstraites pour éviter des créer des tables inutiles avec plein de foreign keys.On y avait pensé, mais le problème est que les classes
Thread
etNotification
pointent versCommentable
etNotifying
, donc elles vont nécessiter une table quoi qu'il arrive.Quand on regarde le code sans les explications, l'intérêt d'avoir une classe
Commentable
qui hérite deNotyfing
sans rien modifier n'est pas clair. Je suppose que c'est séparé pour éventuellement étendreCommentable
à l'avenir. Pourrait-on avoir une docstring / un commentaire d'une ou deux lignes max pour préciser ça ?Le principe, c'est que les commentaires doivent provoquer une notification, donc
Commentable
est une sous-classe deNotifying
. Effectivement, ça peut être précisé.Ça c'est pas clair du tout pour moi : à quoi correspondent les deux fk vers
Notifying
?Notification
peut utiliser uneGenericForeignKey
etNotifying
deviendrait abstrait.Il faudrait voir si un manager serait plus adapté pour les commantaires.
Dans un genre similaire,
taggit
fait ça :Le modèle
Comment
aurait besoin d'uneGenericForeignKey
.J'ai l'impression que
get_url
ne fait que décaler le problème.On pourrait plutôt mettre en place une redirection de
/notif/<notif_id>
vers ce que renvoitget_absolute_url
de l'instance reliée à la notification.Je crois qu'il faut aussi
null=True
pour unDateTimeField
.Il faudrait remplacer par :
added 1 commit
af75c90b
- Refactor communication modelsCompare with previous version
added 2 commits
19093d01
- Small fixes4e887322
- OopsCompare with previous version
added 2 commits
270e31f1
- adapt migrations and testsda75dc7d
- Test + small changesCompare with previous version
added 1 commit
5b005571
- Event ending_date no longer optionalCompare with previous version
added 2 commits
53d9084d
- Correct Activity inheritance and get_herited()670a9d45
- Use EventSpecificMixin for event-specific modelsCompare with previous version
added 5 commits
master
3439abe9
- Merge branch 'master' of git.eleves.ens.fr:cof-geek/GestionEvenementiel into Auf…Compare with previous version
added 2 commits
8a587b3d
- Override attribution save() + stuffef8c6283
- MigrationsCompare with previous version
added 1 commit
782cb34b
- Change get_herited methodCompare with previous version
changed the description
resolved all discussions
merged
mentioned in commit
110e23a8d2