Some admins (like me) would prefer to have "approval queue" be the default page for "Comments" administration. Perhaps this could be made an option.

Cordially,
O Govinda
www.jswami.info

Comments

yoroy’s picture

Title: Can "approval queue" be the default page for comment administration? » Make "approval queue" the default page for comment administration

I did a quick poll in IRC in #drupal:
Which of these should be the default view for comment administration?
A: Published comments
B: Approval queue

Got three answers:

- Approval Queue.  Published comments have already gone through the approval queue.
- Concur, you want to show the things that are waiting for action
- Approval queue.

I think so too, so that'll be 4 - 0 for approval queue. That's a best of seven :)
Let's not make it an option to make it the default but just change it around.
Me no write patches but sounds like a small one. It would be another nice little usability improvement.

beeradb’s picture

StatusFileSize
new1.13 KB

Here you go, I can provide a screenshot if needed, but I think it pretty much speaks for itself.

beeradb’s picture

Title: Make "approval queue" the default page for comment administration » USABILITY: Make "approval queue" the default page for comment administration
Status: Active » Needs review
yoroy’s picture

Title: USABILITY: Make "approval queue" the default page for comment administration » Make "approval queue" the default page for comment administration

Thank you! and marking needs review. (it's already in the 'usability' component)

morbus iff’s picture

As someone mentioned in IRC, this presumes that comments /require/ approval. What happens if comments are never moderated? Wasted click to come to here by default.

beeradb’s picture

Morbus: that was me who mentioned that case. I went ahead and rolled the patch anyway so the community could decide. In my opinion it requires an extra click one way or the other, and my guess is that more people go to that screen to approve comments than to look through old ones. It's worth having a discussion about.

ultimateboy’s picture

StatusFileSize
new39.89 KB
new40.08 KB

I started to make this patch, and realized that changing this might not be the best solution. Here is my reasoning: I setup a head version of drupal and commented on a node, I then went to admin/content/comment to see my comment. As expected it was published, because I was logged in as a user which did not need approval for comments. If this idea were to be implemented, this page would have presented me with what is now on admin/content/comment/approval, which in my particular case, is blank.

I think that because of this, this feature would actually be a step back in terms of usability. Lets rethink it a bit. What about combining these two lists into one and making a Status field? (Very similar to how the content administration page is setup) I have included a sample screenshot of how this would work..
altered comment admin form

beeradb’s picture

Status: Needs review » Active

I think ultimateboy is on the right track, but I would propose it should be two separate lists, one above for comment approval (only displayed if there are comments to approve) and one below for published comments.

I don't like mixing the two lists because it reduces the functionality of the select all checkboxes, which I think negatively effects usability.

ultimateboy’s picture

StatusFileSize
new14.71 KB

Agreed.. so I have altered my comp to make the comment page more like the content admin page by adding a filter.
Altered comment admin form

beeradb’s picture

I'm not sure how I feel about that change.

1. It reinstates the click to the approval queue we are trying to avoid, in fact I'd say changing the filter probably adds clicks/time it takes to get to get there.
2. It seems a little overblown unless we're trying to filter by other criteria as well. The only other thing I can think of offhand is user.

ultimateboy’s picture

I was thinking that it was a bit overblown while creating it.. but, at the same time, it is following a precedent set by the content management admin and user admin pages.

There are many different filters that could be useful. User, as you mentioned, but also content type of the node which the comment is attached.

I agree that the method that I have proposed is a bit overloaded.. but I think that simply making it the same as other 'content admin pages' is better than the current setup.

drewish’s picture

my ideal case would be to only have an approval tab (which would be the default) when there are moderated comments. if you've got no moderated comments you see the full listing.

or would that be confusing? would people wonder where the approval page had gone?

yoroy’s picture

I talked a bit more about this with beerdadb, and the underlying issue here seems to be that what we need are ‘smarter tabs’: a group of menu items that checks relevant permissions and based on that makes the most appropriate task the default tab.

@12: yes I think that would be the nicest way to handle it as well. It shouldn't be too confusing. If comment approval is enabled, you want to see the approval queue. If comment approval is disabled, you don't need the approval queue. Typical case where context trumps consistency.

yoroy’s picture

Component: usability » base system

So, where are we now with this?

geerlingguy’s picture

Subscribe - would be nice to have.

yoroy’s picture

Version: 7.x-dev » 8.x-dev

Moving to 8

dawehner’s picture

Component: base system » comment.module
Issue summary: View changes

.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.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.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should 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.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should 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.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should 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.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should 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.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.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: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should 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: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

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

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should 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: 9.5.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. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

smustgrave’s picture

Since this had some early discussion wanted to bump 1 more time.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.