Already started working on the patch for this, but essentially I want to prevent certain users that have access to "masquerade" from switching to roles with higher privileges than they may currently have. The best way to accomplish this--as I understand now, is to restrict which roles each role is allowed to "masquerade as".

Would like some feedback on this as well.

Files: 
CommentFileSizeAuthor
#51 1171500-role_defined_access-51.patch6.26 KBjpstrikesback
PASSED: [[SimpleTest]]: [MySQL] 38 pass(es).
[ View ]
#51 1171500-role_defined_access-51-tests-only.patch434 bytesjpstrikesback
FAILED: [[SimpleTest]]: [MySQL] 17 pass(es), 20 fail(s), and 7 exception(s).
[ View ]
#33 1171500-role_defined_access-33.patch5.92 KBjpstrikesback
FAILED: [[SimpleTest]]: [MySQL] 31 pass(es), 4 fail(s), and 1 exception(s).
[ View ]
#31 role_defined_access.patch5.9 KBjrobison
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch role_defined_access.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#25 masquerade-add_permissions_for_each_role-1171500-25.patch17.69 KBmkadin
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-add_permissions_for_each_role-1171500-25.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#25 interdiff.txt834 bytesmkadin
#23 masquerade-add_permissions_for_each_role-1171500-23.patch9.25 KBmkadin
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-add_permissions_for_each_role-1171500-23.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#23 interdiff.txt5.92 KBmkadin
#22 masquerade-add_permissions_for_each_role-1171500-22.patch17.68 KBmkadin
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-add_permissions_for_each_role-1171500-22.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#22 interdiff.txt6.44 KBmkadin
#20 masquerade-add_permissions_for_each_role-1171500-19.patch15.11 KBmkadin
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-add_permissions_for_each_role-1171500-19.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#20 interdiff.txt3.41 KBmkadin
#14 masquerade-add_permissions_for_each_role-1171500-14.patch14.88 KBfuerst
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-add_permissions_for_each_role-1171500-14.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#14 interdiff_1171500-13-to-14.patch1.98 KBfuerst
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch interdiff_1171500-13-to-14.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#13 masquerade-add_permissions_for_each_role-1171500-13.patch14.41 KBfuerst
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-add_permissions_for_each_role-1171500-13.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#9 masquerade-add-masquerade-as-role-permissions-1171500-7.x-1.x-9.patch11.83 KBwjaspers
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-add-masquerade-as-role-permissions-1171500-7.x-1.x-9.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#4 masquerade-7.x-1.x-dev-1171500-add-masquerade-as-role-permissions.patch23.79 KBwjaspers
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in masquerade-7.x-1.x-dev-1171500-add-masquerade-as-role-permissions.patch.
[ View ]

Comments

Got it working. Patch to follow soon. Important note: if the patch to follow is implemented, a hook_update will need to be included that removes existing masquerade as use and masquerade as admin permissions, adjusting them to match newly exposed role permissions.

Question to anyone reading this:

Do you use or would you miss the "masquerade admin" roles functionality? If so, why?

One problem I've encountered with the changes here, is that the 'masquerade admin' functionality interrupts role based permissions and I'm stumped as to what do about it. I can a) try to resolve it (will probably take longer), or b) remove it entirely. All feedback welcomed.

EDIT: Finished code changes needed to make masquerade utilize role-based permissions. Caveat: "Masquerade Admin" settings removed. New features: "quick switches" filter out accounts the current user can't access based on permissions, Views field handler added, Context condition/reaction added. Would still like feedback on the above.

We don't regularly use the "masquerade as admin" permission, since our "admin" users are part of an admin role that has all permissions assigned.

I'm interested in this patch.

So are you saying that this creates new module permissions for "masquerade as [role]"?

Yes I am. I have it working, but it needs a few tests before I can say it's secure.

What's really handy -- in my situation, is that I can assign certain roles to "masquerade as [role]" for customer service purposes. That way I don't need customer service members to spend lots of time tracking down a specific user and adding them to their permitted switches or running the risk of accessing a role they shouldn't have.

