Recent Changes - Search:
PITS /

01533: Scalable user management and analytics wishlist

Summary: Scalable user management and analytics wishlist
Created: 2025-12-21 19:48
Status: Open
Category: Feature
From: Petko
Assigned:
Priority: 5
Version:
OS:

Description:
Discussion about what features would be required for a modern, scalable user management for PmWiki.

Context:

  • PHP 8.4 and more recent have made it slow and impractical to use multiple shared passwords on the wiki.
  • Shared passwords may be simple and reasonable for small trusted teams but review and accountability may be more difficult.
  • Usernames and Usergroups, integrated into AuthUser, provide a flexible and reliable workaround.

Problem:

  • AuthUser is very extensible but out of the box user management is manual and tedious.
  • Current best security practices are not available in PmWiki, either out of the box or via extensions.
  • Analytics/statistics are not easily available.
  • User preferences are not obvious to configure.

Notes:

  • Email addresses are "personal information" per the GDPR, and may require users to agree to this, requirement and disclosure of secure storage practices.
  • So are IP addresses, which most servers store for troubleshooting purposes.
  • Autologin by IP address may also fall in this case.

Possible features for consideration:

  • Users should be able by themselves, without involving the administrators, create their own accounts, select a password, change their password, recover a forgotten password, update their email address.
  • Rich text emails for these notifications (wiki logo, links, bold, additional legal information, unsubscribe).
  • New user accounts could be approved automatically, or held for approval by the administrators. Self-creation of accounts may be disabled, with only administrators able to add accounts and invite users. This may be per wiki or per wiki group.
  • Users should be able to request account deletion.
    • What happens to page history metadata if a user deletes their account? The copyright of collective works lasts for 70 years after publication. Upon deleting the account, the system can go through all user contributions and anonymize the Author
  • To simplify administration and optimize searches and pagelists, drop per-page permissions, only apply per-group permissions (GroupAttributes)?
  • User settings page for preferences, language, 2FA, change email/password
  • User contributions (edits, uploads, talk pages, admin tasks, totals)
  • User watchlists, possibly with email notifications.
  • Is a user profile page necessary? Some FTP servers cannot list more than 1000 pages in a directory, even if per-group storage is enabled, it may be impossible to do backups of such servers.

Pre-defined user groups under consideration:

  • reader (can read, download, search)
  • writer (can edit, upload, see/edit talk pages)
  • editor (publisher, moderator, can approve draft pages, review pages, set page status).
  • administrator (user manager, role may be delegated per WikiGroup).
  • developer (can edit the user interface under Site and SiteAdmin).

User groups based on WikiGroups:

  • For the group Main, the system should allow easy setting for a user: @Mainread, @Mainedit, @Mainpublish, @Mainadmin
  • Temporary/expiring permissions, e.g. @Mainread-2026-06-30

New security features under consideration:

  • User forgot their password can receive via email a random code to prove they own the account, then they can select a new password.
  • Restriction of email address domain names, e.g. corporate or industry email addresses.
  • Enforcement of long passwords or passphrases per the current industry best practice advice.
  • Enforcement of recent, secure hashing functions.
  • One-time passcodes for account recovery.
  • Multi-factor authentication with a TOTP Authenticator app.
  • Passwordless sign in with passkeys (biometric, pin).
    • A user should be able to add and revoke passkeys from different devices.
    • A desktop user should be able to authenticate with a passkey on a mobile phone
  • Autologin - Passwordless read-only access from corporate IP address or VPN.

Analytics wishlist:

  • It should be good enough so a wiki does not need to install external trackers and analytics. Also Privacy-enhanced, compatible with the GDPR.
  • WikiGroup-centered statistics, unlike Google Analytics or others.
  • Page visits, edits, file uploads, downloads (if enabled), admin actions.
  • Monthly statistics, totals for the WikiGroup, and monthly numbers per page.
  • User permissions in the stats:
    1. Protected page, user has no access
    2. unprotected page
    3. autologin user, opening a protected page where they have access
    4. authenticated user, has read permissions for the page
    5. authenticated user, has write/upload permissions for the page
    6. ?
    7. ?
    8. authenticated user, administrator for the wikigroup (can approve other users)
    9. ?
    10. developer
  • Per-user statistics - page edits, uploads, admin tasks
  • Tables and Charts:
    • Per Wiki group, available to editors/admins
    • For the whole wiki (compare wikigroup performance) available to developers
  • Search cloud - search terms, more popular in bigger font
  • External referrer websites. This may not be very reliable as privacy features set by users (in their browsers) and by remote websites may disallow sharing that information with the wiki.

Sample analytics chart: