DokuWiki Installer


This page assists in the first time installation and configuration of Dokuwiki. More info on this installer is available on it's own documentation page.

DokuWiki uses ordinary files for the storage of wiki pages and other information associated with those pages (e.g. images, search indexes, old revisions, etc). In order to operate successfully DokuWiki must have write access to the directories that hold those files. This installer is not capable of setting up directory permissions. That normally needs to be done directly on a command shell or if you are using hosting, through FTP or your hosting control panel (e.g. cPanel).

This installer will setup your DokuWiki configuration for ACL, which in turn allows administrator login and access to DokuWiki's admin menu for installing plugins, managing users, managing access to wiki pages and alteration of configuration settings. It isn't required for DokuWiki to operate, however it will make Dokuwiki easier to administer.

Experienced users or users with special setup requirements should use these links for details concerning installation instructions and configuration settings.

For security reasons this script will only work with a new and unmodified Dokuwiki installation. You should either re-extract the files from the downloaded package or consult the complete Dokuwiki installation instructions

driven by DokuWiki powered by PHP
Issue Voting Requirements [Mantis Bug Tracker Wiki]

User Tools

Site Tools


Issue Voting Requirements

Author: Victor Boctor


The idea of voting is to allow users to vote on the issues that matter most to them. Given that most of the time it is good to have all features implemented and bugs fixed, users should do some choice when deciding to vote for the more important issues. Users should also be able to vote against feature requests that they believe will be of harm to the product.

Database Schema Changes

  • mantis_bug_table (DONE)
    • votes_positive as integer.
    • votes_negative as integer.
  • mantis_bug_votes_table (DONE)
    • issue_id
    • user_id
    • weight (can be positive or negative, typically -1 or +1), can't be 0.

Configuration Changes

  • voting_enabled (boolean, default true) - enable or disable the whole voting feature. (DONE)
  • voting_place_vote_threshold (default REPORTER) - access level required for users to vote on issues. (DONE)
  • voting_view_user_votes_threshold (default DEVELOPER) - access level required for users to view the users who voted and their votes. (DONE)

Votes Columns

  • It should be possible to expose the positive, negative or overall votes as a column in export csv, Excel, View Issues, etc. Overall votes are positive votes minus negative votes. (DONE)

View Issue Page

  • The view issues page should allow users to vote positively or negatively. Also if users have already voted before and the issue is not resolved, then they can remove their vote. (DONE)
  • Display the total number of positive / negative votes (kind of thumbs-up / thumbs-down counters) (DONE)
  • The list of users who voted positively or negatively are listed in the same way users monitoring the issue are listed. (DONE)

The Act of Voting

  • Ensure that users can vote (i.e. have the required access level). (DONE)
  • If users have voted before for this issue, and their new vote is different then remove their current vote. (DONE)
  • Add a record in the votes table. (DONE)
  • Update overall counters on the issue. (DONE)
  • DO NOT Update issue last updated timestamp. If necessary we can make this behavior configurable. (DONE)
  • Update Issue History (DONE)

Implementation Details

  • Deleting an issue must delete all associated votes. (DONE)
  • Deleting a user must delete all associated votes, no update for last_update of the issues. (DONE)
  • Implement core/vote_api.php
    • vote_add( $p_issue_id, $p_weight, $p_user_id = null ) (DONE)
    • vote_delete_issue_votes( $p_issue_id ); (DONE)
    • vote_delete_user_votes( $p_user_id ); (DONE)
    • vote_get_issue_votes( $p_issue_id ) - returns an array of user ids, weight. (DONE)
    • vote_is_enabled( $p_project_id = ALL_PROJECTS ) (DONE)
    • vote_can_vote( $p_issue_id, $p_user_id = null ) (DONE)
    • vote_can_view_vote_details( $p_issue_id, $p_user_id = null ) (DONE)
  • Deleting an issue should delete all associated votes. (DUPE)
  • Deleting a user should delete all associated votes. (DUPE)

View Issues, CSV, Print Issues

