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

feat: recent activity card on Home and Retention card on Settings

Browse Source
This commit is contained in:
fsylvain committed 2026-10-07 16:01:28 +02:00
1 parent 35db442cd3
commit 43469ef08d
33 files changed
+2748 -204
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

features/activity_home_card_and_retention.feature
+349
View File
@@ -0,0 +1,349 @@
Feature: Recent activity card on Home and Retention card on Settings
As a RenewCMS user
I want Home to show my last five activity events and the owner to choose how long activity is kept on Settings
So that I see what happened without opening the Activity page, and the log does not grow without bound
Background:
Given the activity API (features/activity-log-backend.feature, activity-log-producers.feature, activity_screen.feature) and the settings retention fields already exist
And this slice adds one field to the settings API, activity_next_cleanup_at, and wires the SPA to the existing endpoints; there is no other Go change
And the Home card and the Settings "Retention" card are the two items activity_screen.feature left out of scope; the spec of record is docs/design/screens/home.md ("Recent activity card") and docs/design/screens/settings.md ("Activity retention"), groups "Home card" and "Settings retention" of RenewCMS Screens Activity.dc.html
And both boards draw the existing cards as dashed placeholders, so neither card is pixel-compared and Vitest is the SPA coverage
And "owner" and "admin" are the full Home view; any other or absent session role is the regular-user view
And every new English string has a French entry in messages.ts
And GET /v1/settings (every verified user) and PATCH /v1/settings (owner only, behind RequireOwner) both answer with the JSON object {"version", "activity_retention_days", "activity_last_cleanup_at", "activity_last_cleanup_removed", "activity_next_cleanup_at"}, snake_case, nothing else
And this supersedes the statement of features/settings_page.feature that the body is exactly {"version": "<value>"}; the version field and the verified-user access of that feature are unchanged
And activity_next_cleanup_at is an RFC 3339 timestamp with the server's offset, or null when activity_retention_days is 0 (Forever)
And otherwise it is the next 03:00 (audit.CleanupHour) in the server's time zone strictly after the server's current time
And the value is computed in the domain (audit.Settings) from the clock the use cases are built with, never in the handler and never in the SPA
And the cleanup it announces is the existing daily job, which never touches the last 24 hours (audit.KeepRecentHours)
And GetActivityRetentionUseCase and UpdateActivityRetentionUseCase both return the value, so a PATCH response carries the next cleanup of the new period (null after switching to Forever, a timestamp after leaving Forever)
And the existing validation, 400 with the text of apperr.BodyErrorMessage for any value outside 0, 30, 90, 365 or a malformed body, and 403 for a non-owner are unchanged
And the domain package stays free of GORM, HTTP and the clock source (the clock is passed in)
And on /home a card "Recent activity" (RecentActivityCard) sits in a 420 px column to the right of the existing cards from the lg breakpoint up, with a 16 px gap, in a grid (minmax(0,1fr) 420px, items aligned to the start) that spans the full content width, with no max-width, as the board frame draws it
And the greeting header and the update banner stay above the grid at full width
And below lg the card is stacked above the stat tiles and the recent article list, below the banner, with a 16 px gap
And the card is --ui-bg with a 1 px --ui-border and a header row (12px 16px padding, 1 px bottom border) holding the title (14 px semibold, --ui-text-highlighted) and, at the right, the link "View all" with an arrow-right icon (14 px; 44 px touch height below lg) to /activity
And the title is "Recent activity", and "Your recent activity" in the regular-user view
And on mount the card sends exactly one GET /v1/activity?size=5 with no other parameter and never an actor parameter; it never calls /summary or /export; the server returns own events only for a regular user
And no range is sent, so the server's default of 7 days applies and a site quiet for more than a week reads "No activity yet"
And the card loads independently of GET /v1/article/: neither waits for or blocks the other, and an error or empty card leaves the stat tiles, the recent article list, the articles' own empty and error states and "Connect your website" as they are
And each row (up to 5, in API order) has a 24 px avatar, the sentence clamped to two lines with the target name in semibold (composed by ActivitySentence exactly as on /activity, never stored text), then a muted 12 px line: "{actor name} · {time}" in the full view and only "{time}" in the regular-user view
And the avatar is the same as the Actor cell of /activity (initials for a user, key-round for an API key, cog for the system, user-round-x for an anonymous actor)
And the time of an event of today is "{n} min ago" or "{n} h ago" (lib/activityTime), an event of yesterday reads "Yesterday, 14:20" and an older one "3 Oct 2026, 14:20" (French "Hier, 14:20", "3 oct. 2026, 14:20"); the full local time with seconds is its title attribute
And a failed event shows a "Failed" badge at the right of its row; a successful event with security true shows a small shield icon (14 px, --ui-warning) and no badge; a failed security event shows the badge only
And rows are not interactive; only "View all" navigates
And while the request is in flight for longer than 150 ms the card body shows five skeleton rows (24 px circle, two bars) and aria-busy="true"; nothing is drawn in the body for the first 150 ms
And on a 500, any other non-401 status or a network failure the body is an inline role="alert" error with icon circle-x, title "Couldn't load recent activity", no description, and a "Try again" button that sends the same GET /v1/activity?size=5 again; a 401 is handled globally by useApi
And when total is 0 the body is the empty state: icon history, "No activity yet" and "Actions on your site will appear here." (regular user: "Your actions will appear here.")
And on /settings, for the owner only, a third card (RetentionCard) follows UpdatesCard and MediaCleanupCard and has the same width as its sibling cards; for an admin, a regular user or an absent role it is not rendered at all
And the card reads GET /v1/settings, the single call SettingsView already makes, whose typed response is widened with the four activity_* fields; the page still sends exactly one GET /v1/settings per navigation
And the header is "Retention" (14 px semibold) over "How long activity is kept." (12 px muted) with a status area at the right, aria-live="polite": "Saving…" (loader-circle) while a PATCH is in flight, "Saved" (check, --ui-success) for 2 s after it succeeds
And the body has the label "Keep activity for" over a USelectMenu (at most 260 px wide) with the items "30 days", "90 days", "365 days", "Forever" (values 30, 90, 365, 0) and a 12 px muted helper: "Older events are removed automatically." or, for Forever, "Nothing is removed automatically. The log grows over time."
And an info UAlert with icon lock is always shown: "Activity logs are append-only" / "Events can't be edited or deleted from the app. Only the retention period removes them."
And after a divider two read-only lines (120 px label then value; stacked on mobile) are shown in the user's local time: "Last cleanup" reads "6 Oct 2026, 03:00 · 142 events removed" ("1 event removed" for 1), or "Never" when activity_last_cleanup_at is null; "Next cleanup" reads "7 Oct 2026, 03:00" from activity_next_cleanup_at, or "Not scheduled" when it is null
And for Forever the last-cleanup line still shows the real last cleanup when one exists, and "Never" otherwise
And the periods are ordered 30 < 90 < 365 < Forever, and "shorter" means a lower rank than the saved period
And choosing a longer period, including Forever, sends PATCH /v1/settings with {"activity_retention_days": <value>} at once
And choosing a shorter period sends nothing and shows a warning UAlert with icon triangle-alert, title "Events older than {n} days will be removed", text "This happens at the next cleanup on {date}. It can't be undone." (the date is the saved settings' activity_next_cleanup_at, formatted like the line above) and the buttons "Apply {n} days" and "Cancel"
And a PATCH 200 returns the full settings, which refresh the select and the last and next lines
And any non-401 PATCH failure (400, 403, 500, network) shows an error UAlert with icon circle-x, title "Couldn't save the retention period", text "Your previous setting is still in place." and a "Try again" button, reverts the select to the saved value and leaves the lines unchanged; a 403 additionally refreshes the session, after which the card is gone
And "Try again" re-sends the failed value without asking for the shortening confirmation again
And while GET /v1/settings is loading for longer than 150 ms the card shows skeleton lines with aria-busy="true"
And when GET /v1/settings fails the card shows the Media cleanup card's alert, "Couldn't reach RenewCMS. Check your connection and try again." with "Try again", which re-runs the shared load
And while the browser is offline the select, "Apply" and "Cancel" are disabled; the page's offline banner copy is unchanged
Scenario Outline: Settings API, GET returns the next cleanup of the saved period
Given the saved retention is <days> days and the server time is <now> in a server zone of +02:00
When a verified user sends GET /v1/settings
Then the status is 200
And the body has "activity_next_cleanup_at" <next> and the other four fields
Examples:
| days | now | next |
| 90 | 2026-10-06T10:00:00+02:00 | "2026-10-07T03:00:00+02:00" |
| 90 | 2026-10-06T02:59:59+02:00 | "2026-10-06T03:00:00+02:00" |
| 90 | 2026-10-06T03:00:00+02:00 | "2026-10-07T03:00:00+02:00" |
| 30 | 2026-12-31T23:30:00+02:00 | "2027-01-01T03:00:00+02:00" |
| 365 | 2026-10-06T10:00:00+02:00 | "2026-10-07T03:00:00+02:00" |
| 0 | 2026-10-06T10:00:00+02:00 | null |
Scenario: Settings API, GET keeps the existing fields and adds exactly one
Given the saved retention is 90 days, the last cleanup is 2026-10-06T01:00:00Z with 142 events removed
When a verified user sends GET /v1/settings
Then the body is a JSON object with exactly the keys version, activity_retention_days, activity_last_cleanup_at, activity_last_cleanup_removed and activity_next_cleanup_at
Scenario: Settings API, GET is open to every verified user
Given a verified admin or editor sends GET /v1/settings
Then the status is 200 and the body includes activity_next_cleanup_at
Scenario Outline: Settings API, PATCH returns the next cleanup of the new period
Given the saved retention is <from> days and the user is the owner
When the owner sends PATCH /v1/settings with {"activity_retention_days": <to>}
Then the status is 200 and activity_retention_days is <to>
And activity_next_cleanup_at is <next>
Examples:
| from | to | next |
| 90 | 30 | the next 03:00 server time |
| 90 | 0 | null |
| 0 | 365 | the next 03:00 server time |
| 90 | 90 | the next 03:00 server time |
Scenario: Settings API, PATCH with the saved value changes nothing
Given the saved retention is 90 days
When the owner sends PATCH /v1/settings with {"activity_retention_days": 90}
Then the status is 200, nothing is saved and no audit event is recorded
Scenario: Settings API, PATCH by a non-owner is refused and changes nothing
Given a verified admin
When the admin sends PATCH /v1/settings with {"activity_retention_days": 30}
Then the status is 403 with the text "Only the owner can do this." and the saved retention is unchanged
Scenario Outline: Settings API, PATCH rejects invalid input
When the owner sends PATCH /v1/settings with <body>
Then the status is 400 with the text of apperr.BodyErrorMessage and nothing is saved
Examples:
| body |
| {"activity_retention_days": 7} |
| {"activity_retention_days": "30"} |
| {} |
| not json |
Scenario: Settings use cases compute the next cleanup from their clock
Given GetActivityRetentionUseCase and UpdateActivityRetentionUseCase are built with a fake settings repository and a fixed clock
Then GetActivityRetention returns Settings whose NextCleanupAt is the next 03:00 after the clock, or nil for Forever
And UpdateActivityRetention returns the new period with its own NextCleanupAt
And UpdateActivityRetention(7) returns an error satisfying errors.Is(err, audit.ErrInvalidRetention) and saves nothing
Scenario Outline: Home, owner or admin, the last five events with the actor name
Given the session role is "<role>" and GET /v1/activity?size=5 resolves 200 with 5 events, the first being Marta Alves publishing the article "Spring release" 2 minutes ago
When the user navigates to /home
Then the card title is "Recent activity" and "View all" links to /activity
And row 1 reads "Published the article Spring release" with "Spring release" in semibold, over "Marta Alves · 2 min ago", with a 24 px avatar "MA"
And exactly 5 rows are shown and GET /v1/activity was requested once with size=5 and no other parameter
Examples:
| role |
| owner |
| admin |
Scenario Outline: Home, regular user, own events only and no actor name
Given the session role is "<role>" and GET /v1/activity?size=5 resolves 200 with 3 own events
When the user navigates to /home
Then the card title is "Your recent activity"
And each row's meta line is only the time, for example "2 min ago"
And no actor parameter was sent
Examples:
| role |
| editor |
| absent |
Scenario Outline: Home rows, failure and security markers
Given an event with outcome "<outcome>" and security <security>
Then its row shows <marker>
Examples:
| outcome | security | marker |
| success | false | no badge and no shield |
| failed | false | a "Failed" badge |
| success | true | a shield icon and no badge |
| failed | true | a "Failed" badge and no shield |
Scenario Outline: Home rows, the time label follows the day
Given the current time is 2026-10-06 15:00 local and an event created <when>
Then the meta time reads "<label>"
Examples:
| when | label |
| 2026-10-06 14:58 | 2 min ago |
| 2026-10-06 12:00 | 3 h ago |
| 2026-10-05 14:20 | Yesterday, 14:20 |
| 2026-10-03 14:20 | 3 Oct 2026, 14:20 |
Scenario: Home rows, a long sentence is clamped to two lines
Given an event on an article whose title has 150 characters
Then the sentence is clamped to two lines with the title in semibold and the meta line stays on one line
Scenario: Home rows, an unknown action and a failed login
Given an event with action "article.archive" and an "auth.login_failed" event for "alex@example.com"
Then the first row shows "article.archive", the second "Failed login attempt for alex@example.com" with a "Failed" badge and the user-round-x avatar, and nothing throws
Scenario: Home rows are not interactive
Then a click on a row navigates nowhere and opens nothing
Scenario: Home card, skeleton rows only after 150 ms
Given GET /v1/activity?size=5 has not resolved
When the user navigates to /home
Then nothing is drawn in the card body for the first 150 ms
And after 150 ms five skeleton rows are shown and the card is aria-busy="true"
When the request resolves 200 with 5 events
Then the skeletons are replaced by 5 rows
And a response in under 150 ms never shows a skeleton
Scenario Outline: Home card, error shows a retryable alert that leaves the page alone
Given GET /v1/activity?size=5 <failure> and GET /v1/article/ resolves 200 with 6 articles
When the user navigates to /home
Then the card shows an alert "Couldn't load recent activity" with a "Try again" button
And the stat tiles "6" "articles", "4" "online", "2" "drafts", the recent article list and "Connect your website" are shown as in home.feature's Default state
When the user activates "Try again"
Then GET /v1/activity?size=5 is sent again and, on 200 with events, the rows replace the alert
Examples:
| failure |
| resolves with a 500 response |
| resolves with a 403 response |
| never reaches the server |
Scenario Outline: Home card, empty when there are no events yet
Given GET /v1/activity?size=5 resolves 200 with items [] and total 0 and the role is "<role>"
When the user navigates to /home
Then the card shows the history icon, "No activity yet" and "<text>"
And "View all" is still shown
Examples:
| role | text |
| owner | Actions on your site will appear here. |
| editor | Your actions will appear here. |
Scenario: Home card and article list are independent
Given GET /v1/article/ fails with a 500 and GET /v1/activity?size=5 resolves 200 with 5 events
Then the articles alert "Couldn't load your articles" and the 5 activity rows are both shown
And with GET /v1/article/ resolving [] and GET /v1/activity?size=5 failing, the articles' Empty state and the card's error are both shown
Scenario: Home layout is two columns from lg and stacked below
Given the viewport is lg or wider
Then the header and the update banner span the full content width and the grid below them spans the same full width with the article cards on the left and the activity card 420 px wide in the far-right column, 16 px apart, its top aligned with the top of the article cards
Given the viewport is below lg
Then the card sits above the stat tiles, below the banner, at full width
Scenario: Home card, "View all" opens the activity page
When the user activates "View all"
Then the router navigates to /activity
Scenario: Settings retention is hidden for everyone but the owner
Given GET /v1/settings resolves 200 with activity_retention_days 90
When an "admin" (or an "editor", or an absent role) navigates to /settings
Then no "Retention" card and no "Keep activity for" select is in the page
And the Version, Updates and Media cleanup cards are unchanged
And GET /v1/settings was requested once
Scenario: Settings retention, Default with 90 days
Given the role is "owner" and GET /v1/settings resolves 200 with activity_retention_days 90, activity_last_cleanup_at 6 Oct 2026 03:00 local, activity_last_cleanup_removed 142 and activity_next_cleanup_at 7 Oct 2026 03:00 local
When the owner navigates to /settings
Then the third card reads "Retention" and "How long activity is kept."
And the select shows "90 days" with the helper "Older events are removed automatically."
And the lock alert "Activity logs are append-only" is shown
And the lines read "Last cleanup" "6 Oct 2026, 03:00 · 142 events removed" and "Next cleanup" "7 Oct 2026, 03:00"
And no "Saved" is shown, no PATCH was sent and GET /v1/settings was requested once
Scenario: Settings retention, before the first cleanup
Given activity_last_cleanup_at is null and activity_next_cleanup_at is set
Then "Last cleanup" reads "Never" and "Next cleanup" shows the date
Scenario: Settings retention, skeleton lines after 150 ms
Given GET /v1/settings has not resolved and the role is "owner"
When the owner navigates to /settings
Then nothing is drawn in the card body for the first 150 ms, then skeleton lines with aria-busy="true"
Scenario: Settings retention, the settings request fails
Given GET /v1/settings fails with a 500
Then the card shows "Couldn't reach RenewCMS. Check your connection and try again." with a "Try again" button that re-runs the shared GET /v1/settings
Scenario Outline: Settings retention, a longer period saves at once
Given the saved period is <from> and the owner chooses "<to>"
When PATCH /v1/settings resolves 200 with activity_retention_days <value> and the matching activity_next_cleanup_at
Then PATCH was sent once with {"activity_retention_days": <value>} and no warning alert is shown
And the status reads "Saving…" while in flight and "Saved" with a check afterwards, fading after 2 s
And the select shows "<to>" and the "Next cleanup" line shows the returned value
Examples:
| from | to | value |
| 90 days | 365 days | 365 |
| 30 days | 90 days | 90 |
| 90 days | Forever | 0 |
Scenario: Settings retention, Forever changes the helper and the lines
Given the saved period is 90 days and the owner chooses "Forever" and PATCH resolves 200 with activity_retention_days 0, activity_next_cleanup_at null and a last cleanup of 6 Oct 2026 03:00 with 142 removed
Then the helper reads "Nothing is removed automatically. The log grows over time."
And "Next cleanup" reads "Not scheduled" and "Last cleanup" still reads "6 Oct 2026, 03:00 · 142 events removed"
Scenario: Settings retention, Forever and never cleaned
Given GET /v1/settings resolves 200 with activity_retention_days 0, activity_last_cleanup_at null and activity_next_cleanup_at null
Then "Last cleanup" reads "Never" and "Next cleanup" reads "Not scheduled"
Scenario: Settings retention, shortening asks first
Given the saved period is 90 days and activity_next_cleanup_at is 7 Oct 2026 03:00 local
When the owner chooses "30 days"
Then no PATCH is sent and the select shows "30 days"
And a warning alert shows "Events older than 30 days will be removed" and "This happens at the next cleanup on 7 Oct 2026, 03:00. It can't be undone." with "Apply 30 days" and "Cancel"
When the owner activates "Apply 30 days" and PATCH resolves 200 with activity_retention_days 30
Then PATCH was sent once with {"activity_retention_days": 30}, the alert is gone and "Saved" shows
Scenario: Settings retention, shortening cancelled
Given the warning for 30 days is shown on a saved 90
When the owner activates "Cancel"
Then the alert is gone, the select reads "90 days" again and no PATCH was ever sent
Scenario Outline: Settings retention, shortening is relative to the saved period
Given the saved period is <saved>
When the owner chooses "<chosen>"
Then <outcome>
Examples:
| saved | chosen | outcome |
| Forever | 365 days | the warning "Events older than 365 days will be removed" shows |
| 365 days | 90 days | the warning "Events older than 90 days will be removed" shows |
| 90 days | 90 days | nothing happens and no request is sent |
| 30 days | Forever | PATCH is sent at once |
Scenario: Settings retention, choosing a longer period while the warning is open drops it
Given the warning for 30 days is shown on a saved 90
When the owner chooses "365 days"
Then the warning disappears and PATCH is sent once with 365
When the owner then chooses "30 days" and again "365 days" before the first request settles or after it
Then no stale warning is ever left on screen
Scenario Outline: Settings retention, save error reverts the control and Try again retries
Given the saved period is 90 days and the owner chooses "365 days"
When PATCH /v1/settings <failure>
Then an error alert shows "Couldn't save the retention period" and "Your previous setting is still in place." with "Try again"
And the select shows "90 days" again, the lines are unchanged and no "Saved" appears
When the owner activates "Try again" and PATCH resolves 200 with 365
Then PATCH was sent a second time with 365 and "Saved" replaces the alert
Examples:
| failure |
| resolves with a 500 response |
| resolves with a 400 response |
| resolves with a 403 response |
| never reaches the server |
Scenario: Settings retention, Try again after Apply does not ask again
Given the warning for 30 days is shown and the owner activates "Apply 30 days"
When PATCH resolves 500
Then the warning is gone, the error alert is shown and the select reads the saved period
When the owner activates "Try again" and PATCH resolves 200 with 30
Then PATCH was sent a second time with 30 and no warning reappears
Scenario: Settings retention, an owner demoted while the page is open
Given PATCH /v1/settings resolves 403 and GET /v1/auth/me then resolves with role "admin"
Then the error alert is shown and, after the session refresh, the Retention card is no longer rendered
Scenario: Settings retention, offline disables the controls
Given the owner is on /settings and the browser goes offline
Then the select, and "Apply" and "Cancel" when shown, are disabled and nothing is sent
And the page's offline banner keeps its existing copy
Scenario: Settings retention, a 401 is global
Given GET or PATCH /v1/settings resolves 401
Then useApi redirects to /login?redirect=/settings&reason=expired and no card alert is shown
Scenario: The French interface
Given the language is French
Then every string of both cards is French and the Home rows use the French sentence templates of activity_screen.feature
Scenario: Existing behaviour is unchanged
Then every scenario of home.feature, settings_page.feature (except its exact-body statement, superseded above) and the Media cleanup scenarios still holds with GET /v1/activity?size=5 mocked and the settings mock widened with the four activity_* fields