Produits Entr'ouvert » Corbo

Déjà j'utiliserai django-rest-framework sauf si tu veux redévelopper du code de validation de signature.

Pour le reste on colle trop à l'existant, donc je ne pense pas que la notion de canal soit utile, on devrait l'avoir déjà dans identifier en utilisant des schémas d'uri (tel:, mail:, etc..), et on se retrouve avec SubscriptionType et Subcription qui font la même chose. Mais c'est le futur, pour l'instant on va ignorer complètement les SMS on verra plus tard.

Il faut un seul modèle Subscription:

class Subscription(models.Model):
     category = FK(Category)
     identifier = URLField(blank=True)
     uuid = CharField(max_length=128, blank=True)

dans les appels au web-service si uuid est passé on l'enregistre, sinon on ne met rien. Lors des notifications de provisionning on pourra chercher des abonnements par uuid et éventuellement corriger les abonnements de type mailto: ou tel: en fonction. Pour l'abonnement homepage (en fait la génération d'un flux RSS) on met uuid et pas d'identifier.

Donc j'étendrai la cellule abonnement de combo pour envoyer aussi le uuid dans la query string, ensuite dans get_subscriptions j'utiliserai le queryset Subscription.objects.filter(Q(identifier="mailto:" + email)|Q(uuid=uuid)) dans tous les cas je mets homepage dans les transports (si on est abonné il n'y aucune raison de ne pas voir les news sur sa homepage) et si subscription.identifier == "mailto:" + email je renvoi aussi le transport "email". Attention à bien utiliser get_or_create(), s'il existe déjà un abonnement pour cet email mais sans uuid, on le met à jour avec l'uuid.

Dans update_subscription idem, si j'ai email je crée un abonnement avec un identifier mailto: et un uuid (si j'en ai un) et si j'ai juste homepage je ne crée un abonnement qu'avec uuid, si aucun transport je supprime toutes les abonnements ayant cet email ou cet uuid pour la catégorie concernée.

mobile et mail ne sont pas des identifiants de scheme d'URL valides, j'enlèverai complètement le fichier channels.py, j'ignorerai complètement qu'on pourrait un jour envoyer des SMS et je mettrai en dur les deux transports qui existent vraiment, soit "homepage" et "email".

class NewslettersView(APIView):
    def get(self, request):
        newsletters = []
        transports = [{'id': 'email', 'text': _('Email')}, {'id': 'homepage', 'text': _('Homepage')}]
        for c in Category.objects.all():
            newsletter = {'id': str(c.pk), 'text': c.name, 'transports': transports}
            newsletters.append(newsletter)
        return Response({'data': newsletters})

Si email alors identifier = "mailto:" + email (on met ce code en dur dans update_subscriptions), voilà tout.

def update_subscriptions(self, category_id, transports, email=None, uuid=None):
    uuid = uuid or u''
    identifier = u'mailto:' + (email or '')
    try:
        cat = Category.objects.get(pk=category_id)
    except Category.DoesNotExist:
        return

    subcriptions = cat.subcription_set

    if email:
        if 'email' in transports:
            subscriptions.get_or_create(identifier=identifier, uuid=uuid)
            if uuid:  # delete simple other email subscriptions
                subscriptions.exclude(uuid=uuid).filter(identifier=identifier).delete()
        else:
            subscriptions.filter(identifier=identifier).delete()
    if uuid:
        if 'homepage' in transports:
            subscriptions.get_or_create(uuid=uuid)
        else:  # delete simple homepage subscriptions                                                                                                                           
            subscriptions.filter(identifier='', uuid=uuid).delete()

Il faudrait un index unique sur (category, identifier, uuid) sinon les get_or_create() vont foirer. Il faudrait mettre le décorateur @atomic sur cette méthode.

Benjamin Dauvergne a écrit :

mobile et mail ne sont pas des identifiants de scheme d'URL valides, j'enlèverai complètement le fichier channels.py, j'ignorerai complètement qu'on pourrait un jour envoyer des SMS et je mettrai en dur les deux transports qui existent vraiment, soit "homepage" et "email".

J'imaginais les classes dans channels.py avec ses méthodes send qui implementerait chacune son mode d'envoie, mais ok, partons sans pour l'instant

Non mort à l'abstraction.

Le champ channel sur Broadcast et AnnounceForm ne m'a plus l'air utile non plus, pour l'instant on broadcast vers des mails et c'est tout.