Problem/Motivation

Role visibility assignment in the blocks UI does not necessarily grant access to blocks if permissions are needed too. This confuses new Drupal users.

Proposed resolution

Add a explanatory note to the UI.

Remaining tasks

User interface changes

New help text on the Blocks UI.

API changes

n/a

Data model changes

n/a

Original report

I don't know (and apologize if I'm "coloring outside the lines"), but I'm getting no useful response from my post on the user forum: Bartik Footer Bug?
Home » Administration » Structure » Blocks » visibility settings » Roles »

Show block for specific roles
anonymous user
authenticated user
administrator

Show this block only for the selected role(s). If you select no roles, the block will be visible to all users.

I have none of the three options checked (selected) regarding all four of the associated blocks. Apparently, this is not functioning as "advertised".

So . . .what to do? Seems like a bug to me.

CommentFileSizeAuthor
#13 visibility.jpg19.11 KBdcrocks
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rtwingfield created an issue. See original summary.

cilefen’s picture

Category: Bug report » Support request
Priority: Major » Normal
Status: Needs work » Postponed (maintainer needs more info)
Issue tags: -Bartik, -block footer, -user roles

I cannot understand what is being asked in this issue. There are some blocks not visible, it seems. Which blocks? Having read the forum thread, it is the search block. A common misunderstanding is that you have to grant anonymous users permission to use search. Please check on that.

rtwingfield’s picture

I cannot understand what is being asked in this issue. There are some blocks not visible, it seems. Which blocks?

Did you really read it? I don't know how to be more clear. The Bartik theme contains four "footer blocks" . . .left to right, "Footer first column", "Footer second column", "Footer third column", "Footer fourth column". Yes, they are there . . .in addition to yet another "wholesale footer" block that follows below and spans the width of all four previous "footer" blocks (confusing . . .multiple footers followed by a broader single footer). These are apparently described in regions??? Take a look at this URL: Bartik theme footer layouts Of course, you won't see the first three of the four . . .since you can't login as an administrator.

Following the sequence, "Home » Administration » Structure » Blocks » visibility settings » (and finally clicking into) Roles »
. . .you will see instructions for (as follows)

Show block for specific roles (each of the three following options have a little "checky box")
|_| anonymous user
|_| authenticated user
|_| administrator

If this freekin' forum would let me easily post a screen scrape, then I'd show you a visual of what it looks like.

The instructions for administration of the block states, "Show this block only for the selected role(s). If you select no roles, the block will be visible to all users."

Well, I have "selected no roles" . . .so the block(s) should be "visible to all users."

All four of the blocks are only visible if I am logged-in as an administrator.
(BTW, as an experiment, I just checked all three options for all four footer blocks, logged out . . .and same results -- no display of the first three footer blocks.)

Only the fourth block is visible to an anonymous user.

Striking out my "issue comments, description . . .whatever" is as far as I'm concerned, just dismissing my questions regarding the issue and paramount to saying " just go away".

To me, this seems like a bug.

cilefen’s picture

Please understand that support in this queue is from volunteers, often during non-work hours.

The problem you are reporting is unusual. This is why it is met with some skepticism from me. Others that are helping you on this issue may not feel the same way.

Is caching enabled?

dcrocks’s picture

The items you listed are regions, not blocks. From your description, it looks like you clicked on Demonstrate block regions(Bartik) on the Administration>Structure>Blocks page. That is where you would see those regions listed left to right. After exiting from that, you must have clicked configure for one of the blocks which would display the "Roles" options. Could you tell us which block you selected? Or did you click on Add block?

rtwingfield’s picture

First, thanks for your attention to this "issue".

Yes, following the path of Home » Administration » Structure » Blocks
displays a page of four columns:

BLOCK -- REGION -- WEIGHT -- OPERATIONS
(display of weight column is optional)
(operations contains the configure and may have a delete option, too, if the block was a custom add?)

As I've previously mentioned these four "region/blocks" are identified in the BLOCK column as

  1. Footer first column
  2. Footer second column
  3. Footer third column
  4. Footer forth column

