Add support for negating user role condition for block visibility

Patch #2 works for me. Thank you very much.

A lot of times it makes sense that you only want to show a block to authenticated users. This is the base set of users with no special anythings and it makes a lot of sense to be able to isolate this set of users. It would be good to know why this functionality was removed and if this change is going to cause issues down the line. Does anyone have the backstory on the change?

Something to note: this solution does not carry through to block visibility conditions in Panels. So if you are using Panels you may have to resort to using blocks, as well.

Wow! Its amazing how many little things this get lost over time. This is definitely a feature that was required for a member site. show a member renews block on all roles except member.

Patch applied cleanly and works as expected alongside block visibility groups.

I was just looking for this. Patch does the trick. Thank you!

> A lot of times it makes sense that you only want to show a block to authenticated users. This is the base set of users with no special anythings and it makes a lot of sense to be able to isolate this set of users. It would be good to know why this functionality was removed and if this change is going to cause issues down the line. Does anyone have the backstory on the change?

Why do you need invert for that? All users either have anonymous or authenticated roles, so its' very easy to target either all authenticed or all anonymous users.

I would say the main reason it is hidden is that the UX was kept when those settings were converted to more generic plugins but we tried to avoid changing the UI in the same issue.

Hi, Berdir, I mean just authenticated users with no other roles. Obviously when we select authenticate we get the everybody. Sometimes you want just users with only the authenticated role, which leads us to negate.

Yup, #2 works for us too.

+1 to RTBC

This should probably have some test coverage, should be possible to extend an existing test.

Thanks for raising this feature request, I have this exact need also, and it would be good to have it in core (although clearly it is not hard to do in custom hook code).

Case: I want to show certain promotional blocks (in the right sidebar) for users who are anonymous or "only" authenticated, but not for users with higher roles (staff users) who need the entire right sidebar free for viewing large views tables.

Is there someone from the core team we can get to look at this? Always having to remember patching always stinks :)

Having the same use case here.
Would like to display a block, if a user does not have one (or all) of the specific user roles.

Edit:
patch #2 works for me. Would also vote for same feature for content types and aliases.

Hmm okay after updating core from 8.8.2 to 8.8.3 it doesn't take an effect anymore

@kclarkson: Reverting this issue to "Needs work" because it needs tests; it will not get committed to core without tests, so the correct status until the tests are added is "needs work." Once tests are added to the patch, it can be marked "Needs review."

@dercheffe: The patch is working for me on 8.9; please double-check how you are applying the patch if you are still having problems.

You are a star @benjaminbradley #2 patch works perfectly 🌷

- Adding small test cases to evaluate the negate condition.
Tests are passing on local, let's see how it goes.

Slight title update to reflect this is a feature

Issue re-roll with 9.3.x

Replace the deprecated method.

thank you @mohit_aghera, works perfectly 🌿

Applied patch #27 working fine for ref sharing screenshot ....

I added a change record that can be reviewed at https://www.drupal.org/node/3243401. This is working well on our sites.

Nice to see this moving along, however it is not quite ready for RTBC.

There are several steps, or core gates that an issue must pass first. For this issue, an Issue Summary update is needed. Note there are use cases in #8 and $12 that should be put in the IS. For this, I have started by adding that template. so I could add remaining tasks. This is also changing the user interface text, so it needs a change record.

I tested with Drupal 9.3.x, demo_umami install. I added the language switcher block to the Seven theme and that block displayed. I then modified the Roles settings, ticking Administrator and 'negate the condition'. I expected the block to not display but it did. I tested again with Bartik and the negate worked as expected. Does this only work on Bartik?

@vikashsoni, the latest screenshots should be put in the issue Summary.

Also tagging novice because the follow tasks are suitable for someone new to Drupal:

• Issue summary update
• Manual testing
• Add change record

I've tested this with Drupal 9.34, using a custom theme based on Bootstrap 8.x-3.23, and everything works as expected.

I've also taken a swing at updating the issue summary but I don't quite understand how the two-line patch in #27 works, so I've just pointed to the patch and left the rest for a wiser mind (@mohit_aghera?) to complete.

