Posted by heyrocker on August 24, 2012 at 2:55pm
25 followers
Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | user system |
| Category: | task |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | Configuration system, d8dx, Needs issue summary update |
Issue Summary
Currently user_roles is a weird bridge between the list of available roles (which is configuration) and the user (which is an entity). I suggest we move a user's role assignments to the user entity as a default field. This implementation would be similar to the one I proposed for path aliases in #1751210: Convert URL alias form element into a field and field widget.
- Add a multi-instance text field to the user entity, which has a select list of available roles (which will be stored in CMI).
- Set this field to be Format: Hidden by default in all view modes
In the aliases issue I suggested saving the aliases out to denormalized storage for the purposes of performant reading, but I'm not sure that is necessary here.
Comments
#1
I think we should add a fapi element and a field type while we're at it, like we did for language. Ie a role reference field type and a #type => role
#2
#3
So chx tells me this is next on my hit list ;)
#4
Note this dependent on #1479454: Convert user roles to configurables
#5
Tagging as needing to be done by feature freeze
#6
Are you still on this marcingy? Otherwise I can take over and work on a patch on monday.
#7
@Fubhy feel free to work on it I got distracted by some other core stuff. If you don't get to it I will have a look after badcamp.
#8
Okay. Assigning this to me then. :)
#9
Something bugs me big time here, which makes me believe that this is architecturally not correct. I'm not yet sure what exactly, but let me try:
1) A Field API field (not extra field) can be removed. We don't want that.
2) Anything field-related is a huge dependency. Which might not be available early enough.
3) Field module is a module. Modules can be disabled. User roles are a critically important part of the user system.
4) The summary talks about a multi-valued text field with a select widget. That inherently means additional dependencies on Text (field type) and Options (field widget) modules.
5) We don't want to store user role assignments in a field data table.
6) Field values are translatable and automatically get revisioned, depending on the attached entity. Are field modules able to force-opt-out of these features? I don't think we want translatable user role assignments, nor user role values to be revisioned.
#10
Here's the current plan about fields/properties, which I think would quite nicely address sun's concerns.
The property api has been renamed to field API, the idea is that everything is a field, while the current fields are renamed "configurable fields". The basic idea is that everything that's added by the module and can't be removed is a field, all entities have these, while the current "fiedable" will be renamed to "configurable". Fields can be per-language/revision/multiple as required, but don't have to.
I'm not sure yet how exactly we'd handle the storage of this, but we could make roles such a field on the user entity, probably even keep the existing table, at least for now.
So the answer to sun's points based on this would be:
1) Entity fields are handled by the storage controller. The plan is/was to change configurable fields to this as well, although I don't see how we're going to manage that in the remaining time :(
2) See above. Non-configurable fields are available as early as the storage controller.
3) Same.
4) Not sure how the UI would be handled, could be kept custom for the moment?
5) Could stay in it's own table I think.
6) See above, we could make this field multiple but not per-language/revision.
There are quite some dependencies to take care of before this can happen though, including converting user to EntityNG and either the session refactoring or that other issue that would remove the user dependency from session.inc. But we could maybe also keep it as a custom "special" table and add it to $user without calling it field :)
#11
#10 gets it - so yep, we can implement a field (as defined by the new entity field API) without having to make it configurable. It can come pre-defined with user entity type only.
I'd not suggest that, as it would not be properly part of the entity any more then, e.g. it won't be handled by the entity serialization and REST service.
Yes, we don't have to use field API widgets then. Moreover, it won't work right now as afaik field API is not refactored in any way yet to support non-configurable fields as well.
Yep.
#12
Are user roles becoming configuration entities? If so, we should even be able to use the entity_reference_field field type we already have (for stuff like $comment->nid).
#13
@fago, yes... that issue is over here: #1479454: Convert user roles to configurables
#14
Clarification: I meant that to be a temporary solution until the necessary dependences are resolved, because they are non-trivial.
#15
This is my current understanding after talking to heyrocker.
#16
Roles as CMI and user_roles as entity fields makes a lot of sense. Keep going!
#17
Yeah, I got a bit delayed on this because of the roles as CMI / permissions on those roles / etc. introduces a pretty heavy early-bootstrap dependency on entities. Which breaks in a few ugly places in core (update.php, authorize.php, etc.). Will look into that again after the weekend. I hope that I can unblock that somehow.
#18
Talking to heyrocker, he says we basically have to do this or we have no way to deploy user/role assignments.
#19
Yep! I want this to land too, however it is currently blocked by #1818570: Convert users to the new Entity Field API (which should wait for #1818556: Convert nodes to the new Entity Field API to land) if we wan't to do it right. Otherwise we will indeed run into the issues mentioned in #9.
#20
Going to start on a none entityNG version just to get this started, I realise this may mean some re-roll fun but.....
#21
I'm not sure if that is useful.
The EntityNG conversion of users will *require* (at least the full conversion, possibly not the initial BC decorator based on) that this is a field, a field in the NG sense, which means that it has to be defined with hook_entity_field_info() and an item class needs to exist. See PathItem in the taxonomy term conversion issue for $term->path.
#22
Ah, my ignorance of what EntityNG fully is strikes. In that case it sounds like I should start attempting to tackle the conversion issue for user if I want to help push this forward. First task get up too speed with EntityNG.
#23
Tagging for issue summary update - see https://drupal.org/issue-summaries