> For the complete documentation index, see [llms.txt](https://tyrix.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://tyrix.gitbook.io/docs/script-resources/tyrix-frames/admin-panel.md).

# Admin Panel

`/frameadmin` opens a searchable table of **every canvas on the server**, across every routing bucket.

Access is granted by the `tyrix.frames.admin` ace or a framework admin group - see [Configuration → Admin access](/docs/script-resources/tyrix-frames/configuration.md#admin-access). Admin is re-checked server-side on open **and** on every individual action, so the panel cannot be driven by a client that fakes its way in.

## Header stats

Registry-wide counts, not just the page you are looking at:

| Tile        | Meaning                                            |
| ----------- | -------------------------------------------------- |
| Total       | Canvases placed server-wide                        |
| With photos | How many have a photo set                          |
| Owners      | Distinct characters owning at least one            |
| Buckets     | Distinct routing buckets in use                    |
| Per size    | A chip per canvas size - click one to filter by it |

## The table

| Column           | Notes                                                          |
| ---------------- | -------------------------------------------------------------- |
| Thumbnail        | The photo itself, or a blank placeholder                       |
| Owner            | Character name when online, plus the raw identifier underneath |
| Size             | Sortable in catalog order, not alphabetically                  |
| Bucket           | Routing bucket                                                 |
| Coords           | Rounded world position                                         |
| Placed / Updated | Timestamps                                                     |

Sort any column. Filter by owner (matches both the character name and the raw identifier), size, bucket, or whether a photo is set. Results are paginated at 50 rows — the whole table is never shipped to the UI at once.

Owner names are resolved for players who are **currently online**; offline owners show the identifier only, in italics.

## Row actions

| Action         | Effect                                                             |
| -------------- | ------------------------------------------------------------------ |
| **TP**         | Teleport you to the canvas, switching your routing bucket to match |
| **Wipe Photo** | Clear the photo, leaving the canvas in place                       |
| **Delete**     | Remove the canvas entirely. **No item is refunded**                |
| **Copy**       | Copy the owner identifier or the coordinates to your clipboard     |

Every one of these is Discord-logged with your player info attached, plus the frame owner's identifier as a separate field - see [Discord Logging](/docs/script-resources/tyrix-frames/discord-logging.md).

### Notes on TP

The teleport handles the bucket switch for you and rebuilds your replication window at the destination, so the canvas is loaded and visible the moment you arrive rather than after the next watcher tick.

### Notes on Delete

Delete is the blunt instrument - it is for canvases that should not exist, not for tidying. It gives the owner nothing back. If the owner should keep their item, ask them to pick it up, or use **Wipe Photo** if the problem is only the image.

## Moderation workflow

The panel is one half of moderation; Discord logging is the other.

`photo_set` embeds the image itself in the log, which means an admin scrolling the log channel sees exactly what was hung on a wall, with the frame id, owner and coordinates. That is usually faster than the panel for catching something, and the panel is then how you deal with it - filter by owner, wipe or delete.

There is no approval queue: photos go live immediately and moderation is after the fact. That is a deliberate design decision, not an oversight.

## Performance

The panel's queries run against the in-memory registry, not the database, so filtering and sorting cost no SQL. Stats and online-name lookups are cached for a couple of seconds because the panel refetches on a 300 ms debounce as you type - without that, one admin typing in the owner filter would re-scan the whole registry on every keystroke.