I've tried to put some thought into how to handle permissions while masquerading, as well, but I doubt most will need it. (I.E. Limiting what a user that is masquerading can do, even if the role they're masquerading as has a permission to do something.)

StatusFileSize
new23.79 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in masquerade-7.x-1.x-dev-1171500-add-masquerade-as-role-permissions.patch.
[ View ]

Alright, here's a patch -- which also includes my handlers for CTools the Context module, and Views--just depends on which the maintainers want to process.

I will note, in this patch, I took out the "Test user" fields.

This patch might be best placed in a Masquerade - 2.x branch -- although I have not altered the database schema in any way. Again, its up to the maintainers how they want to handle this.

Status:Active» Needs review

Status:Needs review» Needs work

Thanks for the patch. It looks like it's using Windows line endings, which throws errors when using git apply. Future patches should have Unix line endings to prevent this issue - you might need to change a setting in your text editor to default to Unix line endings.

I think the CTools and Context should be their own issue, and Views integration should be separate as well. In fact, looks like you've started an issue over at #1167744: Add Views, CTools, and Context module support..

Most of my comments are style related that could probably be detected using Coder; I stopped adding comments as there are many lines with identical issues.

+++ b/masquerade.module Tue Jun 21 17:34:26 2011
@@ -23,15 +22,23 @@
+  // load and build permissions for all roles in our site

Capitalize "Load" and make all comments use sentence case.

+++ b/masquerade.module Tue Jun 21 17:34:26 2011
@@ -23,15 +22,23 @@
+      $description = t('Grant this permission <em>with caution</em>. Any user signed in is given this role.'); ¶

Fix lines containing trailing spaces.

+++ b/masquerade.module Tue Jun 21 17:34:26 2011
@@ -23,15 +22,23 @@
+  ¶

Fix lines containing only whitespace.

