Install 'Masquerade role' and create a dedicated role for it

[willguv]

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

Andy said at a PG that Brighton is using this successfully - covers the bases of features being visible and useable by specific roles

Masquerade was previously suggested https://www.drupal.org/project/masquerade but it's not covered by the Drupal security policy

[andybroomfield]

I'd consider Masqurade role instead as its a better fit for what actully needs testing (user roles and role combinations) and is a bit more lightweight.

[willguv]

Totally works for me, thanks @andybroomfield

I'll update the card

[willguv]

Andy suggests https://www.drupal.org/project/msqrole

[markconroy]

Are we sure we want to create a dedicated role for this? I'm not a fan of one-off roles, as they make the Drupal permissions page very large.

I wonder should we create a more generic role called "Developer" or something like that. And we can give these developer type permissions to that role?

To be honest, I'm not even fully convinced that we need to add masquerade functionality at all to the CMS, maybe it's enough for sites that need it to add it (remember each module is another potential security vector, and also more code to be loaded). What was the specific use-case we had for this?

===
Thanks to Big Blue Door for sponsoring my time to work on this.

[willguv]

It's very handy for product managers testing work intended for other roles. Like when we did the content by path stuff. Very tricky without @markconroy

[markconroy]

I've a PR created for this, but it is only to

1. Add the module to the codebase, and
2. Enable the module

It does not create a dedicated role just for this one feature. If we want that functionality, let's think of a new generic role for it. At the moment, we can just assign the msqrole functionality to any role we want. Actually, the best role might be the upcoming 'Admin' role that we have on the way.

===
Thanks to Big Blue Door for sponsoring my time to work on this.

[ekes]

[aside and possibly I misunderstand whot you mean by upcoming admin role]

Actually, the best role might be the upcoming 'Admin' role that we have on the way.

Do you mean in core? I'm kinda staring at this. The calculated permissions item that's gone into core seems the same as it is already in Group. So 'Admin' in that case is the new User 1. It doesn't have any explicit Permissions. When the Permissions Item gets queried for a permission it always says yes. So a role defined as Admin that way will always have all permissions.

[ekes]

@willguv

It's very handy for product managers testing work intended for other roles.

Would you be doing this on production, or on a stage site?

[willguv]

Unlikely a production site. More likely testing on staging then deploy when ready

[markconroy]

@ekes no, not Drupal core. I mean the admin role we are creating for LGD - localgovdrupal/localgov_core#217

[finnlewis]

Discussing in Merge Tuesday.

@stephen-cox reminded us that we have a process to assess inclusion of contrib in our profile. I'll check and report back.

See https://docs.google.com/document/d/1OCs3W7WFGtDNpL0U-6lhT6pQpOf2RydjtpkAMOrUeI4/edit

[willguv]

As per the process, I think this is a common need as product people in councils will want to test as other users - having it includes more and better testing and helps time poor people do important things more quickly

I'd argue for this to be switched on by default - if people know it's there they'll use it

I hear some agencies include this by default in their LGD offer

[willguv]

Product Group notes:

• Starshot went for Masquerade
• Masquerade is pick a user

Let's go for Masquerade

[andybroomfield]

Just to add that Masquerade has a 2.0 release and now has security coverage.

[markconroy]

PR ready - #777