Produits Entr'ouvert » Combo

Je n'avais pas lu le ticket lié, les derniers patchs font en sorte qu'un ack() sur une notification sans fin fasse aussi un forget() (on pourrait vouloir faire varier cela, par exemple plutôt qu'un forget donner un end_timestamp proche comme 1 jour).

Je viens de pousser ça dans wip/22732-notifications-without-expiration-rebase, à relire parce que rebase délicat.

Notamment parce que ça m'a fait relire des patchs passés genre https://dev.entrouvert.org/attachments/24576/0001-lingo-fix-notifications-expiration-for-expired-invoi.patch où je ne comprends toujours pas pourquoi l'ajout d'une facture à ignorer (c'est le cas que le commit corrige) ajoute malgré tout une notification au compte final.

Et réponse de Serghei à ça, c'est parce que dans le test (non visible), il y a un passage qui modifie les dates,

        for username in FAKE_PENDING_INVOICES['data']:
            for invoice in FAKE_PENDING_INVOICES['data'][username]['invoices']:
                invoice['pay_limit_date'] = new_pay_limit_date

Comme ce passage est supprimé dans ces tests introduisant freezegun, il apparait donc normal que le compte de notification passe de 3 à 2.

La property Notification.visible ne tiens pas compte d'en éventuel end_timestamp à None.

Notification.ack peut se re-écrire en :

def ack(self):
        if self.end_timestamp:
            self.acked = True
            self.save(update_fields=['acked'])
        else:
            self.forget()

Et donc j'essaie de résumer le comportement que l'on obtiens ici : une notification sans expiration est visible ad vitam eternam tant qu'elle n'est pas 'ack' ou 'forget' ces deux actions devenant strictement équivalentes pour une notification de ce type.

Je manque de contexte pour comprendre si c'est bien ça que l'on veut mais si c'est bien ça alors très bien.