Custom Query filter on Milestone not working

[gctrekker]

When I use a Custom Query and select "Milestone" in the Filters "And"
drop down the word "Milestone" is a selection displayed in the box but
nothing else happens when I select milestone. All other selections in
the drop down work properly. If I edit the URL line in the browser
and add "&milestone=" and have it redisplayed the Filter adds the
Milestone selection to the filter and I can see all of our milestones.

I am using Trac 1.0. It is doing this on both processors that I have
Trac on. One is using python 2.5 and the other is using python
2.6. I just recently noticed this problem.

We have been using Trac for over 4 years and have 60 milestones
defined. Any suggestions on what to look for would be appreciated.
I recently applied the change in http://trac.edgewall.org/ticket/10877
to correct a jquery problem I was having with batch modify on the
python 2.5 processor, but I cannot imagine that causing the
"milestone" to not be added to the filters.

Editting the URL is a work-around but I would like to see it working
again.

[gctrekker]

On Dec 17, 4:47 pm, gctrekker <gctrek...@gmail.com> wrote:
> When I use a Custom Query and select "Milestone" in the Filters "And"
> drop down the word "Milestone" is a selection displayed in the box but
> nothing else happens when I select milestone.  All other selections in
> the drop down work properly.  If I edit the URL line in the browser
> and add "&milestone=" and have it redisplayed the Filter adds the
> Milestone selection to the filter and I can see all of our milestones.
>
> I am using Trac 1.0.  It is doing this on both processors that I have
> Trac on.  One is using python 2.5 and the other is using python
> 2.6.    I just recently noticed this problem.
>
> We have been using Trac for over 4 years and have 60 milestones
> defined.  Any suggestions on what to look for would be appreciated.

> I recently applied the change inhttp://trac.edgewall.org/ticket/10877

> to correct a jquery problem I was having with batch modify on the
> python 2.5 processor, but I cannot imagine that causing the
> "milestone" to not be added to the filters.
>
> Editting the URL is a work-around but I would like to see it working
> again.

I have not received any replies concerning my posting above. Here is
more information about my Milestones.

In our Trac environment, when I go into "Admin / Milestones" the
Manage Milestones list includes an entry with a blank "Name", "Due",
and "Completed" fields. It has this blank named Milestone selected as
the "Default" milestone with 321 "Tickets."

If I select the checkbox for the row of this "blank" milestone and
select "Remove selected items" I get a "Trac Error" screen saying "No
milestone selected."

On another test machines with the same data, I see the same results.
On this machine, I selected a different "Default" milestone to see
what would happen. The "Default" moved to the other milestone when I
selected "Apply changes." I then tried to set the "Default"
milestone back to the milestone with a blank name and selected "Apply
changes" but it does not move back to the milestone with a blank name.

I am using Trac 1.0 and MySQL.
I have been using Trac since May 2008 with 0.11rc1 and updated through
0.11, 0.11.0, 0.11.1, 0.11.2, 0.11.3, 0.11.4, 0.11.5, 0.12.1, 0.12.2,
0.12.3, 1.0


I have three questions:

1. Should the Administration / Manage Milestones include a line with
"Name" field that is blank?

2. What should I do to remove this line if it should not be present?

3. Is this the cause of the problem I first reported?

Thank you.

[gctrekker]

> Thank you.- Hide quoted text -
>
> - Show quoted text -

I solved my problem.

I looked at the MySQL data and did the following:

mysql> use trac;
Database changed

mysql> describe milestone;
+-------------+------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+------------+------+-----+---------+-------+
| name | text | NO | PRI | NULL | |
| due | bigint(20) | YES | | NULL | |
| completed | bigint(20) | YES | | NULL | |
| description | text | YES | | NULL | |
+-------------+------------+------+-----+---------+-------+
4 rows in set (0.00 sec)

mysql> select * from milestone where name="";
+------+------+-----------+-------------+
| name | due | completed | description |
+------+------+-----------+-------------+
| | 0 | 0 | |
+------+------+-----------+-------------+
1 row in set (0.00 sec)

mysql> delete low_priority from milestone where name="";
Query OK, 1 row affected (0.06 sec)

I am not sure how the blank entry got into the milestone table but
removing it worked.
The Custom Query filter is now working with the Milestone field
correctlly.

[RjOllos]

On Friday, December 21, 2012 10:10:11 AM UTC-8, gctrekker wrote:

I am not sure how the blank entry got into the milestone table but 
removing it worked.
The Custom Query filter is now working with the Milestone field
correctlly.

Trac protects against adding a milestone with an empty string as the name (at least in recent version, and I can't imagine this was ever allowed nor did I find any tickets associated with a defect such as this). I tried to reproduced your issue by editing an SQLite db directly. After adding a milestone with an empty string as a name, I initially see "Milestone does not exist" when navigating to /query. I did something different at some point (perhaps clearing "milestone" for the last query?), and now I get the same behavior as you when navigating to the /query page. I select the milestone drop-down, but milestone select list does not appear. There is a not-too-surprising error in the console: Uncaught TypeError: Cannot read property 'value' of null.

As you did, I also get "No milestone selected" when trying to delete this milestone form the /admin/ticket/milestones page. I can see the milestone on the roadmap, but clicking on it just redirects to the /roadmap (not surprising if you look at the code).

Without knowing how that milestone was added into your table, I don't know that there is anything we can do to make Trac more robust. It doesn't seem worthwhile to try to protect against every possible error that could be introduced when the tables are edited directly, and unless you can figure out a way to get that milestone with an empty string as a name into the table /through/ a Trac interface, we'll have to assume it got there by directly editing the table.