feat(web,api): scale spacing with text size, persist preference per account
Build and Push Images / Build jorgecuadros-web (push) Successful in 2m13s
Build and Push Images / Build jorgecuadros-api (push) Successful in 3m16s

Two follow-ups to the text-size control.

Spacing now scales with the text. All padding, margin, gap and min-height
declarations in globals.css move from px to rem (263 declarations, converted
mechanically), so --ui-scale drives the whole layout rather than just the
glyphs. Deliberately left in px: border widths, which must stay hairlines;
box-shadow offsets; border-radius, which reads as bloated when scaled on large
cards; --shell-max, a container cap that must not outgrow the viewport; and
media-query breakpoints, which are conditions rather than declarations. With
spacing following along, the presets gain a 1.5 "Máximo" step and MAX_UI_SCALE
rises from 1.4.

The preference now lives on the account instead of only in one browser.
User.uiScale (Float, default 1) is added to the schema and to the safe select,
so it rides along on /auth/login and /auth/me. PATCH /auth/preferences writes
it, guarded by AuthenticatedGuard only — every role including VIEWER may set
their own, and the target is always the session's user id, never a body
parameter, so this cannot be used to touch another account. The global
ValidationPipe's whitelist rejects any extra field, so role cannot ride in
alongside uiScale.

localStorage stays, demoted to a pre-paint cache for the layout.tsx script;
AppShell reconciles it against the account once /auth/me answers, with the
account winning. FontScaleControl becomes a controlled component since the
same value is now edited from the appbar and the drawer.

Verified against the dev API: PATCH persists and is reflected by a subsequent
/auth/me, out-of-range values are rejected 400, and an extra "role" field in
the body is rejected 400.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-07-27 22:30:06 -07:00
co-authored by Claude Opus 5
parent 0bf97e6d2c
commit c100dfa224
11 changed files with 405 additions and 300 deletions
+28 -1
View File
@@ -1,9 +1,21 @@
import { Controller, Get, HttpCode, Post, Req, Res, UseGuards } from "@nestjs/common";
import {
Body,
Controller,
Get,
HttpCode,
Patch,
Post,
Req,
Res,
UseGuards,
} from "@nestjs/common";
import { Request, Response } from "express";
import { LocalAuthGuard } from "./local-auth.guard";
import { AuthenticatedGuard } from "./authenticated.guard";
import { LoginDto } from "./login.dto";
import { UpdatePreferencesDto } from "./update-preferences.dto";
import { abilitiesFor, Role } from "./abilities";
import { UsersService } from "../users/users.service";
/** Attach the resolved ability map so the web can gate its UI off one payload. */
function withAbilities(user: unknown) {
@@ -14,6 +26,8 @@ function withAbilities(user: unknown) {
@Controller("auth")
export class AuthController {
constructor(private readonly users: UsersService) {}
// LoginDto is only used for request-shape documentation/validation here —
// the actual credential check happens inside LocalStrategy via Passport,
// which populates req.user before this handler runs.
@@ -30,6 +44,19 @@ export class AuthController {
return withAbilities(req.user);
}
/**
* Update the caller's own UI preferences. Deliberately not on /users/:id —
* that controller is ADMIN-only, and this has to work for every role. The
* target is always the session's own user id, never a body parameter.
*/
@UseGuards(AuthenticatedGuard)
@Patch("preferences")
async updatePreferences(@Req() req: Request, @Body() dto: UpdatePreferencesDto) {
const id = (req.user as { id: string }).id;
const user = await this.users.updatePreferences(id, dto.uiScale);
return withAbilities(user);
}
@Post("logout")
@HttpCode(200)
logout(@Req() req: Request) {
@@ -0,0 +1,17 @@
import { IsNumber, Max, Min } from "class-validator";
/**
* Self-service UI preferences — any authenticated user may set these on their
* own account, including VIEWER. No ability gate: it changes nothing but how
* the app looks to that one person.
*
* The bounds mirror MIN_UI_SCALE/MAX_UI_SCALE in apps/web/src/lib/ui-scale.ts;
* keep them in sync. The API clamps rather than trusting the client because
* this endpoint is reachable outside the UI.
*/
export class UpdatePreferencesDto {
@IsNumber()
@Min(0.9)
@Max(1.5)
uiScale!: number;
}
+13
View File
@@ -18,6 +18,7 @@ const safeSelect = {
email: true,
role: true,
active: true,
uiScale: true,
createdAt: true,
updatedAt: true,
} satisfies Prisma.UserSelect;
@@ -101,6 +102,18 @@ export class UsersService {
}
}
/**
* Self-service preference write — no ability check, because the only account
* it can touch is the caller's own (the controller passes the session id).
*/
updatePreferences(id: string, uiScale: number): Promise<SafeUserRow> {
return this.prisma.user.update({
where: { id },
data: { uiScale },
select: safeSelect,
});
}
async resetPassword(id: string, password: string): Promise<SafeUserRow> {
await this.ensureExists(id);
const passwordHash = await argon2.hash(password);