Cannot submit ticket in Mylyn

[wrobel@…]

Error when converting value "true" to int.

It seems that Mylyn Trac connector sends true for boolean fields.

[wrobel@…]

Now my Trac is completely broken! How can I delete this broken ticket if most trac pages broke!

Oops…
Trac detected an internal error:

ValueError: invalid literal for int() with base 10: 'true'

This is probably a local installation issue.
Found a bug in Trac?

If you think this should work and you can reproduce the problem, you should consider creating a bug report.

Note that the sensitivetickets plugin seems to be involved. Please report this issue to the plugin maintainer.

Before you do that, though, please first try searching for similar issues, as it is quite likely that this problem has been reported before. For questions about installation and configuration of Trac or its plugins, please try the mailing list instead of creating a ticket.

Otherwise, please a new bug report describing the problem and explain how to reproduce it.
Python traceback
Most recent call last:

    File "/usr/share/python2.6/site-packages/trac/web/main.py", line 511, in _dispatch_request
    File "/usr/share/python2.6/site-packages/trac/web/main.py", line 237, in dispatch
    File "/usr/share/python2.6/site-packages/trac/ticket/report.py", line 118, in process_request
    File "/usr/share/python2.6/site-packages/trac/ticket/report.py", line 522, in _render_view
    File "/usr/share/python2.6/site-packages/trac/perm.py", line 553, in has_permission
    File "/usr/share/python2.6/site-packages/trac/perm.py", line 567, in _has_permission
    File "/usr/share/python2.6/site-packages/trac/perm.py", line 454, in check_permission
    File "build/bdist.linux-i686/egg/sensitivetickets/sensitivetickets.py", line 55, in check_permission

System information:

User Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Trac 	0.12.2
Babel 	0.9.5
CustomFieldAdmin 	0.2.5
Genshi 	0.6
pysqlite 	2.6.0
Python 	2.6.2 (r262:71600, May 3 2009, 15:02:15) [GCC 4.3.3 20090211 (release)]
RPC 	1.1.2-r9913
setuptools 	0.6c11
SQLite 	3.7.2
jQuery	1.4.2
Enabled plugins:
BlackMagicTicketTweaks 	0.12r1 	/usr/share/trac/plugins/BlackMagicTicketTweaks-0.12r1-py2.6.egg
nevernotifyupdaterplugin 	0.0.9 	/usr/share/python2.6/site-packages/nevernotifyupdaterplugin-0.0.9-py2.6.egg
sensitivetickets 	0.11r1 	/usr/share/trac/plugins/sensitivetickets-0.11r1-py2.6.egg
TicketImport 	0.8 	/usr/share/python2.6/site-packages/TicketImport-0.8-py2.6.egg
TicketSidebarProvider 	0.0 	/usr/share/trac/plugins/TicketSidebarProvider-0.0-py2.6.egg
TracAccountManager 	0.3dev-r9929 	/usr/share/python2.6/site-packages/TracAccountManager-0.3dev_r9929-py2.6.egg
Tracchildtickets 	2.4.0-BETA 	/usr/share/python2.6/site-packages/Tracchildtickets-2.4.0_BETA-py2.6.egg
TracCondFields 	2.0 	/usr/share/trac/plugins/TracCondFields-2.0-py2.6.egg
TracCustomFieldAdmin 	0.2.5 	/usr/share/python2.6/site-packages/TracCustomFieldAdmin-0.2.5-py2.6.egg
TracDiscussion 	0.8-r9877 	/usr/share/trac/plugins/TracDiscussion-0.8_r9877-py2.6.egg
TracMasterTickets 	3.0.2 	/usr/share/trac/plugins/TracMasterTickets-3.0.2-py2.6.egg
TracXMLRPC 	1.1.2-r9913 	/usr/share/python2.6/site-packages/TracXMLRPC-1.1.2_r9913-py2.6.egg

[Steffen Hoffmann]

Sure, this plugin could handle this values more gracefully, even entirely switch from 0/1 to string representation of True/False (watch for backwards-compatibility then!).

But wouldn't it be more sensible to force MylynTracConnector to write values expected by this plugin to the Trac db in the first place? If you agree, I'd still recommend to improve this plugin towards recognition of a number of different representations of binary values before, and to forward this issue to MylynTracConnector afterwards.

[Daniel Kahn Gillmor]

this is now addressed by r11289. I would happily forward this to the MylynTracConnector, but its bugs are apparently supposed to be reported at ​the eclipse bug tracker, which i don't have a login for (and can't actually figure out how to get a login for).

So i'm marking this ticket fixed.

wrobel@…, if you have a login with the eclipse bugtracker, could you follow up there about the connector and report back here with the new bug number so that other people who may have stumbled into this issue will know where else to follow up?

[Steffen Hoffmann]

Cool. +1 for using the Trac core native function as_bool, although it's a TRac 0.12 feature, or 0.11.6 to be correct.

These days I'm already at 0.13dev-r10883, nevertheless I care for Trac support from 0.11 onwards for as many plugins as possible. So would you mind adding a fallback to remove the limitation to Trac >= 0.11.6 for this plugin?

[Daniel Kahn Gillmor]