Almost six weeks have passed since I first encounter this problem regarding the selective display by roles. Exactly how the content of the first three was selected is a little foggy in my memory.

I added custom block content to the forth footer column region(?) regarding the Drupal CMS (Anything that boasts, "Powered by . . .whatever" just annoys me; may as well claim Powered by Kryptonite. I prefer something more pragmatic like "Content managed with Drupal" . . .if to be advertised at all.)

Regardless, continue clicking into configure allows access to Roles within Visibility settings.

The content of these region/blocks are as follows

  1. Footer first column -- Management
  2. (access to Administration page)

  3. Footer second column -- Navigation
  4. (add content and contact)

  5. Footer third column -- Search form
  6. (. . .well just the search form)

  7. Footer forth column -- Content managed with Drupal

If you review this previous post comment #3, I have asked the system to display (by default?) all four footer columns, yet only the forth displays for an anonymous user.

I'm just following the instructions for "Show block for specific roles". Is there some special nuance that I'm "just not getting?"

dcrocks’s picture

Status: Postponed (maintainer needs more info) » Active

Spent some time using the Search block and it seems to be a real documentation problem. Using the visibility settings to enable access by role does not necessarily mean that a given role has permission to display a given block. Roles are collections of users, with the anonymous role being a collection of just one user. For example if you go to 'administration>people>permissions' and scroll down the page to the Search group you will see that the ANONYMOUS USER role does not have permission to use the search block. Turning on that permission there will allow you to see the Search block on the front page.
So what the visibility by role setting is saying that all users belonging to a given role can have access to a given block, if that role's set of permissions allow access to that block. Another way to say it is that using Roles to control visibility means that only the permission set(s) of the selected role(s) will control access.
A little clearer than mud, but not by much. The use of 'Roles' in Drupal can be very powerful but its implementation in a vanilla Drupal install can be a real stumbling block.

dcrocks’s picture

As another note, if you are only interested in specific blocks you can go to administration>people>permissions and set permissions by role there and ignore block visibility settings. But be careful.

cilefen’s picture

Component: Bartik theme » block.module
Category: Support request » Task
Issue tags: +Documentation, +Needs issue summary update

Re #7, true, but this is how it has always worked.

Assuming this is the same in D8, this should be moved to 8.2.x and marked for backport to D7, or, a separate issue opened for D8 (now allowed). It needs an issue summary update as a user-facing documentation change.

dcrocks’s picture

Yes, that is how it has always been, but still confusing, especially for new users. Can you rewrite the issue description and summary?

rtwingfield’s picture

Per dcrocks question,

Can you rewrite the issue description and summary?

I assume that request is addressed to cilefen, re. #9 . . .and not me, rtwingfield. At this point in my "learn Drupal" experience, I'm not knowledgeable to do so, but thank to all for the insight and suggestions. Some solace in learning that perhaps I wasn't too far off base with my "issue".

Seems like "roles" is similar to if not a css class?

Also, seems to me regarding

if you go to 'administration>people>permissions' and scroll down the page to the Search group you will see that the ANONYMOUS USER role does not have permission to use the search block

. . .that the search feature would be a service that all users, guests, authorized experts, whatever, would benefit from having access . . .?

cilefen’s picture

Title: Bartik Footer Blocks not displayed for all user roles » Put a note on the blocks admin UI explaining that setting block visibility by role does not automatically grant permissions to a given block
Version: 7.41 » 8.2.x-dev
Issue summary: View changes
Issue tags: -Needs issue summary update +Needs backport to D7

Some functions, like search, are not granted to the anonymous role in a default Drupal 7 install (it is granted in Drupal8). I don't know why that is by the way.

dcrocks’s picture

FileSize
19.11 KB

Would it do to change the title of that form area from 'Visibility' to 'Visibility Restrictions' The default status for each sub-block is Not restricted. That might relieve the confusion between 'Visibility' and 'Permissions'.

Visibility Form

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.