Edgewall Software
Modify

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#4174 closed enhancement (fixed)

[PATCH] - Enable Ordering on 'datetime' fields within Ticket Query

Reported by: ilias@… Owned by: Christian Boos
Priority: normal Milestone: 0.11
Component: ticket system Version: 0.10.3rc1
Severity: minor Keywords: query datetime production
Cc: Branch:
Release Notes:
API Changes:

Description

It would be nice to have this on t.e.o, as this enables ticket queries like this, which keeps the last modified tickets on top.

this is a subset of #3990

context: http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacro

Attachments (1)

TicketQueryEnableDatetimeOrdering.diff (985 bytes ) - added by ilias@… 13 years ago.

Download all attachments as: .zip

Change History (25)

comment:1 by ilias@…, 13 years ago

I've just noticed that t.e.o uses the 0.10.3dev, thus possibly this could be additionally backported to the 0.10.

http://trac.edgewall.org/about

comment:2 by ilias@…, 13 years ago

It becomes very difficult to track the tickets I've reported here on this instance, simply because i am not able to apply the very basic ordering based on the "latest changed".

This is quite bad publicity for trac.

I cannot workaround this, as I'm not able to create an report here on this trac-instance, e.g. like this one:

reporter=$Reporter, group=Component, order by changetime descending

so, possibly you can just apply this patch or create an report, thus the latest changed tickets of a $Reporter appear on top?

comment:3 by ilias@…, 13 years ago

Owner: Matthew Good removed

This is a complement to the #4158 patch, which was applied to trunk.

comment:4 by Christian Boos, 13 years ago

Keywords: query added
Milestone: 0.11
Owner: set to Christian Boos

I think it's OK for trunk. Have you tested that the patch is also OK for 0.10-stable?

in reply to:  4 comment:5 by ilias@…, 13 years ago

Replying to cboos:

I think it's OK for trunk. Have you tested that the patch is also OK for 0.10-stable?

