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/[EMAIL PROTECTED]:infra/trac-dev/trac/ticket/[EMAIL PROTECTED] or a full diff of the changes: http://dev.lazaridis.com/base/intertrac/diff:sync/[EMAIL PROTECTED]:infra/[EMAIL PROTECTED] > 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. . --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
