Hey guys, I needed to send drips via SMS, so I modified django drip to make things more generic and allow custom senders. After submitting this request I realized it would probably be better to create a new migration rather than edit existing ones. Before I do that though, I want to gauge interest. Is this even a feature you want? Here is the documentation for the new feature (also added to the README). I suppose some new screenshots would also be needed.

Custom Sender

If you want to send messages different from the default sender (SMTP), you can create a custom sender class that inherits from SenderBase. For example:

from drip.models import SenderBase

class CustomSender(SenderBase):
    # drip is the drip.drips.DripBase object which gives access to
    # from_address and from_address_name
    def send_message(self, drip, user, subject, body, plain):
        # Custom sending logic (SMS, in app messaging, snail mail, etc.)
        ...
        # Return a boolean indicating if the message was sent or not

After adding this table to the database using syncdb or a south migration, you will need to create an object of this type:

$ python manage.py shell
>>> from exampleapp.models import CustomSender
>>> sender = CustomSender()
>>> sender.name = 'My Custom Sender'
>>> sender.save()

Now when you create a Drip in the django admin you will have the option of selecting your own custom sender. When these Drips go out, django drip will send the message with your custom sender instead of the built-in method.

I have some querysets that generate many copies of each user. This adds an option to the drip to add .distinct() at the end of the queryset. I could be wrong, but I think it should default to True.

What do you guys think about allowing third party email content compilers to be used?

We currently use https://github.com/bradwhittington/django-templated-email for sending emails which is great (basically, you define the email in a django template file which can extend other templates, and send the email by referencing the template's filename).

The issue is it would make the easiest case harder probably, unless optional subject_template and body_html_template fields are left in the Drip model.

Other, less wasteful (no optional TextFields) options:

1. I could be to make a OneToOneField from a new model DripEmailTemplate to Drip and add it as an Inline to the Drip admin in addition to an optional "template_name" field to send to django-templated-email.
2. It may also be harder for the easiest case, but DripEmailTemplate could be referenced from a optional ForeignKey in Drip which would allow you to have multiple Drips use the same DripEmailTemplate

I'd be willing to take on this project but wanted to see if I could get it to work for more than just us.

Hello Zapier,

Great fan of your work! I am just curious as to the thought process behind the DRIP_FROM_EMAIL setting. Is there a reason why the from email is static? I figured you would want to be able to change the from email depending on the drip campaign unless I am missing a key point? Forgive me if there is something blatantly obvious.

P.S. As per usual for github users, I would be happy to contribute code if there is interest in a non-static from email and if it abides by the wishes of the project maintainers.

Does django-drip support Python 3?

