Mailing List Archive

On Sunday, May 31, 2020 at 10:05:30 PM UTC-4, Aikido Guy wrote:
>
> A TicketQuery (working before upgrade to Trac 1.4.1) has triggered the
> following error message in Trac 1.4.1 (the log file contains):
>
> ERROR: Macro TicketQuery(...)
> trac/wiki/formatter.py line 818 in _macro_formatter
> ...
> trac/ticket/query.py line 1406
> trac/ticket/query.py line 334
> val = from_utimestamp(int(val)) if val else None
>
> ValueError: invalid literal for int() with base 10: '2018/07/03'
>
> Notes:
> (1) I am ordering by a column that use to be of type "text" and was then
> formatted by a plugin (if I remember correctly... it has been about 6 years)
> (2) The new column is now of type "time" with format "date"
>
> Questions:
> (1) Do I need to change the backing sqlite database for this column type
> change from "text" to "time"?
> (2) Is there a little SQL script or something that you already have
> available that could help me with this process if I need to do it myself?
>

Forgot to mention that I also saw #12325 that may be related...

Kindly,
Aikido Guy

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/df887d28-1af3-45be-aa19-f7300146a00e%40googlegroups.com.

On Sunday, May 31, 2020 at 7:07:02 PM UTC-7, Aikido Guy wrote:
>
> On Sunday, May 31, 2020 at 10:05:30 PM UTC-4, Aikido Guy wrote:
>>
>> A TicketQuery (working before upgrade to Trac 1.4.1) has triggered the
>> following error message in Trac 1.4.1 (the log file contains):
>>
>> ERROR: Macro TicketQuery(...)
>> trac/wiki/formatter.py line 818 in _macro_formatter
>> ...
>> trac/ticket/query.py line 1406
>> trac/ticket/query.py line 334
>> val = from_utimestamp(int(val)) if val else None
>>
>> ValueError: invalid literal for int() with base 10: '2018/07/03'
>>
>> Notes:
>> (1) I am ordering by a column that use to be of type "text" and was then
>> formatted by a plugin (if I remember correctly... it has been about 6 years)
>> (2) The new column is now of type "time" with format "date"
>>
>> Questions:
>> (1) Do I need to change the backing sqlite database for this column type
>> change from "text" to "time"?
>> (2) Is there a little SQL script or something that you already have
>> available that could help me with this process if I need to do it myself?
>>
>
> Forgot to mention that I also saw #12325 that may be related...
>
> Kindly,
> Aikido Guy
>

You were probably using DateFieldPlugin, and encountering the problem
described in this ticket:
https://trac-hacks.org/ticket/11856

So, yes, like you've already hinted at, if you want to use a
TicketCustomField of type time, you'll have to migrate your data. Or if
you've created a special column for time data, either directly or via a
plugin. In the latter case, you'll need to change the column type from text
to int64 (and type defined in Trac, which maps to appropriate types in each
supported DB).

If you are using a custom field of type time, then no need to worry about
the database type because all data in the ticket_custom table gets stored
as text. Example:

[ticket-custom]
time1 = time
time1.format = date

Created a ticket #155 with the "time1" field having value "May 1, 2020":

$ litecli ../tracenvs/proj-1.3/db/trac.db
Version: 1.2.0
Mail: https://groups.google.com/forum/#!forum/litecli-users
GitHub: https://github.com/dbcli/litecli
../tracenvs/proj-1.3/db/trac.db> SELECT * FROM ticket_custom WHERE
ticket=155 AND name='time1'
+--------+-------+--------------------+
| ticket | name | value |
+--------+-------+--------------------+
| 155 | time1 | 001588316400000000 |
+--------+-------+--------------------+
1 row in set
Time: 0.010s


I did some quick investigation on conversion:

>>> from trac.util.datefmt import parse_date, to_utimestamp
>>> d = parse_date('2018/07/03'.replace('/', '-'))
>>> d
datetime.datetime(2018, 7, 3, 0, 0, tzinfo=<LocalTimezone "PDT" -1 day,
17:00:00>)
>>> t = to_utimestamp(d)
>>> t
1530601200000000

You can convert "t" to a string and insert into the ticket_custom table.

You should be okay if your server is in approximately the same timezone as
your users, but if not, and if you care, you need to determine who inserted
the data and what timezone they were in. That sounds painful.

- Ryan

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/c6e586fe-b03c-4852-9fa3-b81ae9de7b57%40googlegroups.com.

On Monday, June 1, 2020 at 2:22:12 AM UTC-4, RjOllos wrote:

> On Sunday, May 31, 2020 at 7:07:02 PM UTC-7, Aikido Guy wrote:
>>
>> On Sunday, May 31, 2020 at 10:05:30 PM UTC-4, Aikido Guy wrote:
>>>
>>> A TicketQuery (working before upgrade to Trac 1.4.1) has triggered the
>>> following error message in Trac 1.4.1 (the log file contains):
>>>
>>> ERROR: Macro TicketQuery(...)
>>>
>>> ValueError: invalid literal for int() with base 10: '2018/07/03'
>>>
>>> Notes:
>>> (1) I am ordering by a column that use to be of type "text" and was then
>>> formatted by a plugin (if I remember correctly... it has been about 6 years)
>>> (2) The new column is now of type "time" with format "date"
>>>
>>> Questions:
>>> (1) Do I need to change the backing sqlite database for this column type
>>> change from "text" to "time"?
>>>
>>> Forgot to mention that I also saw #12325 that may be related...
>>
>> You were probably using DateFieldPlugin, and encountering the problem
> described in this ticket:
> https://trac-hacks.org/ticket/11856
>

Yes indeed! That is the plugin's name ;)

So, yes, like you've already hinted at, if you want to use a
> TicketCustomField of type time, you'll have to migrate your data. Or if
> you've created a special column for time data, either directly or via a
> plugin. In the latter case, you'll need to change the column type from text
> to int64 (and type defined in Trac, which maps to appropriate types in each
> supported DB).
>

Understood...

If you are using a custom field of type time, then no need to worry about
> the database type because all data in the ticket_custom table gets stored
> as text.
>

Thanks for that schema reminder! Very helpful tip ;)

Example:
>
> [ticket-custom]
> time1 = time
> time1.format = date
>
> Created a ticket #155 with the "time1" field having value "May 1, 2020":
>
> $ litecli ../tracenvs/proj-1.3/db/trac.db
> Version: 1.2.0
> Mail: https://groups.google.com/forum/#!forum/litecli-users
> GitHub: https://github.com/dbcli/litecli
> ../tracenvs/proj-1.3/db/trac.db> SELECT * FROM ticket_custom WHERE
> ticket=155 AND name='time1'
> +--------+-------+--------------------+
> | ticket | name | value |
> +--------+-------+--------------------+
> | 155 | time1 | 001588316400000000 |
> +--------+-------+--------------------+
> 1 row in set
> Time: 0.010s
>
>
> I did some quick investigation on conversion:
>
> >>> from trac.util.datefmt import parse_date, to_utimestamp
> >>> d = parse_date('2018/07/03'.replace('/', '-'))
> >>> d
> datetime.datetime(2018, 7, 3, 0, 0, tzinfo=<LocalTimezone "PDT" -1 day,
> 17:00:00>)
> >>> t = to_utimestamp(d)
> >>> t
> 1530601200000000
>
> You can convert "t" to a string and insert into the ticket_custom table.
>
> You should be okay if your server is in approximately the same timezone as
> your users, but if not, and if you care, you need to determine who inserted
> the data and what timezone they were in. That sounds painful.
>
> - Ryan
>

