Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Comments administration is a tab on content administration in the d7ux screenshots. Here's a patch which does that.
http://farm4.static.flickr.com/3343/3569318373_4b256ed70c.jpg?v=0
http://www.d7ux.org/category/projectframework/content/
Comment | File | Size | Author |
---|---|---|---|
#26 | screenshot_047.png | 40.1 KB | catch |
#20 | comment_menu_magic.patch | 9.6 KB | chx |
#18 | comment_admin.patch | 4.04 KB | catch |
#17 | comment_menu_magic.patch | 2.18 KB | chx |
#16 | comment_menu_magic.patch | 2.08 KB | chx |
Comments
Comment #1
catchforgot to change tests, let's see how bad this fails.
Comment #2
Dries CreditAttribution: Dries commentedI support this patch (if it doesn't fail badly).
Comment #3
chrishaslam CreditAttribution: chrishaslam commentedHi
This patch applied successfully to drupal 7 CVS
Hunk #1 succeeded at 1648 (offset -6 lines)
Comments administration now appears as a tab as expected after flushing menu cache
Comment #4
buddaI don't believe this adds usability. Its removing 'Comments' from the navigation tree and hiding it under 'Content'. Are comments just classed as content now?
If comments are just part of content, i think the description text needs updating so that the /admin/content page lets a new admin know that comments are hidden away in here too.
Comment #5
catch@budda - the idea with the d7ux mockup is that all content administration are available from one 'find content' page. Comments are already administered as part of 'content', so I think this makes complete sense.
Even with our current IA I think it makes sense to have these available in one place rather than separate menu items - if I'm trying to delete spam, it's easier to switch between tabs than it is to click up and down a menu level.
I looked at adding comments to the description, but the description either has to assume comments are enabled, or it has to add a module_exists() check for comment.module - neither of these seemed ideal but I'm open to ideas - trying to remember if we have a 'description callback' in the menu system or not. If we do it's an easy fix, otherwise a bit of a pain, but yeah needs to be dealt with.
I opened an issue for moving book administration to site building, RSS publishing settings should probably move to settings, taxonomy could also move to site building. That'd leave us with potentially just a single admin/content for administering content - which IMO is all that should really happen there.
#501472: Move book administration to admin/structure
Comment #6
Bojhan CreditAttribution: Bojhan commentedThis is good because we centralize all content under one hub, however this is on the premise that MDB work gets in and we don't have to mess with the non-prominent garland tabs.
Comment #7
catchThis passes comment and tracker tests locally.
Comment #9
catchHello, test bot.
Comment #10
catchAdded hook_menu_alter() for the admin/content/content description.
Comment #11
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks, catch.
Comment #12
catchThanks Dries :)
Comment #13
sunNow someone should create a user that only has privileges to administer comments, but not administer nodes and stuff. The result? No menu item to administer comments.
Comment #14
catchSo just to make it clear what the problem is you can still visit admin/content/content/comments directly with just that permission, but you don't get the menu item or access to admin/content itself.
There's a couple of options - find a way to keep the top level link even if the only thing available is the tab. Or a patch like #301902: Allow more users to see the node admin page to make admin/content accessible to any user who can do something with content (edit own, edit any, administer comments attached to it) and then make the operations you can do there more granular. I think the latter is the proper fix for this particular issue, the tab one is more general though.
By the way tha_sun and i duked this one out in irc for about an hour and somewhat stalemated.
Comment #15
chx CreditAttribution: chx commentedcheck http://drupalbin.com/10179 for a solution that works. I need to fix the description and then it becomes a patch.
Comment #16
chx CreditAttribution: chx commentedI think someone should add a test.
edit: the altered description maybe wants to be 'List and edit site comments and the comment approval queue.'
Comment #17
chx CreditAttribution: chx commentedI have changed the hardwired access check to menu_get_item checks. A bit slower... but i doubt performance is a penultimate problem on these pages.
Comment #18
catchAdded a basic test for who sees what where under what circumstances.
Comment #20
chx CreditAttribution: chx commentedNeither the test nor the patch is perfect but here I offer this way more complete solution.
Comment #21
Dries CreditAttribution: Dries commentedThis needs a generic, clean and elegant fix because this pattern is used throughout many of the mockups in the new IA. Talking to Mark and Leisa, they want to fix the use of tabs and switch the model around. Tabs are views, not actions.
I'm a bit worried about:
Given that this will be a very common practice, I'm not sure we want to use these 'tricks' as a pattern throughout Drupal. The patch is pretty undocumented so I'm not 100% yet what it does, but can't we auto-promote the next tab to the default tab, if there is no default tab?
Comment #23
pwolanin CreditAttribution: pwolanin commentedWhile this might function, I stick by the decision to eliminate the "bubbling" behavior of D5. We should fix up the permissions in the hierarchy if we want users of this page to see a link by default.
Comment #24
sun.core CreditAttribution: sun.core commentedyay, bump! :) This maps 100% to my predictions for 2010.
Comment #25
sun.core CreditAttribution: sun.core commentedComment #26
catchThe comment page now looks like this if you have "access content overview" and "administer comments" - this covers the intent of the D7UX IA as best we could and 'access content overview' was necessary for reasons long predating d7ux.
So I'm moving this over generically to the menu system, leave it up to others whether it's a release blocker or not.
Comment #27
sun.core CreditAttribution: sun.core commentedThis is still critical due to the IA changes we applied to D7. I won't comment on those anymore, but this particular bug makes certain use-case scenarios impossible in D7, which perfectly worked previously.
Comment #28
pwolanin CreditAttribution: pwolanin commentedCan you summarize the bug/regression or use cases that cannot be accommodated? what is the desired behavior?
Comment #29
sunQuite simple:
"A moderator, who moderates comments."
Nothing more, nothing less. No "administer nodes" or whatever permission.
In D6 and below, this user had Administer -> Content management -> Comments.
In D7, this functionality would be expected on Administer -> Content. Technically, by auto-adjusting the default local task according to the user's permissions.
The most recent patch on this issue is quite creative, but is also an aggressive hack. I fail to see how a contributed module would be able to override or extend the local tasks for users that only have the "administer comments" permission.
Comment #30
catchThat's possible now with 'access content overview' - doesn't give you any extra privileges beyond accessing the content overview, and this only shows you content you have access to. It's also no more clicks to go 'content' => 'comments' than it was to go 'content' => 'comments' => in D6. Hence it's not critical - certainly not compared to some other issues which have recently been bumped back to normal.
Comment #31
sunComment #32
sunAlthough badly needed, this is D8 material according to the rules (I had to learn today). It may be backported at a later point in time (though that's unlikely).
Comment #33
Damien Tournoud CreditAttribution: Damien Tournoud commentedOnly feature requests and tasks can be assigned to D8 for now, because the Drupal 8 tree is not opened yet.
Fortunately, this feels more like a feature request to me.
Comment #34
klonos...
Comment #35
catchNot sure what status of this is.
Comment #56
smustgrave CreditAttribution: smustgrave at Mobomo commentedThink this probably can be closed as there hasn't been movement on it for 13 years. Plus there seemed to be some commits already made for it. If still a valid feature request though please reopen updating the issue for how this applies for D10 and up.
Thanks!