CODE - Flexible TicketQuery Macro with extended Query functionality

40 views
Skip to first unread message

Ilias Lazaridis

unread,
Nov 10, 2006, 8:36:46 AM11/10/06
to Trac Development
http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacro

the result allows to apply any ticket queries within a wiki page
(essentially allowing this way create a set of saved queries). It
builds up on the existent "format=table" functionality.

an example:

http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacroTest?format=txt

http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacroTest

the display-fields can be selected based on an additional parameter
"fieldsets".

Fieldsets are defined within the trac *.ini file, within a dynamic
section (as many fieldsets as a user likes to define).

-

the patches are applied within a decentral development branch [1] :

http://dev.lazaridis.com/base/changeset/71
http://dev.lazaridis.com/base/changeset/72
http://dev.lazaridis.com/base/changeset/73
http://dev.lazaridis.com/base/changeset/77

there is a tiny follow-up issue, which is non critical ('Created' and
'Modified' fields appear within the query-modul UI, selecting them
results in no action):

http://dev.lazaridis.com/base/ticket/48

-

As the trac team has enouth work to do, I would like to work further on
this, taking existent trac-team requirements and tickets in account.

I would commit the changes to the decentral-branch on my
infrastructure, removing this way the need for a branch within the
original trac repository[2].

The branch can be reached from:

http://dev.lazaridis.com/base/wiki/ProductInstallation

This would be at the same time a first test in using trac as an
organizational tool for contributing to open source projects without
having access to the original svn repository. [3]

-

I hope that we can work in this way together - the way to a stable and
feature complete trac 1.0 is a difficult and complex one and needs some
more core level 'fighters'.

-

[1]
- Methods for Decentral Branching
http://groups.google.com/group/trac-dev/browse_frm/thread/89bbae56ca8e2e21

[2]
REQUEST - Branch for Query Module
http://groups.google.com/group/trac-dev/browse_frm/thread/3f749fb8ebcad0cd

[3]
http://dev.lazaridis.com/base/wiki/PlanDecentralBranching

Chris Forsythe

unread,
Nov 10, 2006, 8:51:25 AM11/10/06
to trac...@googlegroups.com
Ilias Lazaridis wrote:

>As the trac team has enouth work to do, I would like to work further on
>this, taking existent trac-team requirements and tickets in account.
>
>

Since you've made the point that the trac team has enough work to do,
wouldn't it be better to attach your patches to existing tickets in the
edgewall trac or submit new tickets with patches attached, since that's
how the trac team seems to work?

The way you're doing this seems like a lot of overhead to me.

Chris

Ilias Lazaridis

unread,
Nov 10, 2006, 9:17:38 AM11/10/06
to Trac Development
Chris Forsythe wrote:
> Ilias Lazaridis wrote:
>
> >As the trac team has enouth work to do, I would like to work further on
> >this, taking existent trac-team requirements and tickets in account.
> >
> >
> Since you've made the point that the trac team has enough work to do,
> wouldn't it be better to attach your patches to existing tickets in the
> edgewall trac or submit new tickets with patches attached, since that's
> how the trac team seems to work?

please review the thread.

I've already tried this way, but I cannot wait days - especially when
doing commercial work.

> The way you're doing this seems like a lot of overhead to me.

it seems just so.

Just review the provided links, especially:

REQUEST - Branch for Query Module

http://groups.google.com/group/trac-dev/browse_frm/thread/3f749fb8ebcad0cd/#

and take in account that not only the trac-team has limited time and
resources.

using a decentral branch seems the simplest way of 'doing fulltime
development without repository access'.

-

And finally, as a summary:

I suggest to contribute fulltime development work to the trac project,
this time whilst using a decentral branch.

The team can review the larger scale work (from within the publicly
available repository), and applying the changes (or whole subsystems)
to the trunk.

.

Chris Forsythe

unread,
Nov 10, 2006, 9:28:19 AM11/10/06
to trac...@googlegroups.com
Ilias Lazaridis wrote:

>Chris Forsythe wrote:
>
>
>>Ilias Lazaridis wrote:
>>
>>
>>
>>>As the trac team has enouth work to do, I would like to work further on
>>>this, taking existent trac-team requirements and tickets in account.
>>>
>>>
>>>
>>>
>>Since you've made the point that the trac team has enough work to do,
>>wouldn't it be better to attach your patches to existing tickets in the
>>edgewall trac or submit new tickets with patches attached, since that's
>>how the trac team seems to work?
>>
>>
>
>please review the thread.
>
>I've already tried this way, but I cannot wait days - especially when
>doing commercial work.
>
>

