Add bundle support to user entities

This sort of thing is probably better done with roles -- because what if you wanted one user to be of several different types?

I agree with Joachim, multiple bundles for a user entity sounds highly problematic from an architectural point of view in terms of flexibility.

This introduces the question should roles become enitities and hence fieldable on a pre role basis?

Well one big advantage of having bundles on users is that you can have different fields on different user bundles.

Sure things like this could be done with content_profile as well.

Content profile allowed users to have multiple profile nodes, which would collerate to roles as I see it.

I think I saw a sandbox project which tried to implement user bundles, but I can't find it anymore.

Bundles would be quite interesting. Roles are for permissions, bundles for fields ..

It would be very nice if we could have user bundles with their specific fields and associate roles with these bundles. Of course, it should be possible to have multiple roles asociated with a bundle.

Are there any cases this model doesn't cover? Can't think of one ...

Hah! Found the sandbox project: http://drupal.org/sandbox/yakoub/1259918.

I do see this as a useful ability. Suppose you have two user bundles:

• Employer
• Employee

You would want to provide a field on the employee to link it to an employer. You wouldn't want the same field on the employer.

You might argue that an employer shouldn't be a user, but if you want to be able to provide a company with an account that a designated representative can use to update company details, it seems logical for it to be a user.

Also separate bundles means you can provide separate UIs for adding/editing different types of user.

I would agree this is a fringe case as most people would not be wanting to have multiple types of users. However, it would be useful to make it possible for those who want to do something like this.

I think that there is a place for user bundles, but not in every case.

Consider the following users:

Philosophy department
John Smith
Sally Smith

The Philosophy department may be an instance of the "Department" user bundle
John and Sally may be instances of the generic default "User" user bundle.

John may have the roles "Student" and "Undergraduate student"
Sally may have the roles "Student", "Graduate student", and "Part-time employee"

This is only after a moment of thought. I suppose my thought is that user bundles are useful for distinguishing between types of users (person / department / company), while Roles are useful for distinguishing between sets of permissions within a particular type.

I've submitted a patch which will hopefully represent the beginning of an attempt to make user bundles a possibility in Drupal 7, which is at #1399798: Anonymous user properties are hardcoded .

For these use cases, just use profile2. (Please test on a dev server, as uninstalling these class based modules can be a nasty affair - fatal errors, etc). Also, yakoub appears to have dropped his sandbox project

Allowing entities to belong to multiple bundles would be much more exciting and useful for users! A single user could easily be an employer and an employee! ;) It would be great to see this in core and this would probably be easily extended out into a Profile like user category implementation.

Although profile2 is a useful module, it is not suitable for our needs. We absolutely must have bundles on users.

Users are entities, and entities can have bundles. Currently the way Drupal 7 core is written, users cannot have bundles. I don't believe this is right, hence the creation of #1399798: Anonymous user properties are hardcoded .

The profile2 data structure involves creating a new profile entity (or more than one), and linking it via reference to a user entity. If this was useful in all situations, I would say that if you wanted to have, say, more than one bundle of the node entity, you would create a separate entity and reference that to the node. If you wanted to have, say, more than one bundle of the comment entity, you would, again, create a separate entity, and reference to the comment entity, like the way profile2 works.

The entity system obviously doesn't work in this way. It works in the style of nodes that can have node types, comments that can have comment types. Using a separate module to change this internal structure, purely on the basis that core wasn't written to allow users to have types, is, in my opinion, not a valid way forward.

Re: #10--Having multiple bundles per entity doesn't quite make sense, no more than having multiple content types per node makes any sense. What you are describing sounds like roles or a user taxonomy.

@xjm This is a left field idea, but is fundamentally it is just an implementation of object composition using the existing Drupal framework. For the site we are working on, there are about 30 content types, 27 share the same base 6 fields that defines a simple page (body, featured image, images, ...). If multiple types were allowed, then each of these would implement a basic "standard_page" content type interface. Then we have 4 event based types, each with a vastly different field array. But all 4 share the same base 10 fields. We attach resources to 22 of these types (links array and file resources), again a candidate for this...

This would make the learning curve for Drupal via the UI even steeper, and would probably add a heck of a lot of complication internally, so while it would be nice, I wouldn't push this feature request!

But yes, for users, field access restrictions + roles would easily fulfill the requirements above if you didn't want to use profile2 module :)

> If multiple types were allowed,

See the bundle inheritance issue, where fago makes the interesting suggestions of using mixins for bundles.

@joachim Thanks for the link! I've posted a brief argument there for composition rather than inheritance. Things get so highly coupled and fragile using inheritance.

#100925: Add "OO" bundle inheritance features and Bundle inherit project

What would there be need for in order for the solution of the issue to go on?