Add support to the View Issues, CSV export and Print Issues page to be able to include the following columns: (DONE)

  • votes_balance
  • votes_positive
  • votes_negative


  • Users should be able to filter on issues they have voted on (similar to issues that have monitored). (DONE)

Email Notifications

  • Similar to the way email notifications can be customized for issue notes authors, it should be possible to configure email notifications for voters.

Future Ideas

  • Ability to vote on issue notes - This may mean that we should have a generic mantis_votes_table and include a type and id, rather than having a mantis_bug_votes_table and just having an id.
  • Limit the amount of votes users have
    • Users regularly get granted credits to use for voting.
    • Users get granted credits to use for voting based on certain actions (e.g. submitting an issue, adding a note, etc).
  • Users buy credits to vote.
  • Users get assigned credits manually by users above certain level.
  • Users above a certain access level bypass limits (default DEVELOPER)


Please place any feedback here.

2007-07-31 ave : I would like to vote without changing weight sometimes just to show that 'I have reviewed the issue'. How about adding an configuration option for voting with weight=0?
2007-09-02 vboctor: Should we just have one field in the bug table to carry the overall vote balance?
2007-10-31 CADbloke: You're gunna hate me. A lot. I'd like a voting range, say from -5 to 0 to 5 (I agree with ave about 0 votes and I think negative votes are important), indicating how important the user thinks this issue is (say from DILLIGAF to OMFG-no/yes). I'd then like to be able to see, in the individual bug report, a vote summary with the total number of votes, subtotals of each vote-level (a bar graph would be lovely but possibly superfluous) and the average, to gauge the range of importance of the issue. That way I could prioritise bugs / feature requests and perhaps adjust the targeted release version, or at least see what is giving my users the ….

I'd like to see both the average and the number of votes as columns in the bug lists too. If the vote average is to be displayed in lists of bugs then the average (and the number of votes, and perhaps the subtotal for vote-level .. oh, I can feel a cron job coming on) should be recalculated and stored when a new vote is made to save a massive calculation efforts every time you generate a list of bugs. I think this reporting should be enabled only for the developers, admins etc - there is probably too much calculating and SQL action going on the have this running for everyone.

This level of fancy reporting could (should ?) be done by exporting as a CSV or Excel so the end user (me) could do whatever with the data. If it is unrealistic and over-complicated (as I tend to be, so my Wife tells me) to expect this level of reporting to be implemented in the core - just the export function would be nice, even if it just exports all open issues and their votes. In this case, just a table with Issue# and vote_value would suffice. A user could export this table to do statistical analysis on.

I hope I haven't ruined a perfectly simple idea for everyone. Victor, I'll understand if you delete this before it gets out! ;)

2008-02-20 CADbloke: - Reading that back is giving me a headache. I think my predilection for over complication got the better of me there. I'd be happy with 1-vote means I want it, no votes means indifference - just like any democracy.

2008-03-01 Cornchips - I'm working on this feature now, and will work towards getting a version running that includes everything on this page except the future ideas. I'm about 40% of the way through making this feature, and will pickup the work again next weekend.

2008-03-15 Cornchips - Getting close to feature complete, Havn't looked at the filter or email notifications yet - but should get to them tomorrow. Most code is documented according to mantis standards however I will go back through the code and review this.

2008-03-16 Cornchips - Got really bogged down in the filter api today going around in circles trying to find why the filter selection is being stripped out. Have posted to dev mailing list for assistance.

2008-03-30 Cornchips - Life has been keeping me busy but managed to debug and complete the filtering system. view_all_set.php had been tripping me up before. Currently aiming to submit my patch for this feature on or before april 6th.

2008-04-06 Cornchips - I've just added my patch for svn r5156 (available at ). However i still need to cleanup the code to match the mantis coding guidelines. All basic features are complete, and there is also a credit system based on user access level. I would also still like to add a 'my votes' view similar to the my sponsors view, as well as a brainstorming view like the facebook/uservoice/ubuntu examples mentioned above. So, consider this an 'alpha' version if you like. I should have further time this week to complete the features mentioned above.

mantisbt/issue_voting_requirements.txt · Last modified: 2011/11/16 07:39 by atrol