In Django, a view grants an editor 'newsroom.publish_article' and then calls has_perm() on the same user object, which returns False — why, and how do you fix it?

## The symptom A newsroom has a "promote to editor" view. It grants the custom permission `newsroom.publish_article` and then, in the same function, checks it to decide what to show next: ```python from django.contrib.auth import get_user_model from django.contrib.auth.models import Permission User = get_user_model() def promote(user_id): user = User.objects.get(pk=user_id) user.has_perm("newsroom.publish_article") # False; fills the cache perm = Permission.objects.get( codename="publish_article", content_type__app_label="newsroom" ) user.user_permissions.add(perm) return user.has_perm("newsroom.publish_article") # still False ``` The grant is in the database, yet the second check returns `False`. ## The cause: a per-instance cache in `ModelBackend` `django.contrib.auth.backends.ModelBackend` avoids re-querying on every check by **caching the permission set on the user object itself**. On the first check it runs the queries and stores Python sets of `"app_label.codename"` strings in private attributes: - `_user_perm_cache` — permissions granted directly through `user_permissions`; - `_group_perm_cache` — permissions inherited through `groups`; - `_perm_cache` — the union of both, used by `has_perm()`. Later checks on **the same instance** read the attributes and never query again. Nothing invalidates them: `user_permissions.add()`, `groups.add()` or a removal writes to the join tables but does not touch the cached sets, and Django sends no signal that clears them. The Django documentation adds a detail that catches most people: **`user.refresh_from_db()` does not clear the cache**. It reloads field values; the cache attributes are not fields, so they survive. ## Fixes 1. **Re-fetch the user.** `user = User.objects.get(pk=user.pk)` gives a new instance with no cache attributes; the next check queries fresh. This is the documented approach. 2. **Check before caching.** Reorder the code so no check runs on that instance until after the grant. 3. **Delete the private attributes.** Removing `_perm_cache`, `_user_perm_cache` and `_group_perm_cache` works today, but they are undocumented internals — prefer re-fetching. ## How far the staleness reaches The cache lives exactly as long as the Python object. That bounds the problem: | Situation | Stale? | |---|---| | Next HTTP request for the same user | No — the request's user is loaded as a new instance | | Later in the same request, same `request.user` object | Yes | | A test that grants then asserts on the same instance | Yes | | A long-running process holding one user object (a worker loop, a management command, a long-lived connection handler) | Yes, until re-fetched | It is **not** a cross-request or cross-process cache: it never touches the `CACHES` backends or the session. The same staleness applies to **revocation** — removing a grant does not affect an instance that already cached the old set, which matters in long-running code that should stop an editor mid-session. ## Two cases that never hit the cache - **Active superusers**: `PermissionsMixin.has_perm()` returns `True` before any backend runs, so granting or revoking has no visible effect either way. - **Inactive or anonymous users**: `ModelBackend` returns an empty set without caching anything. ## Choosing a fix in practice - **In a view that grants and then renders**, re-fetch the user after the grant and pass the new instance to the template or to later checks; do not keep using the stale one. - **When the granted user is `request.user` itself**, remember that `request.user` is the stale object for the rest of the request; reassigning it to a newly fetched instance is acceptable, but often the simpler answer is to redirect, so the next request loads the user afresh. - **In long-running code**, re-fetch the user (or at least re-check against a newly loaded instance) before any decision that must reflect a recent revocation, such as allowing a publish. - **In tests**, load a new instance by primary key after changing grants; avoid asserting on the object you used before the grant. Each of these costs one extra query at most, which is almost always cheaper than debugging a check that lies. ## Why tests are where this shows up Tests are the classic place to meet the cache, because a test naturally creates a user, checks, grants, and checks again on one object. A test that seems to prove "the grant does not work" is often proving the cache works. Re-fetch the user between the grant and the assertion, or assert on a new instance loaded by primary key.