# Build an Admin Page in a Django App

An agent builds an admin-only Django page for failed donation attempts, with date filters, permission tests and browser screenshots for team review.

[Run this on Rush](https://cloud.getrush.ai/run/build-admin-page/django/), in a Project that has your repository.

## What the agent does

The agent checks whether the data for the page exists before drawing a table. In [django/djangoproject.com](https://github.com/django/djangoproject.com/blob/HEAD/fundraising/models.py#L105-L134), `Donation` stores subscription details and `Payment` stores an amount, charge identifier and date. There is no failure status on that Payment model. [The failed-payment webhook handler](https://github.com/django/djangoproject.com/blob/HEAD/fundraising/views.py#L343-L359) finds a donation and sends an email, then returns without creating a failure record. A page that filters successful payments cannot honestly list failed attempts. The agent describes that gap and asks the team to approve the smallest durable recording change before presenting invented history.

It follows the existing admin rather than adding a second dashboard framework. [fundraising/admin.py](https://github.com/django/djangoproject.com/blob/HEAD/fundraising/admin.py#L65-L100) already registers donations and payments, uses date ordering and selects related donor data. The proposed page belongs with those registrations and uses the existing admin layout. If failure recording is approved, the implementation stores only the identifiers, timestamp and failure information needed for the list, with a defined duplicate-event policy. It does not retain a complete payment-provider payload, and it cannot reconstruct earlier failures that the application never saved.

The team reviews the field choices, date semantics and permission rule before the agent finishes the page. Put those instructions in the request, ask the agent to end its turn with the open decisions, then send a follow-up after the turn finishes. The API's session answer and transcript let reviewers inspect what it proposes; the follow-up resumes the same sandbox. The new view must check authorization on the server, not just hide its navigation link. The tests cover anonymous access, ordinary users, the approved administrator role, empty results and records on the date-filter boundaries.

The environment follows the repository's own checks. [requirements/tests.txt](https://github.com/django/djangoproject.com/blob/HEAD/requirements/tests.txt#L20-L21) pins Django `6.1.1`; [CI](https://github.com/django/djangoproject.com/blob/HEAD/.github/workflows/tests.yml#L38-L68) installs those requirements, prepares Postgres and Playwright browsers, and runs `make ci`. The agent starts with `python -m manage test fundraising` for the focused changes, checks for missing migrations with `make migrations-check`, and runs the broader supported checks. Browser screenshots use synthetic donation failures and demonstrate the populated list, date filtering and refusal case without exposing donor details.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Build an administrator-only page listing recent failed donation attempts with date filters. First inspect fundraising models, webhook handlers, existing admin registrations and tests. If failure history is not stored, propose the smallest recording change and end the turn waiting for a follow-up approving its fields, deduplication and retention; do not invent historical failures. After approval, follow the existing admin layout and enforce the approved admin role on the server. Test anonymous and non-admin refusal, no unauthorized data disclosure, date boundaries, empty state and duplicate events if recording changes. Use synthetic data for browser screenshots. Run the focused fundraising tests, migration checks and repository CI commands that the environment supports, reporting anything blocked. Ask before adding dependencies, preserve existing donation behavior, and open a pull request after verification.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

The pull request contains the admin page, permission and filtering tests, and any explicitly approved failure-recording migration and webhook change. Its description separates the visible page from the data collection needed to support it. It also states the earliest point from which failures are available, so a reviewer does not mistake missing historical records for a successful backfill.

Reviewers receive screenshots of synthetic rows and the relevant command results, not a claim that a run has already succeeded. They check that a normal user cannot retrieve the same records by requesting the URL directly, that date filters use the agreed timezone, and that webhook retries do not multiply failures. The transcript shows the team's approval before any extra data collection enters the diff.

## Run it on every approved admin-page request

Have your internal work-request automation send this body with the repository URL and the page's acceptance criteria. One request starts one implementation, rather than one run per failed donation. When the agent returns its schema or permission questions, collect the team's answer and send it through `POST /o/{org}/sessions/{id}/messages` after the turn has finished. A completion webhook can notify your own review system when the next turn is ready.

## Why run it on Rush?

A payment-administration change needs a database and browser that can hold synthetic failures without mixing them into an engineer's everyday development data. Rush gives this work its own sandbox and keeps the setup commands and output in the transcript. The team can evaluate the screenshot and the server-side permission tests together, instead of reviewing a table mockup with no trustworthy data source.

The same session can carry the implementation across a review pause. A finished turn parks the sandbox, and a follow-up wakes its retained state, so an approved field change can continue from the inspected work. That is useful when the real question is whether to collect a failure record at all, rather than how to style another admin row.

## Frequently asked questions

### Can it show donation failures that were never stored?

No, the example application's failed-payment handler only sends an email. The agent must identify an approved history source or add forward-looking recording, with the limitation stated in the pull request.

### Does admin-only mean every staff account gets access?

The team must define the allowed role before implementation. The tests should exercise that exact rule, including a staff account without the required permission when those roles differ.

### Can we review the data model before it changes?

Yes, the request asks the agent to finish a proposal turn first. Send approval as a follow-up after that turn, rather than trying to send a second API message while it is still running.

### Will browser screenshots expose real payment details?

This prompt requires synthetic records and forbids complete provider payloads in the new list. Review the generated images and the data fields before sharing them beyond the team.