Masquerade Extras is a small suite that provides ways to interact and extend the functionality of the masquerade module. Build customer service tools, helpful hints while browsing the site as another user, or change the behavior of custom pages using some of the extended features available!
Requires: Masquerade.
Share your feedback, how-to, or what you use this suite for. #1707298: Strut your stuff
Everyone is encouraged to use Masquerade Extras 2.x or newer.
The last 1.x release of Masquerade Extras will be 1.2.
Masquerade ViewsRequires: Views. Compatible with Views 2.x or 3.x. Views support will provide access to the list of users who are currently masquerading, and provides a user link plugin which can permit someone to start masquerading in just one click. Masquerade ContextRequires: Context. Provides a "Masquerading" Context Condition which allows the site to identify when:
|
Masquerade CToolsRequires: Chaos Tool Suite. Provides an "Is Masquerading" Access Plugin which allows the site to identify when the account (from a context) is masquerading as someone else or is being masqueraded by someone else. Also provides a "User from masquerade" relationship, which allows the site builder to access the user from the opposite side of the masquerade from any user context. This is most useful with panels. Masquerade DrushRequires: Drush. Gives someone operating on the site via command line control over masquerades:
|
Masquerade RulesRequires: Rules. Provides conditions for masqeruading and being masqueraded. |
|
Brief FAQWill you create a custom block to display who is using "X" account?No; In my practice, I rarely use pre-defined custom blocks or views. Therefore, I believe it's best to leave this up to the site builder / developers while the site is under construction. Can you create a submodule to control which permissions are allowed while "masquerading"?After thinking heavily about this, I've (currently) decided against it. Drupal's Core API doesn't (currently) have any hooks available to alter access control. Trying to manipulate access control across core and planning in future functionality would require we override EVERY permission. The better solution (in my opinion), is to take advantage of the hook implementations and either custom code your own, or alter or prevent certain actions using masquerade_rules. If you think there's a good solution for this, I'm all ears. |
Future Considerationmasuerade_rules could provide events that take place when the user is about to, and when the user has actually started and stopped masquerading. |
If you have a new idea, please present it to the issue queue!
Project information
- 277 sites report using this module
- Created by wjaspers on , updated
- Stable releases for this project are covered by the security advisory policy.
There are currently no supported stable releases.
Releases
Development version: 7.x-2.x-dev updated 4 Mar 2015 at 02:43 UTC