Generate generic activity streams from the actions on your site. Users can follow any actors' activities for personalized streams.

The overall functionality to store actions via signals seems to work nicely in Django 1.11, but trying to use the activity_stream and display_action templatetags I came across some small things that are broken due to changes in 1.11.

• actstream/templatetags/activity_tags.py, line 96:

  return render_to_string(templates, context)
  

  Context is a django.template.context.Context instance here, but in 1.11 it must be a simple dict,

  return render_to_string(templates, context.flatten())
  

  would possibly fix that, haven't fully tested it yet.

• actstream/urls.py, top of the file:

  try:
      from django.conf.urls import url, patterns
  except ImportError:
      from django.conf.urls.defaults import url, patterns
  

  The patterns() function is not available anymore, either the url patterns need some rework or you'd have to provide your own vendorized version. In 1.9 it says:

  django.conf.urls.patterns() is deprecated and will be removed in Django 1.10. Update your urlpatterns to be a list of django.conf.urls.url() instances instead.

• actstream/views.py: All usage of render_to_response() is a problem, see https://docs.djangoproject.com/en/1.11/releases/1.10/

  The dictionary and context_instance parameters for the following functions are removed: django.shortcuts.render() django.shortcuts.render_to_response()

The changelog tells me that the latest, officially supported Django version is 1.9. Are there any plans yet to extend support to Django 1.10+?

Hi. I just found about django-activity-stream. As a newbie, to create something like activity feeds in not a good idea. So I was very excited to use django-activity-stream. But I felt that the documentation was not up to what I can understand to. It was not so hard to grasp the idea behind. But "how-to" do x to get y, was a bit exhausting for me. I installed it, and added the app in my settings, and then I was lost! It would be really great, if the documentation was improved from a newbie's point of view. Best wishes! Thank you.

Consider such a signal which aims to create an activity when a user registers:

def user_registered_activity(sender, **kwargs):
    if not kwargs.get('created', False):
        return None
    action.send(kwargs['instance'], verb='registered')
signals.post_save.connect(user_registered_activity, 
    sender=models.get_model('auth', 'user'))

Well guess what happens when the user is deleted: the actions are not.

To keep our database sane, i use this snippet:

def delete_object_activities(sender, **kwargs):
    """
    This signal attempts to delete any activity which is related to Action
    through a generic relation. This should keep the Action table sane.
    """
    Action.objects.filter(
        action_object_object_id=kwargs['instance'].pk,
        action_object_content_type=ContentType.objects.get_for_model(
                                                        kwargs['instance'])
        ).delete()
    Action.objects.filter(
        actor_object_id=kwargs['instance'].pk,
        actor_content_type=ContentType.objects.get_for_model(
                                                        kwargs['instance'])
        ).delete()
    Action.objects.filter(
        target_object_id=kwargs['instance'].pk,
        target_content_type=ContentType.objects.get_for_model(
                                                        kwargs['instance'])
        ).delete()
signals.pre_delete.connect(delete_object_activities)

In general, i'd recommend to just add the full snippet to actstream:

from django.db.models import signals                                               
from django.db import models
from django.contrib.contenttypes.models import ContentType                         

from actstream import action                                                       
from actstream.models import Action                                                

def user_registered_activity(sender, **kwargs):                                    
    if not kwargs.get('created', False):                                           
        return None
    action.send(kwargs['instance'], verb='registered')                             
signals.post_save.connect(user_registered_activity, 
    sender=models.get_model('auth', 'user'))

def delete_object_activities(sender, **kwargs):
    """
    This signal attempts to delete any activity which is related to Action         
    through a generic relation. This should keep the Action table sane.            
    """     
    Action.objects.filter(
        action_object_object_id=kwargs['instance'].pk,                             
        action_object_content_type=ContentType.objects.get_for_model(              
                                                        kwargs['instance']) 
        ).delete()                                                                 
    Action.objects.filter(
        actor_object_id=kwargs['instance'].pk,
        actor_content_type=ContentType.objects.get_for_model(                      
                                                        kwargs['instance'])        
        ).delete()
    Action.objects.filter(                                                         
        target_object_id=kwargs['instance'].pk,                                    
        target_content_type=ContentType.objects.get_for_model(                     
                                                        kwargs['instance'])        
        ).delete()
