Closed (fixed)
Project:
Administration Views
Version:
7.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
7 May 2012 at 16:36 UTC
Updated:
26 May 2012 at 22:00 UTC
Jump to comment: Most recent file
Comments
Comment #1
szt commentedAlso the List tab...
Comment #2
damiankloip commentedI can confirm this too, on the latest dev version. I am looking into what's happening here now.
Comment #3
damiankloip commentedHmmm, it seems that user.module is creating a menu item at admin/people, that is the actual user listings callback page you see, but also an empty tab that just acts as a default tab, with the callback being inherited from it's parent (admin/people). So if the view is admin/people/people we get our tab back ok, but can't see the view at admin/people only by going to admin/people/people...
Comment #4
sunThat's odd. The System display handler should account for the default local task and any other local tasks already.
I wonder why this works for the admin/content view, but not for the admin/people view?
Comment #5
damiankloip commentedsun, yes, it's strange. They both have the same menu structure I think.....
Comment #6
lpalgarvio commentedconfirming this issue, drupal 7.14.
additionally, if you try creating a custom page in ctools page manager, it won't let you.
admin/people
admin/people/people
and when i try to access admin/people/people, i get a not authorized error.
Comment #7
sunI've spent the past couple of hours to debug, analyze, and fix this bug. (Even though I don't have the pleasure to be able to use this module in any of my projects myself currently...)
Attached patch fixes the router item property inheritance and makes those pages work again.
Comment #8
sunNow with automated tests to prevent this from happening in the future.
Comment #9
sunThanks for reporting, reviewing, and testing! Committed to 7.x-1.x.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.