Well, there's no patch in the issue, so it isn't going anywhere without that. Also, I don't think there's consensus yet that this is a good idea, but we will easily debate in circles forever until there is a specific patch to evaluate. :)

I see that the main problem to implement user bundles seems to be the user roles, but why we can't have both?

Maybe users can have multiple roles and at the same time can have multiple bundles, if some fields has to change any behavior per role there is no issue because that can be handled programatically.

related issue:
Drupal 7 - #1399798: Anonymous user properties are hardcoded
Drupal 8 - #1361228: Make the user entity a classed object

Why aren't the roles themselves the bundles? You usually want to add new permissions and information onto users in the same fashion. e.g. Blog Writers get new permissions and the new fields needed to display their author/user profile on the blog posts.

Attach fields to roles and not users. The only problem i see is multiple roles but that could be easily solved with fieldgroups/tabs for each role on the UI side at least.

> Why aren't the roles themselves the bundles?

Because an entity only has one bundle, and can't change bundle.

Users have multiple roles and change them.

What would there be need for in order for the solution of the issue to go on?

I agree with #11 chriscohen
I need also bundles for user entity...

I can bring another example becose having user's bundles is a nice idea.

Im building a small crm to handle invoices, so we have basically 2 kind of users: Customers and Staff.

Customers must have the company, billing and shipping information (entities + entity reference field), while staff should have contacts (email, skipe, phone, etc..) 2 images (logotypes used in the invoice) and so on.

Permissions/roles are a different thing, even if customer roles could be kept separate from staff's roles, that is just a matter of convenience.

At the moment, i'll add both fields to the users, and using form api and css remove/hide them based on the user's type (that is itself a taxonomy field), but it is somethign very ugly.

We're facing a serious logical flaw and conflict here, because the profile2 in core patch was essentially rejected

because you can have fields on users

— but without bundles, that is not a comparable substitute at all.

Second, we can only remove hook_schema_alter() from core if all core entities have support for bundles, so that no contributed module has a need to inject a 'bundle' column into a core entity schema.

I wonder how trivial a patch for this issue can be today?

> — but without bundles, that is not a comparable substitute at all.

Even with bundles, it's not a comparable substitute. You can still only have one user entity for a user. And you can't change its bundle.

Same situation with files.

looks better to file separate issue for files

Second, we can only remove hook_schema_alter() from core if all core entities have support for bundles, so that no contributed module has a need to inject a 'bundle' column into a core entity schema.

This argument is no longer valid, that hook no longer exists file_entity provides that this is still possible without that hook.

Given that, I don't see how this is a major task or even a task at all.

No more valid, cos "file_entity" does that

Re-opening. Suggest breaking the similar file entity issue into a dedicated, separate issue (if it still exists). A few points with regard to user bundle support:

- Adding bundle support to users doesn't really have anything to do with roles and permissions. Roles and permissions are a neat feature tied to user entities, regardless of type.
- You can change an entity's bundle programmatically (at least in D7 - I haven't tried this yet in D8). But that's beside the point. I think the goal of this issue is to add bundle support to users - not to add a bundle-switching UI or API (that's really getting fringe and probably belongs in contrib for now).
- While we can work around the lack of user bundles with modules like Profile/2 and Field Permissions, we're essentially just working around this oddity in our system. Every other entity type in Drupal enjoys native bundle support - but for some reason not users...

I think we should add bundle support to users. I'm not sure how many of us are out there, but It would be a real benefit to the project I'm working on.

The attached patch brings bundle support to User entities in Drupal 8.6.x. Needs review.

With this patch:

- You can now create additional types of users in Drupal
- Each user type can have its own fields and display configuration
- You can indicate which type of user the registration form should create

Here are some screenshots:

- This is integrated with views and relevant views are updated
- This is integrated with token
- Routes / links / tasks / actions are updated
- Help text is updated
- Some backwards compatibility is in place
- Many tests updated

I intend to test this patch more rigorously over the coming months, and improve it. If you feel like lending a hand - here are some remaining @todo's:

- Kick the tires
- Test user migrations
- Does anyone know how to update views-config on existing installations? I'm not sure it's 100% necessary or possible, but getting the "Type" column and filter into the People view for existing installs would be a nice touch.
- Test and improve backwards-compatibility with external, bundle-unaware code
- Add a deprecated layer onto user creation that specifies the default "user" bundle when not provided (currently if you attempt to create a new user and don't specify the bundle you'll get an error).
- The field UI routes for user types now require the "type" (bundle) parameter. I've got a deprecated backwards-compatibility layer in here for old links but something that would work for Url::fromRoute would be great to have in here too. I tried altering the affected routes via a route subscriber and adding a bundle default, but this had the unintended and unfortunate side-effect of producing 404s for the altered field UI routes. Any ideas welcome...
- Help get all the tests passing
- If the community feels it's necessary, we may need to add some test coverage over the whole user types arena (like user type CRUD tests).

