﻿ticket	summary	type	release	owner	status	created	modified	_description	_reporter
13847	"Exception ""Invalid query constraint value"""	defect	1.4		new	2020-07-10T21:29:28+02:00	2020-11-02T23:43:13+01:00	"I am upgrading my Trac server from 0.12 to the latest, 1.4.2.  I have used WikiCalendar for a long time, and now apparently WikiTicketCalendar comes with it.  I tried using it, but there was a problem.  Note: The Trac instance is a new scratch environment with a couple test tickets and such.

FYI, I am using ""trunk"" of WikiCalendar as of today.

Attempting one of the example invocations:

{{{
[[WikiTicketCalendar(*,*,true,/Meeting-%Y-%m-%d)]]
}}}

... I get an exception:

{{{
QueryValueError: Invalid query constraint value
}}}

I'm not adept enough at Trac plugin development to fully understand what might actually be going wrong, but in a small amount of debugging it seems that at least some query passes succeed, and they appear to have similar (or the same) query string ...

As a work-around, I caught the exception.  The calendar appears and the day with a log entry (I added one with the WikiCalendar to test it) is red, as I would expect.  I'm not sure if other features of WikiTicketCalendar are being lost, since I'm really not familiar with it yet.

Here is the work-around I placed in ticket.py in order to make it (appear to) work:

{{{#!python
        try:
            result = query.execute(req)
        except:
            result = []
}}}

"	anonymous
8295	Relative month/year values, multiple navigation-synced instances on same page	enhancement	0.11		new	2010-12-10T04:23:32+01:00	2020-05-01T06:51:13+02:00	"Requesting the template month and year values support input relative to the current date.  For example, 1 would display next month while -1 would display last month.  Perhaps just adding a keyword to set date input to relative relative dates would suffice?

Thank you for your consideration."	trac-hacks-tickets@…
10987	Ability to display tickets based on ticket's changetime	enhancement	0.11		new	2013-03-29T17:55:10+01:00	2016-12-02T23:51:54+01:00	"It is very useful plug-in. Thank you.

One feature that we would like to be added is the following.
We would like to have a calender view of closed tickets on days when they have been closed as opposed to days when they have been opened/created.

Can you provide an option to select ""time"" or ""changetime"" or both to be tied to the calendar?"	gribovm@…
11656	Datetime calculation breaks calendar at last day(s)-of-month	defect	0.11		new	2014-03-31T21:07:15+02:00	2020-05-01T06:51:13+02:00	"Today, 31-Mar-2014, some colleagues of mine reported a broken wiki calendar:

{{{#!python
2014-03-31 09:41:52,378 Trac[formatter] ERROR: Macro WikiTicketCalendar(None) failed: 
Traceback (most recent call last):
  File ""/local/lib/python2.7/site-packages/Trac-1.1.1dev_r11359-py2.7.egg/trac/wiki/formatter.py"", line 765, in _macro_formatter
    return macro.ensure_inline(macro.process(args))
  File ""/local/lib/python2.7/site-packages/Trac-1.1.1dev_r11359-py2.7.egg/trac/wiki/formatter.py"", line 356, in process
    text = self.processor(text)
  File ""/local/lib/python2.7/site-packages/Trac-1.1.1dev_r11359-py2.7.egg/trac/wiki/formatter.py"", line 343, in _macro_processor
    text)
  File ""build/bdist.linux-i686/egg/wikicalendar/macros.py"", line 402, in expand_macro
    today = now.replace(month=month)
ValueError: day is out of range for month
}}}

In general it happens, when you jump to months with less days then your current day-of-month. February is broken at any 30. and 31. of all other months, and in most years even on each 29th day-of-month."	Steffen Hoffmann
12133	WikiCalendarMacros uses undefined function format_datetime if babel library is not importable	defect			new	2015-01-07T17:14:13+01:00	2016-12-02T23:51:54+01:00	"There is some fallback code in source:wikicalendarmacro/trunk/wikicalendar/macros.py@13798 

{{{
#!python
has_babel = True
try:
    from babel import Locale, UnknownLocaleError
    from babel.core import LOCALE_ALIASES
    from babel.dates import format_datetime, get_day_names
except ImportError:
    has_babel = False
    def get_day_names(*args):
        """"""Cheap replacement for the identically named Babel function.""""""
        names = dict()
        for day in range(0, 7):
            dt = datetime(2001, 1, day + 1)
            names[day] = dt.strftime('%a')[:2]
        return names
}}}

but this is incomplete, as no alternative for `format_datetime()` is provided, and `format_datetime()` is called in the implementation.

I'll attach a patch which shows how we resolved this for our own project.
"	nick.piper@…
12605	When used on a wiki page that matches the format string, set current day	enhancement			new	2015-12-08T11:56:26+01:00	2017-03-27T06:46:00+02:00	"Here's a small enhancement patch. It adds one automatic (no configuration needed) feature:

When the macro is used on one of the calendar's by-date subpages, and the page was not reached by navigation (today not yet determined), the patch sets the current day to the subpages date itself.
"	Patrick Schaaf
14132	Patch to allow WikiCalendarMacro to work with Trac 1.6, plus other stuff	enhancement		Ryan J Ollos	accepted	2022-04-09T00:00:16+02:00	2022-04-09T05:48:21+02:00	"I'm attaching a patch to allow running with Trac 1.5.4

Beware that some changes are related to #13847, for which I never got back to Ryan.  (sorry)  Therefore, this patch includes the infamous `daystr=('..').join`, which didn't work for him.

I also noticed this year that the month when daylight savings time happened, the days were shifted on the calendar.  For example, Tuesday items appeared under Wednesday.  So I modified it to make some of the calculations use noon instead of midnight, which solved the problem.  I'll admit it's not exactly pretty, but it worked.

I also incidentally used this plugin on a test system with Babel installed, which I don't usually use.  That also caused a problem with shifting days on the calendar, and I noticed that the Babel weekday list was probably ordered differently than the code assumed.  So there is one line in a conditional that seemed to fix that problem as well.

Now that I'm using WSL, I think I understand what you're asking for regarding the locale.  I'm using Ubuntu 22.4LTS as my test for Python 3 and Trac 1.5.4.

{{{
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE=""C.UTF-8""
LC_NUMERIC=""C.UTF-8""
LC_TIME=""C.UTF-8""
LC_COLLATE=""C.UTF-8""
LC_MONETARY=""C.UTF-8""
LC_MESSAGES=""C.UTF-8""
LC_PAPER=""C.UTF-8""
LC_NAME=""C.UTF-8""
LC_ADDRESS=""C.UTF-8""
LC_TELEPHONE=""C.UTF-8""
LC_MEASUREMENT=""C.UTF-8""
LC_IDENTIFICATION=""C.UTF-8""
LC_ALL=
}}}

I will also attach a Python 3 update to Blog.py that I use in conjunction with this macro.
"	Dan
