Edgewall Software
Modify

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#11798 closed defect (wontfix)

Version appears at "Show tickets" list even if we have no version

Reported by: somenxavier@… Owned by:
Priority: normal Milestone:
Component: report system Version:
Severity: normal Keywords:
Cc: somenxavier@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

Hi,

I remove all the versions. So in the GUI there should not be available version, but in the "Show tickets" there is still appears that…. I think it's not conherence…

Attachments (0)

Change History (9)

comment:1 by Jun Omae, 9 years ago

Keywords: needinfo added

It seems to be a PluginIssue. Trac core doesn't have Show tickets views and links. Please let us know where is Show tickets.

$ git --no-pager grep -i 'show *ticket' mirror/0.12-stable
mirror/0.12-stable:trac/wiki/default-pages/TracTicketsCustomFields:'''Note''' that this will only show tickets that have progress set in them, which is '''not the same as showing all tickets'''. If you created this custom ticket field ''after'' you have already created some tickets, they will not have that field defined, and thus they will never show up on this ticket query. If you go back and modify those tickets, the field will be defined, and they will appear in the query. If that's all you want, you're set.
$ git --no-pager grep -i 'show *ticket' mirror/1.0-stable
mirror/1.0-stable:trac/wiki/default-pages/TracTicketsCustomFields:'''Note''' that this will only show tickets that have progress set in them, which is '''not the same as showing all tickets'''. If you created this custom ticket field ''after'' you have already created some tickets, they will not have that field defined, and thus they will never show up on this ticket query. If you go back and modify those tickets, the field will be defined, and they will appear in the query. If that's all you want, you're set.
$ git --no-pager grep -i 'show *ticket' mirror/trunk
mirror/trunk:trac/wiki/default-pages/TracTicketsCustomFields:'''Note''' that this will only show tickets that have progress set in them, which is '''not the same as showing all tickets'''. If you created this custom ticket field ''after'' you have already created some tickets, they will not have that field defined, and thus they will never show up on this ticket query. If you go back and modify those tickets, the field will be defined, and they will appear in the query. If that's all you want, you're set.

comment:2 by anonymous, 9 years ago

Sorry, I translated wrongly "Mostra els tiquets" to "Show the tickets" (I have catalan translation of trac). The correct is "View Tickets".

In the "View Tickets" section, there is a one column called "Version", even if we remove all versions

comment:3 by anonymous, 9 years ago

The "View Tickets" links to http://trac.edgewall.org/report

comment:4 by Jun Omae, 9 years ago

TracReports allows to use SELECT statement and customize the statements. Initial reports are created by initenv and are using version column in SELECT statements. Even if all versions are deleted, Trac wouldn't modify statements in the reports. But a user manually can modify the reports any time.

comment:5 by Jun Omae, 9 years ago

Component: generalreport system
Keywords: needinfo removed
Resolution: wontfix
Status: newclosed

Closing as wontfix.

comment:6 by somenxavier@…, 9 years ago

What a pitty. I think trac should modify the TracReports if I remove all versions. And if a user would create again the versions, trac should write down back. It's computer mechanism. All what computers could do, people should not do it…

A user modification implies learning SQL statements and such stuff and no ones knows or wants to know another language.

There is a notice in the Version section: "As long as you don't add any items to the list, this field will remain completely hidden from the user interface." It's not true. The TracReports does not respect it. So if you want, remove this notice because it's not completely true.

in reply to:  6 ; comment:7 by Ryan J Ollos, 9 years ago

Replying to somenxavier@…:

What a pitty. I think trac should modify the TracReports if I remove all versions. And if a user would create again the versions, trac should write down back. It's computer mechanism. All what computers could do, people should not do it…

Implementing that feature would be a lot of work. If you were to browse through the issue tracker and look at all the feature we could implement, how high would you rate that on your list? If you rate it highly, I suspect you are an outlier. In the time I have available to dedicate to this project I try to tackle the issues that will have the greatest positive effect on users and administrators. If many administrators complain about this issue then I will reconsider it. However, in my best judgement I can't consider this to be a major issue relative to all the other missing features and defects that exist.

We try to satisfy the requests of users, but we are a relatively small team and we cannot satisfy every request and make Trac behave in an absolutely methodical way. The best way to handle this issue for now will be to document it and suggest manual steps the user can perform when removing all Versions. For that we especially ask for your help since the wiki documentation is freely editable by anyone.

I don't mean to be dismissive of your feature request, I'm just trying to put it in perspective. It feels like there are many more important things we could work on. As always, PatchWelcome.

A user modification implies learning SQL statements and such stuff and no ones knows or wants to know another language.

That's why we have TracQuery. With time the QueryModule will replace more of the ReportModule.

There is a notice in the Version section: "As long as you don't add any items to the list, this field will remain completely hidden from the user interface." It's not true. The TracReports does not respect it. So if you want, remove this notice because it's not completely true. I will state for the record that Trac is and never will be perfect, without defects and will never be feature-complete. We have to prioritize our resources.

Strictly speaking that is true. However for most practical purposes the field is hidden from the user interface. TracReports are just a special case which represent static snapshots.

Last edited 9 years ago by Ryan J Ollos (previous) (diff)

in reply to:  7 comment:8 by somenxavier@…, 9 years ago

Replying to rjollos:

Implementing that feature would be a lot of work. If you were to browse through the issue tracker and look at all the feature we could implement, how high would you rate that on your list? If you rate it highly, I suspect you are an outlier. In the time I have available to dedicate to this project I try to tackle the issues that will have the greatest positive effect on users and administrators. If many administrators complain about this issue then I will reconsider it. However, in my best judgement I can't consider this to be a major issue relative to all the other missing features and defects that exist.

In understand… there is time and person limitation, but strictly it's still a bug.

There is a notice in the Version section: "As long as you don't add any items to the list, this field will remain completely hidden from the user interface." It's not true. The TracReports does not respect it. So if you want, remove this notice because it's not completely true. I will state for the record that Trac is and never will be perfect, without defects and will never be feature-complete. We have to prioritize our resources.

Strictly speaking that is true. However for most practical purposes the field is hidden from the user interface. TracReports are just a special case which represent static snapshots.

So, I think the best option is to modify this notice "As long as you don't add any items to the list, this field will remain completely hidden from the user interface with an exception of Trac Reports". Sure it's easy to patch.

Thanks,

comment:9 by Peter Suter, 9 years ago

I wouldn't consider the reports as part of the user interface, so I don't think the message should be changed. The reports are just user data / content, possibly changed or unchanged from the defaults. If an installation has no one that understands SQL the reports can and should probably be disabled and TracQuery used instead.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) 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.