The process I indicated does not stop you from working in the your own
svn repo on your requirements. However, I'm saying that your proposal to
have patches submitted by having trac developers review your codebase
and then create the patchfiles from your commits seems kind of a waste.

If you know an issue resolves a problem for your customer(s), you could
create a patch after the fact rather easily, and then perform the
process I described.

I just thought it'd be easier on both parties (yours and trac devs),
since you'd be able to create specific code in your repo, and generic
patches could be submitted to the edgewall trac. If you don't think so,
you don't have to do it, but then you are left without a way to trac an
issue on the trac devs side. What I mean by this is, the trac devs would
have less responsibility to work on issues if they are not in trac.
Since you are asking them to proactively look at your svn repo, that
takes a lot of extra time and effort on their part with questionable
returns.

Chris

Christian Boos

unread,
Nov 10, 2006, 9:44:54 AM11/10/06
to trac...@googlegroups.com
Chris Forsythe wrote:
> ... What I mean by this is, the trac devs would

> have less responsibility to work on issues if they are not in trac.
>

Ilias already created the corresponding tickets in Edgewall's Trac.

> Since you are asking them to proactively look at your svn repo, that
> takes a lot of extra time and effort on their part with questionable
> returns.
>

Well, it's not directly a raw "svn repo" it's a Trac ;)
Instead of attaching patches to Trac tickets, Ilias could instead write
InterTrac diff links targeting the relevant changes in his branches. A
kind of "DIY" distributed VCS ;)

-- Christian

Luc Van Tien

unread,
Nov 10, 2006, 9:44:59 AM11/10/06
to trac...@googlegroups.com
My Trac system located in : http://203.162.21.33:9999/trac/ Any one explain for me why lose css in homepage ?
Which steps are wrong in installation ?
Thank you very much.


Hãy ghé qua trang chủ Yahoo! Việt Nam!


Hãy ghé qua trang chủ Yahoo! Việt Nam!

Chris Forsythe

unread,
Nov 10, 2006, 9:47:33 AM11/10/06
to trac...@googlegroups.com
Christian Boos wrote:

>Chris Forsythe wrote:
>
>
>>... What I mean by this is, the trac devs would
>>have less responsibility to work on issues if they are not in trac.
>>
>>
>>
>
>Ilias already created the corresponding tickets in Edgewall's Trac.
>
>

Ahh, good stuff indeed :)

Sorry for the misfire Ilias

Chris

Christian Boos

unread,
Nov 10, 2006, 9:47:25 AM11/10/06
to trac...@googlegroups.com
Luc Van Tien wrote:
> My Trac system located in : http://203.162.21.33:9999/trac/ Any one explain for me why lose css in homepage ?
> Which steps are wrong in installation ?
> Thank you very much.
>

... when I said the MailingList, I should have said the "trac-users"
mailing list, sorry!

Please don't use the trac-dev mailing list for installation support
requests.

-- Christian

Sid Wiesner

unread,
Nov 10, 2006, 9:48:17 AM11/10/06
to trac...@googlegroups.com
Luc Van Tien wrote:
> My Trac system located in : http://203.162.21.33:9999/trac/ Any one
> explain for me why lose css in homepage ?
> Which steps are wrong in installation ?
> Thank you very much.

If you append 'wiki' to your link, the css shows up fine:
http://203.162.21.33:9999/trac/wiki

Sid

Ilias Lazaridis

unread,
Nov 10, 2006, 10:30:27 AM11/10/06
to Trac Development

Sounds interesting (but I'm not sure I've understood)

How do I write those intertrac diff links?

Ilias Lazaridis

unread,
Nov 10, 2006, 10:34:13 AM11/10/06
to Trac Development

no problem.

I'm myself not sure about all this, just 'feel' that it's the right way
(with the right tool, which is trac).

.

Christian Boos

unread,
Nov 10, 2006, 11:10:43 AM11/10/06
to trac...@googlegroups.com
Ilias Lazaridis wrote:
> Christian Boos wrote:
>
>> ...

>> Instead of attaching patches to Trac tickets, Ilias could instead write
>> InterTrac diff links targeting the relevant changes in his branches.
>>
>
> Sounds interesting (but I'm not sure I've understood)
>
> How do I write those intertrac diff links?
>

