- About Pinax
- Overview
- Documentation
- Change Log
- History
- Contribute
- Code of Conduct
- Connect with Pinax
- License
Pinax is an open-source platform built on the Django Web Framework. It is an ecosystem of reusable Django apps, themes, and starter project templates. This collection can be found at http://pinaxproject.com.
pinax-eventlog is a simple app that provides an easy and clean interface for logging diagnostic as well as business intelligence data about activity that occurs in your site.
By default this app writes directly to the database.
For small sites, it should be good enough to use inline but you might want to consider wrapping calls to the log() method and queue them in
a job manager like celery or pyres so that the calls become asynchronous.
| Django \ Python | 2.7 | 3.4 | 3.5 | 3.6 |
|---|---|---|---|---|
| 1.11 | * | * | * | * |
| 2.0 | * | * | * |
To install pinax-eventlog:
$ pip install pinax-eventlogAdd pinax.eventlog to your INSTALLED_APPS setting:
INSTALLED_APPS = [
# other apps
"pinax.eventlog",
]Run the app's migrations:
$ python manage.py migrate eventlogUsing pinax-eventlog is pretty simple. Throughout your site, you just call a single function, log() to record whatever information you want to log. If you are wanting to log things from third party apps, your best bet is to use signals. Hopefully the app in question provides some useful signals, but if not, perhaps some of the built in model signals will be enough (e.g. pre_save, post_delete, etc.)
Example:
from pinax.eventlog.models import log
def some_view(request):
# stuff is done in body of view
# then at the end before returning the response:
log(
user=request.user,
action="CREATED_FOO_WIDGET",
obj=foo,
extra={
"title": foo.title
}
)
return HttpResponse()The action parameter can be any string you choose. By convention, we
always use all caps. Take note, however, whatever you choose, will be the
label that appears in the admin's list filter, so give it some thought on
naming conventions in your site so that the admin interface makes sense
when you have 50,000 log records you want to filter down and analyze.
The extra parameter can be anything that will serialize to JSON. Results
become easier to manage if you keep it at a single level. Also, keep in
mind that this is displayed in the admin's list view so if you put too much
it can take up a lot of space. A good rule of thumb here is put enough
identifying data to get a sense for what is going on and a key or keys
that enable you to dig deeper if you want or need to.
You can also easily make your class based views auto-logged by using the
pinax.eventlog.mixins.EventLogMixin. The only requirement is defining an
action_kind property on the view. But you can also override a number of
properties to customize what is logged.
There is a signal that you are setup a receiver for to enable you to trigger other actions when an event has been logged:
event_logged provides an event object as an argument that is the event that
was just logged.
- Use SET_NULL so Log instances are not deleted when related object is deleted
- Update runtests.py
- Update CI configuration
- Update jsonfield requirement
- fix setup.py LONG_DESCRIPTION for PyPi
- Standardize and improve documentation
- Add Django 2.0 compatibility testing
- Drop Django 1.8, 1.9, 1.10 and Python 3.3 support
- Convert CI and coverage to CircleCi and CodeCov
- Add PyPi-compatible long description
- Move documentation to README.md
- Fix spelling error in documentation
- Added wheel release
- Dropped 3.2 support
- Added missing migration from the switch to jsonfield
- Started testing against Django master
- Switched to
jsonfieldfromdjango-jsonfield - Added ability to link a log to any object via a GFK
- Added ability to override timestamp
- Fixed template fragment path
- Eldarion donated to Pinax, renaming from
eventlogtopinax-eventlog
- added the ability to link content objects you are logging about
- added property to provide template fragment name
- Add mixin for making it easy to audit CBV
- removed non-working templatetag
- update setup to work with Python 3.3+
- remove pusher integration
- support for custom user model
- added the
event_loggedsignal - corrected typo in usage documentation
- attempts at fixing admin performance
- attempts at fixing admin performance
- attempts at fixing admin performance with an index on action
- attempts at fixing admin performance with an index on timestamp
- update setup.py to use install_requires instead of setup_requires
- made the extra argument optional
- improve the admin
- use
django.utils.timezone.nowinstead ofdatetime.datetime.nowfor timestamp
- when a user is deleted set FK to null instead of losing data
- bumped version on django-jsonfield
- added docs
- initial release
This project was originally named eventlog and was created by the team at Eldarion. It was later donated to Pinax and at that time renamed to pinax-eventlog.
For an overview on how contributing to Pinax works read this blog post and watch the included video, or read our How to Contribute section. For concrete contribution ideas, please see our Ways to Contribute/What We Need Help With section.
In case of any questions we recommend you join our Pinax Slack team and ping us there instead of creating an issue on GitHub. Creating issues on GitHub is of course also valid but we are usually able to help you faster if you ping us in Slack.
We also highly recommend reading our blog post on Open Source and Self-Care.
In order to foster a kind, inclusive, and harassment-free community, the Pinax Project has a code of conduct. We ask you to treat everyone as a smart human programmer that shares an interest in Python, Django, and Pinax with you.
For updates and news regarding the Pinax Project, please follow us on Twitter @pinaxproject and check out our Pinax Project blog.
Copyright (c) 2012-2019 James Tauber and contributors under the MIT license.