Using a Radix-based theme, as well as on the demo_umami install profile, and #27 works as expected in both cases.
@quietone maybe you can check your settings and re-test?

All tasks have been addressed addressed.

It would be good to know why this functionality was removed and if this change is going to cause issues down the line.

This wasn't actually removed as such.

Block visibility originally didn't have a built in concept of 'negate', and role visibility didn't include its own one.

When the visibility options were moved to plugins, a generic concept of 'negate' was added, but for existing ones that didn't previously have it, this was disabled to avoid making UX/functionality changes. i.e. more or less what Berdir says in #2986958-6: Add support for negating user role condition for block visibility.

It makes sense to have these consistent to me.

The test exposes a bit of a usability issue though - i.e. what is the difference between 'authenticated' + negate and anonymous, or between anonymous + negate and authenticated - since those roles are always mutually exclusive. Having said that, since either direction works maybe it doesn't matter to offer both?

However, I can see the use-cases for 'show to all authenticated users but not site admins' and not sure it's worth complicating the code further to avoid combinations that will work. Although if you picked both anonymous and authenticated then negated, the block would show to no-one.

Tagging for usability review to get an extra opinion.

Thanks for that detailed history @catch

fwiw, block viz settings already have some other contradictions, e.g. various ways to set a block to never appear with path settings, or combining an admin-only path with a non-admin role.

+1 for making the "negate" setting consistent

For usability (and other) review, it will help to have some before/after screenshots in the issue summary, under "User interface changes".

Updated IS with pics from #29

#27 works for latest drupal?

Hi,

We discussed this in UX weekly last month and came up with some suggestions for the UI. Sorry for the delay in posting this comment.
You can find the recording of the meeting linked to the meeting issue https://www.drupal.org/project/drupal/issues/3296084

In some cases Drupal uses a checkbox to negate a setting, but this does add to the cognitive strain. One needs to know the original rule and then understand what the result is when the rule negated. "When the user has the following roles" do what? What happens when that is negated.

Our conclusion was that it is more usable to have similar setting as we have for the Pages-tab as radiobuttons where the effect of the setting is explained directly.
- Show for the listed pages
- Hide for the listed pages

Also it would be useful if the selection of action would precede selection of the roles.
- Show for the selected roles
- Hide for the selected roles

I'll add screenshots of the existing default Pages tab in Claro and a mockup of the suggestion for roles. (Pages tab would probably also benefit from moving the radiobuttons first.)

I am setting the status to NW based on #41. That comment has the usability review, so I am removing the tag for that.

Thanks for the feedback @benjifisher and @simohell
Looks like changes will be related to title and re-arranging few things.
I've updated the patch as per the feedback.

I think test cases will remain the same.

I understand this from a usability perspective, the problem is that this results in yet another custom optimization that only that specific condition and the block UI benefits from.

Conditions are a generic plugin system that are used by contrib modules in other places, those will still get the other UI. And other plugins will all require a custom and unique solution for this.

But even doing it generically in this specific plugin is tricky for backwards compatibility and the text might not make sense in other contexts. A condition might be used to execute a certain action or not, nothing is shown or hidden.

But again, I understand that this is much better for users, it's just a bit sad from a technical perspective.

Another note: I believe this still uses the standard negate behavior though, which could be interesting. with custom rules and authenticated. the tests only verifies the generic authenticated role. can we check what happens if you hide it for a specific role but not authenticated? I'm honestly not sure what happens then.

Hi @Berdir
Yes, looks like something is wrong with Negate condition with other role.
I am attaching a patch for reference which seems to be failing on local.
Mainly it is same patch as #43, I've just added few more test cases.

Sorry, bad patch; please ignore and will fix.

Here's a corrected reroll of #46.

#53 would require some changes as it isn't removing these 2 lines and the radio buttons disappear as their type gets changed to 'value'.

-      $form['user_role']['negate']['#type'] = 'value';
-      $form['user_role']['negate']['#value'] = $form['user_role']['negate']['#default_value'];

Also, the saved value of user role negation isn't reflected in the UI after saving the block. Should we make this change as well:

-      $form['user_role']['negate']['#default_value'] = (int) $form['request_path']['negate']['#default_value'];
+     $form['user_role']['negate']['#default_value'] = (int) $form['user_role']['negate']['#default_value'];

Thoughts?

How I wish this negate role functionality could be committed, it is awesome! Been having to hack the block module since D8 😉

Me too, this would be such a great development to have this in core.

Thank you! But the patch in #53 does not save when you select 'hide for the selected roles'.

Oh dear, I have tried patch #43, #46, #53, #54: still 'hide for selected roles' is not saving.

Any progress most appreciated.

Thank you #@mohit! #46 is definitely the one.

Updating patch in #46 to fix default value problem mentioned in #54.

@gaurav.kapoor I renamed request_path to user_role; that was a mistake on my part. Thank you for pointing it out.

As for the first two lines, in Drupal 11 it seems those lines are already gone.

Is there a patch for 10.2.x which works on this thread?

I've tried #53, which will apply, but as mentioned in #58, saving the block does not update or reflect the negate/non negate setting. The patches at #43, #46 and #60 will not apply to 10.2.6.

Patch for Issue #2986958: Invert visibility of chosen roles for blocks

Here is the patch to invert the visibility of chosen roles for blocks as per Issue #2986958.

This patch introduces a custom block permissions handler that allows inverting the visibility settings for blocks based on roles.
@iancawthorne #62
Please review and test the changes.
This patch tested with Drupal 10.2.x

https://www.drupal.org/files/issues/2024-06-03/2986958-invert-block-visibility-by-role.patch

The patch at #63 works great on 10.2.x.

The patch #63 works on 10.2.x.

Warning: Patch #63 is a different modification than the MR 2986958-add-support-for and the rest of the patches in this thread. Patch #63 inverts the visibility of the roles in all cases, whereas the rest of the patches and the MR 2986958-add-support-for add a setting that allows the roles to be negated. Patch #63 is not a solution to this issue and it doesn't have any tests.

@ptmkenny Can you clarify on the inverts the visibility of the roles in all cases part?

From my testing, I update a blocks visibility and did a config export. Only the user role visibility changed in that config export, as expected. No config changed for negating visibility was negated for any of the other conditions, such as by content type, by page or by vocabulary etc.

Are you talking about a different scenario which I'm missing?

@iancawthorne I meant all cases for user roles, not for the other conditions. Anyway, you can clearly see this by reading the code for the patch; patch #63 is a one-liner whereas the other patches in this thread are many more lines.

I noticed a few things, and I would like to request your inputs on the following considerations:

• By default none of the radio boxes should be selected, currently by default "Show for the selected roles"is selected and it gives the impression that we have to select some role before proceeding
• There should be some description under roles checkboxes like "If nothing is selected the block will be visible to all the listed roles"
• The "Roles" label should be just above the roles checkboxes and not above the radioboxes.

Please see the attached screenshot.

@ptmkenny I can see the patch at #63 is a lot less lines of code than others. However, up until needing to upgrade from Drupal 10.1.x to 10.2.x, I've been using the patch at #21. If you take out the test lines for that patch, you are left with a two liner, which as far as I can tell does the same as patch #63 but in a very slightly different way.

I'm still not sure what you mean by all cases for user roles though?

@Prashant.c First, please note that this change has already undergone a usability review.

As for your points:

By default none of the radio boxes should be selected, currently by default "Show for the selected roles"is selected and it gives the impression that we have to select some role before proceeding

In Drupal, radios generally have something selected by default. For example, in "Submission form settings", "Preview before submitting" also has a default value selected. If no default value was selected, when creating a new entity, users would always have to fill out that part of the form. Anyway, this is the way other

There should be some description under roles checkboxes like "If nothing is selected the block will be visible to all the listed roles"
The "Roles" label should be just above the roles checkboxes and not above the radioboxes.

This could be a helpful suggestion but I think it is out of scope for this issue, as the change has already undergone usability review. Please consider opening a new issue with this request.

For anyone coming to this issue and "just looking for a patch," please consider using the User Not Role module instead, which does what this issue will eventually accomplish in core.

@ptmkenny

Thanks for your responses; I understand your points. Apologies for missing #41