django-jira is a complete rewrite of Chris Northwood's original project. This uses Django's use of the Python logging framework. It will automatically create a JIRA issue whenever an exception is encountered.

If there is a problem communicating with the JIRA service, then it falls back to Django's admins and emails them the original exception as well as the traceback for the problem with the JIRA location.

Requires: jira-python (Django, obviously. Version 1.4+ recommended)

To install, run:

python setup.py install

Then configure your logging settings. Here is an example LOGGING dictionary:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'filters': {
        'require_debug_false': {
            '()': 'django.utils.log.RequireDebugFalse',
        },
    },
    'handlers': {
        'jira': {
            'class': 'django_jira.log.JiraHandler',
            'level': 'ERROR',
            'filters': ['require_debug_false'],
            'server_url': 'http://localhost:2990/jira/',
            'auth_type': "basic",
            'user': "django",
            'password': "jira_pwd",
            'issue_defaults': {
                    "project": {"key": "JIRA"},
                    "issuetype": {"id": "1"},
            },
            'reopen_closed': (4,6),
            'reopen_action': 3,
            'wont_fix': 2,
            'comment_reopen_only': False,
        },  
    },  
    'loggers': {
        'django.request': {
            'handlers': ['jira'],
            'level': 'ERROR',
        },  
    }   
}

The following is further information about the settings under the "jira" handler. The values shown above are the default values unless otherwise specified.

server_url:

A URL with trailing slash to the JIRA install (e.g., http://www.example.com/jira/).

auth_type:

Either None, "basic" or "oauth". This currently isn't implemented and the software only supports BASIC authentication or None.

user:

The username of the user to log in to JIRA as. If omitted, no user will be passed in. If auth_type is set to None, this will be ignored.

password:

The password of the user to log in to JIRA as. If omitted, no password will be passed in. If auth_type is set to None, this will be ignored.

issue_defaults:

A dictionary of the settings to use when creating a JIRA issue, e.g.:

{
    'project': {"key": 'JIRA'},     # The project code inside JIRA
    'type':    {"issuetype": "1"} # The Name of the issue type to be created.
}

The above are required.

watchers:

A sequence of watchers to add to the issue if creating a new issue.

reopen_closed:

If an exception is raised and an issue is closed is in any of the states indicated by this setting, it will be reopened. Set to an empty tuple to disable, otherwise (4,6) is 'Resolved' and 'Closed' in a default JIRA install.

reopen_action:

The ID of the action to apply in JIRA to reopen an issue that is closed (by default '3' is Reopen Issue).

wont_fix:

The ID of the "Won't Fix" resolution, Django - JIRA won't reopen tickets with this resolution.

comment_reopen_only:

If set to True, then JIRA will only add a comment if the issue was reopened, otherwise, nothing occurs.

no_view_full_stack:

If the message exc_info argument is given, no_view_full_stack evaluates as True, and no Django view can be resolved, then include the whole stack trace, not just the Traceback's stack trace up to the point of the exception handler. If the message exc_info argument is not given, no_view_full_stack evaluates as True, and no Django view can be resolved, then include the whole stack trace, from the caller of the logger method. This may be useful to capture more context for your exception handling code.

Additionally, the following keys passed in the extra mapping to the logger method (logger.error(), logger.exception(), etc.) will affect the behavior of the individual message.

full_stack:

If full_stack evaluates as True, then the stack trace behavior of no_view_full_stack above described above will take effect regardless, even if a Django view could be resolved.

The RequireDebugFalse filter is useful here so that if you're debugging your application, it won't submit a ticket for every exception. The filters configured in the LOGGING dictionary above are set up for just that. If you would like your application to submit a JIRA even in DEBUG, you may just remove the "filters" key from the "jira" section under handlers.