If the "Administer Panelizer overview" permission is not enabled, then the "panelizer" tab does not show on an entity, even if the user would have access to other tabs below it (like content). While to some extent that makes sense, it's completely non-obvious. At the least, that should be specified in a permission description.

If a user has "panelizer overview" and "panelizer content" permission, he can get to the content page. On that page, however, no tabs show. The page works, but there are no tabs, which makes it impossible to go back to the node itself when you're done. Enabling "panelizer settings" permission brings back all of the tabs, but that's not desirable since in my case I don't want users to be able to mess with the renderer, custom CSS, etc.

The modules page reports my Panelizer version as 7.x-3.0-rc1+0-dev, for whatever that's worth. :-)

Comments

Taxoman’s picture

Priority: Normal » Major
merlinofchaos’s picture

Like as not, the Overview is going to be required; because Drupal does not let you switch which tab the 'default' tab is, thus the default tab must have the "minimal" permissions for the system. So the overview tab will always be required.

However it seems like a bug if the settings tab is required, so I will have to doublecheck that part.

merlinofchaos’s picture

Status: Active » Fixed

After some investigation, the problem is basically a flaw in the tabs system that is more or less unfixable, as near as I can tell, because Drupal won't let you define a default local task dynamically. And if the 'settings' page isn't visible (which is the default local task for any given view mode) that tab becomes invisible. And then, Drupal elects not to render the parent tabs, for reasons I don't understand.

However, it *does* render whole path in a breadcrumb, so you *can* get back, you just have to know to look at the breadcrumb.

I committed and pushed a fix to improve the text on the overview permission, but I don't think I can actually do any more. :(

merlinofchaos’s picture

Maybe a workaround is that if all you *really* want them to have is the content tab, just give them IPE instead?

merlinofchaos’s picture

I suppose one fix might be to use some kind of switch logic so that the default local task is always the first one available, but the access logic gets complicated, because...well, you have 4 tabs:

settings, layout, content, context

'settings' is default. Its logic would look like this:

  if (user_access(settings)) { 
    return settings page; 
  } 
  else if (user_access_'layout') {
    return layout page; 
  }
  // ... and so on

And it would need the access callback and title callback to work similarly.

THEN, however, layout, content and context would all need this in their access:

  if (!user_access(settings)) {
     // if 'settings' is inaccessible, I need to check and see if this page is replacing settings; if it is, it is inaccessible from this tab.
  }

I'm trying to decide if it's worth it to put in that beastly logic. It's made works because the whole operations tree is alterable so that modules like panels_breadcrumbs can add a breadcrumb tab.

Status: Fixed » Closed (fixed)

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