+++ b/masquerade.module Tue Jun 21 17:34:26 2011
@@ -232,7 +238,6 @@
-      if ($uid) {

This is removed with no corresponding close bracket?

+++ b/masquerade.module Tue Jun 21 17:34:26 2011
@@ -757,23 +750,14 @@
+  // ensure the account we're switching to isn't our own and that we have permission to masquerade with these roles

Wrap comments at 80 characters.

+++ b/masquerade.module Tue Jun 21 17:34:26 2011
@@ -781,6 +765,7 @@
+  // hooray, we made it!

This is redundant.

+++ b/masquerade.module Tue Jun 21 17:34:26 2011
@@ -836,4 +821,134 @@
+ * Tell ctools where to look for plugins

Should be "Implements hook_ctools_plugin_directory()."

+++ b/masquerade.module Tue Jun 21 17:34:26 2011
@@ -836,4 +821,134 @@
+ * Adds a masquerading condition to the context module

Same thing here.

+++ b/masquerade.module Tue Jun 21 17:34:26 2011
@@ -836,4 +821,134 @@
+ * Tells the Context module to look for our custom plugins.

And here.

+++ b/masquerade.module Tue Jun 21 17:34:26 2011
@@ -836,4 +821,134 @@
+ * Triggers our custom context reactions.
+ * Why isn't this handled by the Context plugin manager??

Here as well. Instead of leaving a question in the comments, we should figure it out and document why.

+++ b/masquerade.module Tue Jun 21 17:34:26 2011
@@ -836,4 +821,134 @@
+ * Checks if the user has access to masquerade as a specific role.

Add @param phpdoc.

+++ b/masquerade.module Tue Jun 21 17:34:26 2011
@@ -836,4 +821,134 @@
+ *  Whether or not the current user is allowed to masquerade as someone with this role.

Missing an indentation space.

@deviantintegral,
What's the best way to split up new features between patches, then? (It sucks developing in a Windows environment)
I have a full patch prepared, but as you mentioned, they should be submitted separately.

Should I submit a patch as if it came after the CTools+Views+Context integrations?

In this case, the patches don't have any dependencies on each other. So, write them all against 7.x-1.x without sharing any code. Create a local branch for each patch to make things simpler to track. If you're using all of the patches on a site, you can apply them individually to your specific site's copy of the module. If for some reason a patch depends on another patch, set the issue to "postponed" with a link to the other issue.

git add --patch might be helpful to you, as you can add parts of your changes to the staging area, and do a commit. git stash is also useful when moving uncommitted changes between branches.

StatusFileSize
new11.83 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-add-masquerade-as-role-permissions-1171500-7.x-1.x-9.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Good to know--thank you for the detailed explanation.

Here's a patch that does NOT contain any the aforementioned Ctools/etc... integration.

Status:Needs work» Needs review

Since this hasn't gotten much feedback; would it be appropriate that this patch be useful for a 7.x-2.x branch, wherein the "quickswitch" block is eliminated?

Certainly interested in the capability of controlling whether someone with the permission to masquerade should be restricted from masquerading as users with roles x y or z

StatusFileSize
new14.41 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-add_permissions_for_each_role-1171500-13.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Refreshed the patch from #9 for 7.x-1.x-dev (2012-Jun-25).
I also added the role based restrictions to the query used to generate the autocomplete list.

StatusFileSize
new1.98 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch interdiff_1171500-13-to-14.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
new14.88 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-add_permissions_for_each_role-1171500-14.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Enhanced the patch as following:

* Autocomplete treats a masquerade as Authenticated User permission like expected: Masquerade to all roles allowed
* Use db_select() (DBTNG) instead of db_query()

Note: LIKE is case insensitive in DBTNG so no need for LOWER() anymore.

I am certainly also interested in role based permissions. Would have suggested this functionality, but found that the issue was already created. As regards to your question, I have never had any need for the "masquerade admin" permission.

@rosell.dk: Can you try the patch masquerade-add_permissions_for_each_role-1171500-14.patch in #13? When successful please set this issues status to reviewed & tested by the community.

Sorry, but I don't have much time on my hands right now. Hope that someone else will review the patch!

There's a check I introduced in the original patch (and I think it has followed thus far) which looks to see if the user has masquerade as X permissions, which winds up requesting info from the DB several times. I remember seeing something in another issue queue which checks the user's permissions against the user object (and requires fewer trips the DB).
This would be a worthwhile performance benefit. If anyone knows it offhand, it would be great to see this introduced.

This functionality is important to a project I'm working on; we'd love to see it included in the module. I've reviewed fuerst's work and it looks pretty solid. This patch has some minor docs improvements and removed a line or two that didn't need to be there.

The way this patch was set up, you have to have permission to switch to ALL of the roles that the target user has. I think this is the correct approach. The only reservation I have here is the special handling for the 'authenticated user' role.

<?php
function masquerade_check_roles($roles = array()) {
  foreach (
$roles as $rid => $role) {
    if (
$rid == DRUPAL_AUTHENTICATED_RID) {
      continue;
    }
    if (!
masquerade_check_role_permission($role)) {
      return
FALSE;
    }
  }
  return
TRUE;
}
?>

Why should we be skipping over the 'authenticated user' role? Seems to me that this might be confusing behavior, if all of the other roles matter.

StatusFileSize
new3.41 KB
new15.11 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-add_permissions_for_each_role-1171500-19.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

And here's my slightly different patch

Status:Needs review» Needs work

There's actually more to the problem discussed in #19. Users that don't have the 'masquerade as authenticated users' permission can still masquerade as any authenticated user.

I could imagine the use case where a site builder wants to have a role called 'masqueradable' and only wants to give certain roles the permission to masquerade as only a class of 'masqueradable' users. This patch would end up allowing them to masquerade as anybody.

Status:Needs work» Needs review
StatusFileSize
new6.44 KB
new17.68 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-add_permissions_for_each_role-1171500-22.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Here's an updated patch that treats authenticated users as any other role. This means that if you want someone to be able to masquerade as a user with role X, you'll have to give them rights to masquerade as authenticated users and as role X. This is consistent with how the patch treats all the other roles. I think this makes it less confusing and also solves the problem discussed in the first half of #21.

This patch also updates the autocomplete queries to only show users who you can switch to.

Test it out / review it so we can get this in!

StatusFileSize
new5.92 KB
new9.25 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-add_permissions_for_each_role-1171500-23.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

I've changed my thinking on the issue of special handling for authenticated users. This patch makes what I was discussing in the 2nd half of my comment from #21 is possible.

If a user has no roles (besides 'authenticated user'), then you have to have the 'masquerade as authenticated user' permission to switch to them.

If a user has other roles besides 'authenticated user', its not necessary to have the 'masquerade as authenticated user' permission as ong as you have permissions to masquerade as all of the other roles.

Though this logic complicates some of the queries and logic, I think its worth what you can get out of it.

GIve it a whirl to test it.

I agree with mkadin. This does complicate things a bit (both code and UX) but there are times I need the flexibility to give role A the ability to masquerade as users with only role B, but don't want to allow role A to masquerade as users who only have the authenticated user role. I think this makes sense.

Will review/test the patch today or tomorrow.

One thing though, maybe a change in the permission title for "Masquerade as Authenticated User" may help from a UX perspective...something that roughly connotes "masquerade as users who are only members of the Authenticated User role." I'll run it by some tech writers for suggestions that meet clarification and concision needs.

StatusFileSize
new834 bytes
new17.69 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-add_permissions_for_each_role-1171500-25.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Agreed, this changes the language to 'Masquerade as a user who has no roles besides authenticated user' and also adds the security warning to all masquerade permissions.

Status:Needs review» Reviewed & tested by the community

This patch has been working like a charm for us in both our test and production environments. Marking as RTBC.

Title:Add "masquerade as @role" permissions for each role Add "masquerade as @role" permissions/settings for each role
Priority:Normal» Major
Status:Reviewed & tested by the community» Needs work

I'd like to commit this feature with proper implementation. So it need re-architecture and re-think settings storage to be more useful so re-titled to point that "permissions" should be stored within module settings.

This needs additional hooks to react on role change, D7 got a lot of them. Needs upgrade path for current settings and probably a tests.

I think current implementation is no-go:
1) it changes a permission model and does not provide a upgrade path
2) it makes permissions page to grow much more
3) adds more queries, some are LEFT JOIN - needs performance testing
4) additional and mostly useless user_load() could be very expensive on sites with big profiles or using OG.
5) code logic and docs makes module much more sophisticated.

