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.
I could really use an option to prohibit members from voting on their own nodes. This could be in role permissions or on the existing "content types" preferences screen.
This would be a big help.
Thanks.
Comments
Comment #1
photoscapes CreditAttribution: photoscapes commentedI am looking for the same thing. Did you find a solution to this yet?
Comment #2
neopoet CreditAttribution: neopoet commentedNope :(
Comment #3
neopoet CreditAttribution: neopoet commentedI just discovered this-- it might be of interest.
Instead of prohibiting people from voting on their own items, it automatically "self votes" 100% on each-- I suppose it has essentially the same effect.
http://drupal.org/node/176560
Comment #4
john.karahalis CreditAttribution: john.karahalis commentedThis feature is needed. I'm going to send a quick message to the developer and ask what he/she thinks.
Comment #5
ezra-g CreditAttribution: ezra-g commented[edited for clarity]
A quickie way of achieving this functionality would be to set the Fivestar widget to display manually and then in the node template add a conditional to check if the current user is the author of the node being viewed before printing the fivestar widget:
If this was added to the module as a configuration option, should it be site-wide, on a per-role or a per-node type basis?
Comment #6
john.karahalis CreditAttribution: john.karahalis commentedI thought about doing something like that, but wouldn't that also prevent the author from seeing the current rating of his own posts?
Comment #7
jhedstromI've created a patch that accomplishes this via an additional permission (rate own content). Note, since the new permission won't be immediately granted to users, this will change default behaviour, which may cause confusion (users who used to be able to vote on their own content, won't be able to do so, until the new permission is granted).
Comment #8
dawehneri wrote a similar patch, which adds some more features than just rating on own content
* allow to rate on author content, by nodetype
* allow certain users to rate always on own content, even if forbidden by the node type settings
Here is the patch
written for head, but should also work for previous versions
Comment #9
ibexy CreditAttribution: ibexy commentedapplied this patch. The option for vote on own node appeard in as expected and even though its not checked, users can still vote on their own node. I have installed the advanced profile module and it creates profiles as biography node type. Users can still vote on their own profile display in a view I implemented.
Comment #10
roderikFYI: I applied the patch from #8 (whose way of thinking seems to me to be more inline with Drupal/fivestar than #7) to the 6.x-1.13 release.
It applied (with huge offsets, but still) and worked well against my custom node type. NB: the 3rd hunk of the patch fails to apply; this is not a problem. (See the patch itself, if curious.)
Comment #11
dawehneryes definitve something strange, the last part
i wrote the patch, if i remember right for the last five devel version
it removed the 3 stuff and there are no problems anymore with patching
more people who would like to test?
Comment #12
chasz CreditAttribution: chasz commented+1
Comment #13
yrre7 CreditAttribution: yrre7 commentedsubscribing
Comment #14
quicksketchThis patch seems like a pretty good idea in most regards, but the implementation does not work at all. There are several permissions that are checked:
Yet these permissions "rate on own content" and "allow always to rate on own content" don't exist. I don't think they should exist at all anyway. I'd find their usefulness extremely limited compared to the addition of code. So I'd opt for removing what exists of them from the patch.
The patch also sets a variable for
'fivestar_author_'. $node_type
, but doesn't use it anywhere. This should be the only variable checked for access IMO (in addition to "rate content" of course).I do like how this patch modifies fivestar_widget_form() to include the permission checking though. This would save a lot of themers the hassle of checking permissions themselves. It would also allow us to simplify the code in fivestar_nodeapi(), where we're doing similar checks.
Lastly, this patch would also have to incorporate functionality into fivestar_comment module, as this approach would only stop you from voting directly on nodes, but you could still leave a rating through a comment.
So I'm in full support of this patch, but it still needs some work.
Comment #15
dawehnerVery very strange, here is the original patch rerolled to the new version
The patch applies perfect here, even on the current version for 6
but i have to create a fivestar_access function, because fivestar/vote could be accessed without the permission to vote on own content.
fivestar_access is not good, because of hook_access, any other suggestions
Comment #16
hedac CreditAttribution: hedac commentedis this applied in current dev of 6.x ?
an "Allow users to vote own nodes" toogle in the options of each content type would be awesome. just below "Allow users to undo their votes".
Comment #17
dawehneri think this is not part of any dev.
i will find time this weekend to reroll the patch... get some work in it
Comment #18
gonzalez_ea CreditAttribution: gonzalez_ea commentedsubscribing
Comment #19
Flying Drupalist CreditAttribution: Flying Drupalist commentedSubscribe
Comment #20
dawehnergood morning
i removed the permissions and just check for content type now.
additional i added support for comments and testet it
Off Topic: What does this line? :)
<?php $comment->fivestar_rating = $comment->fivestar_rating; ?>
here is the patch
Comment #21
dawehnerComment #22
oradoe CreditAttribution: oradoe commentedDELETED
Comment #23
roderik#20 applies to 5.x-1.13 and 6.x-1.13. (to both modules with offsets? But does not matter I guess)
And works.
So after the scrutiny already received by quicksketch, I guess I can change status?
(I should be more proactive next time and ask "what are all these permissions", I guess.)
Comment #24
sped2773 CreditAttribution: sped2773 commentedThe patch in #20 will not work for fivestar_comment the + line below only checks if the fivestar_author_vote variable is set or not i.e. it will be disabled or enabled it does not take into account the current user at all so if it is enabled everyone can rate, if it is disabled no one can rate.
There needs to be a check similar to that perform in the fivestar_widget_form in fivestar.module to check the if the user is the node author e.g.
Comment #25
quicksketchYep, needs work per sped2773's comments. This needs to be updated for fivestar_comment.module.
Comment #26
dawehnerhere is a new version which solved the fivestar_comment problem.
OT. should i write a test for this?
Comment #27
bakhayt CreditAttribution: bakhayt commentedSubscribing
=====
The online community of Dubai.
Comment #28
gunzip CreditAttribution: gunzip commentedsubscribe (will this appear in the core ?)
Comment #29
czeky CreditAttribution: czeky commentednew patch on this?
Comment #30
czeky CreditAttribution: czeky commenteddid the patch manually on older dev version, thanx
Comment #31
Parkes Design CreditAttribution: Parkes Design commentedSubscribing
Comment #32
Breakerandi CreditAttribution: Breakerandi commentedI'm too stupid to do a patch, so I hope the problem will be fixed in the next release..
Comment #33
jwjoshuawalker CreditAttribution: jwjoshuawalker commentedHey guys, not sure if everyone is content with the current fixes available. I hadn't seen this thread during my time working on creating this effect.
Here is a method of preventing the node owner from voting on the node. This does not 'patch' or in any other way effect the fivestar module which allows you to upgrade as new versions come out.
First step is making a node-your_content_type.tpl.php for the node types you have fivestar voting on.
Next, in the location you wish your fivestar to be located, enter this code:
This obviously also prevents anonymous users from voting. It also checks to see if this user has voted previously and does not let him vote on the node again or change his vote.
To accomplish preventing the author from voting on his own node without doing the other 2 checks, just enter the code like this:
I know this works on fivestar 6.x-1.15 and 6.x-1.18 and probably any other release.
If you use the first version of the code, users will be able to change their vote while still on the page in case of an accident or mis-click, but once they leave the page or refresh, the vote is locked and they cannot change it. The second version however, uses fivestar's typical procedure that allows users to change their vote at any time.
Also be sure to go back to the settings page for that content type, and turn off the fivestar displays for teaser and full node. DO NOT disable it, just select "hidden" from the 'Teaser ' & 'Full Node' display options.
Comment #34
gunzip CreditAttribution: gunzip commented@blindside,
correct me if i'm wrong but i think this does not solve the problem at all
as users can still vote on their own items doing a direct http POST request.
Comment #35
jwjoshuawalker CreditAttribution: jwjoshuawalker commentedNever looked at that. I didn't count on fivestar ninjas~
I suppose in that case, if you still wanted to stay out of the module's code, you could put something else inline with the 'if this node is owned by this user' check, a URL parse to also exit() or something if they try to do a direct POST.
Comment #36
drupov CreditAttribution: drupov commentedsubscribe
Comment #37
gmcs CreditAttribution: gmcs commentedsubscribing. this is surely an essential feature for a fair reflection on voting?
Comment #38
mrówek CreditAttribution: mrówek commentedThis works with Fivestar 6.x-1.19
1) Add to function fivestar_form_alter
2) Add after
this additional checks
Insert global $user; before those ifs
Comment #39
GreenReaperSurely all you need for part 2 is this?
&& ($node->uid != $user->uid || variable_get('fivestar_author_vote_'. $node->type, 1))
If the first test fails, the first part of the second test is redundant.
Comment #40
azwildcat CreditAttribution: azwildcat commentedI applied the patch from #26 and it did what it was supposed to do but now the authored user cannot see the score for his node. The star display style setting is “display user vote value” and text display style setting is “current average in text.” See the attachments to see what I mean. Users should not be allowed to vote on their own contents but should be able to see the scores tallied from other users. Please fix. Thanks.
Comment #41
mrówek CreditAttribution: mrówek commented@GreenReaper
This test is used to decide if to use static (info only) or dynamic (voting) widget:
$node->uid != $user->uid // use dynamic widget always when not-author is watching
OR
$node->uid == $user->uid && variable_get('fivestar_author_vote_'. $node->type, 1) // if author is watching but setting says author can vote on him self - use dynamic widget
"If the first test fails, the first part of the second test is redundant."
Yes you are right :) , but i prefer using more readible way.
----
@azwildcat
I had same problem with this patch. Try my way. I don't know how to make patches, no time to learn it :|
Comment #42
drupov CreditAttribution: drupov commented@mrówek: hi, what do you mean in #38 by "Insert global $user; before those ifs". Which "ifs" do you mean?
Would it be possible to make a patch for your solution?
Comment #43
kumobako CreditAttribution: kumobako commentedPatch for #38 against 6.x-1.x-dev 2010-Jan-28.
Thank you mrówek.
Comment #44
GreenReaperTo extend this to comments, which can be posted by anonymous users, I needed the hostname. I ended up adding hostname in various database query strings in the fivestar_bonus_api module and then using it in fivestarextra. Just throwing these patches out there in case anyone is in a similar situation.
Comment #45
joeytheman CreditAttribution: joeytheman commentedis this going to be committed?
Comment #46
joeytheman CreditAttribution: joeytheman commentedor developed for 6.x?
Comment #47
tbertin CreditAttribution: tbertin commentedsubscribing
Comment #48
mstrelan CreditAttribution: mstrelan commentedsubscribe
Comment #49
joyseeker CreditAttribution: joyseeker commentedForget what I wrote earlier -- got the patch in #43 working -- I guess it would help to log in as a different user when making a comment to test it... Thanks for the patch!
Comment #50
ltwinner CreditAttribution: ltwinner commentedIt's nearly 3 years since this issue was posted, any chance of committing a fix?
Comment #51
mstrelan CreditAttribution: mstrelan commentedComment #52
coolhandlukek2 CreditAttribution: coolhandlukek2 commentedSubscribe - will try #43 kumobako's patch would be good to have this commited.
Comment #53
dawehnerUnassign myself.
Comment #54
YK85 CreditAttribution: YK85 commentedsubscribing
Comment #55
udvranto CreditAttribution: udvranto commentedNot sure why it's not part of the module!
Version 1.3:
includes/fivestar.admin.inc
fivestar.module
function fivestar_get_settings($node_type, $tag):
Comment #56
udvranto CreditAttribution: udvranto commentedWhat do I need to do to check it in the dev?
Comment #57
udvranto CreditAttribution: udvranto commentedChanges for 7.x
Update: Ignore this
Comment #58
udvranto CreditAttribution: udvranto commentedFor 7.x
Update: Ignore this
Comment #59
udvranto CreditAttribution: udvranto commentedVersion 6.x-2.x
Comment #60
udvranto CreditAttribution: udvranto commentedVersion 7.x-2.x head
Not sure if I should change the version in the issue.
Comment #61
Weka CreditAttribution: Weka commented+1 Subscribe
Comment #62
Weka CreditAttribution: Weka commentedAnother temporary solution until this feature is implemented would be to:
1: Change the Teaser/Full node display options to either 'hidden' or 'Static display ...
2. Set up a view for the voting process using the User: Current filter.
Comment #63
udvranto CreditAttribution: udvranto commentedI am not sure why this feature is not being considered for so long. Clearly many users want this and has been manually implemented by many.
I have been using the dev version and getting tired of manually patching the module again and again. :(
Comment #64
ezra-g CreditAttribution: ezra-g commentedComment #65
brunorios1 CreditAttribution: brunorios1 commentedsub
Comment #66
john.karahalis CreditAttribution: john.karahalis commentedThis bug has been open for a long time. Is this something that belongs in the Voting API instead? If so, maybe we could hand it off to them.
Comment #67
ericduran CreditAttribution: ericduran commentedHmm, so this has been a request for a long time now and is actually one of those tickets that just keep coming up, so lets just fix it once and for all.
Some feedback on the ticket. -- We need too suport both the node specific fivestar widget but we also need to add support for the exposed stars formatter since it's probably going to be more popular because is the only way you can get fivestar on any entity.
Comment #68
gawi CreditAttribution: gawi commentedWhat is the current state of this fix and condition of this request?
Thanks
Comment #69
Leeteq CreditAttribution: Leeteq commentedComment #70
ericduran CreditAttribution: ericduran commentedThis is not a major issue. I'm changing to minor. For my own sanity on the issue queue.
Comment #71
ericduran CreditAttribution: ericduran commentedOk, so unless someone writes a patch for the 7.x-2.x version, I honestly don't see this feature getting in.
Marking it as wont fix unless someone wants to take it over.
Comment #72
kssundar CreditAttribution: kssundar commentedHere's a js quick fix. No need to change fivestar module
You can try to simplify this further by writing hook_perm in a custommodule and using the permission here.
You can also put this code in node.tpl.php or node-content_type.tpl.php. Just replace $form['nid']['#value'] with $node->nid and there will be no need of form alter there.
Comment #73
rogical CreditAttribution: rogical commentedthis is quite necessary and waiting for a patch also.
Comment #74
Energyblazar CreditAttribution: Energyblazar commented+1 me too waiting form a long time for this patch, that disables the author to vote on himself...
Comment #75
dimitriz1 CreditAttribution: dimitriz1 commentedThis is a joke that this hasnt been implemented into the module yet. One of first things anyone would think of when writing a rating system is to prevent a user voting on their own content...how did no one think of it for this module. And this is the longest running and has the most comments of any issue in the queue, maybe the maintainer should step aside from this module if they are not bothered putting in this simple and much demanded feature that has been requested for nearly 5 years now.
Comment #76
rogical CreditAttribution: rogical commentedAgree.
Comment #77
Mile23Just to point out that there's a patch at http://drupal.org/node/189527#comment-3973308
Comment #78
soulfroysI use the patch in #43 since 11.07.2010 without problems. I fixed the codeding standard and reroll against the last version (6.x-1.20). This is critical, isn't It? Without this feature, I can not use it.
Comment #80
soulfroysOops...
Comment #81
soulfroys#78: allow-disallow-rate-own-content-option-189527-78.patch queued for re-testing.
Comment #82
G2 CreditAttribution: G2 commentedComment #84
G2 CreditAttribution: G2 commentedComment #86
G2 CreditAttribution: G2 commentedI created a patch for the latest version (7.x-2.x-dev) using the same logic as the patch in #78. It also works well with 7.x-2.0-alpha2.
Comment #87
G2 CreditAttribution: G2 commentedComment #88
Energyblazar CreditAttribution: Energyblazar commentedHi there guregori
Firstly thank u for ur time and effort...
I did try ur patch, after applying went to Configuration > Content Authoring > Fivestar, found no checkbox there. So then when to structure > content types > created content > Manage Fields > Fivestar field settings, still no checkbox named "Allow author to rate own content".
But yes when i went to People > Permissions > Fivestar, i saw an option called rate own content.
Now i am confused weather as to option was already there or was added in global permission by your applied patch.
Also, can we disable current user voting on himself.
To be specific, i have enabled user voting on users ( so instead of voting on another content, user votes on another user)
Now i want to disable current user voting on himself....any suggestions to as to how can i achieve this.
Thanks
Comment #89
G2 CreditAttribution: G2 commentedHi,
You should find the checkbox in Configuration > Content Authoring > Fivestar if you applied the patch correctly. It's a patch against multiple files so make sure to use 'patch -p1 fivestar-disallow-rate-own-content-189527-86.patch' to make every necessary changes. Don't forget to flush caches, just to be sure.
Also, check if there exists any other copy of fivestar module in each possible location, there might be an other somewhere if the checkbox is still not there.
If you see a 'rate own content' permission, that is not caused by this patch, but some other one, that's the only possibility I can think of. Though I think it's a good idea to implement it this way.
If you disable users voting on their own content using my patch, users won't be able to vote on themselves as well.
Comment #90
Energyblazar CreditAttribution: Energyblazar commentedYep guregori, found the checkbox, had to delete and reinstall the fivestar module.
You were right the rate own content was due to different patch. Here is link [ http://drupal.org/node/1549218 ]
I have 2 different installations of drupal where i am testing your patch...and in both i am facing 2 different difficulties
In first one which is a very fresh installation, i can't untick the checkbox "Allow author to rate own content". If i untick and save it again it returns back as ticked checkbox.
In second installation it gets unticked but still the user can vote on himself. I forgot to mention i am using this user reference patch http://drupal.org/node/1300766 . This patch enables me to cast vote on any user, from the list of users, in the user reference field.
Comment #91
G2 CreditAttribution: G2 commentedTry to flush caches and refresh the page if you can't untick the checkbox. To be honest I can't see what might cause the problem there.
As for the other thing, I think you'd need the 'disallow user voting on himself' feature implemented in that patch you're using. Did you try adding a fivestar field to the user object instead of using a patch? You can do that in Configuration -> People -> Account settings -> Manage fields.
Sorry for the late answer, hope I could help.
Comment #92
Energyblazar CreditAttribution: Energyblazar commentedHello guregori...
I did try to flush caches and refresh pages but still no use. What i shall do is email u admin id and password if you mail me your email at energyblazar@gmail.com.
Also for other thing i think i owe you a further indepth explanation.
In my site i have 2 entites, (1) USERS (2) GROUPS.
->USERS join/create GROUP/S (multiple groups).
->USERS can caste VOTE.
->VOTES can be caste'd only on GROUP MEMBERS.
My Solution using modules Fivestar + User Reference + Few Patches (which includes your patch)
Added Fivestar field in User Profiles (Parent), and one more in User Group comment form (Targets parent feild via user reference fivestar patch).
Thus, Before saving a comment in the particular group, user selects rating (out of 5 stars) and also selects user to be rated via user reference field.
Now i dont want user selecting himself and rating himself.
And many many thanks for your helping hand in the confusing puzzle of drupal Land. :D
Comment #93
Routh CreditAttribution: Routh commented@guregori :
I'm trying to get your patch applied to the 7.x-2.x-dev branch, however I'm getting a Hunk#1 and Hunk#2 fail on both files:
Not sure what's wrong. Patch is downloaded to the fivestar directory. This patch has worked for others?
Comment #94
Routh CreditAttribution: Routh commented#86: fivestar-disallow-rate-own-content-189527-86.patch queued for re-testing.
Comment #95
tmctighe CreditAttribution: tmctighe commentedI had the same issue, created a patch that adds a per-field choice as opposed to a global setting (patch from #86 would need to remove the created variable on hook_uninstall to meet drupal standards, this shouldn't).
This patch worked for me (7.x-2.x).
Comment #97
tmctighe CreditAttribution: tmctighe commentedFixing patch from #95 (notices).
Comment #98
tmctighe CreditAttribution: tmctighe commentedforgot status change...
Comment #99
drupov CreditAttribution: drupov commentedYeah,
patch from #97 works fine!
Great, thanks!
Comment #100
matt.rad CreditAttribution: matt.rad commented+1
Comment #101
whiteph CreditAttribution: whiteph commentedI applied the patch in #97 in my test system. It works fine for the case where votes are made directly on nodes. It fails when votes can be made on comments attached to a target node. fivestar_field_formatter_view(), which is where the disabling logic is in patch #97, isn't called for fivestars within comments. A possibility is to unset the fivestar form within the comment form, so the user can't see the widget if it's his/her own. That's going to need a fair bit of messing around in something like fivestar_form_comment_form_alter(), plus digging out the "can vote" field meta data which contains the yes/no value for whether owner is allowed to vote or not.
Another challenge is that even though the default is "no, owners can't vote on their own nodes", we'd have to create an update method to set all of the existing fivestar metadata to be set to "yes", otherwise 20,000+ D7 sites in the wild would suddenly find that voting behaviour has changed and they have to do something pronto as we've introduced the new constraint.
Finally, we'd have to test with all of the various other voting targets like users and entity references.
All of which means that this is a chunky piece of work. Anybody up for doing some of this?
Comment #102
whiteph CreditAttribution: whiteph commentedComment #103
whiteph CreditAttribution: whiteph commentedThinking a bit more about my last comment, the need to include comment-based voting may be an example of "the perfect is the enemy of the good". That is, adding the feature for fivestar widgets which get voted on directly is a perfectly good addition to the module.
Having just fixed Don't let user to change his vote or re-vote, where I created a simple update function, creating a similar function for this issue will be trivial.
So, next time I get some time I'm going to do this.
Comment #104
whiteph CreditAttribution: whiteph commentedDon't let user to change his vote or re-vote created an instance-based property to control re-voting. To keep in sympathy with that, I've re-worked the patch for this feature to be instance-based too.
I've also created an update hook, which sets the allow_ownvote property to TRUE for all existing Fivestar widgets, so existing websites using Fivestar get no surprises. Be sure to run the update after installing the latest 7.x-2.x-dev version.
If anybody wants protection for comment-based votes, please open a new feature request.
Comment #106
msypes CreditAttribution: msypes commentedNot sure why this was closed, as it still doesn't work, at least not entirely.
While whatever was done to prevent users from voting on their own nodes on the actual node view page, users can still vote on their nodes in a view.
Comment #107
neopoet CreditAttribution: neopoet commented[deleted - this should be "needs review"]
Comment #108
neopoet CreditAttribution: neopoet commentedchanging status to "needs review"
Comment #109
Mile23I would suggest filing a new issue dealing with views, especially if you have a patch to fix it.
Comment #110
TR CreditAttribution: TR commentedThis issue was improperly reopened in #106. As stated in #109, if you have found a problem with this feature open a new issue.
Also, "Needs review" is not the appropriate status - there is nothing (no patch) to review here ...
Comment #111
TR CreditAttribution: TR commented