If so, it would be nice to designate that on PyPI using classifiers in setup.py (see https://pypi.python.org/pypi?%3Aaction=list_classifiers)

If not, what does the path forward look like?

I apologize if I'm mistaken, but it looks like you're using the template source and not the rendrered template for the HTML version of the email body.

See drips.drip:122

# check if there are html tags in the rendered template if len(plain) != len(body): email.attach_alternative(self.body_template, 'text/html')

It should reference the body local variable not self.body_template.

I lack the ability to unsubscribe from the emails sent by drip. We're about to start using it for our customers, but anticipate that certain users will want to unsubscribe.

Is this something that could be integrated with Drip, or handled separately? How do others do it?

I forked budlights repository and then added the ability to use F expressions in field values.

Bud lights comments aren't very explanatory but he has made some worthwhile improvements.

Having updated to Django 1.5 and migrated my profile information onto an extended User model, drip does not allow my app to start:

django.core.management.base.CommandError: One or more models did not validate:
drip.sentdrip: 'user' defines a relation with the model 'auth.User', which has been swapped out. Update the relation to point at `settings.AUTH_USER_MODEL`.

May I suggest the following, in models.py:

try:
  from settings import AUTH_USER_MODEL
except:
  AUTH_USER_MODEL = 'auth.User'

...

user = models.ForeignKey(AUTH_USER_MODEL, related_name='sent_drips')

Use __count for a field name and then treat define the rest of the rule normally. In QuerySetRule.apply, the queryset is annotated behind the scenes and then the filter is applied.

I wasn't sure how best to update the docs. This patch should apply cleanly to master, even though it was written against several other patches.

This isn't a problem with django-drip==0.1.3, only with the latest source. Steps to reproduce:

$ mkvirtualenv testpip
$ pip install mock -e \
git+https://github.com/zapier/django-drip.git#egg=django-drip
$ python

>>> from mock import patch
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name patch

• [ ] Update testing infrastructure.
  • [x] Use Tox
  • [x] Move tests out of the package.
  • [x] Lint code base.
    • [x] Run flake8 during CI.
    • [x] Run isort during CI.
  • [ ] Add coverage support.
• [ ] Adjust Django version supports.
  • [ ] Add support for Django 1.8.
  • [ ] Drop support for Django < 1.8.
  • [ ] Add support for Django 1.8+.
• [ ] Update documentation.
• [ ] Release 1.0.

In utils.py at following line its hard to understand its like "tuple + tuple + list". fields = Model._meta.fields + Model._meta.many_to_many + Model._meta.get_all_related_objects() This is caused me error so I converted it to tuple(Model._meta.get_all_related_objects()). However now I am getting error with following traceback:

File "C:\Users\Mudassar\dressikarepo\lib\site-packages\django\core\handlers\base.py" in get_response
  132.                     response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "C:\Users\Mudassar\dressikarepo\lib\site-packages\django\contrib\admin\options.py" in wrapper
  616.                 return self.admin_site.admin_view(view)(*args, **kwargs)
File "C:\Users\Mudassar\dressikarepo\lib\site-packages\django\utils\decorators.py" in _wrapped_view
  110.                     response = view_func(request, *args, **kwargs)
File "C:\Users\Mudassar\dressikarepo\lib\site-packages\django\views\decorators\cache.py" in _wrapped_view_func
  57.         response = view_func(request, *args, **kwargs)
File "C:\Users\Mudassar\dressikarepo\lib\site-packages\django\contrib\admin\sites.py" in inner
  233.             return view(request, *args, **kwargs)
File "C:\Users\Mudassar\dressikarepo\lib\site-packages\drip\admin.py" in add_view
  83.             request, extra_context=self.build_extra_context(extra_context))
File "C:\Users\Mudassar\dressikarepo\lib\site-packages\drip\admin.py" in build_extra_context
  78.         extra_context['field_data'] = json.dumps(get_simple_fields(User))
File "C:\Users\Mudassar\dressikarepo\lib\site-packages\drip\utils.py" in get_simple_fields
  121.     return [[f[0], f[3].__name__] for f in get_fields(Model, **kwargs)]
File "C:\Users\Mudassar\dressikarepo\lib\site-packages\drip\utils.py" in get_fields
  98.                 RelModel = field.related.parent_model

Exception Type: AttributeError at /admin/drip/drip/add/
Exception Value: 'ManyToManyRel' object has no attribute 'parent_model'

I am using djagno 1.8.5. Please advise.

I'm running Django 1.8.4 and cannot run tests. I also needed to install a forked version of django drip just to get it to run - see issue #51. I've looked through the app to try to figure out where this might be but it's beyond me.

Trying to to run tests produces:

Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
    utility.execute()
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 330, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/core/management/commands/test.py", line 30, in run_from_argv
    super(Command, self).run_from_argv(argv)
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/core/management/base.py", line 393, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/core/management/commands/test.py", line 74, in execute
    super(Command, self).execute(*args, **options)
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/core/management/base.py", line 444, in execute
    output = self.handle(*args, **options)
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/core/management/commands/test.py", line 90, in handle
    failures = test_runner.run_tests(test_labels)
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/test/runner.py", line 210, in run_tests
    old_config = self.setup_databases()
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/test/runner.py", line 166, in setup_databases
    **kwargs
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/test/runner.py", line 370, in setup_databases
    serialize=connection.settings_dict.get("TEST", {}).get("SERIALIZE", True),
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/db/backends/base/creation.py", line 368, in create_test_db
    test_flush=not keepdb,
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 120, in call_command
    return command.execute(*args, **defaults)
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/core/management/base.py", line 444, in execute
    output = self.handle(*args, **options)
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 179, in handle
    created_models = self.sync_apps(connection, executor.loader.unmigrated_apps)
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 318, in sync_apps
    cursor.execute(statement)
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/db/backends/utils.py", line 64, in execute
    return self.cursor.execute(sql, params)
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/db/utils.py", line 97, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/home/vagrant/Envs/gitjobs/local/lib/python2.7/site-packages/django/db/backends/utils.py", line 62, in execute
    return self.cursor.execute(sql)
django.db.utils.ProgrammingError: relation "auth_user" does not exist