On 29 Nov 2012, at 16:27, Gary Martin <[email protected]> wrote:
> On 29/11/12 15:16, Olemis Lang wrote:
>> On 11/29/12, Gary Martin <[email protected]> wrote:
>>> On 19/11/12 15:36, Olemis Lang wrote:
>>>> On 11/19/12, Peter Koželj <[email protected]> wrote:
>>>>> First I would like to check if I understand this correctly.
>>>>> So, this means that a user can embed widgets from dashboard in wiki
>>>>> pages
>>>>> or ticket descriptions?
>>>> anywhere WikiFormatting is supported , yes . Widgets are enhanced
>>>> macros in first place.
>>>>
>>>>> I do not se any problems with this at the moment
>>>> cool
>>>>
>>>>> but, this can not be a
>>>>> substitute for user customizable dashboard.
>>>>> We still need to provide fully customizable dashboard
>>>> +1
>>>> for the moment think of it like the replacement to TicketQuery et al.
>>>> as we use it today on i.a.o . It looks weird to me that we were able
>>>> to customize those views and we can not embed a similar widget in a
>>>> wiki page when we need it .
>>> I don't see that it is weird not to be able to do this.
>> I could find the right word ...
>>
>>> The advantage is
>>> if we bring enhancements to the existing functionality. At the moment,
>>> in terms of TicketQuery vs Widget(TicketQuery, ...) we bring certain
>>> improvements but not all the functionality yet.
>> what's missing
>
> Well, I suppose there is a question of whether any discrepancies matter. I
> note that columns are linked to queries in the TicketQuery that give the list
> of tickets ordered by the relevant field. It is possible that if we were to
> put links on columns that we would want their primary action to be to order
> by that field with a bit of ajax.
>
> Interestingly [[TicketQuery(table, ?status=!closed&keywords=~starter,
> max=5)]] also seems to include the keywords field as one of the columns. That
> is almost certainly not the desired output for our dashboard views but I
> suppose it may be a comfort to some that it was the right query.
I think it would be better to provide an indicator what the query is and not
show the column, unless requested.
That indicator could be a line of text showing the query in a readable way or
an info/config dialogue. Anyway, we don't need to decide thy just yet.
>>
>>> At some point, once we get feature parity, we could consider overriding
>>> TicketQuery so that it uses Widget(TicketQuery,...) instead.
>> fwiw it's possible to have TicketQueryWidget( ... ) rather than
>> Widget(TicketQuery, ...) . In general , <WidgetName>Widget( ... ) vs
>> Widget(<WidgetName>, ...)
>
> Well, not quite what I mean - two macros for effectively the same thing is
> not really ideal.
>
> Cheers,
> Gary