All very excellent points. And it would be very painful if I needed hourly
information! That's for sure!

My current global trac.ini contains something similar to your example:

[ticket-custom]
time1 = time
time1.format = date
time1.label = "Blah (YYYY/MM/DD)
time1.value =
time1.order = 5

I've followed all of your advice and am now left with one small (not
urgent) question. In particular, my original TicketQuery now works (yah!);
however, instead of having '2018/07/03' shown in my table, I have "*at*
2018/07/03".
- Is there a configuration option to control how the time is output? In my
case, since there are no hours, minutes or seconds, it could be "*on *2018/07/03"
instead?
- Or maybe there is some kind of option to control a little more the format
of the date being output? i.e. a way to remove the "at"? or to add an "on"
etc...

As a side thought as I am typing... is the "*at* 2018/07/03" supported
across languages?

Kindly,
Aikido Guy

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/31f21a1d-85c1-43f3-a514-d103ccdaf341%40googlegroups.com.

On Monday, June 1, 2020 at 10:40:30 PM UTC-4, Aikido Guy wrote:
>
> [ticket-custom]
> time1 = time
> time1.format = date
> time1.label = "Blah (YYYY/MM/DD)
> time1.value =
> time1.order = 5
>
> I've followed all of your advice and am now left with one small (not
> urgent) question. In particular, my original TicketQuery now works (yah!);
> however, instead of having '2018/07/03' shown in my table, I have "*at*
> 2018/07/03".
> - Is there a configuration option to control how the time is output? In my
> case, since there are no hours, minutes or seconds, it could be "*on *2018/07/03"
> instead?
> - Or maybe there is some kind of option to control a little more the
> format of the date being output? i.e. a way to remove the "at"? or to add
> an "on" etc...
>
> As a side thought as I am typing... is the "*at* 2018/07/03" supported
> across languages?
>

I realize that this might be a bit of a rabbit hole... because I can also
imagine using "by end of 2018/07/03"... a lot of duplicated text...

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/2913108a-bb41-459d-8c85-097bf29b6fd8%40googlegroups.com.

On Monday, June 1, 2020 at 7:44:04 PM UTC-7, Aikido Guy wrote:
>
> On Monday, June 1, 2020 at 10:40:30 PM UTC-4, Aikido Guy wrote:
>>
>> [ticket-custom]
>> time1 = time
>> time1.format = date
>> time1.label = "Blah (YYYY/MM/DD)
>> time1.value =
>> time1.order = 5
>>
>> I've followed all of your advice and am now left with one small (not
>> urgent) question. In particular, my original TicketQuery now works (yah!);
>> however, instead of having '2018/07/03' shown in my table, I have "*at*
>> 2018/07/03".
>> - Is there a configuration option to control how the time is output? In
>> my case, since there are no hours, minutes or seconds, it could be "*on *2018/07/03"
>> instead?
>> - Or maybe there is some kind of option to control a little more the
>> format of the date being output? i.e. a way to remove the "at"? or to add
>> an "on" etc...
>>
>> As a side thought as I am typing... is the "*at* 2018/07/03" supported
>> across languages?
>>
>
> I realize that this might be a bit of a rabbit hole... because I can also
> imagine using "by end of 2018/07/03"... a lot of duplicated text...
>

I tested with trunk, but time is also shown for format=date. Did you find
otherwise on 1.4-stable?
https://trac.edgewall.org/ticket/13309

It is localized. Here is English and French for:
[[TicketQuery(id=102, format=table, col=time1)]]

[image: Screen Shot 2020-06-02 at 00.50.11.jpg] <about:invalid#zClosurez>





[image: Screen Shot 2020-06-02 at 00.55.24.jpg] <about:invalid#zClosurez>




The "at .." is prepared by Chrome.pretty_dateinfo:
https://trac.edgewall.org/browser/tags/trac-1.4.1/trac/web/chrome.py?marks=1258-1263#L1237

You could probably write a small plugin to either monkey-patch that method
or change the data in IRequestFilter.post_process_request, but it would be
a little tricky.

There's an open ticket to develop and interface that I think would allow
modifying the presentation of query results, but not much movement on
implementing it.

Or, you could write a report instead and display it with WikiReportMacro:
https://trac-hacks.org/wiki/WikiReportMacro

You can format the output in SQL to display "by end of ..."

- Ryan



--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/1538abe9-6eb9-4ea0-af71-aa1afbbd6248%40googlegroups.com.

On Tuesday, June 2, 2020 at 4:03:12 AM UTC-4, RjOllos wrote:

> On Monday, June 1, 2020 at 7:44:04 PM UTC-7, Aikido Guy wrote:
>>
>> On Monday, June 1, 2020 at 10:40:30 PM UTC-4, Aikido Guy wrote:
>>>
>>> [ticket-custom]
>>> time1 = time
>>> time1.format = date
>>> time1.label = "Blah (YYYY/MM/DD)
>>> time1.value =
>>> time1.order = 5
>>>
>>> I've followed all of your advice and am now left with one small (not
>>> urgent) question. In particular, my original TicketQuery now works (yah!);
>>> however, instead of having '2018/07/03' shown in my table, I have "*at*
>>> 2018/07/03".
>>> - Is there a configuration option to control how the time is output? In
>>> my case, since there are no hours, minutes or seconds, it could be "*on
>>> *2018/07/03" instead?
>>> - Or maybe there is some kind of option to control a little more the
>>> format of the date being output? i.e. a way to remove the "at"? or to add
>>> an "on" etc...
>>>
>>> As a side thought as I am typing... is the "*at* 2018/07/03" supported
>>> across languages?
>>>
>>
>> I realize that this might be a bit of a rabbit hole... because I can also
>> imagine using "by end of 2018/07/03"... a lot of duplicated text...
>>
>
> I tested with trunk, but time is also shown for format=date. Did you find
> otherwise on 1.4-stable?
> https://trac.edgewall.org/ticket/13309
>

I'm pretty sure I typed the right trac.ini config section... I've double
checked and here it is again (only difference is order from what I typed
before, and I fixed a typo):

[ticket-custom]
time1 = time
time1.label = Blah (YYYY/MM/DD)
time1.format = date
time1.value =
time1.order = 5

Looks like I have a different result than you. I have "*at* 2018/07/03" , "
*at* 2019/03/07" etc, with no time values in my custom field column in my
TracQuery. In my case, the TracQuery is inside a custom plugin that I
built, but I don't think that should make any difference...

My TicketQuery is something like this:
[[TicketQuery(order=time1,status,time1!=,desc=0,format=table,col=complete|status|time1|summary)]]

- It is ordered by the custom field
- If the custom field is missing then tickets should not be displayed
- It is using the table output format
- The custom field is one of the middle output columns (i.e. it is not the
first and not the last column)

It is localized. Here is English and French for:
> [[TicketQuery(id=102, format=table, col=time1)]]
>
> [image: Screen Shot 2020-06-02 at 00.50.11.jpg]
>
>
>
>
>
> [image: Screen Shot 2020-06-02 at 00.55.24.jpg]
>
>
>
>
>
Nice ;)

The "at .." is prepared by Chrome.pretty_dateinfo:
>
> https://trac.edgewall.org/browser/tags/trac-1.4.1/trac/web/chrome.py?marks=1258-1263#L1237
> <https://www.google.com/url?q=https%3A%2F%2Ftrac.edgewall.org%2Fbrowser%2Ftags%2Ftrac-1.4.1%2Ftrac%2Fweb%2Fchrome.py%3Fmarks%3D1258-1263%23L1237&sa=D&sntz=1&usg=AFQjCNGSCfODvkW3XGZl4PBsMBt8-LIhbA>
>

