It was discovered when writing the MongoDB user storage that User::preCreate() always adds the authenticated user role, to the list of roles for a user. Always? you ask, you mean, except for the anonymous user, right? No, I mean always.
$anonymous = User::create(['uid' => 0]);
$roles = $anonymous->getRoles();
$roles === ['authenticated'] // TRUE;
This could be fixed by checking the user ID in User::preCreate(). Instead I propose removing that code and adding the appropriate role (DRUPAL_ANONYMOUS_RID and DRUPAL_AUTHENTICATED_RID) in User::getRoles().
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2374081-3-user-pre-create.patch | 3.47 KB | tstoeckler |
Comments
Comment #1
chx commentedThis is why you need alternate storage engines in core.
Comment #2
tstoecklerThe reason this currently works is because core's
UserStoragedecides to never save the authenticated and anonymous users, so this never gets persisted.Comment #3
tstoecklerLet's see if this works.
There are a bunch of changes which seem out of scope speaking strictly in terms of the bug in the issue summary, but in terms of making
UserStorageindependent of this I would consider them in scope. NowUserStorageknows nothing ofDRUPAL_ANONYMOUS_RIDorDRUPAL_AUTHENTICATED_RID. Storages now just need to remember to callgetRoles(TRUE).On an also related note: Is it just me or is a parameter name called
$exclude_locked_roles = FALSEbackwards? Wouldn't$include_locked_roles = TRUEbe more self-including, which would make the caller dogetRoles(FALSE). Thoughts?Comment #5
berdirWould be great to focus on #2248977: Complete support for multi-value base fields in ContentEntitySchemaHandler and use it for the user.roles field if that is still doable, because that is fixing up a lot related to users/roles.
Comment #6
berdirOk, that issue is RTBC, as soon as it is committed, we can close this as a duplicate I think.