I am running an election in which we do not want the members to see the running results of the vote. However, there is an Election Committee (role) who needs to be able to see the results whenever they want.

What this patch does:

  • Adds a column to the table to save the "view results" setting for each poll.
  • Adds a permission to "view results".
  • Adds to the content type form "Display results" options to allow "By view results permission". [I didn't enclose the permission name in quotes because I didn't know if the "t" function could handle it.]
  • Adds to the poll's settings form "Display results" options to allow "By view results permission".
  • Modifies the checking in _advpoll_can_view_results.

Note that the "view results" permission is only used if the poll (or the default) is set to "By view results permission". Also, update.php must be run after applying this patch.

Feel free to remove my comments. Also, I accidentally left my need for a 3 week duration in the patch, feel free to remove that as well.

I think this is a nice feature to have and it works for me. It was actually much easier than I anticipated and works on a per-poll basis, which I was originally afraid wouldn't be easy.

CommentFileSizeAuthor
advpoll_viewresults.txt7.29 KBnancydru

Comments

anders.fajerson’s picture

anders.fajerson commented
Title: Add ability to control viewing of results » Add ability to restrict view results to permission

Thanks for the patch! Much appreciated.

I can't really test this as it doesn't apply (tip: always make patches against the latest revision, preferably a cvs checkout).

Could you give an usercase why this have to be on a per poll basis? My suggestion for implementing this would either be to merge it to the "inspect all votes" feature by simply adding a result summary (probably the usual result display) to that page. Or by adding a "always view results" permission. Users with that permission would always be able to access the results tab (which now is used when "always show result" is set) regardless of view result settings.

Could you give me some examples when those implementations wouldn't suffice?

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented
Status: Active » Needs work

IMO, I don't think the title change is accurate - what I had before was better.

In my current case, I am running an election, which has a set of rules that are not appropriate for an opinion poll (which I had to stop when I first set up the election). For the election, we don't want the general users to be able to see the results (but the election committee can), while we want opinion poll results visible. And we want both at the same time. I simply don't want to have to switch the defaults and stop every poll every time we have a vote that is different than the current ones.

I applied this against a version that I downloaded a day or two ago, I think.

anders.fajerson’s picture

anders.fajerson commented

Let's not argue about the title here, feel free to improve it ( I changed "Add ability to control viewing of results" as that's already possible and fails to explain what would be added with this patch").

I fail to understand your example, sorry. Maybe Chris have better luck.

Changed line endings and it applied.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

Is there something in the way I'm using diff that messed up the line endings? I do "diff -u old_mod new_mod > patch.file"

anders.fajerson’s picture

anders.fajerson commented
Title: Add ability to restrict view results to permission » More settings to control viewing of results

It's a common windows problem: http://drupal.org/node/75806

I think I understand you example know, I was too focused on the permission thing. You basically need this:
1. A role who can always see results
2. Some binary polls that users can see results on, and some binary polls that users can't see result on.

Both these should be possible to achieve by overriding theme_advpoll_results() in a custom theme and using taxonomy or something else to separate polls of the same content type (for #2).

As explained before we have a real problem with settings bloat, so I rather see these special cases be dealt with without needing to resort to more settings. Suggestions welcomed.

Oh, one more thing. *I've never tried this*, but it should be possible to duplicate a mode (.inc file in the modes folder), replace all instances of binary with e.g. binary2 and then have a new content type (e.g. advpoll_binary2) that can have it's own defaults and result view settings. And yes, it would have been nice if it was possible to create poll content types within the admin interface...

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

As I've tried to explain to others, I currently have 16 sites, with more coming. I simply cannot afford to produce and maintain 16 modified themes, even if I knew how. I have trouble understanding the idea of making theme changes for stuff that should be in the code. But you're not the first to do this.

Compared to many modules, you have few settings. And all I really did here was reflect settings that were already on the content type form to the poll form.

It's funny that I see all these posts from your users wanting things on a per poll basis and when one is given to you, you don't want it. Oh well, my version is going into production.

ChrisKennedy’s picture

ChrisKennedy commented

Overriding "theme" function is a powerful and important part of Drupal to understand, and you have to maintain "16 modified themes". Anywhere that you see theme("blah", $args...) you can create a custom version of that function in the theme for that site - so you could edit themes/garland/template.php (or include a separate file and edit that) and make phptemplate_blah($args) and change how it works. See http://drupal.org/node/55126

As you say, lots of individuals request per-poll settings. Our job as maintainers is to consider the 99% of people who don't care about that very specific setting, as well as numerous users who have made it clear that the number of settings is confusing and hurts usability (which is a valid argument). Just because a feature is requested, or even coded, doesn't mean it's necessarily worthwhile to include in the official module, or that the particular implementation is optimal. We only integrate features that have compelling use-cases, don't overly complicate the module, and work with the long-term roadmap. These are judgment calls that can be influenced by persuasion and can change over time.

Also, for diffs please include the "p" option as well, so that we can see which function the code is changing. See http://drupal.org/patch/create (there's some line-ending discussion there too).

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented
Status: Needs work » Closed (fixed)
anders.fajerson’s picture

anders.fajerson commented
Status: Closed (fixed) » Closed (won't fix)

Good summary Chris, nice to have in the issue queue for future reference.