Wondering out loud... what makes *dateonly* become True?
def pretty_dateinfo(date, format=None, *dateonly*=False)

I looked at my Admin panel and default date format is ISO8601 and default
time format is relative.

You could probably write a small plugin to either monkey-patch that method
> or change the data in IRequestFilter.post_process_request, but it would be
> a little tricky.
>
> There's an open ticket to develop and interface that I think would allow
> modifying the presentation of query results, but not much movement on
> implementing it.
>
> Or, you could write a report instead and display it with WikiReportMacro:
> https://trac-hacks.org/wiki/WikiReportMacro
>
> You can format the output in SQL to display "by end of ..."
>
> - Ryan
>

This is starting to be a little unmaintainable for me. My original hope was
for the date "2019/03/29" without anything else attached to it... I do like
"on 2019/03/29" and "by end of 2019/03/29" and "before 2019/03/29" etc.
etc. but it seems like a bit of work for me to customize this and/or to get
the behaviour that the plugin was providing before upgrading.

If there was a way to configure the TracQuery so that the date was not
annotated that would get me what I need... because I guess what I'm asking
for is specific to that macro rather than general for all uses of the
custom field. Alternatively, if there was a trac.ini way to indicate how
TracQuery should display the custom field that would work for me too. The
latter would be nice because then I could configure my custom date fields
to display differently... depending on context. For example, one could be
"on 2019/03/29" and one could be "before 2019/03/29" and one could be
simply "2019/03/29" etc. etc.

Maybe something like this:

[ticket-custom]
time1 = time
time1.label = Blah (YYYY/MM/DD)
time1.format = date
time1.tracqueryformat = just a date ;) perhaps a coffee first?? haha
time1.value =
time1.order = 5

Kindly,
Aikido Guy

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/cc10e33d-1d73-47ea-91e5-17c5f110906e%40googlegroups.com.

On Tuesday, June 2, 2020 at 11:38:30 AM UTC-7, Aikido Guy wrote:
>
> On Tuesday, June 2, 2020 at 4:03:12 AM UTC-4, RjOllos wrote:
>
>> On Monday, June 1, 2020 at 7:44:04 PM UTC-7, Aikido Guy wrote:
>>>
>>> On Monday, June 1, 2020 at 10:40:30 PM UTC-4, Aikido Guy wrote:
>>>>
>>>> [ticket-custom]
>>>> time1 = time
>>>> time1.format = date
>>>> time1.label = "Blah (YYYY/MM/DD)
>>>> time1.value =
>>>> time1.order = 5
>>>>
>>>> I've followed all of your advice and am now left with one small (not
>>>> urgent) question. In particular, my original TicketQuery now works (yah!);
>>>> however, instead of having '2018/07/03' shown in my table, I have "*at*
>>>> 2018/07/03".
>>>> - Is there a configuration option to control how the time is output? In
>>>> my case, since there are no hours, minutes or seconds, it could be "*on
>>>> *2018/07/03" instead?
>>>> - Or maybe there is some kind of option to control a little more the
>>>> format of the date being output? i.e. a way to remove the "at"? or to add
>>>> an "on" etc...
>>>>
>>>> As a side thought as I am typing... is the "*at* 2018/07/03" supported
>>>> across languages?
>>>>
>>>
>>> I realize that this might be a bit of a rabbit hole... because I can
>>> also imagine using "by end of 2018/07/03"... a lot of duplicated text...
>>>
>>
>> I tested with trunk, but time is also shown for format=date. Did you find
>> otherwise on 1.4-stable?
>> https://trac.edgewall.org/ticket/13309
>>
>
> I'm pretty sure I typed the right trac.ini config section... I've double
> checked and here it is again (only difference is order from what I typed
> before, and I fixed a typo):
>
> [ticket-custom]
> time1 = time
> time1.label = Blah (YYYY/MM/DD)
> time1.format = date
> time1.value =
> time1.order = 5
>
> Looks like I have a different result than you. I have "*at* 2018/07/03" ,
> "*at* 2019/03/07" etc, with no time values in my custom field column in
> my TracQuery.
>

The ISO8601 format setting is the difference. Same result here if using
ISO8601 format. Looking at the code, it makes sense:
https://trac.edgewall.org/browser/tags/trac-1.4.1/trac/web/chrome.py?marks=1258-1259#L1237


> In my case, the TracQuery is inside a custom plugin that I built, but I
> don't think that should make any difference...
>

Are you constructing a Query object in the custom plugin? Or returning
markup containing [[TicketQuery(...)]]? Either way, that that should allow
you to parse and modify the HTML that is generated.

More simply, you could modify what is displayed using some custom site
JavaScript. It should be fairly straightforward to create a selector and
then modify the content of the span:



[image: Screen Shot 2020-06-02 at 12.39.13.jpg]



> My TicketQuery is something like this:
>
> [[TicketQuery(order=time1,status,time1!=,desc=0,format=table,col=complete|status|time1|summary)]]
>
> - It is ordered by the custom field
> - If the custom field is missing then tickets should not be displayed
> - It is using the table output format
> - The custom field is one of the middle output columns (i.e. it is not the
> first and not the last column)
>
> It is localized. Here is English and French for:
>> [[TicketQuery(id=102, format=table, col=time1)]]
>>
>> [image: Screen Shot 2020-06-02 at 00.50.11.jpg]
>>
>>
>>
>>
>>
>> [image: Screen Shot 2020-06-02 at 00.55.24.jpg]
>>
>>
>>
>>
>>
> Nice ;)
>
> The "at .." is prepared by Chrome.pretty_dateinfo:
>>
>> https://trac.edgewall.org/browser/tags/trac-1.4.1/trac/web/chrome.py?marks=1258-1263#L1237
>> <https://www.google.com/url?q=https%3A%2F%2Ftrac.edgewall.org%2Fbrowser%2Ftags%2Ftrac-1.4.1%2Ftrac%2Fweb%2Fchrome.py%3Fmarks%3D1258-1263%23L1237&sa=D&sntz=1&usg=AFQjCNGSCfODvkW3XGZl4PBsMBt8-LIhbA>
>>
>
> Wondering out loud... what makes *dateonly* become True?
> def pretty_dateinfo(date, format=None, *dateonly*=False)
>

The argument isn't used by TicketQuery. The argument is used when the
function is called in history views and the repository.


> I looked at my Admin panel and default date format is ISO8601 and default
> time format is relative.
>
> You could probably write a small plugin to either monkey-patch that method
>> or change the data in IRequestFilter.post_process_request, but it would be
>> a little tricky.
>>
>> There's an open ticket to develop and interface that I think would allow
>> modifying the presentation of query results, but not much movement on
>> implementing it.
>>
>> Or, you could write a report instead and display it with WikiReportMacro:
>> https://trac-hacks.org/wiki/WikiReportMacro
>>
>> You can format the output in SQL to display "by end of ..."
>>
>> - Ryan
>>
>
> This is starting to be a little unmaintainable for me. My original hope
> was for the date "2019/03/29" without anything else attached to it... I do
> like "on 2019/03/29" and "by end of 2019/03/29" and "before 2019/03/29"
> etc. etc. but it seems like a bit of work for me to customize this and/or
> to get the behaviour that the plugin was providing before upgrading.
>
> If there was a way to configure the TracQuery so that the date was not
> annotated that would get me what I need... because I guess what I'm asking
> for is specific to that macro rather than general for all uses of the
> custom field. Alternatively, if there was a trac.ini way to indicate how
> TracQuery should display the custom field that would work for me too. The
> latter would be nice because then I could configure my custom date fields
> to display differently... depending on context. For example, one could be
> "on 2019/03/29" and one could be "before 2019/03/29" and one could be
> simply "2019/03/29" etc. etc.
>
> Maybe something like this:
>
> [ticket-custom]
> time1 = time
> time1.label = Blah (YYYY/MM/DD)
> time1.format = date
> time1.tracqueryformat = just a date ;) perhaps a coffee first?? haha
> time1.value =
> time1.order = 5
>

