2.0.1 (October 13, 2025)

Bugfixes

• Improve performance by not always prefetching channels and target

This fixes performance for the common use case where people don't use Notification.target to dynamically generate the notification text. By always prefetching the target field, it was a performance penalty for everyone. Now you need to explicitly prefetch the target field yourself. See performance.md for more information.

Always prefetching the channels relationship didn't make sense since users don't normally display these fields.

Documentation Changes

• Fixed "prefetch deeper relationships" documentation to make it clear it's not just a matter of not being "efficient" with heterogeneous targets - it literally doesn't work
• Link from the multilingual docs to the performance docs

2.0.0 (October 12, 2025)

Improvements

• Moved the actual sending of emails within EmailChannel to its own method. This makes it easy to subclass the EmailChannel and handle the sending via Celery for example, without having to repeat all the other logic of the EmailChannel. (closes #12)
• The digest sending has been moved to its own send_notification_digests function. This is used by the send_digest_emails command (renamed to send_notification_digests) but can easily be used to start the digest sending via other means, in case you don’t want to use Django’s management command and/or a cron job (closes #9)
• Replaced the global sent_email_at tracking with a per-channel delivery status via a new NotificationChannel model (closes #16)
• Renamed classes and methods to remove "email" terminology and make them channel-agnostic (closes #15)
• Enhanced channel architecture to support digest-only and realtime-only channels

Documentation changes

• Split the giant readme into multiple smaller files (closes #14)
• Added migration documentation for 2.0.0

Breaking changes

Class renames

• Renamed NotificationChannel -> BaseChannel
• Renamed NotificationFrequency -> BaseFrequency

Model changes

• Renamed EmailFrequency model to NotificationFrequency model

Method renames

• Renamed NotificationType.default_email_frequency -> NotificationType.default_frequency
• Renamed NotificationType.set_email_frequency -> NotificationType.set_frequency
• Renamed NotificationType.get_email_frequency -> NotificationType.get_frequency
• Renamed NotificationType.reset_email_frequency_to_default -> NotificationType.reset_frequency_to_default

Command and function renames

• Renamed the send_digest_emails command to send_notification_digests

API changes

• The get_notification_preferences function now returns notification_frequency instead of email_frequency
• The process method moved from individual channel implementations to the BaseChannel class, and calls either send_now or send_digest

1.4.0 (October 11, 2025)

New Features

• Prefetch the target generic relationship by default (on Django 5.0+) (#11 by kevinrenskers)

Documentation Changes

• Include section on Admin Integration
• Added documentation for multi-lingual notifications

1.3.0 (August 13, 2025)

New Features

• Include an absolute link to notification.url in the default emails

1.2.1 (August 13, 2025)

Bugfixes

• Fix pluralization issue in the digest emails (no more "1 new notifications")

1.2.0 (August 11, 2025)

New Features

• Add a proper apps.py file with a proper verbose_name

1.1.1 (August 4, 2025)

Bugfixes

• Prevent circular dependencies when your own models import our types

1.1.0 (August 3, 2025)

New Features

• Include user preference helpers with the library (#3 by kevinrenskers)
• Added helper methods to NotificationType (#4 by kevinrenskers)

1.0.0 (August 1, 2025)

This is a complete rewrite of django-generic-notifications. It keeps the same generic idea but much more flexible and modern. The last release was before Django even had migrations - it still used South!

• The NotificationEngine has been renamed to NotificationRegistry but behaves mostly the same.
• Backends have been renamed to channels, and we now ship with 2: website and email.
• Notification types work in much the same way, except for allowed_backends we now have required_channels.

New features:

• The website channel means it's now very easy to show notifications on the website.
• Email digest with custom frequencies (daily, weekly).
• Notification grouping.
• Cleaned up and simplified. For example there's no more built-in queue, as it's not needed for the built-in channels. This allows people building custom channels to write their own processing functions that behave however they want.
• Unit tests 🎉
• Example project

0.2.2 (February 5, 2012)

• New timed queue, send notifications after a certain time
• The default types and backends are no longer registered by default, the developer needs to do this explicitly