PLAN_REDESIGNS §2, the Rust half (D164, D192, D332, D333):
- rust.template.kit_weekend (core registerEventTemplates, MODULE_API 1.13.0):
inputs kit/minutes/message/delivery; one phase advance after the weekend,
core.lease rust.group.permission default/<kit permission> + rust.kit.entitle
linked. Steps only where the kit can use them; validated by the real core.
- rust.kit.entitle: recipients 'linked' (every linked player who has played
on the server, no tally, refused past the bound), optional message ({kit})
and delivery, stored per row (rust_perm_run_grants.notice*).
- perm.sync notices: the untold set to the picked account, keyed
run:step:user, in the digest; the report's noticesTold marks them told.
- rust.options.grouppermissions notes a kit's permission rows via kits.uses
(cached a minute per server; a failure is no note).
- duration: 'minutes' on rust.zone.open and rust.participation.open; the
group-permission lease's value example is true.
- protocol 13 -> 14, coreApi ^1.13.0; ci/core-ref.json pinned to website#212's
head while it is open; engagement-triggers.json regenerated (coreApi line).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
222 lines
8.2 KiB
JavaScript
222 lines
8.2 KiB
JavaScript
// ── SQL, and nothing else ─────────────────────────────────────────────────
|
|
//
|
|
// The `.db.js` half of the pair (see `servers.db.js` for why the split earns its
|
|
// keep). Raw parameterised SQL through `core.query`, placeholders always.
|
|
|
|
const core = require('../../core')
|
|
|
|
const LINKS = 'rust_account_links'
|
|
const PLAYERS = 'rust_players'
|
|
const STATS = 'rust_player_wipe_stats'
|
|
const EVENTS = 'rust_events'
|
|
|
|
/**
|
|
* The link for one Steam id, or undefined.
|
|
*
|
|
* Joins core's `users` for the username, because every caller that asks "who
|
|
* owns this?" wants a name rather than an integer — and the one caller that
|
|
* refuses a re-link has to be able to say *whose* it is.
|
|
*/
|
|
async function getBySteamId(steamId) {
|
|
const rows = await core.query(
|
|
`SELECT l.steam_id AS steamId, l.user_id AS userId, l.name, l.server_id AS serverId,
|
|
l.linked_at AS linkedAt, u.username
|
|
FROM ${LINKS} l
|
|
JOIN users u ON u.id = l.user_id
|
|
WHERE l.steam_id = ?`,
|
|
[steamId],
|
|
)
|
|
return rows[0]
|
|
}
|
|
|
|
/**
|
|
* Every Steam account one website user holds, newest first.
|
|
*
|
|
* **It joins `rust_players` for the name the game last saw**, and that is not a
|
|
* convenience. The name on the LINK is what the player was called at the moment
|
|
* they linked, which is a Rust name and changes on a whim — so a player who has
|
|
* renamed since sees a name they no longer use, on the one page of the site that
|
|
* is about who they are. The admin panel already preferred the newer one; this
|
|
* is the same rule applied where the person themselves is reading.
|
|
*
|
|
* A LEFT JOIN, because a player can link an account and never play on it.
|
|
*/
|
|
async function listForUser(userId) {
|
|
return core.query(
|
|
`SELECT l.steam_id AS steamId, l.user_id AS userId, l.name, l.server_id AS serverId,
|
|
l.linked_at AS linkedAt, p.name AS playerName
|
|
FROM ${LINKS} l
|
|
LEFT JOIN ${PLAYERS} p ON p.steam_id = l.steam_id
|
|
WHERE l.user_id = ?
|
|
ORDER BY l.linked_at DESC`,
|
|
[userId],
|
|
)
|
|
}
|
|
|
|
/**
|
|
* Record a link.
|
|
*
|
|
* **A plain INSERT, never an upsert**, and that is the whole of D23 expressed in
|
|
* SQL. `ON DUPLICATE KEY UPDATE` here would silently move a Steam id from one
|
|
* website account to another — which, once phase 7 makes a link a privilege path
|
|
* and phase 13 makes it an entitlement, is an account takeover performed by
|
|
* typing a six-character code. The duplicate-key error is the refusal, and the
|
|
* controller turns it into a sentence.
|
|
*/
|
|
async function insert({ steamId, userId, name, serverId }) {
|
|
await core.query(
|
|
`INSERT INTO ${LINKS} (steam_id, user_id, name, server_id)
|
|
VALUES (?, ?, ?, ?)`,
|
|
[steamId, userId, name || null, serverId || null],
|
|
)
|
|
}
|
|
|
|
/**
|
|
* Remove a link the caller owns.
|
|
*
|
|
* Scoped by `user_id` in the statement rather than checked before it: a delete
|
|
* that reads, decides, then writes has a gap between the read and the write, and
|
|
* this way the ownership test and the deletion are the same operation. Answers
|
|
* how many rows went, so a caller can tell "removed" from "was not yours".
|
|
*/
|
|
async function removeOwned(steamId, userId) {
|
|
const result = await core.query(
|
|
`DELETE FROM ${LINKS} WHERE steam_id = ? AND user_id = ?`,
|
|
[steamId, userId],
|
|
)
|
|
return Number(result && result.affectedRows) || 0
|
|
}
|
|
|
|
/**
|
|
* Remove a link whoever holds it — the in-game `/unlink` path, and the staff
|
|
* unlink on the `admin.users.detail` panel (D25).
|
|
*
|
|
* Unscoped by user on purpose: neither caller is the link's owner and both have
|
|
* already established their authority another way. In game the authority is the
|
|
* Steam account itself — whoever is connected as it is who it is; on the admin
|
|
* panel it is the tier gate. Which is why the admin caller writes an
|
|
* `activity.log` entry naming the operator and this does not: it cannot tell the
|
|
* two apart, and a log line that guessed would be worse than none.
|
|
*/
|
|
async function removeBySteamId(steamId) {
|
|
const result = await core.query(`DELETE FROM ${LINKS} WHERE steam_id = ?`, [steamId])
|
|
return Number(result && result.affectedRows) || 0
|
|
}
|
|
|
|
/**
|
|
* Every link one user holds, enriched with what this module knows about that
|
|
* player — for the `admin.users.detail` panel.
|
|
*
|
|
* A LEFT JOIN, because a player can link an account and never play on it. An
|
|
* operator looking at that user should see the link, not an empty panel.
|
|
*/
|
|
async function listForUserWithPlayer(userId) {
|
|
return core.query(
|
|
`SELECT l.steam_id AS steamId, l.name, l.server_id AS serverId, l.linked_at AS linkedAt,
|
|
p.name AS playerName, p.first_seen AS firstSeen, p.last_seen AS lastSeen
|
|
FROM ${LINKS} l
|
|
LEFT JOIN ${PLAYERS} p ON p.steam_id = l.steam_id
|
|
WHERE l.user_id = ?
|
|
ORDER BY l.linked_at DESC`,
|
|
[userId],
|
|
)
|
|
}
|
|
|
|
/**
|
|
* Per-server all-time totals for one Steam id.
|
|
*
|
|
* The same rows the public leaderboard sums, grouped by server instead of
|
|
* filtered to one — so an operator sees a player across the fleet in one read.
|
|
* All-time, deliberately: an admin looking at a user wants their history, not
|
|
* this week's.
|
|
*/
|
|
async function statsForSteamId(steamId) {
|
|
return core.query(
|
|
`SELECT s.server_id AS serverId, srv.name AS serverName,
|
|
SUM(s.kills) AS kills,
|
|
SUM(s.deaths) AS deaths,
|
|
SUM(s.npc_kills) AS npcKills,
|
|
SUM(s.structures) AS structures,
|
|
SUM(s.playtime_sec) AS playtimeSec,
|
|
MAX(s.last_seen) AS lastSeen,
|
|
COUNT(DISTINCT s.wipe_id) AS wipes
|
|
FROM ${STATS} s
|
|
LEFT JOIN rust_servers srv ON srv.id = s.server_id
|
|
WHERE s.steam_id = ?
|
|
GROUP BY s.server_id, srv.name
|
|
ORDER BY SUM(s.playtime_sec) DESC`,
|
|
[steamId],
|
|
)
|
|
}
|
|
|
|
/**
|
|
* Which of these Steam ids are linked, and to whom.
|
|
*
|
|
* The one question every notification asks — "who on the website is this
|
|
* player?" — asked for a set at once, because a raid names a cupboard's whole
|
|
* authorisation list and a clan event a whole roster. An unlinked id is simply
|
|
* absent from the answer: there is nobody to tell.
|
|
*/
|
|
async function userIdsForSteamIds(steamIds) {
|
|
if (!steamIds.length) return []
|
|
const marks = steamIds.map(() => '?').join(', ')
|
|
return core.query(
|
|
`SELECT steam_id AS steamId, user_id AS userId FROM ${LINKS} WHERE steam_id IN (${marks})`,
|
|
steamIds,
|
|
)
|
|
}
|
|
|
|
/**
|
|
* The linked players of one server: every linked Steam account that has played
|
|
* there, in any wipe (PLAN_REDESIGNS.md §2.5, the kit weekend's `linked`).
|
|
*
|
|
* "Has played there" is a stats row on that server, which every player who ever
|
|
* connected has. A link is fleet-wide, so the server is what narrows it: a kit
|
|
* weekend on one server rewards that server's players, not every account on the
|
|
* site. Bounded at `limit`, ordered by most recently seen, so a caller with a
|
|
* cap keeps the people who are actually around.
|
|
*/
|
|
async function linkedOnServer(serverId, limit = 5000) {
|
|
return core.query(
|
|
`SELECT l.steam_id AS steamId, l.user_id AS userId, l.name AS name, MAX(s.last_seen) AS lastSeen
|
|
FROM ${LINKS} l
|
|
JOIN rust_player_wipe_stats s ON s.steam_id = l.steam_id AND s.server_id = ?
|
|
GROUP BY l.steam_id, l.user_id, l.name
|
|
ORDER BY lastSeen DESC, l.steam_id
|
|
LIMIT ?`,
|
|
[serverId, Number(limit) || 5000],
|
|
)
|
|
}
|
|
|
|
/**
|
|
* The servers that handed out a link code in the last `windowSec` (PLAN_FIXES F5).
|
|
*
|
|
* Every `/link` in game emits `account.link.requested`, which ingest stores like
|
|
* any frame — without the code, which travels through the player. So the site
|
|
* cannot know WHICH server minted a code, but it does know which servers minted
|
|
* one at all. Read on the database's clock (`created_at`, set at ingest) rather
|
|
* than the frame's `t`, which is the game host's clock.
|
|
*/
|
|
async function recentLinkIssuers(windowSec) {
|
|
const rows = await core.query(
|
|
`SELECT DISTINCT server_id AS serverId FROM ${EVENTS}
|
|
WHERE kind = 'account.link.requested'
|
|
AND created_at >= NOW() - INTERVAL ? SECOND`,
|
|
[Number(windowSec)],
|
|
)
|
|
return rows.map((row) => String(row.serverId))
|
|
}
|
|
|
|
module.exports = {
|
|
recentLinkIssuers,
|
|
getBySteamId,
|
|
listForUser,
|
|
listForUserWithPlayer,
|
|
insert,
|
|
removeOwned,
|
|
removeBySteamId,
|
|
statsForSteamId,
|
|
userIdsForSteamIds,
|
|
linkedOnServer,
|
|
}
|