I think this is a solid start toward achieving user bundle support in core and I hope this re-ignites the conversation surrounding the idea. Looking forward to feedback and review.

For a quick functional evaluation, here's a SimplyTest.me testing environment:

https://simplytest.me/project/drupal/8.6.x?patch[]=https://www.drupal.or...

u:admin/p:admin

Improved patch. Smaller and should pass more tests. It appears some of the tests were failing because they weren't installing the initial "user" bundle config entity before diving into user CRUD operations. I've fixed a bunch of those. I also added a layer onto user creation so the bundle defaults to "user" when not specified. This should be a solid step toward more complete backwards-compatibility.

There seems to be an issue with tests that utilize any of the testing DB dumps / "fixtures". I'm not, at this point, certain how to address this. It would seem that these tests install an old, user-bundle-unaware Drupal DB and then attempt to run code that interacts with the user tables. This errors out because the new bundle/"type" fields are never installed, but this new bundle-capable user module codebase expects them to exist (by way on fresh install or the update hook - neither of which happen). If anyone has ideas I'm all ears... Is this a point where we'd need to re-generate those starter DB files?

New simplytest.me link:

https://simplytest.me/project/drupal/8.6.x?patch[]=https://www.drupal.or...

> Is this a point where we'd need to re-generate those starter DB files?

No, this is about testing the upgrade path. and will need to be fixed without updating the old dumps.

To be perfectly honest, I think the changes of this getting committed are very low and before you spend more time on this I would discuss with the product/release managers. Without their buy-in, this is not going to happen. And you will need to convince them that doing this in drupal core is worth it and enough users need this. I personally am not convinced of that at all ;)

@Berdir so great to have your valued opinion here. I’m very curious if you could expand upon why you are not convinced of the utility of this change to core? And are those the same reasons for the low chance of this getting committed?

Thank you.

Because it is a big change that will require an upgrade path and the majority of users will in my opinion not need this feature. Also, you will have to convince us that this makes sense to have in core, not the other way round.

You might want to have a look at file_entity, there I'm extending the core file entity to have bundles. You could do the same for the user entity in a contrib module and then users that want to be able to do that could install it and it won't affect the others.

@chrisolof, @mpaler:
Great work, continue in contrib module, eg.: https://www.drupal.org/project/user_bundle ?
And I think, please enable change default bundle.

Thanks for the feedback gentlemen. I've transformed the patch code into an 8.x-1.x branch of the User bundle module, and everything appears to be working well.

I'll be curious to see if this module gains any traction. Up until now, someone in my shoes who just wanted that simple feature of User entity sub-types had only one recommended/viable route: Profile/2. Collectively the Profile/2 modules are currently installed on around 43,000 sites. Did all of these sites need the extra features that Profile and Profile 2 offer? Or are some (dare I say many?) just after that basic feature of fieldable User entity sub-types? And how many of these sites would have preferred to work with the simpler, more familiar data model that comes with the bundle approach?

Anyway I guess we'll just have to wait and see. In the mean time I intend to keep improving this patch alongside the User bundle module as time permits. Then, if this idea ever does gain community support, we'll have a good starting point in terms of working code.

Hello all, just curious if the solution going forward is to use the user_bundle contrib module, or if maybe there are some other ideas. For me personally, using roles to function as bundles would be fine except for create access checks.

User::access()

or:

ContentEntityBase::access()

only passes in the $entity->bundle(). It'd be great if maybe in the future this is overridden in User::access() to pass in roles as well, that way, in our case we can control access for users specifically creating other users with certain roles. (right now I added a field constraint).
But passing in roles is complicated as well, as this ->checkCreateAccess at the route level and User::access() runs in AccountForm for the current user.

I think tying the roles to the bundles is not possible because a user can have many roles but there is no concept in Drupal of an entity having many bundles AFAIK

Bundles for Users is really the thing to have...
It is much more simple to create profiles, it is much more efficient to create views and any code dealing with profiles will be more complex than any code dealing with bundles.
Moreover, the bundles are already used and understood by a lot of users... nothing to add on this side.

Unfortunately, it looks like very few peoples are using the User bundle module... it's a vicious circle: the module doesn't look like it is fully supported (last commit is one year ago) and there are few download. Thus people may think that this module have a lot of issues.

I am supporting this idea at 100%, but I will use the Profile feature on my project because it is in core and I know it will be upgraded at the same time Drupal is upgraded. it sucks on my part, I could give it a try, I could consider helping this project but I am out of time...
As I said, it's a vicious circle...

This project needs at least some support from the product/release managers to build trust, as this is what is missing.

