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
mail
theme
signature
signature_format
created
access
login
status
timezone
preferred_langcode
preferred_admin_langcode
picture
data
uid
username (previously name)
pass
created
init

Comments

andrewbelcher’s picture

I'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 and status move into user rather than account.

andrewbelcher’s picture

Issue summary: View changes

Added the list of items

rlmumford’s picture

This 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:

users accounts
uid
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
uid
username (previously name)
pass
created
theme
login
init
timezone
preferred_langcode
preferred_admin_langcode
andrewbelcher’s picture

I 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...

rlmumford’s picture

One 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:

  • Translation
  • Timezone
  • Theme

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)?

andrewbelcher’s picture

One 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.

This 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.

andrewbelcher’s picture

Status: Active » Fixed

Ok, decision is that we will go with the separation:

users accounts
uid
uuid
name (now a nice name)
langcode
mail
theme
signature
signature_format
created
access
login
status
timezone
preferred_langcode
preferred_admin_langcode
picture
data
uid
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

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Moved login and status into user