[RFC] Consolidate users in a single table
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 36.9k
- Forks
- 5.2k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 713
Description
Idea
Have a single trusted table for users.
It should contain:
- id: Snowflake ID, can be used later as foreign key
- login: current uid
- email: user primary email address
- status: enabled/disabled
- source: provider who created the user (Database, LDAP…), maybe with a
last_sync - last_seen: timestamp of last ping on Nextcloud (not updated on all requests)
- last_login: last successful connection on Nextcloud
Why
It's often difficult to find information about users because it needs to fetch information from several backends.
Examples:
- is this user exists? We have to check in all backends
- is this user disabled? It's stored as a preference
- get a list of user who actually connect? Also a preference
- search a user? We need to search in all backends
This table should be a single source of truth for users.
The related class can cache users so it becomes easier to know if a user exists or not.
Challenge
External backends like LDAP can add and remove user at any time. Our table must stay in sync with the backends.
This can be a background job but we have to find a good frequency.
It will introduce a latency between user added/deleted from backend and user actually in Nextcloud database.
The class should probably introduce a fallback for some important operations like login.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by mapping the existing user backends, preference-based status and activity data, and the login path described in the issue. Define the table's ownership and synchronization behavior, including external additions and removals, background-job frequency, and login fallback before implementation. Done means the design resolves these trade-offs and identifies the affected components and validation approach.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- authentication, backend, databases
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100