django-slick-reporting: dashboards as declarative Django classes

A report is a class, and its attributes are the output

Django Slick Reporting is described as the reporting engine for Django, for creating dashboards and standalone reports and charts. The tagline is that every report is one small declarative class, and the promise is that grouped totals, time series, crosstabs and charts are declared once and generated for you, so that changing one line of the class gives you a completely different report.

The mechanism is a class that inherits from ReportView. Every attribute on it maps to a visible part of the output. There is a report_model naming the model to report over, a date_field, a group_by, a list of columns, and a chart_settings list describing the chart. The library assembles a filter form, the chart, a sortable table and a CSV export from those attributes, and the documentation notes that the report view is added to the URLconf with a single path entry, so the whole feature is one class and one line of routing.

That is the design decision worth understanding, and it is a different bet from a charting library. A charting library gives you a chart; this gives you an entire report view, which means the query, the filters, the table and the export all have to agree with each other. The payoff is that a dashboard for a new aggregate is a class, not a view, a template and a URL.

The cost is that the shape of the report is one of a small number of shapes. The docs cover list views, custom querysets, precomputed crosstabs and time-series combined with crosstabs as further options, and the examples in the readme show three of them: a group-by, a time series and a crosstab. A report that does not fit one of those shapes is a fight with the library.

The project is BSD-3-Clause licensed, published on PyPI as django-slick-reporting, and the default branch is develop with the readme linking the repository under the ra-systems organisation.

One class, three shapes, and the line that changes between them

The readme makes its point by changing one line at a time on the same SalesTransaction model, and that progression is the clearest available description of the API.

The first version is a group-by report. It sets report_model to SalesTransaction, date_field to the date field, and group_by to product, with a columns list that includes a plain field and a ComputationField created with Sum over the value field, named value__sum with the verbose name Total sold $. The chart_settings list holds a Chart for that column with Chart.BAR as the type, data_source pointing at value__sum and title_source at name.

The second version changes one line. group_by becomes client instead of product, and the result is the same report regrouped, with the columns and the chart untouched. The examples make clear that group_by accepts any field or relation path.

The third version adds two lines rather than changing one. time_series_pattern is set to monthly and time_series_columns holds the computation, and the chart type changes from BAR to LINE. The pattern accepts daily, weekly, yearly or a custom pattern, and the output becomes one column per month computed per period.

The fourth shape is the crosstab. crosstab_field names the column dimension, crosstab_columns holds the computation for the cells, and the columns list adds the literal string __crosstab__ alongside the total column. The result is products as rows, clients as columns, and totals at the intersections.

Two implementation details are visible in the code. The computation is created through a factory, ComputationField.create, with the aggregate class, the source field, a name and a verbose name, and the name is what the chart refers to in data_source. And the crosstab is inserted into the columns list as a special marker string, which is a slightly different style from the rest of the declarative approach.

The readme also states the broader set of shapes: list views, custom querysets, precomputed crosstabs and time-series combined with crosstabs, all documented at the readthedocs site.

Charts come from the same class, and the engine is swappable

The second half of the design is that the visualisation is a property of the report rather than a separate object you build.

The rule is that the calculation is declared once and the visualisation is switched by changing a single argument, with no new query and no new template. The chart types shown in the documentation include the bar, line and other forms referenced in the examples, and the engine itself is set with chart_engine on the report or on an individual Chart.

That engine setting is the part that matters for adoption, because it decides whether you have a hard dependency. Three engines are named: Highcharts with chart_engine set to highcharts, Chart.js with chartsjs, and ApexCharts with apexcharts. The same data renders through whichever engine you choose, and the report class does not change.

This is a real advantage over the usual pattern, where a report view renders a template that embeds a specific charting library's JavaScript and therefore commits the project to that library. With this arrangement the aggregation is in Python and the rendering is in JavaScript, and the seam between them is the data_source and title_source lists.

The pivot table support is visible in the topic list, and the charts come with line and bar types in the examples, so the library covers the common analytics shapes: totals by category, movement over time, and a matrix of one dimension against another.

For the install, the project shows a single command:

pip install django-slick-reporting

and the runtime requirements file lists Django, python-dateutil at 2.8.1 or newer, pytz, simplejson, and django-crispy-forms, which is what renders the filter form the report generates.

Where django-slick-reporting is the wrong choice

The first limitation is that the report is a fixed shape. Group by, time series and crosstab are the vocabulary, and a report that needs something else, a running total, a difference between two periods, a percentile, a cohort analysis, a filtered aggregate over a window function, is not a class you can write. The documentation lists custom querysets as an option, and that is the escape hatch, but at that point you are writing the query yourself and the library is providing the table and the export.

The second is that you do not control the markup. A generated view and its generated template are the point, and a team with a strict design system, a house table component, or a translation workflow that assumes its own templates cannot easily use them. The library solves the report problem, not the presentation problem, and for many teams those are the same problem.

The third is the dependency list, and it is longer than the feature list suggests. django-crispy-forms is a rendering framework dependency that comes with its own opinions about form markup, python-dateutil and pytz are date handling dependencies, and simplejson is there presumably for a consistent JSON implementation. A project that already has a date library, a form rendering approach and a JSON policy now has to reconcile three of them.

The fourth is the charting engines. Supporting Highcharts, Chart.js and ApexCharts is generous, but each of those is a JavaScript library with its own licence, its own build step and its own version, and the Python side has to produce data shaped the way that engine expects. The flexibility is real, and so is the maintenance of three integrations rather than one.

The fifth is project maturity and naming. The repository lives under the RamezIssac organisation, while the readme badges and links point at ra-systems, which is a sign of a project that has moved or is maintained under a different name. The default branch is develop, the releases are v1.5.0 from 2026-10-14, v1.4.0 from 2026-05-02 and 1.3.1 from 2024-06-16, and the last push was on 2026-10-14. The version numbers below 1.4.0 do not carry the v prefix while the newer ones do, which is a small inconsistency but a hint that the packaging changed recently.

Editorial conclusion

django-slick-reporting fits a Django team whose stakeholders want dashboards and the developers who are tired of hand-writing a view, a template and a chart for each one, since a report class generates the filter form, the table, the chart and the export together. It is the wrong choice if you need full control of the rendered markup, and it is the wrong choice if your aggregation logic does not fit a group-by, a time series or a crosstab, since those three shapes are what the library generates. Before adopting it, define one report class by hand and check that its output matches what your users expect, and note that the last push was on 2026-10-14 with version 1.5.0 released the same day.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. RamezIssac/django-slick-reporting on GitHub
4. README
5. Releases