Should be something like: lazaridis:diff:infra@70//infra@72, but:
- it's buggy ;) sorry have to fix that first...
- we would have to add the lazaridis intertrac prefix

This could be workarounded by explicitely writing:
http://dev.lazaridis.com/base/intertrac/diff:infra@70//infra@72

but as I said, for some reason, this doesn't work right now
(though searching for "diff:infra@70//infra@72" makes you quickjump to
the right page)

-- Christian

Matt Good

unread,
Nov 10, 2006, 3:58:03 PM11/10/06
to Trac Development
Ilias Lazaridis wrote:
> http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacro
>
> the result allows to apply any ticket queries within a wiki page
> (essentially allowing this way create a set of saved queries). It
> builds up on the existent "format=table" functionality.
>
> an example:
>
> http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacroTest?format=txt
>
> http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacroTest
>
> the display-fields can be selected based on an additional parameter
> "fieldsets".
>
> Fieldsets are defined within the trac *.ini file, within a dynamic
> section (as many fieldsets as a user likes to define).

I found the name "fieldset" confusing, since I assumed it had something
to do with the HTML <fieldset> tag. The parameter could be called
"cols" which I think would be more clear. Maybe the trac.ini section
could be renamed to "query-field-aliases" or "query-col-aliases", but
I'm open to suggestions there.

The changes in r77 completely override the behavior that automatically
determines what fields to display. While users may want to specify a
default list of fields they want to see, the query becomes less useful
without the automatic addtion of relevant fields.

For example if I add the filter "Keywords contains needinfo" the
results will contain the column "keywords" so that I can see the
contents of that field I'm filtering on. The final version of this
patch will need to account for that behavior.

Also, the automatic column list also removes columns that the user has
limited to 1 possible value, since displaying it would be redundant.

So, I think that for the Query page it should take into account some
"default" set of columns defined in trac.ini, and then apply the
automatic adjustments to display extra columns being filtered on, or
remove columns restricted to a single value.

For the TicketQuery macro the results should apply the same logic with
the default field list with automatic adjustment, *unless* the "cols"
parameter is passed, which would override that with a specific list of
columns which would not be adjusted.

> there is a tiny follow-up issue, which is non critical ('Created' and
> 'Modified' fields appear within the query-modul UI, selecting them
> results in no action):

Well, I think my previous patch for adding the "Created" and "Modified"
fields as sortable columns was sufficient for now, and avoids the bug
where they appear in the filter list. We will get many confused users
reporting a bug if they see those filters, but can't select them. Once
the code is in place to enable filtering by dates, *then* those filters
can be added to the list.

Hopefully that explains my expectations for how this should work when
it is merged into the Trac source. If you'd like to work on those
changes that'd be great, otherwise myself or maybe one of the other
devs can try to make those adjustments.

-- Matt Good

Ilias Lazaridis

unread,
Nov 11, 2006, 2:31:10 AM11/11/06
to Trac Development
Christian Boos wrote:
> Ilias Lazaridis wrote:
> > Christian Boos wrote:
> >> ...
> >> Instead of attaching patches to Trac tickets, Ilias could instead write
> >> InterTrac diff links targeting the relevant changes in his branches.
> >
> > Sounds interesting (but I'm not sure I've understood)
> >
> > How do I write those intertrac diff links?
>
> Should be something like: lazaridis:diff:infra@70//infra@72, but:
> - it's buggy ;) sorry have to fix that first...
> - we would have to add the lazaridis intertrac prefix
>
> This could be workarounded by explicitely writing:
> http://dev.lazaridis.com/base/intertrac/diff:infra@70//infra@72
[...]

replacing "//" with ":" does the work:

http://dev.lazaridis.com/base/intertrac/diff:infra@70:infra@72

so this one gives the full changes:

http://dev.lazaridis.com/base/intertrac/diff:infra@70:infra@77

very interesting functionality (and most possibly a central tool for
decentral branching/collaboration).

.

--
http://dev.lazaridis.com/base/wiki/PlanDecentralBranching

Ilias Lazaridis

unread,
Nov 11, 2006, 8:37:22 AM11/11/06
to Trac Development
Matt Good wrote:
> Ilias Lazaridis wrote:
> > http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacro
> >
> > the result allows to apply any ticket queries within a wiki page
> > (essentially allowing this way create a set of saved queries). It
> > builds up on the existent "format=table" functionality.
> >
> > an example:
> >
> > http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacroTest?format=txt
> >
> > http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacroTest
> >
> > the display-fields can be selected based on an additional parameter
> > "fieldsets".
> >
> > Fieldsets are defined within the trac *.ini file, within a dynamic
> > section (as many fieldsets as a user likes to define).
>
> I found the name "fieldset" confusing, since I assumed it had something
> to do with the HTML <fieldset> tag.

ok, sounds like a rational objection.

> The parameter could be called "cols" which I think would be more clear.

The model talks about "fields", thus possibly this term should be
prefered for consistency reasons (the user does not see the term "cols"
within the code).

one thing is a given: the parameter describes a collection of "sets".

Thus, if "col" should be use, the parameter would be "colsets".

> Maybe the trac.ini section
> could be renamed to "query-field-aliases" or "query-col-aliases", but
> I'm open to suggestions there.

Query is not specific enouth (other queries will become possible, e.g.
MilestoneQuery).

Ticket-Query qualifies further

ticket-query-display-fields possibly would express it precisely, or

ticket-query-display-cols

(although I have an aversion to "cols", as it reminds me the relational
world.)

> > the patches are applied within a decentral development branch [1] :
> >
> > http://dev.lazaridis.com/base/changeset/71
> > http://dev.lazaridis.com/base/changeset/72
> > http://dev.lazaridis.com/base/changeset/73
> > http://dev.lazaridis.com/base/changeset/77
>
> The changes in r77 completely override the behavior that automatically
> determines what fields to display. While users may want to specify a
> default list of fields they want to see, the query becomes less useful
> without the automatic addtion of relevant fields.

I apoligize, the provided diff contains a change against a previous
version of mine and is missleading. the default behaviour is not
overridden:

a more concise diff:

http://dev.lazaridis.com/base/intertrac/diff:sync/trac/trac/ticket/query.py@109:infra/trac-dev/trac/ticket/query.py@109

or a full diff of the changes:

http://dev.lazaridis.com/base/intertrac/diff:sync/trac@109:infra/trac-dev@109

> For example if I add the filter "Keywords contains needinfo" the
> results will contain the column "keywords" so that I can see the
> contents of that field I'm filtering on. The final version of this
> patch will need to account for that behavior.

this is already the case.

> Also, the automatic column list also removes columns that the user has
> limited to 1 possible value, since displaying it would be redundant.
>
> So, I think that for the Query page it should take into account some
> "default" set of columns defined in trac.ini, and then apply the
> automatic adjustments to display extra columns being filtered on, or
> remove columns restricted to a single value.
>
> For the TicketQuery macro the results should apply the same logic with
> the default field list with automatic adjustment, *unless* the "cols"
> parameter is passed, which would override that with a specific list of
> columns which would not be adjusted.

That's the exact current behaviour.

> > there is a tiny follow-up issue, which is non critical ('Created' and
> > 'Modified' fields appear within the query-modul UI, selecting them
> > results in no action):
>
> Well, I think my previous patch for adding the "Created" and "Modified"
> fields as sortable columns was sufficient for now, and avoids the bug
> where they appear in the filter list.

This patch did not work (time was use later in comparisons).

Additionally: this task needed to be solved as a whole.

> We will get many confused users
> reporting a bug if they see those filters, but can't select them. Once
> the code is in place to enable filtering by dates, *then* those filters
> can be added to the list.

avoiding those filters to get into the combo-box should be trivial
(e.g.
initially with a 'manual' intervention in the template).

> Hopefully that explains my expectations for how this should work when
> it is merged into the Trac source.

ok

> If you'd like to work on those
> changes that'd be great, otherwise myself or maybe one of the other
> devs can try to make those adjustments.

I can do the adjustments, thus the other dev's and you can focus on
their active tasks.

.

Matt Good

unread,
Nov 11, 2006, 5:53:28 PM11/11/06
to Trac Development
Ilias Lazaridis wrote:

> Matt Good wrote:
> > The parameter could be called "cols" which I think would be more clear.
>
> The model talks about "fields", thus possibly this term should be
> prefered for consistency reasons (the user does not see the term "cols"
> within the code).

Well, the model's part of the code too, so they wouldn't see "fields"
either. I went ahead and wrote a patch tthat should fix the issues I
mentioned before which uses "columns". I figured this would be
meaningful to end-users since it corresponds to the columns in the
displayed table of results. However, I'd be fine with "fields" if
there's consensus from the other developers for that.

