Hi there! First off @gwen - thank you very much for taking this module over. It's a shame it languished for so long as it's very much needed (and I was surprised to see the feature wasn't already in core).
On to my problem. I am running D6.20 with the core blog module, and am trying to enable my bloggers to admin comments on their own blogs, so I installed 6.x-2.0 of this module. I then set my permissions up as follows:
http://screencast.com/t/6EMNWpL5Iq
http://screencast.com/t/VEinanrY
(Yeah, I took the "shotgun" approach on the "own content" permissions as a last resort...)
When I log in as a user who has been assigned the blog author role, I am unable to see comments waiting for approval on any of my existing blog content. However, signed in as an user assigned the editor or administrator role, I do see the comments pending approval, with the "approve" link available.
I updated to 6.x-2.x-dev in the hopes this was maybe on old bug, but am still seeing the same behavior. Is anyone else having this problem, or can suggest the proper combination of permissions to achieve what I'm shooting for?
Thanks!
Comments
Comment #1
axxint commentedI believe I have the very same problem! I posted in the forums a little while ago but haven't heard anything back (http://drupal.org/node/1063902) Here's the content of my post:
I'm trying to use the User Comment Module (6.x-2.0) to allow bloggers to moderate comments on their own blogs.
I've got the module installed & configured and it adds a "delete" permission (next to each already-approved comment) for the role + content type I want to grant access to, but it won't grant "approve" permission even though I have it selected in my permissions for the correct role and content type. Is there something I'm missing somewhere else?
I've been testing it out with comments made after installation in case that matters.
And is it supposed to send an email message out to the approver? It's not doing that either.
Thanks!
I'm using drupal 6.19. I tried upgrading to the dev version of the module as well and that didn't help.
Comment #2
rschwab commentedI'm trying repeatedly to make this bug happen but so far I'm not having any luck. Can you guys provide any more information that may help? Like other modules installed, what theme you're using.
Comment #3
rschwab commentedclosed #1066204: Can't not approve own comments with out comment module 'adminster comments' permission as duplicate.
EDIT: The user there reported using these comment-related modules:
1. Comment Mail
2. Comment form above
3. Comment Notify
4. Comment Permissions
5. Comment Service?
Of the 4 of those I can find, I suspect usercomment might be having a conflict with 1 & 4. Do either of you guys use these modules as well? If so, what are your settings for them?
Comment #4
rschwab commentedPlease understand that I don't doubt you are seeing a legitimate bug, but without a way to see it in action I don't know where to begin to try to squash it.
Comment #5
SchwebDesign commentedi'm so glad to find this thread as i'm having similar issues. This module is exactly what i needed and in my case seems to be working as advertised EXCEPT that emails are not sent out to a user when comments are submitted. Everything else seems to work fine (approve, reply, delete links exist on each comment, comments to approve show on user's content type's page as well as approved comments)!
Here's my setup:
Drupal 6.20
Theme : Acquia Prosper 6.x-1.1
Modules installed that could possibly affect this problem (there are others installed):
User Comment 6.x-2.0
Boost 6.x-1.18
Content Profile 6.x-1.0
Content Profile User Registration 6.x-1.0
Content Profile Tokens 6.x-1.0
Better Formats 6.x-1.2
CAPTCHA 6.x-2.4
Image CAPTCHA 6.x-2.4
Fivestar 6.x-1.19
Fivestar Comments 6.x-1.19
Voting API 6.x-2.3
Any advice, comments, or questions to help me troubleshoot and get to the bottom of this would be greatly appreciated!!
Comment #6
SchwebDesign commentedalso, for user's role i'm testing with "skip author approval queue when posting comments" and "administer comments on own content" are both enabled.
also "Receive e-mail notifications" IS enabled on this test user's profile edit page.
Comment #7
SchwebDesign commentedokay good news and sorry for any false alarm but something still seems fishy here:
I realized the following was automatically checked for my test user as well. not "Profile" is the name of the content type for me.
As soon as i unchecked this and tested a comment, i did get the email as expected! Now i'm searching for a way to have this disabled by default as this was my expected default functionality... any advice would be appreciated!
Comment #8
SchwebDesign commentedOkay i just found Untick "Skip page approvals" by default: http://drupal.org/node/583698 and your response:
am i misunderstanding this?
In my case, having this ticked disabled emails being delivered when comments were made which makes sense... however if a user doesn't know this is checked by default, they'll never know why they're not receiving emails notifications. When unticked, i got the email notification as expected. Either way, this checkbox had NO effect on allowing/disallowing commenting. Rather, it did have effect on whether or not email notifications were received, and as such, seems it should be DISABLED by default as people expect email notifications to be received with this module "out of the box" unless that's turned off by unchecking "Receive e-mail notifications"
...any thoughts...?
thanks!
Comment #9
rschwab commentedHello and thanks for trying to help get this resolved. Here are the assumptions behind the defaults:
- The average user would be surprised in a bad way if they started receiving a bunch of "approve this comment?" e-mails from a site without first giving that site explicit permission to e-mail them (this is the receive e-mail notification default being unticked).
- Many sites have users who post a node or two, and never return to the site. If this user didn't also visit their account page to check "skip approvals", comments on their nodes would never be published. The assumption is that site owners want comments being made, but also want to give their returning users some extra power on their nodes (hence the skip approvals ticked by default).
- You as a site builder may expect e-mails to go out by default, but the average user isn't aware of all the features of a site. The default of approvals being skipped assumes that the average user won't set their account settings, and therefore won't miss the feature they don't know exists. A user who returns often will eventually discover the feature, and make the choice at that point whether they want to start controlling comments on their nodes.
My statement "It would effectively disable commenting until the author became aware of the feature" refers to that point above. It doesn't actually disable commenting, but a user who never came back to the site and didn't check their settings would have comments awaiting approval indefinitely.
These are only the assumptions I've made, I welcome more discussion on the topic.
In the meantime, those who want comments to require approval by default please see the very helpful code snippet here: http://drupal.org/node/583698#comment-4208540
So far I have two requests for an option for site builders to choose that default, I suppose if I get some more I'll add that to the modules admin settings form.
Comment #10
SchwebDesign commentedThanks for your very well elaborated response. Thanks for seeing the "big picture" here - I actually agree with your assumptions 100%, but do believe it would be helpful for some to have an option in the module's admin to allow site builders to choose this default. But like you said- it may be rather uncommon.
My implementation of Drupal and this module is a site where people can post a profile with their user account which is search-able by people who already know who they are. Thus each user only has one piece of content on which to manage comments. Comments in this implementation could affect a user's "reputation" and thus the ideal in my case is for comments to require approval of the user whose profile they are posted on.
ref: www.findmyhairstylist.com
Thanks again for the great support and module
Comment #11
rschwab commentedOn second thought more flexibility when the overhead is virtually non-existent can only be a good thing. I'm going to open a separate feature request issue to allow site builders to choose their defaults. The defaults from my assumptions above will be the defaults on the admin settings form. Now the trick is finding time to implement this stuff :)
Unfortunately its been almost a month since I've heard from the people experiencing an actual bug, and because I can't reproduce it I'm going to close this for now. As always, I encourage you to re-open this issue if you guys can provide more information.
Comment #12
SchwebDesign commentedGood point. Thanks for doing that.