It would be good if we provided hooks to customize the result of the query,
but adding options that have very limited audience is something we try to
avoid.

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/229b941d-4584-45a7-9869-dae28c73f5c7%40googlegroups.com.

On Tuesday, June 2, 2020 at 3:47:32 PM UTC-4, RjOllos wrote:
>
> On Tuesday, June 2, 2020 at 11:38:30 AM UTC-7, Aikido Guy wrote:
>>
>> On Tuesday, June 2, 2020 at 4:03:12 AM UTC-4, RjOllos wrote:
>>
>>> On Monday, June 1, 2020 at 7:44:04 PM UTC-7, Aikido Guy wrote:
>>>>
>>>> On Monday, June 1, 2020 at 10:40:30 PM UTC-4, Aikido Guy wrote:
>>>>>
>>>>> [ticket-custom]
>>>>> time1 = time
>>>>> time1.format = date
>>>>> time1.label = "Blah (YYYY/MM/DD)
>>>>> time1.value =
>>>>> time1.order = 5
>>>>>
>>>>> I've followed all of your advice and am now left with one small (not
>>>>> urgent) question. In particular, my original TicketQuery now works (yah!);
>>>>> however, instead of having '2018/07/03' shown in my table, I have "
>>>>> *at* 2018/07/03".
>>>>> - Is there a configuration option to control how the time is output?
>>>>> In my case, since there are no hours, minutes or seconds, it could be "*on
>>>>> *2018/07/03" instead?
>>>>> - Or maybe there is some kind of option to control a little more the
>>>>> format of the date being output? i.e. a way to remove the "at"? or to add
>>>>> an "on" etc...
>>>>>
>>>>> As a side thought as I am typing... is the "*at* 2018/07/03"
>>>>> supported across languages?
>>>>>
>>>>
>>>> I realize that this might be a bit of a rabbit hole... because I can
>>>> also imagine using "by end of 2018/07/03"... a lot of duplicated text...
>>>>
>>>
>>> I tested with trunk, but time is also shown for format=date. Did you
>>> find otherwise on 1.4-stable?
>>> https://trac.edgewall.org/ticket/13309
>>>
>>
>> I'm pretty sure I typed the right trac.ini config section... I've double
>> checked and here it is again (only difference is order from what I typed
>> before, and I fixed a typo):
>>
>> [ticket-custom]
>> time1 = time
>> time1.label = Blah (YYYY/MM/DD)
>> time1.format = date
>> time1.value =
>> time1.order = 5
>>
>> Looks like I have a different result than you. I have "*at* 2018/07/03"
>> , "*at* 2019/03/07" etc, with no time values in my custom field column
>> in my TracQuery.
>>
>
> The ISO8601 format setting is the difference. Same result here if using
> ISO8601 format. Looking at the code, it makes sense:
>
> https://trac.edgewall.org/browser/tags/trac-1.4.1/trac/web/chrome.py?marks=1258-1259#L1237
>

Great! Thanks for figuring out what the difference was ;) But "at
2018-07-03" is not compliant with ISO8601... but "2018-07-03" would be
compliant... right?


> In my case, the TracQuery is inside a custom plugin that I built, but I
>> don't think that should make any difference...
>>
>
> Are you constructing a Query object in the custom plugin? Or returning
> markup containing [[TicketQuery(...)]]? Either way, that that should allow
> you to parse and modify the HTML that is generated.
>

I'm returning markup containing [[TicketQuery(...)]]...

More simply, you could modify what is displayed using some custom site
> JavaScript. It should be fairly straightforward to create a selector and
> then modify the content of the span:
>
>
>
> [image: Screen Shot 2020-06-02 at 12.39.13.jpg]
>

Yup... that's a good thought ;)


> My TicketQuery is something like this:
>>
>> [[TicketQuery(order=time1,status,time1!=,desc=0,format=table,col=complete|status|time1|summary)]]
>>
>> - It is ordered by the custom field
>> - If the custom field is missing then tickets should not be displayed
>> - It is using the table output format
>> - The custom field is one of the middle output columns (i.e. it is not
>> the first and not the last column)
>>
>> It is localized. Here is English and French for:
>>> [[TicketQuery(id=102, format=table, col=time1)]]
>>>
>>> [image: Screen Shot 2020-06-02 at 00.50.11.jpg]
>>>
>>>
>>>
>>>
>>>
>>> [image: Screen Shot 2020-06-02 at 00.55.24.jpg]
>>>
>>>
>>>
>>>
>>>
>> Nice ;)
>>
>> The "at .." is prepared by Chrome.pretty_dateinfo:
>>>
>>> https://trac.edgewall.org/browser/tags/trac-1.4.1/trac/web/chrome.py?marks=1258-1263#L1237
>>> <https://www.google.com/url?q=https%3A%2F%2Ftrac.edgewall.org%2Fbrowser%2Ftags%2Ftrac-1.4.1%2Ftrac%2Fweb%2Fchrome.py%3Fmarks%3D1258-1263%23L1237&sa=D&sntz=1&usg=AFQjCNGSCfODvkW3XGZl4PBsMBt8-LIhbA>
>>>
>>
>> Wondering out loud... what makes *dateonly* become True?
>> def pretty_dateinfo(date, format=None, *dateonly*=False)
>>
>
> The argument isn't used by TicketQuery. The argument is used when the
> function is called in history views and the repository.
>

Ok... so there are 2 different ways that dates are displayed... gotcha...

I looked at my Admin panel and default date format is ISO8601 and default
>> time format is relative.
>>
>> You could probably write a small plugin to either monkey-patch that
>>> method or change the data in IRequestFilter.post_process_request, but it
>>> would be a little tricky.
>>>
>>> There's an open ticket to develop and interface that I think would allow
>>> modifying the presentation of query results, but not much movement on
>>> implementing it.
>>>
>>> Or, you could write a report instead and display it with WikiReportMacro:
>>> https://trac-hacks.org/wiki/WikiReportMacro
>>>
>>> You can format the output in SQL to display "by end of ..."
>>>
>>> - Ryan
>>>
>>
>> This is starting to be a little unmaintainable for me. My original hope
>> was for the date "2019/03/29" without anything else attached to it... I do
>> like "on 2019/03/29" and "by end of 2019/03/29" and "before 2019/03/29"
>> etc. etc. but it seems like a bit of work for me to customize this and/or
>> to get the behaviour that the plugin was providing before upgrading.
>>
>> If there was a way to configure the TracQuery so that the date was not
>> annotated that would get me what I need... because I guess what I'm asking
>> for is specific to that macro rather than general for all uses of the
>> custom field. Alternatively, if there was a trac.ini way to indicate how
>> TracQuery should display the custom field that would work for me too. The
>> latter would be nice because then I could configure my custom date fields
>> to display differently... depending on context. For example, one could be
>> "on 2019/03/29" and one could be "before 2019/03/29" and one could be
>> simply "2019/03/29" etc. etc.
>>
>> Maybe something like this:
>>
>> [ticket-custom]
>> time1 = time
>> time1.label = Blah (YYYY/MM/DD)
>> time1.format = date
>> time1.tracqueryformat = just a date ;) perhaps a coffee first?? haha
>> time1.value =
>> time1.order = 5
>>
>
> It would be good if we provided hooks to customize the result of the
> query, but adding options that have very limited audience is something we
> try to avoid.
>