> one thing is a given: the parameter describes a collection of "sets".
>
> Thus, if "col" should be use, the parameter would be "colsets".

Well, I don't think it should just be limited just to the column lists
defined in trac.ini. This patch provides a "columns" parameter which
can contain a list of column names, or aliases defined in trac.ini:

http://en.pastebin.ca/246140

This also allows aliases to be defined in terms of each other such as:
basic = id,description
expanded = basic,reporter,owner

> > Maybe the trac.ini section
> > could be renamed to "query-field-aliases" or "query-col-aliases", but
> > I'm open to suggestions there.
>
> Query is not specific enouth (other queries will become possible, e.g.
> MilestoneQuery).

I was thinking there was already a [query] section, so I was going to
be consistent with that, but I checked again and realized that's not
yet defined. The patch I provided uses [ticket-query-column-aliases].
That is a bit long though, so suggestions for shorter names would be
fine.

> I apoligize, the provided diff contains a change against a previous
> version of mine and is missleading. the default behaviour is not
> overridden:

Well, I noticed that it wasn't diffed against a vanilla Trac, but
that's not what I was referring to. See:
http://dev.lazaridis.com/base/browser/infra/trac-dev/trac/ticket/query.py?rev=88#L111

In line 111 and 112 Trac defines the initial list of "cols", which you
override in lines 118 and 121. Compare the columns when querying your
site with a "Keywords" filter:
http://dev.lazaridis.com/base/query?status=new&status=assigned&status=reopened&keywords=%7Ea&order=priority

To the same query on the Trac site:
http://trac.edgewall.org/query?status=new&status=assigned&status=reopened&keywords=%7Ea&order=priority

The Trac site lists the "Keywords" column in the results while yours
doesn't. The patch I provided above also fixes this.

-- Matt Good

Ilias Lazaridis

unread,
Nov 12, 2006, 4:55:52 AM11/12/06
to Trac Development
Matt Good wrote:
> Ilias Lazaridis wrote:
> > Matt Good wrote:
> > > The parameter could be called "cols" which I think would be more clear.
> >
> > The model talks about "fields", thus possibly this term should be
> > prefered for consistency reasons (the user does not see the term "cols"
> > within the code).
>
> Well, the model's part of the code too, so they wouldn't see "fields"
> either. I went ahead and wrote a patch tthat should fix the issues I
> mentioned before which uses "columns". I figured this would be
> meaningful to end-users since it corresponds to the columns in the
> displayed table of results. However, I'd be fine with "fields" if
> there's consensus from the other developers for that.

The TracQuery user documentation mentions only "field/fields":

http://trac.edgewall.org/wiki/TracQuery

Thus the term "fields" should be prefered.

> > one thing is a given: the parameter describes a collection of "sets".
> >
> > Thus, if "col" should be use, the parameter would be "colsets".
>
> Well, I don't think it should just be limited just to the column lists
> defined in trac.ini. This patch provides a "columns" parameter which
> can contain a list of column names, or aliases defined in trac.ini:
>
> http://en.pastebin.ca/246140
>
> This also allows aliases to be defined in terms of each other such as:
> basic = id,description
> expanded = basic,reporter,owner

This looks very interesting, but I personally prefere to add
functionality incrementally in small steps, taking some
(dev)user-feedback in account (at this point I got only feedback ffrom
one user).

> > > Maybe the trac.ini section
> > > could be renamed to "query-field-aliases" or "query-col-aliases", but
> > > I'm open to suggestions there.
> >
> > Query is not specific enouth (other queries will become possible, e.g.
> > MilestoneQuery).
>
> I was thinking there was already a [query] section, so I was going to
> be consistent with that, but I checked again and realized that's not
> yet defined. The patch I provided uses [ticket-query-column-aliases].
> That is a bit long though, so suggestions for shorter names would be
> fine.

I still suggest "ticket-query-fieldsets" or
"ticket-query-display-fieldsets"

> > I apoligize, the provided diff contains a change against a previous
> > version of mine and is missleading. the default behaviour is not
> > overridden:
>
> Well, I noticed that it wasn't diffed against a vanilla Trac, but
> that's not what I was referring to. See:
> http://dev.lazaridis.com/base/browser/infra/trac-dev/trac/ticket/query.py?rev=88#L111

