Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Adding VBO-failure through Rules Component script - to this bug.
I have write a Rule Component called "Activate User account" and checked it in Views VBO - and the failure is the same there!
The DP-log reporting the same "reason" as above to abrupt the action - and failure to change the user account status!
If I run the Component Action Manually - directly from Rules Component (and set a Uid manually) - it works!
By that I upgrade this Bug report to "Major" because it seams that VBO is blocking all possibilities to change a user accounts Status.
Additional: After deep digging and testing I realize that this issue could be as it "should" and not a BUG..?..!. If so, I ask deeply to consider the stupid Drupal dilemma "all-or-nothing" when it come to a way to Activate account status.
After lot of testing together with Rules Component, I found out that I am able to run a rule-script who is blocking Users status, but not to run rule-script who is activate user account status , if not the user who run the script has permission: Administer users!!!!
If the only way to give a user right to activate is to give him the permission "Administer users" it open a HIGH STRONG SECURITY RISK.. With that permission he is able to take over the account of user 1!
More info about this BUG
The permission "Administer users" is blocking VBO permission. If I set Permission to "Administer users" for the Role who is running the "Rules Component" it works as it should, from the Views-display where the VBO- and Rule-process shall change setting for "active or blocked users" (Status) , !
- The problem is that the user shall not have that kind of permission, and the VBO shall instead give permission for the processes to run through the filtered user-list with allowed users for the role that has permission to change status for only his group of users (Views filter). ( and no other user or user groups - at all).
My Dev site waiting to go public and this bug is to one who blocks the possibility.
I could not find any way to use VBO to clear this matter - but when I use "Rules Link" I was able to build the function of "Disable" and "Activate" user accounts, filtered by views, without having the permission "Administer users" in Drupal setting to do so.
VBO is only capable of to "Disable" status on a account by its own permissions setting, not to "Activate" it. If this not is a bug (see the question above #1) it is instead a great dilemma, which a permit is required that will overrides the security of Drupal, to perform an activation of an account.
Please advice if this is a bug, or it is the case of a "ordinary" restriction that prevents the use of VBO to in any way activate accounts?
Comments
Comment #1
Göran CreditAttribution: Göran commentedAdding VBO-failure through Rules Component script - to this bug.
I have write a Rule Component called "Activate User account" and checked it in Views VBO - and the failure is the same there!
The DP-log reporting the same "reason" as above to abrupt the action - and failure to change the user account status!
If I run the Component Action Manually - directly from Rules Component (and set a Uid manually) - it works!
By that I upgrade this Bug report to "Major" because it seams that VBO is blocking all possibilities to change a user accounts Status.
Additional: After deep digging and testing I realize that this issue could be as it "should" and not a BUG..?..!. If so, I ask deeply to consider the stupid Drupal dilemma "all-or-nothing" when it come to a way to Activate account status.
After lot of testing together with Rules Component, I found out that I am able to run a rule-script who is blocking Users status, but not to run rule-script who is activate user account status , if not the user who run the script has permission: Administer users!!!!
If the only way to give a user right to activate is to give him the permission "Administer users" it open a HIGH STRONG SECURITY RISK.. With that permission he is able to take over the account of user 1!
Comment #2
Göran CreditAttribution: Göran commentedI did make a try with the 7.x-3.x Dev version - Same result!
Comment #3
Göran CreditAttribution: Göran commentedMore info about this BUG
The permission "Administer users" is blocking VBO permission. If I set Permission to "Administer users" for the Role who is running the "Rules Component" it works as it should, from the Views-display where the VBO- and Rule-process shall change setting for "active or blocked users" (Status) , !
- The problem is that the user shall not have that kind of permission, and the VBO shall instead give permission for the processes to run through the filtered user-list with allowed users for the role that has permission to change status for only his group of users (Views filter). ( and no other user or user groups - at all).
My Dev site waiting to go public and this bug is to one who blocks the possibility.
Please advice or support this bug.
Comment #4
Göran CreditAttribution: Göran commentedComment #5
Göran CreditAttribution: Göran commentedComment #6
Göran CreditAttribution: Göran commentedComment #7
Göran CreditAttribution: Göran commentedI could not find any way to use VBO to clear this matter - but when I use "Rules Link" I was able to build the function of "Disable" and "Activate" user accounts, filtered by views, without having the permission "Administer users" in Drupal setting to do so.
VBO is only capable of to "Disable" status on a account by its own permissions setting, not to "Activate" it. If this not is a bug (see the question above #1) it is instead a great dilemma, which a permit is required that will overrides the security of Drupal, to perform an activation of an account.
Please advice if this is a bug, or it is the case of a "ordinary" restriction that prevents the use of VBO to in any way activate accounts?
Comment #8
portulacaMaybe this prevented the "Activate current user" from getting onto the default VBO list?