fsylvain/RenewCMS
1
1 Fork 0
Code Issues Pull Requests Packages Projects Releases 20 Wiki Activity

chore: groundwork for new design and features related to users and settings

Browse Source
This commit is contained in:
fsylvain committed 2026-09-29 23:19:41 +02:00
1 parent 65ced64568
commit 6dc47789ef
10 files changed
+265 -56
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/design/screens/profile.md
+10 -8
View File
@@ -10,7 +10,7 @@ Once saved it replaces the username everywhere a person is named:
- the sidebar chip and the account menu (name, and the avatar initials)
- the Home greeting ("Good morning, Marta Alves")
- the Users list, with the username beside it
- the Display name column of the Users list
- the emails RenewCMS sends, such as "Marta Alves invited you to RenewCMS"
Saving it empty goes back to the username. Logging in still uses the username.
@@ -48,11 +48,13 @@ Desktop: a 224 px popover above the chip, aligned to its left. Mobile: the accou
| Header | The name in semibold (display name, or the username), and the email in muted 12 px (14 px on mobile, with a 36 px initials avatar beside them) |
| Item | Profile (circle-user icon), highlighted while on `/profile` |
| Separator | |
| Items | System, Light, Dark: a radio-style group, the current choice carries a check icon at the right edge; choosing one applies the theme at once and keeps the menu open |
| Separator | |
| Item | Log out (log-out icon) |
Avatar initials come from the first letters of the first two words of the display name, uppercased ("Marta Alves" gives MA). Without a display name they come from the username.
The board's menu has no System, Light or Dark items, while the shipped UserMenu has them. This is an open question, see the notes below.
The board's menu now carries System, Light and Dark, matching the shipped UserMenu. The theme choice stays in the account menu; the Profile page does not repeat it. Items are 32 px on desktop and 48 px in the mobile sheet.
## States
@@ -62,7 +64,7 @@ The board's menu has no System, Light or Dark items, while the shipped UserMenu
- Breadcrumbs: Home (mobile title "Home")
- Page behind the menu: Home, default
- Menu open, as described above
- Menu open, as described above, with the System, Light and Dark group between Profile and Log out. The board shows Light checked
### Loading
@@ -161,17 +163,17 @@ The board's menu has no System, Light or Dark items, while the shipped UserMenu
### Display names in the Users list
**Trigger:** Accounts with a display name show it first, with the username beside it in grey. Accounts without one show the username. This state needs the Users page ([users.md](users.md)).
**Trigger:** The Display name column of the Users list shows the name when one is set and a dash when not. Your own row follows your saved name. This state needs the Users page ([users.md](users.md)).
- Breadcrumbs: Users (mobile title "Users")
- Signed-in user's display name: "Marta Alves" (sidebar chip shows it too)
- Row `marta` (you): "Marta Alves", `marta` beside it in muted text, "you" tag, Accepted
- Row `ines`: "Inès Duarte", `ines` beside it in muted text, Accepted
- Row `jonas`: `jonas` alone, Accepted
- Row `marta@renew.example` (you): display name "Marta Alves", role owner, Accepted
- Row `ines.duarte@renew.example`: display name "Inès Duarte", role admin, Accepted
- Row `jonas@renew.example`: display name "—" (muted), role admin, Accepted
## Notes for implementation
- `PATCH /v1/user/me` is marked pending by the design: it does not exist yet. `GET /v1/auth/me` has to start returning the display name.
- The Password card sends the reset email to the account's own address through the existing `POST /v1/auth/password-reset`. The link ends on the reset confirm screen, and a successful reset invalidates the current session like any other reset.
- "Disabled for 5 minutes" is the design's number. The real window comes from the `Retry-After` header, as on the login and reset screens.
- Open question: the shipped UserMenu offers System, Light and Dark, and the redesigned menu does not. Decide whether the theme choice stays in the menu, moves to the Profile page, or is dropped, before building the menu.
- Resolved: the theme choice (System, Light, Dark) stays in the account menu, as the board now draws it. The board still draws Profile highlighted on Home; the app highlights it only on `/profile`.
docs/design/screens/settings.md
+35
View File
@@ -0,0 +1,35 @@
# Settings
- **Route:** `/settings`
- **API:** GET /v1/settings (not drawn, see the notes)
- **Visual reference:** `source/RenewCMS Screens Back-office.dc.html`, group "Settings" (open it in a browser; each state is drawn at desktop and mobile, with a light/dark toggle).
Opened from the sidebar (Settings, settings icon, after Integration) and from the mobile drawer. Every verified user sees it, owner and admins alike. For now it holds a single section, Version. Nothing on it can be edited.
## The page
Title "Settings" and the subtitle "Workspace information.", 720 px wide at most. Page padding 32 px on desktop and `20px 16px 88px` on mobile, 20 px between the header and the card.
One card (`--ui-bg`, 1 px `--ui-border`, 20 px padding on desktop and 16 px on mobile), a single row with the label on the left and the value on the right, 16 px apart:
| Part | Content |
|---|---|
| Label | "Version", 15 px semibold, `--ui-text-highlighted` |
| Value | The running build's version in IBM Plex Mono 14 px, `--ui-text-toned`. The board shows `v2.2.0-beta`. Shown exactly as the server reports it, so the SPA adds no `v` prefix. |
## States
### Default
**Trigger:** Opened from the sidebar.
- Breadcrumbs: Settings (mobile title "Settings")
- Section: Version, `v2.2.0-beta`
The board draws no loading or error state. Decide them in the spec (see the notes).
## Notes for implementation
- The board's API line says "none (static)", but the version lives in the Go binary (`main.version`, set with `-ldflags -X`, `dev` when unset), so the SPA has to ask for it. The recommendation is `GET /v1/settings` returning `{ "version": "..." }` inside the verified group, so later settings have a home. It is read once at startup and never from the environment at request time.
- Not drawn: loading (the recommendation is a skeleton for the value only, after 150 ms, like the other pages), and a failed request (an inline error in the card with "Try again", using the global copy "Couldn't reach RenewCMS. Check your connection and try again.").
- Keep the page free of actions, toggles and links until a later slice adds a real setting.
docs/design/screens/users.md
+120 -12
View File
@@ -1,24 +1,60 @@
# Users
- **Route:** `/users`
- **API:** GET /v1/user/ · POST /v1/user/invite
- **API:** GET /v1/user/ · POST /v1/user/invite · DELETE /v1/user/invite/:id (pending) · POST /v1/user/invite/:id/renew (pending)
- **Visual reference:** `source/RenewCMS Screens Back-office.dc.html`, group "Users" (open it in a browser; each state is drawn at desktop and mobile, with a light/dark toggle).
One shared workspace: every user sees the same articles and this same list. Rows have no actions yet, so nobody can be removed, promoted or have an invite revoked from here. Pending and expired invites show the email address, because a username only exists once the invite is accepted.
One shared workspace: every user sees the same articles and this same list. The list shows email, display name, role, invite status and created date. A Pending invite can be cancelled and an Expired one renewed; accepted accounts have no row actions, so nobody can be removed or promoted from here. Only the owner can invite, cancel and renew (see "Roles").
An invite is **Pending** until its link is used, **Expired** after 3 days, and **Accepted** once the account is created. The list is sorted by created date, newest first.
## Roles
There are two roles. They are shown as a badge and are not editable.
| Role | Who | Can |
|---|---|---|
| owner | The account that registered first on the workspace. There is exactly one. | Everything an admin can, plus invite users, cancel invites and renew invites. |
| admin | Everyone who joined through an invite. Every invite creates an admin. | Read and write articles, see the Users list, edit their own profile, see Settings. |
The owner is the only difference for now. The role cannot be changed, transferred or removed from the UI.
**Not drawn by the board** (decide in the spec, cover by Vitest and Go tests only, like the 429 on invite):
- What a non-owner sees: the recommendation is to hide "Invite user" (desktop and mobile), hide the row actions, and hide the "Invite someone…" hint on the "Only you" state.
- The API answer when a non-owner calls an owner-only endpoint: the recommendation is 403 with a plain-text body, and no state change.
- The message if the owner's session sees a 403 anyway (role changed under it): the global 403 handling applies.
## The list
| Column | Content |
|---|---|
| Username | An accepted user: the display name if there is one (medium weight, highlighted) with the username beside it in muted text; otherwise the username alone. A pending or expired invite: the email address, regular weight, toned. The current user's row carries a muted mono "you" tag. |
| Email | The account's or invite's email address, medium weight, highlighted. The current user's row carries a muted mono "you" tag after it. |
| Display name | The display name when set, highlighted; a muted dash `—` when not. An invite has none, so it shows the dash. Your own row follows your saved name. |
| Role | A mono 11 px badge, 20 px high: `owner` (filled, `--ui-primary` with `--ui-bg` text) or `admin` (transparent, toned text, `--ui-border-accented` border). An invite shows the role it will create, `admin`. |
| Invite status | A badge: Accepted (circle-check, success), Pending (mail, warning), Expired (clock-alert, outline, muted). Shown by icon and word as well as color. |
| Created | The date as `27 Sep 2026`, or "Today" for the current day. For an invite it is the day the invite was sent, for a user the day the account was created. |
| Created | The date as `27 Sep 2026`, or "Today" for the current day. For an invite it is the day the invite was sent (or last renewed), for a user the day the account was created. |
| (actions) | Right-aligned, no header text. Pending row: "Cancel invite". Expired row: "Renew invite". Accepted row: empty. |
Desktop is a table: 36 px header, 44 px rows, columns `minmax(0,1fr) 160px 160px`. Below md it becomes a card list (68 px minimum row height): the name line, then the badge and "Created {date}". The page header is a title "Users" with the subtitle "Everyone who can sign in and work on your articles." and a primary "Invite user" button (user-plus icon) on its right. On mobile the button becomes a full-width 48 px button pinned to the bottom of the screen.
The username is no longer shown in this list.
The admin who registered first is always listed, so the list is never empty.
Desktop is a table: 36 px header, 48 px rows, columns `minmax(0,1.3fr) minmax(0,1fr) 84px 120px 110px 150px` with a 12 px gap. Below md it becomes a card list (68 px minimum row height): the email line (with "you"), the display name below it when there is one, then the role badge, the status badge and "Created {date}" on one line, then the row action, if any, as a 44 px button with 14 px side padding.
The page header is a title "Users" with the subtitle "Everyone who can sign in and work on your articles." and a primary "Invite user" button (user-plus icon) on its right. On mobile the button becomes a full-width 48 px button pinned to the bottom of the screen.
The owner is always listed, so the list is never empty.
### Row actions
| Action | Shown on | Icon | Look |
|---|---|---|---|
| Cancel invite | Pending | user-x | Outline button, text in `--ui-error` |
| Renew invite | Expired | refresh-cw | Outline button, text `--ui-text-highlighted` |
Desktop buttons are 28 px high, 12 px medium text, a 13 px icon, 9 px side padding, `--ui-border-accented` border, `--ui-bg` fill. Mobile buttons are 44 px high and 14 px side padding with a 14 px icon.
- **Cancel invite** asks first with a danger confirmation dialog, since it cannot be undone from here (the address can be invited again).
- **Renew invite** asks nothing, since it only sends an email. While the request runs, that row's button reads "Renewing…" with a loader-circle icon at 50 % opacity and is disabled. Only that row is busy.
## States
@@ -27,21 +63,28 @@ The admin who registered first is always listed, so the list is never empty.
**Trigger:** The list loaded, newest first.
- Breadcrumbs: Users (mobile title "Users")
- Rows: `sam.oliveira@renew.example` Pending, 27 Sep 2026 · `p.huber@gmail.com` Expired, 3 Aug 2026 · `ines` (display name "Inès Duarte") Accepted, 18 Jun 2026 · `jonas` Accepted, 2 Apr 2026 · `marta` (you) Accepted, 12 Mar 2026
- Rows:
- `sam.oliveira@renew.example`, no display name, admin, Pending, 27 Sep 2026, "Cancel invite"
- `p.huber@gmail.com`, display name "Paul Huber", admin, Expired, 3 Aug 2026, "Renew invite"
- `ines.duarte@renew.example`, "Inès Duarte", admin, Accepted, 18 Jun 2026
- `jonas@renew.example`, no display name, admin, Accepted, 2 Apr 2026
- `marta@renew.example` (you), no display name, owner, Accepted, 12 Mar 2026
The board gives the Expired invite a display name. A real invite has none, so the SPA renders whatever `display_name` the item carries and the dash when it is empty.
### Loading
**Trigger:** The first load, or a retry. Skeletons appear after 150 ms.
- Breadcrumbs: Users (mobile title "Users")
- Five skeleton rows
- Five skeleton rows, one bar per column, plus a role-badge and a status-badge placeholder
### Only you
**Trigger:** Nobody has been invited yet. The admin who registered is always listed.
**Trigger:** Nobody has been invited yet. The owner is always listed.
- Breadcrumbs: Users (mobile title "Users")
- One row: `marta` (you) Accepted
- One row: `marta@renew.example` (you), owner, Accepted
- Hint under the list: "Invite someone so they can sign in with their own account instead of sharing yours."
### Error
@@ -111,14 +154,79 @@ The admin who registered first is always listed, so the list is never empty.
**Trigger:** 201: the dialog closes, the new invite appears at the top as Pending (highlighted row), and a toast confirms.
- Breadcrumbs: Users (mobile title "Users")
- New first row: `lea.martin@renew.example` Pending, created "Today", row background `--ui-bg-elevated`
- New first row: `lea.martin@renew.example`, no display name, admin, Pending, created "Today", row background `--ui-bg-elevated`, with "Cancel invite"
- Toast (success, circle-check): **Invite sent** "lea.martin@renew.example has 3 days to accept."
The "Today" label makes this state clock-sensitive, so `task visual:check` skips it.
### Cancel invite: confirm
**Trigger:** "Cancel invite" on a Pending row.
- Breadcrumbs: Users (mobile title "Users")
- Modal (danger): **Cancel this invite?**
- text "The link sent to sam.oliveira@renew.example will stop working. You can invite the address again later."
- cancel "Keep invite"
- confirm "Cancel invite"
### Cancel invite: sending
**Trigger:** Request in flight. Both buttons are disabled and the dialog can't be dismissed.
- Breadcrumbs: Users (mobile title "Users")
- Modal (danger): **Cancel this invite?** (same text)
- cancel "Keep invite", disabled
- confirm "Cancelling…", loading
### Cancel invite: failed
**Trigger:** 500 or network failure. The dialog stays open.
- Breadcrumbs: Users (mobile title "Users")
- Modal (danger): **Cancel this invite?** (same text)
- notice "Couldn't cancel the invite. Try again in a moment."
- cancel "Keep invite"
- confirm "Cancel invite"
### Cancel invite: done
**Trigger:** 204: the row disappears and a toast confirms.
- Breadcrumbs: Users (mobile title "Users")
- The Pending row `sam.oliveira@renew.example` is gone; the other four remain
- Toast (success, circle-check): **Invite cancelled** "sam.oliveira@renew.example can no longer use the link."
### Renew invite: sending
**Trigger:** "Renew invite" on an Expired row. No confirmation, since it only sends an email. The button shows progress and is disabled.
- Breadcrumbs: Users (mobile title "Users")
- The Expired row's button reads "Renewing…" with a loader-circle icon, 50 % opacity, disabled
### Renew invite: done
**Trigger:** 200: the row becomes Pending with today's date, moves to the top, and the old link stops working.
- Breadcrumbs: Users (mobile title "Users")
- First row: `p.huber@gmail.com` Pending, created "Today", row background `--ui-bg-elevated`, now with "Cancel invite"
- Toast (success, circle-check): **Invite renewed** "p.huber@gmail.com has 3 days to accept the new link."
The "Today" label makes this state clock-sensitive, so `task visual:check` skips it.
### Renew invite: failed
**Trigger:** 500 or network failure. The row stays Expired and the button can be pressed again.
- Breadcrumbs: Users (mobile title "Users")
- Toast (error, circle-x): **Couldn't renew the invite** "Try again in a moment."
## Notes for implementation
- An accepted user is shown by username and display name only, never by email.
- Accepted users are now listed by email, display name and role. This reverses the earlier rule that a user is never listed with an email.
- How display names look in this list is the state "Display names in the Users list" of [profile.md](profile.md). The board draws it in the Profile group, and `task visual:check` finds states by group.
- The board's API line marks both new endpoints "(pending)", meaning "not built yet". Cancel applies to a Pending invite. Renew is drawn on an Expired one; the recommendation is that the API also accepts a Pending one (it resets the 3 days and replaces the link) and refuses an Accepted one with 409. The SPA only offers Renew on Expired rows.
- Renewing replaces the code and expiry, resets the created date to now, and sends the invitation email again. The old link stops working. The email is specified in [emails.md](../emails.md).
- A 404 on cancel or renew (the invite was already used or cancelled elsewhere) is not drawn. Decide it in the spec; the recommendation is to drop the row and toast the outcome.
- 429 on the invite request is not drawn. Decide it in the spec before coding.
- The email the invite sends is specified in [emails.md](../emails.md). The screen the link opens is in [accept-invite.md](accept-invite.md).
- The role rules and what is not drawn are in "Roles" above.