[simlarsen]

What was asked

• Maintainer: "On Alert/Incident creation - I don't see a way to add the team of the incident creator as an owner. Can you please check if this is true, and if this is true, can you please build that option as well? We can have that and more, so it is not visible by default on the form."
• Customer: the confirmation step never said which owner rules would run ("tell me either the name of the rules that will apply, or the action it will take - Team_XYZ will be added"), and: how do I automatically add (a) the incident creator and (b) the team the incident creator belongs to as owners?

What I found

• True: Declare Incident and Create Alert had no Owners field at all (it was removed in February, when roles came). Owners from an incident template were sent without being shown. Create Incident Episode had no Owners field either.
• (a) is already the case: whoever creates an incident or an alert is made an owner when it is saved (DatabaseService.autoOwnerOnCreate, incidents and alerts are operational resources). Nothing said so on the form.
• Bug: Create Alert Episode has asked for owners for a while, but AlertEpisodeService never added them - the picks were dropped.
• Owner rules ran only after the create, and nothing before it said what they would do.

What changes

On the create forms (Declare Incident, Create Alert, Create Incident Episode; Create Alert Episode keeps its On-Call & Owners step)

• Owners, one people-and-teams picker, folded under More fields at the end of the first step - not visible by default. Its line says what is already true: "You become an owner when you declare it. Add your team, or anyone else who should own it."
• Under the picker, the creator's own teams are one click away: Your teams: + Database + Members + Platform · Add all. Nothing is picked by itself (Members and Owners are teams too).
• The review step always has an Owners row: the owners picked (or "Nobody else picked."), then Added by owner rules - each owner rule that will run, by name, with the people and teams it will add (the customer's "Team_XYZ will be added").
• That list comes from the server: POST /api/<incident|alert|incident-episode|alert-episode>/owner-rule-preview runs the same planRules the create runs (the engines now plan first, then write), for the draft as the form holds it - title, description, severity, labels, monitors and other resources. Nothing is guessed in the browser. While it asks, the row says so; if it fails, it says the rules still run when the incident is created, and creating is never blocked. Someone who may not read the owner rules is told nothing about them (the route answers as a read of the rule model, project-scoped, and refuses ids from another project).
• Declaring from a template now starts the field with the template's owners, visible and editable, instead of sending them unseen.
• The picks travel as ownerUsers / ownerTeams misc data, as the API already took them: the server checks the creator may add them before anything is saved, and adds them once the event exists. Both episode services now do this too, which fixes the dropped alert episode owners.

On incident and alert owner rules

• New Creator's Team list (creatorTeams), last in the Inherit Owners fold of the rule's Owners step: of the teams listed, each one the person who created the event is a member of becomes an owner too. The fold's folded line now names it ("Optionally assign owners from related entities, or the creator's team, to the incident.").
• A rule that lists only a team there adds something: it saves, is named "Add the creator's team as an owner" until you type a name, is not marked Adds nothing, and the API refusal for an empty rule names the list ("...a team in Creator's Teams, or turn on an Inherit Owners switch.").
• An incident or alert made by a monitor, a workflow, a form or an API key has no creator, so it gets none of these teams. A creator who has left the project is in none of its teams.
• Migration 1806300000000-AddOwnerRuleCreatorTeams (generated): two new join tables, IncidentOwnerRuleCreatorTeam and AlertOwnerRuleCreatorTeam, indexes and foreign keys on empty tables, nothing to backfill. Ran all migrations on a fresh Postgres: no schema drift.

Option on the form vs rule target: which one when

	Owners on the create form	Creator's Team on an owner rule
Who decides	the person creating it, each time	a rule author, once, for everyone
What it adds	anyone picked, with their own teams one click away	of the teams the rule lists, the ones the creator is in
When	only when someone opens More fields and picks	every matching incident or alert a person creates
Visible	folded under More fields	in the rule's Inherit Owners fold; the create form's review lists the rule and the team it will add

There is no "add the creator" rule target: the creator is always made an owner of an incident or alert already, so such a switch could only ever be on. There is no "every team of the creator" switch either: people are invited into the project's Members team by default (and teams also carry permissions), so it would make Members - everyone - an owner of every incident someone declares. A rule names which teams count instead.

What existing customers will notice

• Declare Incident, Create Alert and Create Incident Episode have one more item under More fields; the review step has an Owners row. Nobody's form opens differently.
• Owner rules saved before keep adding exactly what they added; the new list starts empty.
• Alert episodes created with owners now actually get them.
• Owners from an incident template now show in the field before declaring.

Tests

• Server: OwnerRulePlan, CreatorTeams, InheritedOwners, OwnerRulePreviewBuilder, OwnerRulePreviewRoute (permissions, project scoping, refusals, cache headers), EpisodeOwnersPickedOnCreate (both episode services: checked before save, added after, before the rules run), the rule engine suites (plan = writes), OwnerRuleAssignment, empty-rule refusals, RuleAction.
• Dashboard: OwnersOnCreateRules, OwnersOnCreateForm (field, suggestions, Add all, review row states), template owners, CreateFormsInitialState, DeclareFormsAdvancedRender, ResourceRuleForm / ResourceRuleFormsRender, RuleTablesAddsNothing, BasicFormPeoplePicker.
• Guards: form/route guards taught the Creator's Team and the preview routes (ResourceRuleFormsGuard, OwnersFieldGuard, DeclareAndCreateFormsGuard, ExpiredSessionRouteGuards, ProjectScopedApiTenantHeader, ...).
• Browser (offline fixture, Chromium, 22 tests): packages/E2E/OwnersOnCreate - npm run test-owners-on-create-ui, added to CI group 5 with its screenshots uploaded. The real Declare Incident, Create Alert and owner rules pages over an in-memory project: folded Owners, Your teams, Add all, the review's rules and what the preview is asked, what a create sends, slow / failing / denied previews, the rule form's Creator's Team (save, Edit reads it back, Adds nothing), at 1280 and 390 px, dark, German.
• Docs, 17 languages: Declaring an Incident (Owners bullet, "Who will own it", the API), Alerts, Alert Episodes, Label and Owner Rules ("The creator's team", the new refusal), the incident owners page and both rules settings pages.

What ran

• Common: every suite above, npx jest Guard (162 suites), the listed gates (RelationListReadCoverage, PlanGatedTableLeftovers, PageSearchIndexCovers*, Update/DeleteChecksReadHeldRows, HookWritesCallersMayMake, ListOrderColumnModels, PermissionCatalogueCoverage, SchemaMigrationsOnlineDdl/Ordering), npm run compile, npm run compile-tests.
• App: compile, root tests, Short/Card description guards, NormalizeListOrder, the docs suites for every page touched plus the all-pages ones, docs:check-anchors, i18n:check / i18n:extract / i18n:validate; no cross-package imports in tsc --listFiles.
• E2E: the whole new suite, 22/22.
• Migrations from scratch on Postgres 15 + the schema drift check.
• Prettier and ESLint on every changed file; the regex timing checker (no new non-linear pattern outside tests).

UI review

What I looked at. The real pages in the offline fixture (Chromium, Inter, Tailwind), at 1280 and 390 px, light and dark, English and German: Declare Incident, Create Alert, Create Incident Episode and Create Alert Episode - the Owners field folded and open, Your teams for someone in no team, one, three and eight teams (long names), and the summary's Owners row with rules, with owners already picked, with every owner picked, while it checks, when it fails, when the person may not read the rules, and with nobody picked. The incident and alert owner rules pages: create, edit, a rule's own page, the table's Adds nothing. Also the feed note a creator's team rule writes, the in-app help on both rules pages, and the English and German docs pages.

What I changed, and why.

• A rule's line on the summary no longer repeats owners already picked. With Platform picked, a rule that brings Platform and Database read "Platform, Database" right under "Platform". Each line now names only the people and teams the rule adds that are not owners yet. It leaves out the owners picked and the person creating an incident or alert, since OneUptime adds an owner only once. When that leaves nobody, the line says Everyone it adds is already an owner. The rule still has its line, because it still runs. (getOwnersNewFromRule)
• A master admin is no longer told they become an owner. OneUptime never makes a master admin the owner of what they create (DatabaseService.autoOwnerOnCreate), and the first person to sign up on a self-hosted install is one. They now read Add your team, or anyone else who should own it., and the summary says Nobody picked. A rule that names them still lists them.
• The summary's rule-name column is wide enough for the default name Add the creator's team as an owner to fit on one line (w-56 to w-64, measured at 237 px in Inter).
• The summary's rules list is labelled by its Added by owner rules heading, so a screen reader announces what the list is.
• The incident and alert feed note now reads "...is a member of them." instead of ending on "...is a member."
• The help on both owner rules pages describes the creator's team in plainer words.
• FormSummary now gives each step a key. React warned "Each child in a list should have a unique key" on every stepped summary, on every create form.
• Two new Dashboard strings, translated in all 17 locales.

Left alone on purpose.

• Create Alert Episode keeps Owners visible on its On-Call & Owners step, while Create Incident Episode folds Owners under More fields as Declare Incident does. Moving the alert episode's field would change a form people already use.
• The Inherit Owners fold line keeps the builder's words, which match its sibling Inherit Labels lines.
• Shared form fields never link their description to their input for screen readers (no aria-describedby anywhere in FormField). That gap predates this PR and is not specific to it.
• The docs still say "you become an owner whatever you pick". That is true for everyone except master admins, and the form now tells master admins the truth.

Tests I added or changed.

• Common/Tests/App/Dashboard/OwnersOnCreateRules.test.ts: getOwnersNewFromRule (picked people and teams, the creator, any id shape and case, nobody new, the rule left unchanged), and the master admin case (isCreatorMadeOwner, the field line, the nobody-picked text).
• Common/Tests/App/Dashboard/OwnersOnCreateForm.test.tsx: a rule's line names only new owners, says so when everyone is already an owner, and leaves the creator out. Also the master admin's summary and field line, and the list's accessible name.
• Common/Tests/Server/Services/RuleRun/IncidentAlertMaintenanceRuleEnginesRun.test.ts: the feed note's whole sentence, for incidents and alerts.
• E2E/OwnersOnCreate (offline browser suite, CI group 5): 27 tests in about 59 s, up from 22 in about 46 s, so roughly 13 s added. New tests cover a rule whose owners are all picked, Platform no longer repeated, a master admin, and Create Incident Episode (folded Owners, Your teams, the summary's rule, the preview route, the owners the create sends). They also cover Create Alert Episode (Owners on On-Call & Owners) and a rule's own page listing its Creator's Team. The fixture now serves both episode forms and the rule page route, and takes ?admin=1 and ?teams=lots.

What I ran. Offline browser suite 27/27. Common: the 17 suites that read the changed files (847 tests), npx jest Guard (162 suites), npx jest Locale (38 suites), npm run compile, npm run compile-tests. App: npm run compile, the root tests, DashboardLocalesGuard, ProjectScopedApiTenantHeader, the description guards and npx jest Locale (30 suites in all). E2E npm run compile. i18n:extract (nothing new), i18n:check, i18n:validate, the regex timing checker (nothing new), and prettier and eslint on every changed file. The three Common suites I changed also ran with ee/ hidden. Master had not moved since the builder's last merge, so no new merge was needed.

🤖 Generated with Claude Code

[simlarsen]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.