When using UUID Services to save a user account, the user's roles (which were provided by the source site via Deploy) are blindly passed to user_save() and saved to the database.

So for example, if the user account on the source site had roles "3 => editor" and "4 => blogger", but the target site only has one role defined ("3 => administrator"), then the user will be assigned the administrator role on the target site (because the IDs match), and it will also get a non-existent role "4" in the database which will take effect later if and when a role with ID "4" is created. This is a major problem because it can result in the user being granted undesired permissions.

One could argue that this is a configuration issue and that it's necessary for the source and target site to always have the exact same set of roles (and role IDs) in order for users to be copied correctly between them, but this is somewhat limiting and not even always feasible (due to vagaries in database engines, etc). Also, when other kinds of data (for example, fields) are different between sites, things generally fail in a more graceful way.

The attached patch fixes this by using hook_entity_uuid_presave() to only save roles whose names exist on the target site (roles don't have real machine names, but the 'name' property is the closest that exists to that and is also consistent with how the Features module handles roles). I realized after writing this patch that a better way to go here might just be to make the module support UUIDs for roles themselves (see also: #1167784: UUID for Roles). But, that might be a fair amount more complicated (since roles aren't entities), so I'm posting the patch as is for now.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dixon_’s picture

Assigned: Unassigned » dixon_

I'll try to have a look at this today. The patch makes a lot of sense.

dixon_’s picture

Regarding UUID support for roles, me and skwashd has discussed that a lot.
I'm of the opinion that roles should not have UUIDs. The role name them selfs are treated as machine names by many modules, including Features.

dixon_’s picture

Assigned: dixon_ » Unassigned

Status: Needs review » Needs work

The last submitted patch, uuid-roles.patch, failed testing.

minorOffense’s picture

We wrote a UUID role module. Pretty simple stuff, just adds a UUID column and generates UUIDs when roles are saved. And it has a nice little API in it to help you operate on roles / permissions by UUID.

Feel free to give it a try.

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

Vj’s picture

@dixon_

I have tried uuid-roles.patch and its working for me. Where as UUID_ROLE module not worked in my case.

Here is the test case.
1. on my dev server i have roles "editor" (rid : 5), "writer" (rid : 4)
2. on my stg server i have roles "editor" (rid : 7), "writer" (rid : 8)
3. When writer user pushes content where he is author of content. On stage he looses its role.
4. Using uuid-roles.patch my issue was resolved.
5. Also tried uuid_role module enabled on both server, but it created different UUID's so deploy user with roles was not worked.

Let me know if any changes required to patch, i can give a try.

Thanks,
Vj

saurabh-chugh’s picture

saurabh-chugh’s picture

Status: Needs work » Needs review
minorOffense’s picture

You have to export your roles once they have a uuid set (e.g. https://www.drupal.org/project/features_roles_permissions)

Then reference the uuid value in the rest of your code.

If you just create new roles on each site you'll always get a new unique id (that's how uuids work). But once your roles are exported they'll have the fixed uuid value and then you can use the helper functions in the uuid_role module to interact with them.

skwashd’s picture

Status: Needs review » Closed (won't fix)

As mentioned by @dixon_ earlier, we will not be adding role support to the uuid module. If you want to use UUIDs with roles then you can check out the uuidrole module mentioned in this issue. To be clear, the uuid maintainers do not endorse the use of this module.

Closing as wontfix.