Ok... no hooks ;) But perhaps if I am requesting ISO compliant dates then
an ISO compliant date could be displayed? i.e. no "on", no "at" etc....
just the ISO compliant date for the custom field?

Any chance that I'm able to convince you "This is the Right Thing (tm)" ;)

Kindly,
Aikido Guy

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/b4b38aa0-4c79-4bf8-822f-b3dd47fd7949%40googlegroups.com.

On Tuesday, June 2, 2020 at 1:17:34 PM UTC-7, Aikido Guy wrote:
>
> On Tuesday, June 2, 2020 at 3:47:32 PM UTC-4, RjOllos wrote:
>>
>> On Tuesday, June 2, 2020 at 11:38:30 AM UTC-7, Aikido Guy wrote:
>>>
>>> On Tuesday, June 2, 2020 at 4:03:12 AM UTC-4, RjOllos wrote:
>>>
>>>> On Monday, June 1, 2020 at 7:44:04 PM UTC-7, Aikido Guy wrote:
>>>>>
>>>>> On Monday, June 1, 2020 at 10:40:30 PM UTC-4, Aikido Guy wrote:
>>>>>>
>>>>>> [ticket-custom]
>>>>>> time1 = time
>>>>>> time1.format = date
>>>>>> time1.label = "Blah (YYYY/MM/DD)
>>>>>> time1.value =
>>>>>> time1.order = 5
>>>>>>
>>>>>> I've followed all of your advice and am now left with one small (not
>>>>>> urgent) question. In particular, my original TicketQuery now works (yah!);
>>>>>> however, instead of having '2018/07/03' shown in my table, I have "
>>>>>> *at* 2018/07/03".
>>>>>> - Is there a configuration option to control how the time is output?
>>>>>> In my case, since there are no hours, minutes or seconds, it could be "*on
>>>>>> *2018/07/03" instead?
>>>>>> - Or maybe there is some kind of option to control a little more the
>>>>>> format of the date being output? i.e. a way to remove the "at"? or to add
>>>>>> an "on" etc...
>>>>>>
>>>>>> As a side thought as I am typing... is the "*at* 2018/07/03"
>>>>>> supported across languages?
>>>>>>
>>>>>
>>>>> I realize that this might be a bit of a rabbit hole... because I can
>>>>> also imagine using "by end of 2018/07/03"... a lot of duplicated text...
>>>>>
>>>>
>>>> I tested with trunk, but time is also shown for format=date. Did you
>>>> find otherwise on 1.4-stable?
>>>> https://trac.edgewall.org/ticket/13309
>>>>
>>>
>>> I'm pretty sure I typed the right trac.ini config section... I've double
>>> checked and here it is again (only difference is order from what I typed
>>> before, and I fixed a typo):
>>>
>>> [ticket-custom]
>>> time1 = time
>>> time1.label = Blah (YYYY/MM/DD)
>>> time1.format = date
>>> time1.value =
>>> time1.order = 5
>>>
>>> Looks like I have a different result than you. I have "*at* 2018/07/03"
>>> , "*at* 2019/03/07" etc, with no time values in my custom field column
>>> in my TracQuery.
>>>
>>
>> The ISO8601 format setting is the difference. Same result here if using
>> ISO8601 format. Looking at the code, it makes sense:
>>
>> https://trac.edgewall.org/browser/tags/trac-1.4.1/trac/web/chrome.py?marks=1258-1259#L1237
>>
>
> Great! Thanks for figuring out what the difference was ;) But "at
> 2018-07-03" is not compliant with ISO8601... but "2018-07-03" would be
> compliant... right?
>
>
>> In my case, the TracQuery is inside a custom plugin that I built, but I
>>> don't think that should make any difference...
>>>
>>
>> Are you constructing a Query object in the custom plugin? Or returning
>> markup containing [[TicketQuery(...)]]? Either way, that that should allow
>> you to parse and modify the HTML that is generated.
>>
>
> I'm returning markup containing [[TicketQuery(...)]]...
>
> More simply, you could modify what is displayed using some custom site
>> JavaScript. It should be fairly straightforward to create a selector and
>> then modify the content of the span:
>>
>>
>>
>> [image: Screen Shot 2020-06-02 at 12.39.13.jpg]
>>
>
> Yup... that's a good thought ;)
>
>
>> My TicketQuery is something like this:
>>>
>>> [[TicketQuery(order=time1,status,time1!=,desc=0,format=table,col=complete|status|time1|summary)]]
>>>
>>> - It is ordered by the custom field
>>> - If the custom field is missing then tickets should not be displayed
>>> - It is using the table output format
>>> - The custom field is one of the middle output columns (i.e. it is not
>>> the first and not the last column)
>>>
>>> It is localized. Here is English and French for:
>>>> [[TicketQuery(id=102, format=table, col=time1)]]
>>>>
>>>> [image: Screen Shot 2020-06-02 at 00.50.11.jpg]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> [image: Screen Shot 2020-06-02 at 00.55.24.jpg]
>>>>
>>>>
>>>>
>>>>
>>>>
>>> Nice ;)
>>>
>>> The "at .." is prepared by Chrome.pretty_dateinfo:
>>>>
>>>> https://trac.edgewall.org/browser/tags/trac-1.4.1/trac/web/chrome.py?marks=1258-1263#L1237
>>>> <https://www.google.com/url?q=https%3A%2F%2Ftrac.edgewall.org%2Fbrowser%2Ftags%2Ftrac-1.4.1%2Ftrac%2Fweb%2Fchrome.py%3Fmarks%3D1258-1263%23L1237&sa=D&sntz=1&usg=AFQjCNGSCfODvkW3XGZl4PBsMBt8-LIhbA>
>>>>
>>>
>>> Wondering out loud... what makes *dateonly* become True?
>>> def pretty_dateinfo(date, format=None, *dateonly*=False)
>>>
>>
>> The argument isn't used by TicketQuery. The argument is used when the
>> function is called in history views and the repository.
>>
>
> Ok... so there are 2 different ways that dates are displayed... gotcha...
>
> I looked at my Admin panel and default date format is ISO8601 and default
>>> time format is relative.
>>>
>>> You could probably write a small plugin to either monkey-patch that
>>>> method or change the data in IRequestFilter.post_process_request, but it
>>>> would be a little tricky.
>>>>
>>>> There's an open ticket to develop and interface that I think would
>>>> allow modifying the presentation of query results, but not much movement on
>>>> implementing it.
>>>>
>>>> Or, you could write a report instead and display it with
>>>> WikiReportMacro:
>>>> https://trac-hacks.org/wiki/WikiReportMacro
>>>>
>>>> You can format the output in SQL to display "by end of ..."
>>>>
>>>> - Ryan
>>>>
>>>
>>> This is starting to be a little unmaintainable for me. My original hope
>>> was for the date "2019/03/29" without anything else attached to it... I do
>>> like "on 2019/03/29" and "by end of 2019/03/29" and "before 2019/03/29"
>>> etc. etc. but it seems like a bit of work for me to customize this and/or
>>> to get the behaviour that the plugin was providing before upgrading.
>>>
>>> If there was a way to configure the TracQuery so that the date was not
>>> annotated that would get me what I need... because I guess what I'm asking
>>> for is specific to that macro rather than general for all uses of the
>>> custom field. Alternatively, if there was a trac.ini way to indicate how
>>> TracQuery should display the custom field that would work for me too. The
>>> latter would be nice because then I could configure my custom date fields
>>> to display differently... depending on context. For example, one could be
>>> "on 2019/03/29" and one could be "before 2019/03/29" and one could be
>>> simply "2019/03/29" etc. etc.
>>>
>>> Maybe something like this:
>>>
>>> [ticket-custom]
>>> time1 = time
>>> time1.label = Blah (YYYY/MM/DD)
>>> time1.format = date
>>> time1.tracqueryformat = just a date ;) perhaps a coffee first?? haha
>>> time1.value =
>>> time1.order = 5
>>>
>>
>> It would be good if we provided hooks to customize the result of the
>> query, but adding options that have very limited audience is something we
>> try to avoid.
>>
>
> Ok... no hooks ;) But perhaps if I am requesting ISO compliant dates then
> an ISO compliant date could be displayed? i.e. no "on", no "at" etc....
> just the ISO compliant date for the custom field?
>
> Any chance that I'm able to convince you "This is the Right Thing (tm)" ;)
>
> Kindly,
> Aikido Guy
>

