First, I need to say that you've been doing an amazing job with this module.

I noticed today that you changed the permissions, that's probably because of the toolbar-per-role functionality. But for some reason, now anonymous users see the toolbar even if it is disabled for them.

Because the toolbar is divided in two parts, the shortcuts links and the static links (Hello @username / Logout) the permissions are not being applied to the static links, therefore an anonymous user can see the toolbar.

Comments

dankh’s picture

dankh commented

I'll check this tonight. I'm really busy today, but it's seems like a critical bug. I'll try to fix it as fast as I can, and maybe pull a beta3.

I've just tested quickly. Are you sure you are using 6.x-2.1-beta2, I can't reproduce the bug. The toolbar is ok for anonymous users (Login link), and the toolbar is not visible if there is no toolbar set for anonymous user role.

Please give me more info, thank you.

lelizondo’s picture

lelizondo commented
Version: 6.x-2.x-dev » 6.x-2.1-beta2

For this issue I will use this concepts:

Toolbar: The black thing that goes at the top of your screen.
Static links: the two links to the right, 'Hello Username' and 'Logout' / 'Login' and 'Register'.
Shortcuts: the custom links created by an admin.

Because there are no permissions now to 'see' the toolbar, anonymous users see the toolbar and the static links, if they have no shortcut set enabled for their role, they will not see any shortcuts, but they still see the toolbar with the static links. That's why there has to be a 'use the toolbar' permission, because there might be cases when an admin wants the anonymous users to see the toolbar, with shortcuts and with static links for them, and there might be other cases when visitors shouldn't be allowed to see the toolbar at all.

Also, when you enable the toolbar module in a fresh site, the admin won't see the toolbar at all until he/she enables a shortcut set for the anonymous users, but that's probably another issue.

I'll take a look at the code this weekend if I finish a site I have to publish next monday :)

BTW, I tested this bug with 2.1-beta2, until I check that this same behavior is presented in -dev, I'll change the version.

lelizondo’s picture

lelizondo commented
Version: 6.x-2.1-beta2 » 6.x-2.x-dev

It seems that -dev and beta2 have the same code. Sorry.

dankh’s picture

dankh commented

Also, when you enable the toolbar module in a fresh site, the admin won't see the toolbar at all until he/she enables a shortcut set for the anonymous users, but that's probably another issue.

I installed a fresh Drupal 6.17 installed 6.x-2.1-beta2, the default toolbar ( "Admin", "Administer toolbar", "Toolbar settings") is displayed and the system links ("Hello admin", "Logout", "?"). Are you sure you did a fresh install ?

Because there are no permissions now to 'see' the toolbar, anonymous users see the toolbar and the static links, if they have no shortcut set enabled for their role, they will not see any shortcuts, but they still see the toolbar with the static links.

If there is no toolbar enabled for anonymous users, they see nothing (as expected). If there is a toolbar for anonymous users but they can't access (don't have the permissions to access) any of the shortcuts (try to set the Default toolbar to anonymous users) no shortcuts will be displayed, but the static links are still available, because the toolbar is enabled for the role.

The toolbar module only displays links, this module doesn't manage permissions. If the site administrator creates shortcuts for paths that are not accessible by the toolbar's users, it's site's administrator's problem, not Toolbar module. Example: create shortcut for path "admin" in a toolbar, and then enable this toolbar for anonymous users. They'll not see the "admin" shortcut because they can't administrate the site (or they if they have the permission).

That's why there has to be a 'use the toolbar' permission, because there might be cases when an admin wants the anonymous users to see the toolbar, with shortcuts and with static links for them, and there might be other cases when visitors shouldn't be allowed to see the toolbar at all.

There is such permission it's the "toolbar per role" settings. Every user in Drupal has at least one role (even user 1 (admin) has the role "authenticated user"). If admin wants only to display static/system links then create a toolbar, add no shortcuts in it and set it to anonymous users.

I'm not sure if this is a bug. I think with toolbar per role the module is much more flexible.

lelizondo’s picture

lelizondo commented
Status: Active » Closed (works as designed)

It seems all those problems are caused because I didn't uninstalled the previous version.

dankh’s picture

dankh commented

Ok, great, I'm happy it works. I'll leave this open for a moment if there are other questions related on anonymous user visibility.

Thanks,

lelizondo’s picture

lelizondo commented
Status: Closed (works as designed) » Active

I'm still having problems with this. I have identified the problem, but I still don't know what is causing it.

I have a site and is showing the toolbar for anonymous users because there's a record in the toolbar_user table:

mysql> select * from toolbar_user;
+-----+-------------+
| uid | name        |
+-----+-------------+
|   0 | set-default |
+-----+-------------+

After I deleted it, everything started working. The next step is knowing why there's a record for the uid = 0 in the toolbar_user table.

dankh’s picture

dankh commented

Hi,

uid 0 is the anonymous user. The only way you can have this result in database is :

- give anonymous user the permission to select toolbar
- anonymous user have accessed to user/0/toolbar and has selected toolbar.

You can change this by going to user/0/toolbar select "Role default toolbar" (which actually will delete the database record). But if you really don't want anonymous user to change toolbar remove the permission.

lelizondo’s picture

lelizondo commented
Status: Active » Fixed

I'm changing this to fixed. If anyone has a the same problem, this is probably the problem and the solution. Thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.