Implementing User-Scoped Next/Previous Navigation in a Django DetailView with Circular ORM Queries

Add next/previous navigation to a Django DetailView using ORM-only, user-scoped queries. Handle permissions, wrap circularly, and keep navigation secure.

Implementing next/previous navigation in a Django DetailView sounds trivial until permissions get involved. When a user can only see their own records, you can’t blindly jump by ID or iterate across the whole table. The goal is simple: navigate within the user’s allowed subset, keep it circular, and avoid preloading large structures like linked lists. Here’s a compact, ORM-native approach that achieves exactly that.

Problem setup

Suppose you render a list of entities and link each one to its detail page. The URL patterns might look like this, and the detail page is linked from a template:

urlpatterns = [
    path("records/", views.RecordListView.as_view(), name="records"),
    path("record/<int:pk>/", views.RecordDetailView.as_view(), name="record"),
]

href='{% url "record" obj.id %}'

The DetailView is straightforward:

class RecordDetailView(LoginRequiredMixin, DetailView):
    model = Record
    template_name = "record.html"

You want to render buttons on the detail page that jump to the next and previous records, staying within the current user’s scope, and wrapping around at the ends. The template might try to use something like this:

<a class='button' href='{% url "record" next_record_id %}'>Next</a>

The missing piece is how to provide next_record_id (and its previous counterpart) to the template without iterating over data you can’t access or building a linked list in memory.

Why this happens

The naive increment-by-ID trick fails because IDs aren’t guaranteed to be contiguous within the user’s dataset. Some IDs may belong to other users or not exist at all. Preloading a full list for each navigation is unnecessary overhead, especially when the database can compute the next/previous neighbors with simple, bounded queries. The cleanest solution is to ask the database for the nearest higher or lower ID within the user’s subset and fall back to the first or last item to keep navigation circular.

Solution: let the ORM do the work

Use two targeted queries to fetch the next and previous records relative to the current one. If there’s no “next” within the user’s records, wrap to the smallest ID. If there’s no “previous,” wrap to the largest ID. Add both IDs to the context and wire them in the template.

class RecordDetailView(LoginRequiredMixin, DetailView):
    model = Record
    template_name = "record.html"
    def get_context_data(self, **kwargs):
        payload = super().get_context_data(**kwargs)
        current = self.get_object()
        nxt = Record.objects.filter(
            user=self.request.user,
            id__gt=current.id
        ).order_by('id').first()
        prv = Record.objects.filter(
            user=self.request.user,
            id__lt=current.id
        ).order_by('-id').first()
        if not nxt:
            nxt = Record.objects.filter(user=self.request.user).order_by('id').first()
        if not prv:
            prv = Record.objects.filter(user=self.request.user).order_by('-id').first()
        payload['next_record_id'] = nxt.id if nxt else None
        payload['prev_record_id'] = prv.id if prv else None
        return payload

And in the template:

{% if prev_record_id %}
    <a class='button' href='{% url "record" prev_record_id %}'>Previous</a>
{% endif %}
{% if next_record_id %}
    <a class='button' href='{% url "record" next_record_id %}'>Next</a>
{% endif %}

Why this matters

This approach avoids loading or maintaining any in-memory sequence, which makes it resource friendly. It respects per-user visibility by constraining every lookup to user-scoped records. It also supports circular navigation without special data structures: the ORM queries are clear, predictable, and easy to maintain.

Conclusion

Next/previous navigation inside a Django DetailView doesn’t need linked lists or session-stored sequences. Query for the closest higher and lower IDs within the current user’s data and wrap around when you hit the ends. Keep the logic inside get_context_data, pass the computed IDs to the template, and render links only when they exist. The result is simple, secure, and efficient navigation across a user’s own records.