The issue is how the query results template chooses to present the data.
You would like the results presented without any decoration. I don't have a
problem using dateonly=True to avoid the decoration.
https://trac.edgewall.org/ticket/13309#comment:3

I'm not sure when I'll have time to work on #13309. It needs test coverage
for the proposed fixes.

Btw, as an interim solution you could copy
trac/ticket/templates/query_results.html to a global templates directory
and modify with dateonly=True, as shown in #13309. Just be sure to copy and
apply the patch when you upgrade Trac.
https://trac.edgewall.org/wiki/TracIni#GlobalConfiguration

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/f1dedc91-2336-4a7d-9005-b67d75316308%40googlegroups.com.

On Tuesday, June 2, 2020 at 1:41:55 PM UTC-7, RjOllos wrote:

> Btw, as an interim solution you could copy
> trac/ticket/templates/query_results.html to a global templates directory
> and modify with dateonly=True, as shown in #13309. Just be sure to copy and
> apply the patch when you upgrade Trac.
> https://trac.edgewall.org/wiki/TracIni#GlobalConfiguration
>

More details on that here:
https://trac.edgewall.org/wiki/TracUpgrade#CustomizedTemplates

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/7c6be532-f6e3-47f3-a7a8-c60ef1cf9233%40googlegroups.com.

On Tuesday, June 2, 2020 at 4:41:55 PM UTC-4, RjOllos wrote:
>
> On Tuesday, June 2, 2020 at 1:17:34 PM UTC-7, Aikido Guy wrote:
>>
>> On Tuesday, June 2, 2020 at 3:47:32 PM UTC-4, RjOllos wrote:
>>>
>>> On Tuesday, June 2, 2020 at 11:38:30 AM UTC-7, Aikido Guy wrote:
>>>>
>>>> On Tuesday, June 2, 2020 at 4:03:12 AM UTC-4, RjOllos wrote:
>>>>
>>>>> On Monday, June 1, 2020 at 7:44:04 PM UTC-7, Aikido Guy wrote:
>>>>>>
>>>>>> On Monday, June 1, 2020 at 10:40:30 PM UTC-4, Aikido Guy wrote:
>>>>>>>
>>>>>>> [ticket-custom]
>>>>>>> time1 = time
>>>>>>> time1.format = date
>>>>>>> time1.label = "Blah (YYYY/MM/DD)
>>>>>>> time1.value =
>>>>>>> time1.order = 5
>>>>>>>
>>>>>>> I've followed all of your advice and am now left with one small (not
>>>>>>> urgent) question. In particular, my original TicketQuery now works (yah!);
>>>>>>> however, instead of having '2018/07/03' shown in my table, I have "
>>>>>>> *at* 2018/07/03".
>>>>>>> - Is there a configuration option to control how the time is output?
>>>>>>> In my case, since there are no hours, minutes or seconds, it could be "*on
>>>>>>> *2018/07/03" instead?
>>>>>>> - Or maybe there is some kind of option to control a little more the
>>>>>>> format of the date being output? i.e. a way to remove the "at"? or to add
>>>>>>> an "on" etc...
>>>>>>>
>>>>>>> As a side thought as I am typing... is the "*at* 2018/07/03"
>>>>>>> supported across languages?
>>>>>>>
>>>>>>
>>>>>> I realize that this might be a bit of a rabbit hole... because I can
>>>>>> also imagine using "by end of 2018/07/03"... a lot of duplicated text...
>>>>>>
>>>>>
>>>>> I tested with trunk, but time is also shown for format=date. Did you
>>>>> find otherwise on 1.4-stable?
>>>>> https://trac.edgewall.org/ticket/13309
>>>>>
>>>>
>>>> I'm pretty sure I typed the right trac.ini config section... I've
>>>> double checked and here it is again (only difference is order from what I
>>>> typed before, and I fixed a typo):
>>>>
>>>> [ticket-custom]
>>>> time1 = time
>>>> time1.label = Blah (YYYY/MM/DD)
>>>> time1.format = date
>>>> time1.value =
>>>> time1.order = 5
>>>>
>>>> Looks like I have a different result than you. I have "*at*
>>>> 2018/07/03" , "*at* 2019/03/07" etc, with no time values in my custom
>>>> field column in my TracQuery.
>>>>
>>>
>>> The ISO8601 format setting is the difference. Same result here if using
>>> ISO8601 format. Looking at the code, it makes sense:
>>>
>>> https://trac.edgewall.org/browser/tags/trac-1.4.1/trac/web/chrome.py?marks=1258-1259#L1237
>>>
>>
>> Great! Thanks for figuring out what the difference was ;) But "at
>> 2018-07-03" is not compliant with ISO8601... but "2018-07-03" would be
>> compliant... right?
>>
>>
>>> In my case, the TracQuery is inside a custom plugin that I built, but I
>>>> don't think that should make any difference...
>>>>
>>>
>>> Are you constructing a Query object in the custom plugin? Or returning
>>> markup containing [[TicketQuery(...)]]? Either way, that that should allow
>>> you to parse and modify the HTML that is generated.
>>>
>>
>> I'm returning markup containing [[TicketQuery(...)]]...
>>
>> More simply, you could modify what is displayed using some custom site
>>> JavaScript. It should be fairly straightforward to create a selector and
>>> then modify the content of the span:
>>>
>>>
>>>
>>> [image: Screen Shot 2020-06-02 at 12.39.13.jpg]
>>>
>>
>> Yup... that's a good thought ;)
>>
>>
>>> My TicketQuery is something like this:
>>>>
>>>> [[TicketQuery(order=time1,status,time1!=,desc=0,format=table,col=complete|status|time1|summary)]]
>>>>
>>>> - It is ordered by the custom field
>>>> - If the custom field is missing then tickets should not be displayed
>>>> - It is using the table output format
>>>> - The custom field is one of the middle output columns (i.e. it is not
>>>> the first and not the last column)
>>>>
>>>> It is localized. Here is English and French for:
>>>>> [[TicketQuery(id=102, format=table, col=time1)]]
>>>>>
>>>>> [image: Screen Shot 2020-06-02 at 00.50.11.jpg]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> [image: Screen Shot 2020-06-02 at 00.55.24.jpg]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Nice ;)
>>>>
>>>> The "at .." is prepared by Chrome.pretty_dateinfo:
>>>>>
>>>>> https://trac.edgewall.org/browser/tags/trac-1.4.1/trac/web/chrome.py?marks=1258-1263#L1237
>>>>> <https://www.google.com/url?q=https%3A%2F%2Ftrac.edgewall.org%2Fbrowser%2Ftags%2Ftrac-1.4.1%2Ftrac%2Fweb%2Fchrome.py%3Fmarks%3D1258-1263%23L1237&sa=D&sntz=1&usg=AFQjCNGSCfODvkW3XGZl4PBsMBt8-LIhbA>
>>>>>
>>>>
>>>> Wondering out loud... what makes *dateonly* become True?
>>>> def pretty_dateinfo(date, format=None, *dateonly*=False)
>>>>
>>>
>>> The argument isn't used by TicketQuery. The argument is used when the
>>> function is called in history views and the repository.
>>>
>>
>> Ok... so there are 2 different ways that dates are displayed... gotcha...
>>
>> I looked at my Admin panel and default date format is ISO8601 and default
>>>> time format is relative.
>>>>
>>>> You could probably write a small plugin to either monkey-patch that
>>>>> method or change the data in IRequestFilter.post_process_request, but it
>>>>> would be a little tricky.
>>>>>
>>>>> There's an open ticket to develop and interface that I think would
>>>>> allow modifying the presentation of query results, but not much movement on
>>>>> implementing it.
>>>>>
>>>>> Or, you could write a report instead and display it with
>>>>> WikiReportMacro:
>>>>> https://trac-hacks.org/wiki/WikiReportMacro
>>>>>
>>>>> You can format the output in SQL to display "by end of ..."
>>>>>
>>>>> - Ryan
>>>>>
>>>>
>>>> This is starting to be a little unmaintainable for me. My original hope
>>>> was for the date "2019/03/29" without anything else attached to it... I do
>>>> like "on 2019/03/29" and "by end of 2019/03/29" and "before 2019/03/29"
>>>> etc. etc. but it seems like a bit of work for me to customize this and/or
>>>> to get the behaviour that the plugin was providing before upgrading.
>>>>
>>>> If there was a way to configure the TracQuery so that the date was not
>>>> annotated that would get me what I need... because I guess what I'm asking
>>>> for is specific to that macro rather than general for all uses of the
>>>> custom field. Alternatively, if there was a trac.ini way to indicate how
>>>> TracQuery should display the custom field that would work for me too. The
>>>> latter would be nice because then I could configure my custom date fields
>>>> to display differently... depending on context. For example, one could be
>>>> "on 2019/03/29" and one could be "before 2019/03/29" and one could be
>>>> simply "2019/03/29" etc. etc.
>>>>
>>>> Maybe something like this:
>>>>
>>>> [ticket-custom]
>>>> time1 = time
>>>> time1.label = Blah (YYYY/MM/DD)
>>>> time1.format = date
>>>> time1.tracqueryformat = just a date ;) perhaps a coffee first?? haha
>>>> time1.value =
>>>> time1.order = 5
>>>>
>>>
>>> It would be good if we provided hooks to customize the result of the
>>> query, but adding options that have very limited audience is something we
>>> try to avoid.
>>>
>>
>> Ok... no hooks ;) But perhaps if I am requesting ISO compliant dates then
>> an ISO compliant date could be displayed? i.e. no "on", no "at" etc....
>> just the ISO compliant date for the custom field?
>>
>> Any chance that I'm able to convince you "This is the Right Thing (tm)" ;)
>>
>> Kindly,
>> Aikido Guy
>>
>
> The issue is how the query results template chooses to present the data.
> You would like the results presented without any decoration. I don't have a
> problem using dateonly=True to avoid the decoration.
> https://trac.edgewall.org/ticket/13309#comment:3
>
> I'm not sure when I'll have time to work on #13309. It needs test coverage
> for the proposed fixes.
>
> Btw, as an interim solution you could copy
> trac/ticket/templates/query_results.html to a global templates directory
> and modify with dateonly=True, as shown in #13309. Just be sure to copy and
> apply the patch when you upgrade Trac.
> https://trac.edgewall.org/wiki/TracIni#GlobalConfiguration
>