it is a pity this is still an issue in 2020. as long as drupal won't change the core user into a fully fledged typed entity (e.g. by integrating excellent contrib user bundle module into core) modules will stubbornly lack support for the concept ☹

Since there's still active interest in this functionality, I spent some time and brought the 8.x-1.x version of User bundle into better shape, and released a 8.x-1.0 version as well, so the module doesn't look abandoned anymore :)

@amateescu Many thanks for this!!
I have a question: should I take some action to convert users created before installing the module to the new TypedUser? (Ie the storage has been updated as well I think)

We should thank @chrisolof, he wrote the 8.x branch of that module :) This would've been better posted as an issue in the module's issue queue, but since we're here.. you don't need to do anything special to convert existing users, they will be assigned the user bundle by default.

I realised that I have a usecase for this.

I am working on a project which uses Drupal Commerce, we need a definitive and reliable way to distinguish between customers and staff. Roles aren't enough because any given user can have multiple roles; Commerce relies on the Profiles module, which could be used in this case (with a "staff" and a "customer" profile), however this has the same problem as using roles. We need a way to definitively say "this user is a staff member or a customer, it should never be possible for them to be both nor for that to change", bundles gives us that assurance and so we can deisgn business logic around that. For instance, in our application, adding and editing staff should be a different experience to adding and editing customers, even to the point where we are planning separate routes and views based on this principle. Staff and customers, in this case, are very different types of users, and as such they see varyingly different user interfaces. In my case I also need to make it possible to seperate the r oles by user type, for instance, it should n ever be possible for a customer user to be given staff roles.

The problem here is that, the use case I described above, is not the case for every Commerce site, and among all Drupal sites the usecase for this is even less. If we consider the majority of Drupal sites, a signle user type and using roles to distinguish between those users is as much as the majority tend to need. If we were to introduce this into Core, we would have the problem of trying to communicate to site builders and administrators what the differences between roles and account/user types are, and for the majroity of sites that difference would be meaningless and probably just result in confusion around what to use and when.

With that in mind I don't reasonably see this getting into Core "as is". What I think would be more likely to make it into core, would be some groundwork to better support this usecase. I really quite like the idea of the User Bundles module (reference in other comments), but the potential problem for me is that it has to make fundamental modifications to the data model of the User Entity, and for me that might be too big of a risk to adopt that module (as in, what's to say that won't break in the future). Now, to be clear, I'm not saying that's a bad approach, I think what the User Bundles module implements and the way it does is the only reasonable approach and quite necesary to make the whole thing work. What I'm suggesting here is that, if Core could provide the data model to facilitate this and then leave the implimtetion of the user interface up to the contrib module. That would make it a lot easier to simply adopt the contrib module.

The way I see that working is that the Core User Entity would have bundles enabled "under the hood", possibly provide the required Config Entity, but never expose the UI and by default only provide one bundle. The User Bundles contrib module would then only need to provide the user interface for the Config Entity type and any tweaks to make the Field UI work (e.g. modifying routes and links). This, I think, strikes a nice balance, for the majoirty of Drupal sites that don't have a usecase for this, they would never see it, and thus avoiding the confusion and trying to explain what the purpose of user/account types are; While for the minority of sites that do need this functionality, it ensures that the underlying data model is in Core and will be supported, thereby reducing the risks to adopting this.

Furthermore, if the fundations for this were in Core, it would make it much easier to support an ecosystem of modules around this usecase. For example, a specific usecase I identified ealier in this post was the ability to tie specific roles to a specific user type, for instance, for any user that is of the type "customer", I always want them to have the "Customer" role, in the same way that they would always have the authenticated role; With the staff user type always having the staff role, then being able to limit specific roles to only being able to be assigned to users of the staff type. A module could be developed to facilitate this usecase, and while it would stil be possible without the foundations being in core, the barrier to entry for this module would be greately reduced if the groundwork was already provided by core.

So that's my take on this.

Thanks,
-Aaron

I also support having Bundles for users which next usecase:
we are building b2b service and would be good to have company account, which does not represent any physical person but company who works with us with all related fields we need; and a physical person profile which represents particular John Smith who is related to particular companies with all related to person fields and not company fields.

P.S. Thanks, @amateescu ( https://www.drupal.org/project/drupal/issues/1288658#comment-13649117 ) will try your module now
P.S. Seems module does its job, shall use, thanks

@Mykola Dolynskyi re #57: I presume you've looked at this, but I wonder if the profile module also covers some or all of your use-case: you could have a company profile and a person profile with specific fields for each.

https://www.drupal.org/project/profile

Thanks,
-Aaron

Thanks, @Aaron. Yes, it can cover but with bigger amount of custom code "from the box". And does not cover (can be solved with custom code) feature to login with "company profile" instead of an individual.