signals.pre_delete.connect(delete_object_activities)

hi. I'm expecting troubles with actor_stream(request.user).

for example:

from actstream.models import actor_stream, Action
print actor_stream(request.user)[0].target # returns None
print Action.objects.all()[0].target # returns Target object

BUT:

from actstream.models import actor_stream, Action
print request.user.actor_actions.all()[0].target  # returns Target object

User model - this is a custom user model, configured as described in djangoproject tutorial. Target model looks like this:

class Task(models.Model):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
    user = models.ForeignKey('core_auth.User', blank=True, null=True)
    ... < more fields >

Let me show you:

>>> from actstream.models import actor_stream, Action
>>> from core_auth.models import User
>>> u = User.objects.get(username='fynjah')
>>> actor_stream(u)[0].target # None
>>> x = actor_stream(u)[0]
>>> x
<Action: fynjah changed status DONE 58 minutes ago>
# BUT:
>>> x.target_content_type
<ContentType: Task>
>>> x.target
>>> x.target_object_id
u'f08ae5ab-8c07-4929-9021-62c867f0d081'
# AND:
>>> u.actor_actions.all()[0].target
<Task: wdstrm compositing>

What am i doing wrong :\

This is more of a suggestion: I am using Userena with actstream, and I am not at all sure if I did this right to register the User model.

class StubsConfig(AppConfig):
    name = 'stubs'

    def ready(self):
        registry.register(self.get_model('Band'))
        registry.register(self.get_model('Concert'))
        registry.register(self.get_model('Location'))
        from django.contrib.auth.models import User
        registry.register(User)

Either way it would be nice to mention in the docs the right way to register the user model.

Hi,

I just noticed an error that when you try to use any Django feature that joins GFK enabled models with other models (e.g. having GenericRelation defined on that model with some related_query_name), it produces an SQL error (PostgreSQL).

Let's take this example model:

class Post(models.Model):
    content = models.TextField(blank=True, null=True)
    position = models.PositiveSmallIntegerField(default=0, blank=True, editable=False)
    action_set = GenericRelation('actstream.Action', object_id_field='action_object_object_id', content_type_field='action_object_content_type', related_query_name='post')

We are using https://docs.djangoproject.com/en/1.8/ref/contrib/contenttypes/#reverse-generic-relations here with a related_query_name defined to help sorting/filtering activity streams based on this generic related model (Post) attributes. At this point, a query like below would produce some SQL error:

target_stream(another_object).order_by('post__position')

The error produced, in particular by PostgreSQL backend is:

operator does not exist: character varying = integer

Further investigation reveals that because you are using CharField for GenericForeignKey's PK/ID part, and because by convention other Django models use PositiveIntegerField for their primary keys, Django's SQL compiler is NOT type casting the JOIN clause. Thus, the JOIN is failing from SQL backend due to an attempt to JOIN by (varchar == int) clause.

I have successfully mitigated this issue by replacing your CharField definitions with PositiveIntegerField definitions. So, please have a look at my commit and let's discuss if there's any compelling reason to stick to CharFields.

Thanks, Shanto

This package is currently importing JSONfield from either django-jsonfield + django-jsonfield-compat or django_mysql, however the django-jsonfield/django-jsonfield-compat combination only supports up to django 1.9.

I can make a PR for importing from the current preferred location, django.contrib.postgres.fields, but I just need to know if you'd also want to continue support for django =< 1.9 and therefore allow import from the existing packages.

I am not a mysql user, but it appears no change is needed there, and importing from django_mysql is still the preferred method.

Hello!

I have created own model Notification. There is foreign key to actstream Action:

class Notification(models.Model):
    user = models.ForeignKey(User)
    action = models.ForeignKey(Action)
    is_read = models.BooleanField(default=False)

And when I run manage.py makemigrations myapp django creates one more migration for actstream. Here it is:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals
from django.db import migrations, models

class Migration(migrations.Migration):

    dependencies = [
        ('actstream', '0001_initial'),
    ]

    operations = [
        migrations.RemoveField(
            model_name='action',
            name='data',
        ),
    ]

So what should I do?