+++ b/sites/all/modules/masquerade/masquerade.moduleundefined
@@ -23,15 +23,22 @@ function masquerade_help($path, $arg) {
+  foreach (user_roles() as $rid => $role) {
+    $title = 'masquerade as '. $role;
+    $description = t('Masquerade as a member of the @role role.', array('@role' => $role));
+    if ($rid == DRUPAL_AUTHENTICATED_RID) {
+      $description = t('Masquerade as a user who has no roles besides authenticated user');
+    }
+    $roles[$title] = array(
+      'title' => t($title),
+      'description' => $description,
+      'restrict access' => TRUE,

I really dislike this change. It makes permission page to grow slightly!
I'd prefer to have our 2 permission but provide a matrix of permission internally from admin settings.

+++ b/sites/all/modules/masquerade/masquerade.moduleundefined
@@ -859,3 +885,99 @@ function masquerade_switch_back() {
+ * Checks if the user has access to masquerade as a specific role.
+ * @param string $role

needs blank line between

+++ b/sites/all/modules/masquerade/masquerade.moduleundefined
@@ -859,3 +885,99 @@ function masquerade_switch_back() {
+function masquerade_check_role_permission($role) {
+  $permission = stripos($role, 'masquerade as') ? $role : 'masquerade as ' . $role;

this would break when roles are translated. so needs other way to solve this

+++ b/sites/all/modules/masquerade/masquerade.moduleundefined
@@ -859,3 +885,99 @@ function masquerade_switch_back() {
+ * Checks an array of roles to see if we have access to them.

Really?

+++ b/sites/all/modules/masquerade/masquerade.moduleundefined
@@ -859,3 +885,99 @@ function masquerade_switch_back() {
+function masquerade_check_roles($roles = array()) {
+  foreach ($roles as $rid => $role) {
+    if ($rid != DRUPAL_AUTHENTICATED_RID) {
+      if (!masquerade_check_role_permission($role)) {

Functions needs a better names and doc-blocks.
Role grants a set of permissions. So the comment make no sense at all!!!

+++ b/sites/all/modules/masquerade/masquerade.moduleundefined
@@ -859,3 +885,99 @@ function masquerade_switch_back() {
+ * @param mixed
+ *   The user object to check roles. Also accepts uids and user names.
...
+function masquerade_check_user_roles($user) {
+  if (is_numeric($user)) {
+    $user = user_load($user);
+  }
+  elseif (is_string($user)) {
+    $user = user_load_by_name($user);
+  }
+  elseif (!is_object($user) || !isset($user->roles)) {

So what is the parameter? I think it's possible to unify it

+++ b/sites/all/modules/masquerade/masquerade.moduleundefined
@@ -859,3 +885,99 @@ function masquerade_switch_back() {
+function masquerade_has_any_masquerade_permission() {
+  $return = FALSE;
+  foreach(user_roles() as $rid => $role) {
+    if (masquerade_check_role_permission($role)) {

Useless if we stay with current permissions.

+++ b/sites/all/modules/masquerade/masquerade.moduleundefined
@@ -859,3 +885,99 @@ function masquerade_switch_back() {
+ * Get roles the current user is allowed to masquerade to.
...
+function masquerade_get_not_allowed_roles() {
+  $rids = array();
+  foreach (user_roles() as $rid => $role) {
+    if (!masquerade_check_role_permission($role)) {

Why not simply array_intersect_key() with allow roles?

No problem. Let's clean it up.

Responding to your points:

1) it changes a permission model and does not provide a upgrade path

What would you propose the upgrade path be? If a role has 'masquerade as a user' before, then we give that role permission to masquerade as every role after the upgrade?

2) it makes permissions page to grow much more

I agree it does add rows to the permissions page, and I generally try to avoid that, but I also don't like modules that put their permissions somewhere else. To me it makes sense for all permissions to be in teh same place. But we can move it if you think its necessary.

3) adds more queries, some are LEFT JOIN - needs performance testing

The query changes are in the autocomplete function for the switch user block. This isn't really the critical path for performance, so I don't think that's a big issue. To me, i'd rather have that autocomplete take a few ms longer than have the autocomplete return options for users you can't switch to, which is the purpose of the query's change.

4) additional and mostly useless user_load() could be very expensive on sites with big profiles or using OG.

You're talking about masquerade_check_user_roles($user)? It'd be better to query for the roles directly then instead of loading the whole user object? That makes sense.

5) code logic and docs makes module much more sophisticated.

I'm not sure this can be avoided, but if you have specifics that you think can be done another way, we can definitely clean it up.

From your code comments:

this would break when roles are translated. so needs other way to solve this

I haven't worked much with multilingual sites, perhaps you can suggest a solution.

Really?
Functions needs a better names and doc-blocks.
Role grants a set of permissions. So the comment make no sense at all!!!

Much of these docs / function names were inherited from the earlier folks on this issue, so have no problem changing them, but the docs you're referring to here seem to make sense to me, and I don't know what "Really?" means.

So what is the parameter? I think it's possible to unify it

Whoever authored this function was looking to make it versatile. It's possible to unify it, it will just add more logic throughout the module instead of including it here. I like it as is, but we can change if necesesary. I understand why we want to avoid user_load in this function though.

Why not simply array_intersect_key() with allow roles?

Right now, there is no function that returns all of the allowed masquerade roles...

I'll get started on some of the obvious changes. If you can answer some of these questions, we can keep this thing moving forward.

For D8 it's ok to have custom entity-level permissions (#1807776: Support both simple and editorial workflows for translating entities) so better to keep in mind that we have in progress to port the module to D8 #1836516: Port Masquerade to D8 and rewrite + simplify it into a new 2.x series

+++ b/sites/all/modules/masquerade/masquerade.moduleundefined
@@ -859,3 +885,99 @@ function masquerade_switch_back() {
+ * Checks if the user has access to masquerade as a specific role.
...
+function masquerade_check_role_permission($role) {
+  $permission = stripos($role, 'masquerade as') ? $role : 'masquerade as ' . $role;
+  return user_access($permission);

You already introduces this function so simple this one is a access callback for your list of roles.
Remember that user should have overrides for allowed users to masquerade as (and this patch should bring same ability for roles).
That means no reason to introduce new permissions. Simply make this function more useful.

+++ b/sites/all/modules/masquerade/masquerade.moduleundefined
@@ -859,3 +885,99 @@ function masquerade_switch_back() {
+ * Checks an array of roles to see if we have access to them.
...
+function masquerade_check_roles($roles = array()) {
...
+ * Checks all roles of the user we're trying to become.
...
+function masquerade_check_user_roles($user) {

This functions are useful.

But statement that user has access to roles is wrong. This means some custom logic and another argument for own access callback

Hmmm... I need this feature but it doesn't look like anyone is working on it anymore. Anyone planning to soon? :) If not... I might need to figure out this patch and the changes needed per @andypost.

Issue summary:View changes
StatusFileSize
new5.9 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch role_defined_access.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

I saw this issue after working on my own version of this concept.

Please see the attached patch.

Editing to mention this patch is for 7.x-1.0-rc5

I would really like to commit this if it can get rtbc...

StatusFileSize
new5.92 KB
FAILED: [[SimpleTest]]: [MySQL] 31 pass(es), 4 fail(s), and 1 exception(s).
[ View ]

Just a re-roll of #31 against 7.x-1.x, with which I will test on simplytest.me :)

#31 works by adding a gate at the end of everything to check if a user has access to switch to a users roles, it works from my testing but there are so many different access checks all over the module that without more testing I can't be sure there isn't unexpected/inconsistent behaviour so I wont be the one to RTBC. Still, I like this approach and someone who knows this module better could likely say if it opens any vulnerabilities.

Status:Needs work» Needs review

The last submitted patch, 13: masquerade-add_permissions_for_each_role-1171500-13.patch, failed testing.

The last submitted patch, 14: interdiff_1171500-13-to-14.patch, failed testing.

The last submitted patch, 14: masquerade-add_permissions_for_each_role-1171500-14.patch, failed testing.

The last submitted patch, 20: masquerade-add_permissions_for_each_role-1171500-19.patch, failed testing.

The last submitted patch, 22: masquerade-add_permissions_for_each_role-1171500-22.patch, failed testing.

The last submitted patch, 23: masquerade-add_permissions_for_each_role-1171500-23.patch, failed testing.

The last submitted patch, 25: masquerade-add_permissions_for_each_role-1171500-25.patch, failed testing.

The last submitted patch, 31: role_defined_access.patch, failed testing.

Status:Needs review» Needs work

The last submitted patch, 33: 1171500-role_defined_access-33.patch, failed testing.

StatusFileSize
new429 bytes
FAILED: [[SimpleTest]]: [MySQL] 17 pass(es), 20 fail(s), and 7 exception(s).
[ View ]
new6.25 KB
FAILED: [[SimpleTest]]: [MySQL] 17 pass(es), 20 fail(s), and 7 exception(s).
[ View ]

Little update to test with the new role permissions

Status:Needs work» Needs review

Fire up the bot.

The last submitted patch, 47: 1171500-role_defined_access-47-tests-only.patch, failed testing.

Status:Needs review» Needs work

The last submitted patch, 47: 1171500-role_defined_access-47.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new434 bytes
FAILED: [[SimpleTest]]: [MySQL] 17 pass(es), 20 fail(s), and 7 exception(s).
[ View ]
new6.26 KB
PASSED: [[SimpleTest]]: [MySQL] 38 pass(es).
[ View ]

One more time.

The last submitted patch, 51: 1171500-role_defined_access-51-tests-only.patch, failed testing.

(hiding files)