Edgewall Software
Modify

Opened 14 years ago

Closed 14 years ago

#3771 closed defect (fixed)

Custom query - radio button shows wrong selection even though results are correct

Reported by: sid@… Owned by: Christian Boos
Priority: low Milestone: 0.11
Component: report system Version: 0.9.6
Severity: minor Keywords: query patch
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

I have a custom ticket field called "crb_approved", and I created this custom query with a link from another page:

[query:status=closed&crb_approved=0&order=id Unapproved closed tickets]

When I view the report, the results are correct, but the crb_approved radio button displayed on the Custom Query page shows up with "True" (should be "False") for the crb_approved field based on the query.

Attachments (0)

Change History (6)

comment:1 by sid, 14 years ago

The reason I noticed this is when I close some of those tickets in the custom query, then hit update, the incorrect value for the checkbox is used, and the wrong results come back. Quite confusing.

comment:2 by sid, 14 years ago

Keywords: query added
Severity: trivialminor

The workaround is to use this query instead:

[query:status=closed&crb_approved=!1&order=id Unapproved closed tickets]

It chooses the correct radio button, and pressing Update on the query afterwards displays the correct results.

comment:3 by sid, 14 years ago

I can duplicate this easily on 0.11.

  1. Add a checkbox custom field to trac.ini.
    approved = checkbox
    approved.label = Approved by me
    approved.value = 0
    
  2. Create a few sample tickets, checking the checkbox in some, and not in others
  3. Run a custom query using that custom field as a filter
  4. Try to choose "No" for that custom field, then press "Update".

The "Yes" radio button will show every time. The results are correct though, but if you hit update again without paying attention, the results are dramatically different.

comment:4 by sid, 14 years ago

Keywords: patch added
Milestone: 0.10.40.11

Turns out to be a pretty easy fix:

  • templates/query.html

     
    8585
    8686                        <py:when test="'checkbox'">
    8787                          <input type="radio" id="${field_name}_on" name="$field_name" value="1"
    88                                  checked="${constraint.mode != '!' or None}" />
     88                                 checked="${constraint.mode != '!' or constraint_value == '1' or None}" />
    8989                          <label for="${field_name}_on">yes</label>
    9090                          <input type="radio" id="${field_name}_off" name="$field_name" value="0"
    91                                  checked="${constraint.mode == '!' or None}" />
     91                                 checked="${constraint.mode == '!' or constraint_value == '0' or None}" />
    9292                          <label for="${field_name}_off">no</label>
    9393                        </py:when>

I tested this and it fixes the example in comment:3, and also my originally reported issue as well.

comment:5 by Christian Boos, 14 years ago

Owner: changed from daniel to Christian Boos
Status: newassigned

OK, I'll try to commit that this evening.

comment:6 by Christian Boos, 14 years ago

Resolution: fixed
Status: assignedclosed

Applied in r4462. Also fixed the initial value for the _off radio button when added by Javascript by using "0" instead of "!1". Besides being clearer, this is also not the same: "!1" also matched the tickets for which the field was unset.

There's still a very minor issue when the field is not added by Javascript. As this is very minor and will probably be fixed when the fields are reworked (WorkFlow branch), I'm closing this as fixed.

Thanks for the patch, sid!

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.