Can I migrate it? But in which way will I migrate it in deploy?

What

This PR adds optional support for django-mysql's JSONField (supported by MySQL 5.7+) to be used instead of the already supported django-jsonfield and Django TextField fallback.

Why

We are using MySQL and django-mysql's JSONField already and would like to use this library without having to rely on a different JSONField implementation. See https://github.com/justquick/django-activity-stream/issues/415

How

The new actstream.jsonfield module is responsible to choose a suitable JSONField implementation on startup:

• USE_JSONFIELD = True and django-jsonfield + django-jsonfield-compat installed: Use that.
• USE_JSONFIELD = True and django-mysql installed: Use that instead.
• USE_JSONFIELD = False: TextField Fallback is used.

A debug print like JSONField implementation is: <class 'django_mysql.models.fields.json.JSONField'> is done on startup to be able to manually check whether the correct implementation is chosen.

Testing

There already is a test named TestAppTests.test_jsonfield() that checks that attaching data to the JSONField works as intented, making that pass is the goal.

I have updated the tox configuration to use django-mysql for the sql environments instead of django-jsonfield. Please see https://tox.readthedocs.io/en/latest/config.html#complex-factor-conditions for syntax.

I have done local test runs with Python 2.7 and 3.7 against Django 1.11 and 2.1 using SQLite and MySQL 5.7:

tox -e py27-django111-mysql
tox -e py27-django111-sqlite
tox -e py27-django21-mysql
tox -e py27-django21-sqlite
tox -e py37-django111-mysql
tox -e py37-django111-sqlite
tox -e py37-django21-mysql
tox -e py37-django21-sqlite

Hey every one (@justquick),

I have a django app and now I want to introduce django-activity-stream to notify users from events.

My issue is that I can not filter actions by actor or target:

python3.5 shell

>>> from app import models
>>> a = models.MyAppUser.objects.all()[1]
>>> a
<MyAppUser: Mark>
>>> t = models.MyAppUser.objects.all()[2]
>>> t
<MyAppUser: Steve>
>>> from actstream.models import Action
>>> Action(actor=a, verb='POST', target=t)
<Action: Mark POST Steve 0 minutes ago>
>>> Action.objects.filter(actor=a)

Error:

Traceback (most recent call last):
  File "/.../lib/python3.5/site-packages/django/core/management/commands/shell.py", line 69, in handle
    self.run_shell(shell=options['interface'])
  File "/.../lib/python3.5/site-packages/django/core/management/commands/shell.py", line 61, in run_shell
    raise ImportError
ImportError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/.../lib/python3.5/site-packages/django/db/models/manager.py", line 122, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/.../lib/python3.5/site-packages/django/db/models/query.py", line 790, in filter
    return self._filter_or_exclude(False, *args, **kwargs)
  File "/.../lib/python3.5/site-packages/django/db/models/query.py", line 808, in _filter_or_exclude
    clone.query.add_q(Q(*args, **kwargs))
  File "/.../lib/python3.5/site-packages/django/db/models/sql/query.py", line 1243, in add_q
    clause, _ = self._add_q(q_object, self.used_aliases)
  File "/.../lib/python3.5/site-packages/django/db/models/sql/query.py", line 1269, in _add_q
    allow_joins=allow_joins, split_subq=split_subq,
  File "/.../lib/python3.5/site-packages/django/db/models/sql/query.py", line 1149, in build_filter
    lookups, parts, reffed_expression = self.solve_lookup_type(arg)
  File "/.../lib/python3.5/site-packages/django/db/models/sql/query.py", line 1035, in solve_lookup_type
    _, field, _, lookup_parts = self.names_to_path(lookup_splitted, self.get_meta())
  File "/.../lib/python3.5/site-packages/django/db/models/sql/query.py", line 1316, in names_to_path
    "adding a GenericRelation." % name

django.core.exceptions.FieldError: Field 'actor' does not generate an automatic 
reverse relation and therefore cannot be used for reverse querying. 
If it is a GenericForeignKey, consider adding a GenericRelation.

The output of my pip freeze is:

app==0.0.1
coverage==4.2
dj-database-url==0.4.1
**Django==1.9.5**
**django-activity-stream==0.6.3**
django-anymail==0.5
django-bootstrap-breadcrumbs==0.8
django-bootstrap-datepicker==1.1.1
django-bootstrap3==7.1.0
django-bower==5.1.0
django-configurations==2.0
django-debug-toolbar==1.5
django-formtools==1.0
django-nose==1.4.4
django-postman==3.3.2
factory-boy==2.7.0
fake-factory==0.7.2
flake8==3.0.4
mccabe==0.5.2
nose==1.3.7
Pillow==3.3.1
psycopg2==2.6.2
pycodestyle==2.0.0
pyflakes==1.2.3
python-dateutil==2.6.0
PyYAML==3.12
requests==2.11.1
rollbar==0.13.6
six==1.10.0
sqlparse==0.2.1
whitenoise==3.2.1

Similar like issue 281

I just cobbled this together taking inspiration from django.contrib.auth – it's actually working quite well with minimal effort – my apps tests pass with this, the hidden swappable API is neat.

I mostly need input on the changes made and what you want to do about various BC considerations if this is something you'd be interested in merging.

some thoughts

• [x] AbstractAction
• [x] AbstractFollow
• [x] Django migration handling (swappable handles this)
• [ ] Strip 0002 migration?
• [ ] Scrap JSON support entirely and leave it to developers?
• [ ] South migration handling (no idea... suggestions?)
• [ ] convenient accessors in models (real models aren't available yet... lazy objects?)
• [ ] various other calls to get_model that can/should probably go
• [ ] extra kwargs passed to action.send currently pile into data as per existing implementation - I think as of this work any extra kwargs passed should be assumed to be fields on the model – developers can retain existing behaviour by passing a data dict data={'some':'thing'}

usage example (working my end)

# settings.py
ACTSTREAM_ACTION_MODEL = 'users.Action'
ACTSTREAM_FOLLOW_MODEL = 'users.Follow'

# users/models.py
from actstream.models import AbstractAction, AbstractFollow
from django.contrib.postgres.fields import JSONField
from django.db import models
from uuid import uuid4


class Action(AbstractAction):
    id = models.UUIDField(primary_key=True, default=uuid4, editable=False)
    data = JSONField(default={})

    class Meta(AbstractAction.Meta):
        db_table = 'ras_actions'


class Follow(AbstractFollow):
    id = models.UUIDField(primary_key=True, default=uuid4, editable=False)

    class Meta(AbstractFollow.Meta):
        db_table = 'ras_follows'

migrations

We discussed migrations in the other thread briefly. If you didn't know / remember (I didn't) the way the swappable behaviour works is to default to using the provided migrations. However, if the developer has supplied their own model class, your migrations are totally disabled, and instead they are generated in the developer's app.

What this means moving forward beyond merging this is that anyone using the default model will run any new migrations you write. However, anyone else will simply inherit the new field via abstract model, and will be required to generate their own migration (simply by running makemigrations) – thus it's their problem, this is consistent with django.contrib.auth and a fairly reasonable behaviour.

related issues

#304 #306

Hi there,

In our use case we want to delete Follow objects when the followed object is deleted. We implemented that with Django pre_delete signal, and we thought that this piece of code was generic enough to maybe be integrated in actstream.

What do you think @justquick ? Maybe it could be conditioned to a setting if you don't want this behavior to be applied to everyone.

If you agree I can submit a PR today :wink:

Hello,

first of all everything is working like a charm! I was just wondering if and how i can only display action objects that are distinct. I dont want to i.e., show duplicate comments if they have for example a different actor and target but the user is following both. I added a GenericRelation on the action object I want to filter distinct but I get a cast error. I will provide more info once I debugged further, just wanted to ask if this is even possible so I dont waste no more time on this issue.

Br, Johannes

• Dynamic serializers and viewsets for the registered models in the actstream.registry
• Default config for Action/Follow
• Views to match (most) streams in the action manager
• Ability to view your own actions
• Custom serializer, viewset and permission options in settings
• Related field evaluation using rest-framework-generic-relations

not ready for merge yet

#502 #286

We need to update the app to provide the up to date spec for v2.0 AS

https://www.w3.org/TR/activitystreams-core/#example-1

It's been 11 years since the 1.0 was first introduced so we are behind the times