Basic functionality ideas: unsubscribe one-time-link generation, and emailing to group targets

[RNCTX]

Hello! I'm glad someone has taken up an "official" fork of the original django-drip project, it's still quite useful.

I forked it myself awhile back from, in turn, another fork that had taken up Python 3.x compatibility and added a few basic features for a non-profit's implementation last year. They were using Wagtail so note there are two branches in this repo, one for Django stock and one for Wagtail.

https://github.com/RNCTX/django-drip

I implemented a couple of extra bits of functionality that I think you guys should think about doing as well.

1. Unsubscribe one-time links

One obvious feature missing from the original drip project was unsubscribe links. Since the bulk of the usage for such a component as this will be marketing email, one-click unsubscribe links are necessary for regulatory and email relay service policy compliance. I implemented this using django's internal password-reset token generating function, PasswordResetTokenGenerator, run against the UID, a timestamp of the email being sent, and the user's subscription status.

I then integrated it into django-drip by manually adding it to the template context object via {{ unsubscribe }}, like so...

RNCTX/django-drip@0358b02

Then a simple matter of providing an unsubscribe view/template page that checks the token and returns either a success template or a failure (invalid token) template, and a function unsubscribe_token that generates a django email password reset token with the django password reset link generator functions included in the base, and checks the validity of said tokens...

from users.tokens import unsubscribe_token

User = get_user_model()

def unsubscribe(request, uidb64, token):
    try:
        uid = urlsafe_base64_decode(uidb64).decode()
        user = User.objects.get(email=uid)
    except (TypeError, ValueError, OverflowError, User.DoesNotExist):
        user = None
    if user is not None and unsubscribe_token.check_token(user, token):
        user.subscribe = False
        user.save()
        return render(request, 'account/unsubscribe.html')
    else:
        return render(request, 'account/invalid.html')

Along with a urls.py of:

urlpatterns = [
	#Unsubscribe link generation
	path('unsubscribe/<uidb64>/<token>/', views.unsubscribe, name='unsubscribe')
]

This results in a sufficiently obscure one-time link such as...

https://url.domain.net/unsubscribe/cm9iZXJ0bmNsYXl0b25AZ21haWwuY29t/5ep-c908e346ac45558f9eed/

As you can surmise from the above the org was using a modified user model that replaced integer UIDs with email UIDs and email logins. All of this obviously entails modifying the default user model as a requirement, to add a "subscribed" boolean field of either true or false. I implemented this in the drip context by modifying the default modeladmin for the drip UI in the django/wagtail admin panels to always provide "user.subscribed" = "True" as the first condition to any drip template they might create like so:

RNCTX/django-drip@2e3d050#diff-4bd8c971fa717dbf4acb76dd2e24893ca8e03afd59caa558040235ff4ccccf7d

...and adding the https://{{ unsubscribe }} dynamically generated context link to their base drip email template, like so (beginning on line 130 at the bottom):

RNCTX/django-drip@8ba7f4b#diff-4bd8c971fa717dbf4acb76dd2e24893ca8e03afd59caa558040235ff4ccccf7d

2. Emailing to groups of users as a drip target

Django does not provide anything in the base functionality to my knowledge that allows emailing to a group of users, which is unfortunate considering django does come with group permissions out of the box. To facilitate targeting emails to groups of users for the organization I implemented this for (not necessarily just drips, but all email), I modified their django-post-office installation to loop over users in a group at send time:

RNCTX/django-post_office@1aa4464

I know this is getting out of the scope of this fork by including another project, in my case the org wanted the ability to send emails to groups of staff outside of the context of drips as well. But it might be possible to subclass the Django "mail" functions/classes and maintain compatibility with replacement mailers such as django-post-office which provide identical functionality, although I didn't look into that rather than just modifying the mailer in my case, which was the quicker/dirtier/easier solution.

At the very least, a one-click query button to "only target a specific group with this drip" which helped the admin user make a drip that only worked on one group of users would be useful, since the default Django user/group implementation invites people to make use of groups, and create new groups to drop user signups into (like "customers" or "donors" or "subscribers" or "loyalty_program_members" or other such obvious marketing groups).

[brunomichetti]

Hello @RNCTX , thank you for showing us these features. We will try to implement them in the future.
About "Unsubscribe one-time links", we have discussed to unsubscribe from a campaign-level instead of a user-level unsuscribe. With that, a user can be unsubscribed from a campaign and subscribed to another. WDYT?

[RNCTX]

That was a bit further into the weeds than I was tasked with (especially considering free work donated to a non-profit who wasn't paying me for this implementation), and after thinking about it I explained to my users the considerations and left them with a single catch-all and some explanations of caveats and considerations.

I think this consideration would depend on how the marketing/comms admin uses drip emails. That's not obviously apparent, and is the beauty of drip emails as a concept... they can be less maintenance by the marketing/comms person, because they can be "set and forget" and still capture new users without any manual distribution list maintenance.

In short, it's possible that the marketing/comms admin doesn't want categories at all, and I would offer them the ability to not have them if they don't want them.

If I were to go back and implement distribution lists, I would implement them as a first-step before any other filter. I would add distribution lists in front of every other drip function, so that when created a drip email could (boolean) "belong" to a set number of arbitrary categories (or all categories) that also exist as booleans for subscription status in the user model. That would also fit within the current admin framework by allowing a page where the marketing/comms admin could sort their drip list by category the drips belong to.

I think adding subscription status within the orderable inline drip filters could quickly get too complex for non-developers to use effectively.

In the case of those having distribution list categories my method of generating the links would still work fine, since django handles the auth via its password reset token generating function, and the token is separate from any actual user model methods you choose to execute in the view. I think redirecting the user to a one-time profile login that shows them a form with their email list category subscriptions which can be checked/unchecked and saved would be the proper way at that point.

I based my implementation on the excellent guide on repurposing the password reset token functionality in the django base explained in this blog post:

https://archive.is/P2yIX

[RNCTX]

Oh, and while this is on my mind as I'm implementing my fork into another project today...

The unfortunate thing with providing unsubscribe templates for multiple distribution lists is there is no generic/preferred way to render a user profile. I would guess that the bulk of Django projects are using django-allauth for authentication with a (recommended by that package) custom user model, and they do not provide a default profile view.

One thing you guys might look into with that in mind is the django-sekizai package used by DjangoCMS. It gives you the ability to add template blocks at a set position, and deduplicates redundant content. By using sekizai you could prepend anaccount/profile.html template with an email distribution list subscription block full of boolean selections, that the user could easily override in their project templates by rearranging the placement block. Sekizai is otherwise benign, it won't do anything to templates that its tags aren't loaded into.