I was not sure about the intention of the code, that's was the reason
for this comment:

http://dev.lazaridis.com/base/browser/infra/trac-dev/trac/ticket/query.py?rev=88#L123

> In line 111 and 112 Trac defines the initial list of "cols", which you
> override in lines 118 and 121. Compare the columns when querying your
> site with a "Keywords" filter:
> http://dev.lazaridis.com/base/query?status=new&status=assigned&status=reopened&keywords=%7Ea&order=priority
>

A tiny bug, I've re-created the original behaviour for the keyword, cc,
reporter fields:

http://dev.lazaridis.com/base/changeset/110

> To the same query on the Trac site:
> http://trac.edgewall.org/query?status=new&status=assigned&status=reopened&keywords=%7Ea&order=priority
>
> The Trac site lists the "Keywords" column in the results while yours
> doesn't. The patch I provided above also fixes this.

Your patch differes from my development direction.

I would prefere to see small steps, thus developers can follow the
development and users can review the functionality, too.

Additionally, a newcomer can work on code-clarity - something that the
existent developers cannot do.

But after one month on this topic, I would like to see that something
goes into the trunk (thus I get my 'fulfilled-happiness' that an
open-source project should give to it's contributors) - so if you go
ahead and commit your patch, it would be fine for me.

.

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

Ilias Lazaridis

unread,
Nov 13, 2006, 10:59:52 AM11/13/06
to Trac Development
Matt Good wrote:
> Ilias Lazaridis wrote:
...

> > there is a tiny follow-up issue, which is non critical ('Created' and
> > 'Modified' fields appear within the query-modul UI, selecting them
> > results in no action):
>
> Well, I think my previous patch for adding the "Created" and "Modified"
> fields as sortable columns was sufficient for now, and avoids the bug
> where they appear in the filter list. We will get many confused users
> reporting a bug if they see those filters, but can't select them. Once
> the code is in place to enable filtering by dates, *then* those filters
> can be added to the list.

...

The add-filter issue is trivial:

http://dev.lazaridis.com/base/changeset/115

see sidenote [1]

-

I've removed additionally the change to the "get_ticket_fields"
function within "api/py", so the overall change is only within query.py
and the 2 templates:

http://dev.lazaridis.com/base/intertrac/diff:sync/trac@115:infra/trac-dev@115

.

[1]
sidenote: I have the feeling that the code should be moved away from
the template, e.g. attributes like "field.available_for_filtering" and
"field.filter_disabled"

http://dev.lazaridis.com/base/browser/infra/trac-dev/templates/query.html?rev=115#L117

.

Ilias Lazaridis

unread,
Nov 14, 2006, 8:56:54 AM11/14/06
to Trac Development
Matt Good wrote:
> Ilias Lazaridis wrote:
> > http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacro
......

> Hopefully that explains my expectations for how this should work when
> it is merged into the Trac source. If you'd like to work on those
> changes that'd be great, otherwise myself or maybe one of the other
> devs can try to make those adjustments.

I've further simplified the changes and adjusted to the code to the
patch given in[1]:

http://dev.lazaridis.com/base/intertrac/diff:sync/trac@119:infra/trac-dev@119

the query_div.html part could go into trunk, it's non-critical and
equal for both:

http://dev.lazaridis.com/base/intertrac/diff:sync/trac/templates/query_div.html@119:infra/trac-dev/templates/query_div.html@119

I've filed a ticket:

http://trac.edgewall.org/ticket/4158

-

[1]
http://groups.google.com/group/trac-dev/msg/23a8d456152fd502

.

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

Ilias Lazaridis

unread,
Nov 21, 2006, 11:55:39 AM11/21/06
to Trac Development
Matt Good wrote:
> Ilias Lazaridis wrote:
> > http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacro
> >
> > the result allows to apply any ticket queries within a wiki page
> > (essentially allowing this way create a set of saved queries). It
> > builds up on the existent "format=table" functionality.
...

> Hopefully that explains my expectations for how this should work when
> it is merged into the Trac source. If you'd like to work on those
> changes that'd be great, otherwise myself or maybe one of the other
> devs can try to make those adjustments.

one more separation:

Enable Ordering on 'datetime' fields within Ticket Query
http://trac.edgewall.org/ticket/4174

this one should go into the trac.edgewall.org instance, too.

This would view ticket query results where the last changed ticket
appears on top.

Reply all
Reply to author
Forward
0 new messages