How does this differ from Masquerade?

It is different in one thing that was important for the client I developed this:

Administrator can explicitly specify which roles are permitted for impersonation and this is done on user basis (meaning it can be set/must be set for every user separately). So every user can have personal settings for impersonation.

That's not entirely clear to me how that is different without downloading both modules and trying them out. Perhaps you could take a screenshot of the Impersonate User module's various administration screens - that can often explain it in ways that descriptions can't.

Likewise how does this differ from the switch user block offered by the devel module? For instance does this module enable one to switch from say, uid 1, to some_random_user and then back again without relogging in? (like devel would require...)

Why are everybody so agressive? Let me repeat again. Module was developed based on very specific need by our client.

All impersonation settings are user specific and they are also role based. This means that administrator can set explicitly which roles are available for impersonation for specific user. With such setting user can choose to impersonate users that have any of the specified roles.

For me this justifies separate module. It is just intended for different kinds of uses than Masquerade or switch from devel which are:

- Commercial site has team of writers that should produce content for one drupal user that has specific role without knowing his/her credentials. ( I know it sounds weird but such is a situation). So the management wanted to give them ability to impersonate that drupal user and all the other users with that same role, not including any other role for security reasons. They also insisted that settings are separate for each user so that they can fine tune settings for every single user.

- Tech support case. Basically they wanted to give abillity to their tech support to impersonate any common low-privileged user when he/she communicates the problem with account and/or accessing site without having access to user accounts with elevated privileges.

All impersonation settings are user specific and they are also role based. This means that administrator can set explicitly which roles are available for impersonation for specific user. With such setting user can choose to impersonate users that have any of the specified roles.

This feature works fine and it's very useful. Thumbs up for kiklop74.

I have just tested both Maquerade and Impersonate. I really like Impersonate's ability to give specific users the ability to impersonate only certain roles. This is much more powerful than Masquerade, where someone with masquerade rights can impersonate anyone. In many cases, this will be acceptable, but I can also see the benefit of Impersonate's method. In my opinion, it would be easier to get the Impersonate module to use a block system (like Masquerade) than it would for Masquerade to allow per user settings. As for Devel, I wouldn't consider allowing anyone other than the site developer to use it.

It would be nice to have people with the maintainers of existing modules. But sometimes its hard to get maintainers to implement someone's specific needs (I'm not saying this is the case here), mainly because the maintainer doesn't always have the time to do it. I am of the opinion that having two modules that do similar things, but in obviously different ways, is a good thing. It allows people to have more choice, and it allows for modules to be leaner, rather than bloated with code that accounts for every use case.

Just my $0.02.

BTW, good job on this module - just today I discovered a need for this exact kind of system.

Thank you incrn8 for kind words. I see that you understood the real difference between both modules. As for adding the block interface to impersonate module, do you think it would be useful to do that?

I have no problem adding that, I would just like to hear what would be the use case for that.

Thanks

To be honest, I don't think its really necessary for your module. It is kind of useful as it provides a quick way to change users, rather than going to My Profile and changing there. Don't do anything about it for now, and lets see if anyone else would be interested in that feature.

Since no further comments have been added I will close this issue.

close

I think your description on the home page clarifies well how this module works, which is what I think is most important when a module is created that is similar to an existing one.

Changing to fixed since I think that's most appropriate. When issues are marked "fixed" for 2 weeks they will be closed automatically by cron. By leaving them in fixed state for 2 weeks it makes it easy for someone to find it before submitting a duplicate issue.