no (i'm completely on 0.11dev).

but the code looks identical:

source:branches/0.10-stable/trac/ticket/query.py#L97

comment:6 by Christian Boos, 13 years ago

Resolution: fixed
Status: newclosed

Implemented in r4349.

I also made created an alias for time and modified an alias for changetime, as the latter are not that intuitive for use in TicketQuery macros.

in reply to:  6 ; comment:7 by anonymous, 13 years ago

Keywords: datetime added
Resolution: fixed
Status: closedreopened

Replying to cboos:

Implemented in r4349.

I also made created an alias for time and modified an alias for changetime, as the latter are not that intuitive for use in TicketQuery macros.

ok, very nice!

I guess we have here the situation mentioned by a user in this message, that a ticket affects multiple milestones/releases.

trunk was fixed, but the ticket is still open, as the t.e.o relevant version is still unfixed (thus this example query is still not ordered by changetime.

Thus reopening should be ok in this case, until r4349 gets into 0.10-stable (or t.e.o is moved to 0.11dev).

in reply to:  7 comment:8 by ilias@…, 13 years ago

Replying to anonymous: that was me.

in reply to:  7 ; comment:9 by anonymous, 13 years ago

Type: defectenhancement

Replying to Ilias:

… Thus reopening should be ok in this case, until r4349 gets into 0.10-stable (or t.e.o is moved to 0.11dev).

Well, in our workflow, it's not strictly necessary to keep tickets open for them to be ported to stable: we use the svnmerge avail command, to check what are the revisions left to be merged to stable.

If the merge is worth doing and unproblematic (hence my question above), then the changeset is ported, and the correspond ticket's milestone is updated. Otherwise, the changeset is blocked and the milestone stays as it is.

That ticket is after all an enhancement request, as this is not about fixing something that was advertised to work, but rather adding a capability not previously present.

in reply to:  9 ; comment:10 by ilias@…, 13 years ago

Replying to anonymous:

Replying to Ilias:

… Thus reopening should be ok in this case, until r4349 gets into 0.10-stable (or t.e.o is moved to 0.11dev).

I understand the elaborations on workflow, but this ticket subjects really the t.e.o instance (possibly the component should have been 'project', or better the version 'production', see #4256), an thus it is still open (from a user/reporters point of view).

That ticket is after all an enhancement request, as this is not about fixing something that was advertised to work, but rather adding a capability not previously present.

Isn't some functionality self-advertised?

Can't "ability to oder ticket-query results by the 'latest changed'" be seen as an basic requirement to an issue-tracking-system?

What can I do at this point to make the patch go into 0.10-stable (don't know the workflow)?

in reply to:  10 ; comment:11 by Christian Boos, 13 years ago

Milestone: 0.110.10.3
Resolution: fixed
Status: reopenedclosed

Replying to ilias@lazaridis.com:

… Can't "ability to oder ticket-query results by the 'latest changed'" be seen as an basic requirement to an issue-tracking-system?

Well, half of the enhancement tickets here would probably fall into this category…

I think there's a pretty good rule of thumb that we could follow (could go to TracTicketTriage if others agree):

  • defect: some implemented functionality doesn't work as expected and lead to an error condition or wrong result
  • enhancement: request to implement some additional functionality that is considered to be missing so far

If any missing functionality would be considered as being a defect, there would be no point in having a distinction between defect/enhancement ;) That the missing functionality is of critical importance or not doesn't really matter (and there's the severity field for qualifying that, after all!), as this always depends on your usage pattern. For example, the multi-project aspect won't interest people using Trac for a single project, the query facilities won't interest people not using Trac for their issue tracking system, etc.

What can I do at this point to make the patch go into 0.10-stable

I did it for r4349. That change didn't apply cleanly plus it required an extra change. Agreed, those are small things, but even those small things take time. So in the future, if you'd like a particular changeset to be ported to 0.10-stable, please consider updating the patch and testing it (e.g. in this case preparing a r4349-for-0.10-stable.diff patch).

Implemented for 0.10-stable in r4352.

in reply to:  11 comment:12 by ilias@…, 13 years ago

Replying to cboos: …

I agree to most of your writings.

have placed a link to your comment, thus the document can be updated.

What can I do at this point to make the patch go into 0.10-stable

I did it for r4349. That change didn't apply cleanly plus it required an extra change. Agreed, those are small things, but even those small things take time. So in the future, if you'd like a particular changeset to be ported to 0.10-stable, please consider updating the patch and testing it (e.g. in this case preparing a r4349-for-0.10-stable.diff patch).

Ok (although I've no experience with 0.10).

Implemented for 0.10-stable in r4352.

Thank's a lot.

comment:13 by ilias@…, 13 years ago

Resolution: fixed
Status: closedreopened

reopened, functionality not active on production server (t.e.o).

Please close ticket after t.e.o is updated (I cannot verify this, as the revision-number is not visible, #4126)

(sidenote: within #4296, a predefined report was provided)

comment:14 by Christian Boos, 13 years ago

Resolution: fixed
Status: reopenedclosed

Ilias, you should know by now that this is not how we proceed.

A ticket is set to fixed for a given milestone after the commit is done on the corresponding branch, period.

The version that t.e.o uses is irrelevant (as we could as well decide to switch to 0.11dev at some point in the future).

Please don't reopen tickets without a good reason in the future, consider the 5-10 minutes we loose each time you do that.

in reply to:  14 comment:15 by ilias@…, 13 years ago

Component: report systemproject
Keywords: production added
Resolution: fixed
Status: closedreopened
Version: develnone

Replying to cboos:

Ilias, you should know by now that this is not how we proceed.

No, I know that you permanently insist on defective processes, which you correct by time e.g. within the documents (TracTicketTriage), without even accepting that my insistence is the reason for the corrections.

A ticket is set to fixed for a given milestone after the commit is done on the corresponding branch, period.

You can continue to write in this "dictator-tone", whilst insisting on your defective processes, which raise mainly out of the missusage of milestones (#4236).

I will simply ignore it.

The version that t.e.o uses is irrelevant (as we could as well decide to switch to 0.11dev at some point in the future).

My ticket targets the _live_ version (usually called 'production').

You can refuse to provide this as version field (see #4256), but of course I will not allow you to bring my filed tickets 'out of reality'.

Please don't reopen tickets without a good reason in the future, consider the 5-10 minutes we loose each time you do that.

Please don't close tickets in a way not reflecting reality, and take the intentions of the reporter in account. (you should possibly move this part to the TracTicketTriage).

It should be clear that you are wasting _my_ time whilst closing the tickets in a way that it does not reflect _reality_.

This ticket subjects _functionality_ of the project (Component = project), the affected version is that one _active_ on the production server (Version = none, as and dedicated version is unavailable, keyword = production).

I've changed the ticket information in order to become more concise.

Finally, I like to say that I am very disapointed by this selective behaviour, seeing that it needs others to report similar issues (#4296) in order that the team becomes immediately active (3 hours) to provide an solution which is not thus flexible (based on reports).

comment:16 by anonymous, 13 years ago

Resolution: fixed
Status: reopenedclosed

Responding to your comment 14, your time isn't the one we are interested in making sure isn't wasted, Ilias. A core developer closed this ticket (twice!). As per TracTicketTriage core developers have the final say on closing tickets. (See, I can refer to documents I wrote also!)

in reply to:  16 comment:17 by ilias@…, 13 years ago

Resolution: fixed
Status: closedreopened

Replying to anonymous:

Responding to your comment 14, your time isn't the one we are interested in making sure isn't wasted, Ilias. A core developer closed this ticket (twice!). As per TracTicketTriage core developers have the final say on closing tickets. (See, I can refer to documents I wrote also!)

Please get serious, Mr. Anonymous.

comment:18 by anonymous, 13 years ago

Resolution: fixed
Status: reopenedclosed

I am quite. Marking closed as per TracTicketTriage (again!).

in reply to:  18 comment:19 by ilias@…, 13 years ago

Replying to anonymous:

I am quite. Marking closed as per TracTicketTriage (again!).

Yes, Sir!!! Mr. Anonymous!!! Sir!!!

http://trac.edgewall.org/wiki/TracTicketTriage?version=34#DevelopmentNotes

comment:20 by ilias@…, 13 years ago

Resolution: fixed
Status: closedreopened
Version: none0.10.3rc1

0.10.3rc1 was activated on t.e.o, thus i've checked this, but it leads to an error:

""ProgrammingError: invalid input syntax for integer: ""

verfication: use this query

comment:21 by Christian Boos, 13 years ago

Most likely an issue with dates being fed as floats.

comment:22 by Christian Boos, 13 years ago

Component: projectticket system
Milestone: 0.10.30.11
Resolution: fixed
Severity: normalminor
Status: reopenedclosed

The problem identified in comment:20 was fixed in trunk in r4426.

Reverted r4352 the change on 0.10-stable in r4427. It was not a good idea to backport that "seemingly innocuous" change. The stable branch should only get major bug fixes, not "nice to have enhancements".

The Enable Ordering on 'datetime' fields within Ticket Query feature discussed in this ticket is now only implemented on trunk.

It would be nice to have this on t.e.o

wontfix for that. Wait for 0.11 dev being used on t.e.o, but that's not the main point of this ticket, only a it would be nice to have (quoting).

in reply to:  22 ; comment:23 by ilias@…, 13 years ago

Replying to cboos:

The problem identified in comment:20 was fixed in trunk in r4426.

ok (btw: I had no problems with 0.11dev on my side)

Reverted r4352 the change on 0.10-stable in r4427. It was not a good idea to backport that "seemingly innocuous" change. The stable branch should only get major bug fixes, not "nice to have enhancements".

This policy sounds rational.

The Enable Ordering on 'datetime' fields within Ticket Query feature discussed in this ticket is now only implemented on trunk.

ok

It would be nice to have this on t.e.o

wontfix for that. Wait for 0.11 dev being used on t.e.o, but that's not the main point of this ticket, only a it would be nice to have (quoting).

ok (related: #4315)

in reply to:  23 comment:24 by Christian Boos, 13 years ago

Replying to ilias@lazaridis.com:

Replying to cboos:

The problem identified in comment:20 was fixed in trunk in r4426.

ok (btw: I had no problems with 0.11dev on my side)

The problem was only apparent with PostgreSQL (and probably MySQL as well).

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 as closed 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.