Skip to content

Game Requests

60plus edited this page Jul 12, 2026 · 2 revisions

Game Requests

Game Requests is the built-in wishlist board. It lets anyone on the server ask for a game that is not in the library yet, and it lets everyone else upvote the requests they would most like to see added. An administrator then works through the list, marking each request approved, rejected, or done. It is a top-level feature reachable from the main navigation by every role, not an admin-only tool.

Submitting is deliberately low-friction: instead of typing raw text, you search external metadata sources (IGDB, RAWG, LaunchBox, ScreenScraper, and your own GOG library) right from the request dialog and pick the matching title, so the request lands with a proper name, year, and cover art attached.

Contents

Where to find it

Game Requests is a top-level destination in the main navigation, alongside the Library, and it is available to every role. Opening it takes you to the requests board at /requests. A submit dialog is also reachable from elsewhere in the app (for example a "Request" action), and it opens straight onto the same board once you have submitted.

The requests navigation entry carries a small badge:

  • an administrator (or editor) sees the number of requests still pending a decision, and
  • any user sees a badge when the status of one of their own requests changes (from pending to approved, rejected, or done) since they last looked.

Submitting a request

Anyone can file a request from the Request a game dialog. The dialog handles two kinds of request, chosen by the context it was opened from:

  • a Games request - a normal PC / library title, and
  • a ROMs / Emulation request - a retro title for a specific console, which adds a platform picker (you must choose the platform before you can submit).

Searching for a title

As you type a title (from three characters up) the dialog searches external metadata sources and shows matching games as picker cards with cover, year, developer, and the source it came from. Picking a card fills in the title and, when the source provides them, auto-fills the store/reference link and a description. You can always skip the suggestions and type the request in by hand.

Which sources are searched depends on the request type:

Request type Sources searched
Games IGDB + your synced GOG library + RAWG
ROMs / Emulation ScreenScraper + IGDB + LaunchBox, scoped to the chosen platform

Only sources you have configured are queried - a source with no API key or credentials is simply skipped, and the remaining sources still return results. See Scrapers & Metadata for how each provider is set up. Results from all sources are merged and de-duplicated by title (your own GOG library first for Games requests), and the best matches are shown.

What you fill in

A request stores a small set of fields:

Field Notes
Title Required. The game you want (max 255 characters).
Platform Games or ROMs / Emulation; ROM requests also record the specific console.
Description Optional free text, for example why you want it or which edition (max 2000 characters).
Link Optional reference URL, for example the store or database page (max 512 characters).
Cover Taken from the suggestion you picked, so the request shows artwork on the board.

Submitting creates the request with the status pending and stamps it with your username, then drops you onto the board's list so you can see it and start collecting votes.

The requests board

The board lists every request on the server (not just your own) so the whole community can see what has been asked for and rally behind it. Each row shows the vote control and count, the title, a status badge, a platform badge, the description and link, any administrator note, and who requested it and when.

Two filter groups sit above the list:

  • Status - All, Pending, Approved, Done, or Rejected.
  • Platform - All libraries, Games, or Emulation.

The list is sorted by vote count (most-wanted first), so popular requests rise to the top. Requests that are done or rejected are visually dimmed so open requests stand out.

Voting

Voting is how the community signals what to build next. Any user can upvote any request with the vote button on its row.

  • A vote is an upvote only - there is one vote per user per request.
  • Once you have voted, the button locks; you cannot vote twice on the same request (a second attempt is rejected), and there is no downvote.
  • The running total is shown next to the button and drives the board's default sort order.

Request statuses

A request moves through a fixed set of four statuses. This is the exact set the board and the API accept.

Status Meaning
pending Newly submitted and awaiting a decision. Every request starts here.
approved An administrator has accepted the request and intends to add the game.
rejected An administrator has declined the request.
done The game has been added / the request is fulfilled.

Triaging requests (admin)

Working through the list is an administrator action. On each request row an administrator sees extra controls that other users do not:

  • a status dropdown to move the request between the four statuses above,
  • a note editor to attach an administrator note (for example the reason for a rejection, or which library the game was added to), shown on the request for everyone, and
  • a delete control to remove a request entirely.

Changing a request's status (or adding a note) is what drives the status-change notification described below. Deleting a request removes it and its votes; it is a clean removal, not a status.

The status, note, and delete actions are governed by the requests.write permission. That permission belongs to the Editor, Uploader, and Admin roles, but the built-in requests board only surfaces the triage controls to administrators. See Users & Permissions for the role and scope model.

Requesting from My GOG

If you have connected your own GOG account, the request dialog gains a My GOG tab listing the games you own on GOG. From there you can request any of your owned titles in one click, without searching - the request is created with that game's title and cover already attached. This is the same Game Requests -> My GOG surface described in GOG Integration; use it to ask an administrator to download and publish a game you own so it joins the shared Library.

Notifications

Game Requests can notify by both chat webhook and email so you do not have to watch the board:

  • New request - when anyone submits a request, a "New Game Request" message goes out (blue embed), with the requester, platform, and description. The email is sent to the administrators (plus any Notification recipient).
  • Status change - when an administrator changes a request's status, a message goes out in the status colour (approved green, rejected red, done purple), including the decision and any administrator note. The email is sent to the requester, so they hear the decision on their own request.

Both channels fire only when their respective section is enabled and the Game requests trigger is on; the webhook uses your shared Discord/JSON endpoint and the email uses the shared SMTP server. The per-status wording is customisable with message templates on either channel. See Email & Notifications for setup, the template editor, who receives what, and the placeholders ({title}, {username}, {status}, {platform}, {note}, {description}) these messages use.

Who can do what

Action User Editor Uploader Admin
View the requests board + + + +
Search scrapers and submit a request + + + +
Request an owned title from My GOG + + + +
Upvote a request + + + +
Change status, add a note, delete +

Submitting and voting need the requests.read permission, which every role has. The triage row is shown to administrators on the board; at the API level the write actions require requests.write (Editor role and above), as noted above.

API reference

All routes are prefixed with /api/requests.

Method + path Purpose Access
GET /search Search external sources for title suggestions (q, type=games|roms, platform_slug) Read
GET "" List all requests with vote counts and your own vote flag Read
POST "" Create a request (title, platform, optional description, link, platform_slug, cover_url) Read
POST /{id}/vote Upvote a request (one per user; repeat vote is rejected) Read
GET /notify Badge counts: pending total (admins) and your own requests' statuses Read
PATCH /{id} Change status and / or admin_note Write
DELETE /{id} Delete a request Write

Here Read is the requests.read permission (every role) and Write is requests.write (Editor role and above).

Example - list the board:

curl -H "Authorization: Bearer <token>" \
  "https://your-host/api/requests"

Next: Library - GOG Integration - Email & Notifications

Clone this wiki locally