Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I think we need to sure up exactly what the roles of user and account are to be able to answer things like what fields go on which etc.
users | accounts |
---|---|
uid uuid name (now a nice name) langcode theme signature signature_format created access login status timezone preferred_langcode preferred_admin_langcode picture data |
uid username (previously name) pass created init |
Comments
Comment #1
andrewbelcher CreditAttribution: andrewbelcher commentedI'm aware that we'll be very closely linked with the move of profile2 into core, so some of these fields may move into profile2s, but I think we should keep the two bits of work separate for now...
Here would be my understanding:
user: This represents the user, logged in or not in all their wonderous glory and interaction. Thus things like language, theme etc are all part of a user. This is the bit that is passed round in the session etc etc. External authentication systems will authenticate you for this user as would the internal authentication system.
account: This is the method for authenticating that you are the user. This is purely authentication and is irrelevant for everything else.
As such, I would propose that
login
andstatus
move into user rather than account.Comment #1.0
andrewbelcher CreditAttribution: andrewbelcher commentedAdded the list of items
Comment #2
rlmumfordThis is interesting. My understanding is a little different. This is how I see it:
user: only contains things that every user will need, anonymous or not.
account: holds everything to do with being a logged in user. Any account settings such as language, theme, and timezone should go here. (They don't really make any sense for the anonymous user to have).
If I'm right, the table above looks like this:
uuid
name (now a nice name)
langcode
mail
signature To be moved into fields/profile2
signature_format To be moved into fields/profile2
created
access
status
picture To be moved into fields/profile2
data
username (previously name)
pass
created
theme
login
init
timezone
preferred_langcode
preferred_admin_langcode
Comment #3
andrewbelcher CreditAttribution: andrewbelcher commentedI think I'd like to start off with the separation I described. This allows us to get our changes in without having to make lots of changes to lots of different systems. By putting things like timezone onto account, it means anything that makes use of the user's timezone will need patching. However, with only separating out authentication stuff, it should just be authentication that needs tweaking, plus some UI bits.
We may also decide that we want to separate our the logged in user bits, in which case we could do that into another entity that will attach to the user that only gets created for users that log in...
Comment #4
rlmumfordOne of the advantages of the separation I'm suggesting is that theoretically any module could replace the account system completely or you could turn accounts off without having any extra cruft stored in the User table.
As far as I can tell, my way of thinking is complicated by three features of core drupal:
What we're doing with this sandbox is seeing if we can turn the User entity into a generic "this is a Person in the real world" thing that can then be extended by other modules "attaching" entities to it. Profile2 is module that extends user to store information about it, Account is a not- module that extends users to be able to log in. Should the 3 modules above be modules that extend user to do something clever (either by adding fields or other entities)?
Comment #5
andrewbelcher CreditAttribution: andrewbelcher commentedThis isn't quite true, turning off is fine with yours, but due to storing some of the items in accounts that will be relevant for any authenticated user, you'll be forcing other account implementations to duplicate those in their stuff.
Comment #6
andrewbelcher CreditAttribution: andrewbelcher commentedOk, decision is that we will go with the separation:
uuid
name (now a nice name)
langcode
mail
theme
signature
signature_format
created
access
login
status
timezone
preferred_langcode
preferred_admin_langcode
picture
data
username (previously name)
pass
created
init
This allows account to be purely authentication. There is then a follow up for cleaning up the User entity: #1813046: Clean up the user table
Comment #7.0
(not verified) CreditAttribution: commentedMoved login and status into user