Description

Summary

Introduce a virtual System user, displayed as the author of the changes that no human made by hand (page initialization, data migrations, background processing, installation of the distribution). Superadmin goes back to its original role: the recovery account used when nobody can log in anymore. Only what a human does while logged in as superadmin is attributed to superadmin.

The System user is only ever the original author of a change (the one displayed as having triggered it). It is never an author whose rights apply, it holds no rights, it cannot log in and no code runs as it.

Context

Automatic changes are attributed today to whoever happens to be at hand:

• XWiki#saveDocument never sets an author, so an automatic save that doesn't set one explicitly is credited to the last person who edited the page. This is what happens when a mandatory document initializer updates an existing page (a new class field, for example), for almost all data migrations, and for many background listeners and stores (scheduler job status, average ratings, certificates and keys stores, configuration pages, objects updated after a class rename, …). Users see in their history and notifications changes they never made (see for example XWIKI-15760).
• Pages created by the platform (mandatory document initializers on creation, pages installed by the Distribution Wizard, a new wiki's extensions) are attributed to superadmin. Users don't know what "superadmin" means, and superadmin is also a real account that an administrator can log in with, so automatic changes and the actions of an administrator using that account can't be told apart.
• Some extensions that store the results of a background analysis on pages (e.g. the Documentation Application) also use superadmin as the displayed author, for lack of a better identity.
• The notifications filter that hides "system" changes (SystemUserNotificationFilter, XWIKI-14564, 9.7) hard-codes superadmin as "the system user".

Prior discussions

The topic has come up several times, without a decision on a dedicated user:

• 2009 — [VOTE] Change the default author of documents created programmatically or provided in XARs: a "System" user was considered first, superadmin was chosen ("we already have a 'system' user, it's superadmin"), with the concern that a "System" name could collide with an existing XWiki.System page.
• 2015 — Using superadmin author for pages not imported at runtime: "superadmin" means nothing to users; we'd need two users, a System user one can't log in with, and SuperAdmin; display and localization to be designed first.
• 2016 — Issue with installed count on e.x.o: a reserved, virtual "System" user, with System changes filtered out by default.
• 2017 — Make extension pages author superadmin when current user have programming right (XWIKI-13974): System user preferred over superadmin; risk of collision with an existing user.
• 2021 — Introduce a XWikiDocument#displayedAuthor (XWIKI-19125, 14.0): introduced the original metadata author (displayed) separately from the effective metadata author (rights), which is what makes this proposal possible without touching rights.

Definitions

System user

The identity shown as the author of an automatic change. It names who triggered a change, never who is responsible for it in terms of rights.

Superadmin

The recovery account with all rights, normally disabled, used when no administrator can log in.

Automatic change

A change no human asked for. A side effect of an action a human asked for is attributed to that human (e.g. the backlinks updated when a user renames a page).

Original metadata author

The author who triggered a save, displayed as the author of the change (history, page header, diff, notifications, search).

Effective metadata author / content author

The authors whose rights apply (to the objects and to the content).

Proposal

1. A virtual System user

• A new SystemUserReference.INSTANCE, like SuperAdminUserReference and GuestUserReference: no user page, so it can't be edited, deleted, enabled, given a password, added to a group or granted rights.
• Reserved name XWikiSystem, stored as XWiki.XWikiSystem (same convention as XWikiGuest, in the XWiki* names already reserved by the platform).
• The name is reserved in every place where users are created (registration, administration, the user creation API, authenticators, imports), through a single check shared with superadmin and Guest. Today only the registration form refuses the reserved names.
• No automatic detection of an existing XWikiSystem user: the release notes ask administrators to check they don't have one.

2. Rights rules

• The System user is only ever the original metadata author. It is never the effective metadata author nor the content author.
• The authorization manager denies every right to the System user, unconditionally (the mirror image of superadmin which is allowed everything). This holds whatever the data says, including documents saved by older or misbehaving code.
• Setting the System user as effective or content author logs a warning.
• Code is never executed as the System user: background code keeps running as it does today.

3. Authors of an automatic change

The change is a minor edit by default.

4. What is an automatic change

5. Display

• Virtual users are displayed through their user properties instead of their raw page name: the System user as a translated "System", superadmin as "SuperAdmin", Guest as "Guest". This applies to $xwiki.getUserName / getPlainUserName, #displayUser and the Live Data user displayer.
• The System user is displayed as plain text, without a link (it has no profile page).
• System, superadmin and Guest each get a dedicated icon, different from each other and from the image used for users without an avatar, so that one can see at a glance that a change wasn't made by a regular person. The visual design is to be done by the UI/UX team.
• The System user is never offered in user pickers.
• The places that today display the effective author as "last author" switch to the original author, like the page header, the history and the diff already do: the livetable / Live Data doc.author column (display, filter and sort, in its central implementation so that all applications follow), meta.vm, the PDF cover and the document index. The REST API and HQL queries are unchanged. This also fixes an existing inconsistency (adding a comment or a tag changes the page header's author but not the "last author" column) and can be done first, independently.

6. Notifications and activity

• Document events already record the original author, so automatic changes appear as made by System.
• The "hide system changes" notification filter hides the events of the System user and, during a transition period, those of superadmin, so that extensions still saving as superadmin don't suddenly flood notifications. An xwiki.properties setting (e.g. notifications.hideSuperAdminEvents, default true) lets administrators show superadmin's actions right away. No end date is set for the transition for now: it depends on how fast extensions migrate.
• To find the extensions to migrate, a deprecation warning is logged when a page is saved with superadmin as original author while the current user isn't superadmin (i.e. superadmin used as "the system").
• Known limitation: events that aren't document changes record the user the code runs as; background code that runs as superadmin and sends such events stays attributed to superadmin.

7. API

• Java: SystemUserReference.INSTANCE (user API), and one helper applying the rules of section 3 (exact name and location to be decided during review), used by the platform (initializers, migrations, listeners) and by extensions.
• Scripts: $services.user.systemUserReference, read-only (for comparisons and display). There is no script API to save a change as the System user: attributing a change to the System user hides it from notifications by default, so it must not be available to regular editors. Code that needs it must have programming rights (it already needs them to reach the XWikiDocument).

8. Existing data

Nothing is migrated. Existing pages, revisions and events keep their author: nothing in old data tells an automatic superadmin change apart from a human one, and history must not be rewritten. Only new automatic changes use the System user. Pages whose effective author is superadmin keep their rights as today.

Relation to other proposals

• Deprecate the effective metadata author, synchronizing it with the content author: compatible and independent. That proposal keeps a rights author and the original (displayed) author; this one only ever uses the System user as the original author, never as an author whose rights apply.

Out of scope

• The user under which the Distribution Wizard and the Extension Manager install or upgrade extensions, and the author of pages installed or upgraded by a user from the Extension Manager: Thomas has a separate proposal about it (we couldn't find its link at the time of writing), which shouldn't be mixed with this one. This proposal only changes the displayed author of the pages installed by the Distribution Wizard and on wiki creation (System instead of superadmin); the user they are installed with, and so their rights, stay as they are.
• Running background code as the System user (instead of superadmin or the current user): a much larger change touching the rights model.
• Hiding or collapsing System revisions in the page history, and filtering "last author = System" in Live Data: possible follow-ups.

Implementation plan

Phases 0a and 0b are independent from the System user and have already been filed: XWIKI-25307, XWIKI-25308, XWIKI-25309, XWIKI-25310.

No database schema change and no data migration are needed.

Open questions

• Name and location of the helper for automatic changes.
• Should "System" be selectable as an author filter (e.g. to list the pages last changed automatically)?
• When should superadmin stop being hidden by the notifications filter?