Thank you for creating #13309 and for the tip for the template workaround.
I may try it in the next week or so or may wait for the next Trac release.
Depending on how fast I am ;)
- if I do try it before the next release then I'll certainly report results
back here...

Kindly,
Aikido Guy

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/05d06a04-6dc0-436d-b265-0eb125808b02%40googlegroups.com.

On Tuesday, June 2, 2020 at 6:42:39 PM UTC-7, Aikido Guy wrote:
>
> On Tuesday, June 2, 2020 at 4:41:55 PM UTC-4, RjOllos wrote:
>>
>> On Tuesday, June 2, 2020 at 1:17:34 PM UTC-7, Aikido Guy wrote:
>>>
>>> On Tuesday, June 2, 2020 at 3:47:32 PM UTC-4, RjOllos wrote:
>>>>
>>>> On Tuesday, June 2, 2020 at 11:38:30 AM UTC-7, Aikido Guy wrote:
>>>>>
>>>>> On Tuesday, June 2, 2020 at 4:03:12 AM UTC-4, RjOllos wrote:
>>>>>
>>>>>> On Monday, June 1, 2020 at 7:44:04 PM UTC-7, Aikido Guy wrote:
>>>>>>>
>>>>>>> On Monday, June 1, 2020 at 10:40:30 PM UTC-4, Aikido Guy wrote:
>>>>>>>>
>>>>>>>> [ticket-custom]
>>>>>>>> time1 = time
>>>>>>>> time1.format = date
>>>>>>>> time1.label = "Blah (YYYY/MM/DD)
>>>>>>>> time1.value =
>>>>>>>> time1.order = 5
>>>>>>>>
>>>>>>>> I've followed all of your advice and am now left with one small
>>>>>>>> (not urgent) question. In particular, my original TicketQuery now works
>>>>>>>> (yah!); however, instead of having '2018/07/03' shown in my table, I have "
>>>>>>>> *at* 2018/07/03".
>>>>>>>> - Is there a configuration option to control how the time is
>>>>>>>> output? In my case, since there are no hours, minutes or seconds, it could
>>>>>>>> be "*on *2018/07/03" instead?
>>>>>>>> - Or maybe there is some kind of option to control a little more
>>>>>>>> the format of the date being output? i.e. a way to remove the "at"? or to
>>>>>>>> add an "on" etc...
>>>>>>>>
>>>>>>>> As a side thought as I am typing... is the "*at* 2018/07/03"
>>>>>>>> supported across languages?
>>>>>>>>
>>>>>>>
>>>>>>> I realize that this might be a bit of a rabbit hole... because I can
>>>>>>> also imagine using "by end of 2018/07/03"... a lot of duplicated text...
>>>>>>>
>>>>>>
>>>>>> I tested with trunk, but time is also shown for format=date. Did you
>>>>>> find otherwise on 1.4-stable?
>>>>>> https://trac.edgewall.org/ticket/13309
>>>>>>
>>>>>
>>>>> I'm pretty sure I typed the right trac.ini config section... I've
>>>>> double checked and here it is again (only difference is order from what I
>>>>> typed before, and I fixed a typo):
>>>>>
>>>>> [ticket-custom]
>>>>> time1 = time
>>>>> time1.label = Blah (YYYY/MM/DD)
>>>>> time1.format = date
>>>>> time1.value =
>>>>> time1.order = 5
>>>>>
>>>>> Looks like I have a different result than you. I have "*at*
>>>>> 2018/07/03" , "*at* 2019/03/07" etc, with no time values in my custom
>>>>> field column in my TracQuery.
>>>>>
>>>>
>>>> The ISO8601 format setting is the difference. Same result here if using
>>>> ISO8601 format. Looking at the code, it makes sense:
>>>>
>>>> https://trac.edgewall.org/browser/tags/trac-1.4.1/trac/web/chrome.py?marks=1258-1259#L1237
>>>>
>>>
>>> Great! Thanks for figuring out what the difference was ;) But "at
>>> 2018-07-03" is not compliant with ISO8601... but "2018-07-03" would be
>>> compliant... right?
>>>
>>>
>>>> In my case, the TracQuery is inside a custom plugin that I built, but I
>>>>> don't think that should make any difference...
>>>>>
>>>>
>>>> Are you constructing a Query object in the custom plugin? Or returning
>>>> markup containing [[TicketQuery(...)]]? Either way, that that should allow
>>>> you to parse and modify the HTML that is generated.
>>>>
>>>
>>> I'm returning markup containing [[TicketQuery(...)]]...
>>>
>>> More simply, you could modify what is displayed using some custom site
>>>> JavaScript. It should be fairly straightforward to create a selector and
>>>> then modify the content of the span:
>>>>
>>>>
>>>>
>>>> [image: Screen Shot 2020-06-02 at 12.39.13.jpg]
>>>>
>>>
>>> Yup... that's a good thought ;)
>>>
>>>
>>>> My TicketQuery is something like this:
>>>>>
>>>>> [[TicketQuery(order=time1,status,time1!=,desc=0,format=table,col=complete|status|time1|summary)]]
>>>>>
>>>>> - It is ordered by the custom field
>>>>> - If the custom field is missing then tickets should not be displayed
>>>>> - It is using the table output format
>>>>> - The custom field is one of the middle output columns (i.e. it is not
>>>>> the first and not the last column)
>>>>>
>>>>> It is localized. Here is English and French for:
>>>>>> [[TicketQuery(id=102, format=table, col=time1)]]
>>>>>>
>>>>>> [image: Screen Shot 2020-06-02 at 00.50.11.jpg]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> [image: Screen Shot 2020-06-02 at 00.55.24.jpg]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Nice ;)
>>>>>
>>>>> The "at .." is prepared by Chrome.pretty_dateinfo:
>>>>>>
>>>>>> https://trac.edgewall.org/browser/tags/trac-1.4.1/trac/web/chrome.py?marks=1258-1263#L1237
>>>>>> <https://www.google.com/url?q=https%3A%2F%2Ftrac.edgewall.org%2Fbrowser%2Ftags%2Ftrac-1.4.1%2Ftrac%2Fweb%2Fchrome.py%3Fmarks%3D1258-1263%23L1237&sa=D&sntz=1&usg=AFQjCNGSCfODvkW3XGZl4PBsMBt8-LIhbA>
>>>>>>
>>>>>
>>>>> Wondering out loud... what makes *dateonly* become True?
>>>>> def pretty_dateinfo(date, format=None, *dateonly*=False)
>>>>>
>>>>
>>>> The argument isn't used by TicketQuery. The argument is used when the
>>>> function is called in history views and the repository.
>>>>
>>>
>>> Ok... so there are 2 different ways that dates are displayed... gotcha...
>>>
>>> I looked at my Admin panel and default date format is ISO8601 and
>>>>> default time format is relative.
>>>>>
>>>>> You could probably write a small plugin to either monkey-patch that
>>>>>> method or change the data in IRequestFilter.post_process_request, but it
>>>>>> would be a little tricky.
>>>>>>
>>>>>> There's an open ticket to develop and interface that I think would
>>>>>> allow modifying the presentation of query results, but not much movement on
>>>>>> implementing it.
>>>>>>
>>>>>> Or, you could write a report instead and display it with
>>>>>> WikiReportMacro:
>>>>>> https://trac-hacks.org/wiki/WikiReportMacro
>>>>>>
>>>>>> You can format the output in SQL to display "by end of ..."
>>>>>>
>>>>>> - Ryan
>>>>>>
>>>>>
>>>>> This is starting to be a little unmaintainable for me. My original
>>>>> hope was for the date "2019/03/29" without anything else attached to it...
>>>>> I do like "on 2019/03/29" and "by end of 2019/03/29" and "before
>>>>> 2019/03/29" etc. etc. but it seems like a bit of work for me to customize
>>>>> this and/or to get the behaviour that the plugin was providing before
>>>>> upgrading.
>>>>>
>>>>> If there was a way to configure the TracQuery so that the date was not
>>>>> annotated that would get me what I need... because I guess what I'm asking
>>>>> for is specific to that macro rather than general for all uses of the
>>>>> custom field. Alternatively, if there was a trac.ini way to indicate how
>>>>> TracQuery should display the custom field that would work for me too. The
>>>>> latter would be nice because then I could configure my custom date fields
>>>>> to display differently... depending on context. For example, one could be
>>>>> "on 2019/03/29" and one could be "before 2019/03/29" and one could be
>>>>> simply "2019/03/29" etc. etc.
>>>>>
>>>>> Maybe something like this:
>>>>>
>>>>> [ticket-custom]
>>>>> time1 = time
>>>>> time1.label = Blah (YYYY/MM/DD)
>>>>> time1.format = date
>>>>> time1.tracqueryformat = just a date ;) perhaps a coffee first?? haha
>>>>> time1.value =
>>>>> time1.order = 5
>>>>>
>>>>
>>>> It would be good if we provided hooks to customize the result of the
>>>> query, but adding options that have very limited audience is something we
>>>> try to avoid.
>>>>
>>>
>>> Ok... no hooks ;) But perhaps if I am requesting ISO compliant dates
>>> then an ISO compliant date could be displayed? i.e. no "on", no "at"
>>> etc.... just the ISO compliant date for the custom field?
>>>
>>> Any chance that I'm able to convince you "This is the Right Thing (tm)"
>>> ;)
>>>
>>> Kindly,
>>> Aikido Guy
>>>
>>
>> The issue is how the query results template chooses to present the data.
>> You would like the results presented without any decoration. I don't have a
>> problem using dateonly=True to avoid the decoration.
>> https://trac.edgewall.org/ticket/13309#comment:3
>>
>> I'm not sure when I'll have time to work on #13309. It needs test
>> coverage for the proposed fixes.
>>
>> Btw, as an interim solution you could copy
>> trac/ticket/templates/query_results.html to a global templates directory
>> and modify with dateonly=True, as shown in #13309. Just be sure to copy and
>> apply the patch when you upgrade Trac.
>> https://trac.edgewall.org/wiki/TracIni#GlobalConfiguration
>>
>
> Thank you for creating #13309 and for the tip for the template workaround.
> I may try it in the next week or so or may wait for the next Trac release.
> Depending on how fast I am ;)
> - if I do try it before the next release then I'll certainly report
> results back here...
>
> Kindly,
> Aikido Guy
>

Trac 1.4.2 has been released and should address the issues we discussed in
this thread.

- Ryan

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/e3266170-a5e5-4a77-accb-48967c2db814o%40googlegroups.com.