Flyspray

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Feature Request
  • Category User Interface
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version 0.9.9.1
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 4
  • Private
Attached to Project: Flyspray
Opened by NickHBO - 09.04.2007

FS#1236 - Mark Issue As Verified or Unverifiable

Currently, the Vote functionality provides users a way to say "this issue is important to me". In addition to that functionality, it would be great for users to have a "Verify" ability on open issues; it would provide users a way to say "yes, this happens to me as well".

A "Verified" label would fit nicely right under "Votes", to the right of the label would be "Yes | No", each option being a link. After clicking Yes or No, or if unable to specify (lack of permissions), the text would display "Yes - # | No - # (% verification)" where '%' is the result of ((Yes/(Yes+No))*100).

This feature should not show up on all issues, though. It does not make sense to "verify" a feature request or todo item, for example. When defining task types, the administrator would specify if a type was "Verifiable" by checking a box in a column next to "Show".

If implemented, two great, mini extra features would be:

  1. The ability for the administrator to set the number of "Yes" verifications an issue would need before it was elevated to the next priority, severity, or both (specified by the administrator).
  2. The ability for the administrator to set the number of "No" verifications an issue would need before it was lowered to the previous priority, severity, or both (specified by the administrator).

Both settings should have an option to be incremental (priority / status increased every x verifications) or not (increases once, no matter how many verifications are received); an "Incremental" checkbox would do nicely. Also, a little "Enabled" checkbox next to both settings would be clearer than having zero act as the disable mechanism.

As with voting, a permission should exist to enable or disable this option for a user group. For larger projects, moderators tasked with verifying bugs could be given the permission whereas smaller projects may leave verifications up to the community.

Lastly, a way to send a notification once the number of "Yes" verifications reached a certain value would also be a great addition.

Project Manager
peterdd commented on 11.03.2015 21:56

Personal opinion: Mmh, lets do an example:

  • There is a bug report one user made. He voted for it too.
  • Another user has the same problem, sees this task and voted for it. Maybe he leaves an additional comment too.
  • A third user browses the task, look into this bug report, but hasn't this issue. He has following options:
    • He just go away because he is not effected (99% maybe?), no vote, no comment.
    • He add a comment that he is not affected be this issue. Value of this information: low.

I think a vote for the issue nearly tell the same information as a "verified vote". "Unverifiable vote" doesn't help much. Only if one of the developers made extensive testings. But they can change the task status and add a comment.

What I find better is to make a task also down votable (+1/-1) like you maybe know from other sites as stackoverflow.com.

Project Manager
peterdd commented on 01.10.2015 15:23

Maybe possible easy implementation:
A new (int) field 'task_verified' in the comment table:
* default 0
* 1 for verified
* -1 for unverified

On every task a user can max only set 1 or -1 one times in a comment.
This must be checked with every try to make or update a comment.
(I currently do not see how the unique feature in sql can be used here)

If the user just set verified or unverified but insert no text or attachment, the comment is not shown as normal.

  • needs a simple verify-chooser in the add comment form (3 html radio buttons in the form, but voter ui could even be more appealing/compact..
  • Additional quick verified/unverfied buttons possible on task details view/edit

Pro:

  • relative easy to implement, only on added field
  • also automatic info about who and when a task verification comment is made.
  • the join on the comment table is done for comments yet, so no extra table join

Con:

  • a complete comment entry if only just a verify voting. They shouldn't be counted when comment count should be shown somewhere, e.g. tasklist comment count column.
Project Manager
peterdd commented on 18.07.2016 19:27

a loose compliation of things that should be addressed:

  • What to do if the task type is changed later (e.g. from bug to feature)
  • "multiple verify/unverify" for specified versions too?
  • version ranges like "bug verfied for all version between 3.4 and 6.5"? →min + max tablefields for ranges?
  • os version or incompatibility with specific 3rd party libraries

As you can see, this can get more complex quick.

But also this could be a backchannel for automated tests that "vote" automatic for succeeded/failed tests under different test environments? (API)

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing