Storing the role id in the variables table is next to useless when you want to export this to code, because it ties the value to specific database entries, making it more fragile when moving between environments. This says it all:

# drush vget roleassign_roles
roleassign_roles: Array
(
    [3] => 3
    [4] => 4
    [5] => 5
)

It would be useful for the structure to look like:

roleassign_roles: Array
(
    [0] => administrator
    [1] => editor
    [2] => blogger
)

Comments

salvis’s picture

Status: Active » Closed (works as designed)

This is database 101. You have to join with the {role} table to get the information that you want. The {role} table's primary key is the rid, which is used as the foreign key in all other tables that deal with roles.

jwilson3’s picture

The user schema indicates that the 'name' column is also a unique key -- so there is nothing technical preventing this from being done, except for lack of interest. Performance-wise, the db call might be an extra join at the most (havent looked at the code). I assume this code is not being run on every page, just when needed on the user form, so adding an additional join does not make this any less performant. I understand if you haven't jumped on the exportable human-readable UUID boat, but is that a reason to close this DX feature request?

salvis’s picture

Using a VARCHAR(64) for joining tables? No thanks.

jwilson3’s picture

I'm not following you. If you start the query from the role table, the rid field can still be used for the join, the role.name is only needed in the where clause. no?

Leeteq’s picture

Issue summary: View changes
Status: Closed (works as designed) » Active

This is important in order to manage several sites/stages.

I think we should have a configurable setting where we can select to use either the role NAME or the RID, and then use the name in the where clause to get the RID if that is the chosen option, then use that RID for the join anyway.

shelane’s picture

Status: Active » Closed (duplicate)