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

[ilias@…]

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

[ilias@…]

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

[ilias@…]

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?

[ilias@…]

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

[Christian Boos]

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

[ilias@…]

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​

[Christian Boos]

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.

[anonymous]

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).

[ilias@…]

Replying to anonymous: that was me.

[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).

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.

[ilias@…]

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)?

[Christian Boos]

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.

[ilias@…]

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.

[ilias@…]

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)

[Christian Boos]

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.

[ilias@…]

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).

[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!)

[ilias@…]

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.

[anonymous]

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

[ilias@…]

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

[ilias@…]

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

[Christian Boos]

Most likely an issue with dates being fed as floats.

[Christian Boos]

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).

[ilias@…]

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)

[Christian Boos]

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).