TracError: The Trac Environment needs to be upgraded.

[Hegmartin]

Hi,

In the TracAdmin, I created a new custom field named "Date de répection" with a default JJ/MM/AAAA HH:MM:SS.

After the validation the server display : Trac Error

TracError: The Trac Environment needs to be upgraded.

Run "trac-admin /var/lib/trac/XXXXX upgrade" I can't upgrade the server but, can I delete the new custom field in the Database and where?

Thank you very much. Hervé

[Remy Blank]

Custom fields are defined in trac.ini, so you could try removing it there. OTOH, I don't see how a "bad" custom field could produce such a symptom. Could you please set the version field to your Trac version, and give us some more information about your configuration: OS, web server, database backend, module versions, …

If you were able to add it in the admin panel, you have been using a plugin, as Trac core doesn't have the functionality to add custom fields through the web interface. Please also try disabling all your plugins and add them one by one until the issue pops up again. That should allow isolating the offending plugin.

Come to think of that, what might have happened is that the plugin allowing edition of custom fields has triggered an environment reload, which could have activated a plugin that wasn't active before or that was upgraded, and requires a database upgrade. You may want to try the database upgrade anyway, by running the suggested command.

[Christian Boos]

new custom field named "Date de répection" with a default JJ/MM/AAAA HH:MM:SS.

The following worked for me:

repection = text
repection.label = Date de répection
repection.value = JJ/MM/AAAA HH:MM:SS

But the following didn't:

répection = text
répection.label = Date de répection
répection.value = JJ/MM/AAAA HH:MM:SS

No errors, but nothing visible either.

Turned out this was a nasty problem with the locale and its interaction with the lower() call on the key, done in ConfigParser.

Normally we have an 'é' stored as UTF-8 in trac.ini ('\xc3\xa9'), and we should be able to convert that back to u'\xe9', even if there's a call to lower() on the utf-8 sequence (as the ConfigParser does, so nothing we can avoid):

>>> '\xc3\xa9'.lower() == '\xc3\xa9'
True
>>> import locale
>>> locale.getlocale()
(None, None)

But if we set the locale, as we do in trunk/trac/web/main.py@8720#L366​:

>>> locale.setlocale(locale.LC_ALL, '')
'English_United States.1252'
>>> 'r\xc3\xa9pection' == 'r\xc3\xa9pection'.lower()
False
>>> 'r\xc3\xa9pection'.lower()
'r\xe3\xa9pection'

And '\xe3\xa9' is not a valid UTF-8 sequence, so to_unicode() reverts to latin1 and we end up with the u'r\xe3\xa9pection' value. From that point, we get back to the ConfigParser with a completely different key:

>>> u'r\xc3\xa9pection'.encode('utf-8')
'r\xc3\x83\xc2\xa9pection'
>>> u'r\xc3\xa9pection'.encode('utf-8').lower()
'r\xe3\x83\xe2\xa9pection'

So, worksforme for the original problem, and the locale issue discussed above can be fixed by getting rid of the setlocale call, see #2182.