0.11.7 is the recommended version for trac 0.11 (and 0.11 itself isn't recommended for new installs). If a trac admin cannot upgrade their trac instance to 0.11.7, i would suggest that they don't upgrade their SensitiveTicketsPlugin either.

Basically, i'm fine with requiring trac >= 0.11.6 for this, and i'd rather not carry an unneeded fallback mechanism.

Do you know if there's a way to indicate the dependency explicitly in the plugin?

[Ryan J Ollos]

Replying to dkg:

Basically, i'm fine with requiring trac >= 0.11.6 for this, and i'd rather not carry an unneeded fallback mechanism.

Do you know if there's a way to indicate the dependency explicitly in the plugin?

For some hints, you'll want to read the discussion in #9800 (and ​comment:4 in particular), but for whatever it is worth, +1 for supporting back to 0.11. It is really not that much trouble and usually only amounts to a few lines of code. I just do dev work on 0.11 and then test in 0.13dev (which was a practice I picked up at hasienda's suggestion) and it doesn't really cause any issues. There is a small group of us at least that considers this a best practice.

[Daniel Kahn Gillmor]

Thanks for the pointers to the version-checking, rjollos. I've incorporated osimons check as of r11293.

Can you explain why it's worth supporting 0.11.0 when that version of core doesn't seem to be supported upstream any more either? Are there important installations out there that can't or won't upgrade to the latest point release in the 0.11 line for some reason?

[Daniel Kahn Gillmor]

gah, i'm not sure how i switched the component by accident back in 3, but i'm fixing it now.

[Ryan J Ollos]

Replying to dkg:

Can you explain why it's worth supporting 0.11.0 when that version of core doesn't seem to be supported upstream any more either? Are there important installations out there that can't or won't upgrade to the latest point release in the 0.11 line for some reason?

There seem to be users that can't upgrade, perhaps in a corporate or regulated environments, or in companies that have particular IT policies. There are also users that install Trac from their package manager and have an older OS. I'm even more sensitive of the Python 2.4 issue than the Trac version issue, since Red Hat EL 5 is widely used and still running Python 2.4.

Sadly enough, from reviewing the Trac RSS timeline feed almost daily for a couple of years, there even seem to a significant number of users on 0.10.x (for example #9836 was opened today).

The decision to support 0.11+ rather than 0.11.4+ or some other arbitrary choice is somewhat subjective. However, I think the choice for 0.11 is made with the aim of supporting and building the Trac community as much as possible. The other obvious choice would be to support 0.11.7 and 0.12+, but by supporting 0.11+ we'll gain a few more users that can't upgrade, possibly get them to contribute some patches and it isn't much more effort on the developer's end.

So, it's definitely up to individual developers on what they choose to support, but we are talking about writing a best practices guide to plugin development and capturing the consensus of developers at to what the best practices are, and maybe the 0.11+ support recommendation makes it in there, or maybe not. From my point of view, a really good idea that I think hasienda originally proposed and that we've discussed quite a bit lately, is to add a trac-compatibility class to trac-hacks, which developers can include in their source. We'd copy functions such as as_bool and javascript_quote (added in 0.11.3) in that class, and then developers could just use:

from trac_11_compatibility import javascript_quote

and then trac-11-compatibility would try to import from trac.util.text import javascript_quote and fallback to the copy it has.

Anyway, I'd just like to emphasize that these are just preferences and options, and I'm not trying to force anything just because it is my preferred best practice. It's up to individual developers as to what they choose to support.

[Daniel Kahn Gillmor]

Thans for the discussion, rjollos. I think i'm still unconvinced on the 0.11 front, mainly because the boundaries seem small:

for users forced by IT policies to avoid upgrades, they won't be able to upgrade sensitivetickets anyway to get the changes that we're introducing that rely on as_bool.

my usual metric for old OSes is debian oldstable (currently lenny), which is now ​out of security support. but even lenny has ​0.11.7 available from lenny-backports; if you're running webapps from debian lenny without using backports, i'd be quite surprised.

I suspect that users who need to be able to enforce some level of privacy would be helped more by upgrading an out-of-date (and probably security-vulnerable) instance of trac than they would by installing sensitivetickets anyway, so i'd like to encourage that from a security perspective.

So i think i'm currently settling on supporting 0.11.6+ for sensitivetickets for now, unless other arguments come forward. I do appreciate the discussion, though!

[Steffen Hoffmann]

Clearly you assume, that Trac installation/upgrade and plugin installation/upgrade are roughly the same thing, while I think they are considerably different. I spoke to a number of users and Trac admins, who could opt for specific plugins or even do changes on their own, while the Trac version was fixes like was the Python version of the system in question. This could happen due to various reasons. Inflexible hosters, policy to stick with some OS due to missing upgrade path or licensing issues for some other software, long-term lack of site administration capacity/capability,...

Regarding OS metrics, my own metric has been Debian too, but got brutally pushed back by !RedHat5. Ryan already mentioned most of the arguments I used to convince him about my idea of most sensible backwards-compatibility.

I'm still fine with your decision. Put it up-front in the plugin wiki documentation. And sure you can add a line to your setup.py like so:

setup(
    ...,
    install_requires = ['Genshi >= 0.5', 'Trac >= 0.11.6'],
    ...,
)

Additionally please note, that you could avoid hand-editing tickets with appropriate references to changesets using the ticket-commit-update, where some signal words will trigger a ticket comment action:

• closes #<ticket_nr> --> ticket will receive comment and get closed as fixed,
• refs #<ticket_nr> --> ticket will just receive a comment

There are more valid signal words, anyway that's just meant as a quick-starter, if you're really not aware of this by now.