cannot create new tickets

[izzysoft@…]

I just noticed that somehow I cannot create tickets anymore in my trac installation. I'm not sure when this broke. I upgraded from 0.10 to 0.11stable-r7572 a while ago, and modified the ticket workflow as described.

Now, when I go to create a new ticket, all fields are filled, and I submit the form - I simply see the empty create form again. No data have been committed, no new ticket has been created. If I instead click the preview button, it's exactly the same: The form is emptied, and I get the warning that "Tickets must contain a summary".

I've got no idea what's going on there. Last week I still was able to edit some tickets. Even yesterday I closed some. I only did not create new ones for a while - and now I see I even can't. So only new tickets are affected (just verified again: I can make changes to tickets. And yes, the permission should be there: The user in question has TRAC_ADMIN - but even explicitly granting TICKET_CREATE makes no difference). From the URL I can see that all form details are placed in the GET request - but obviously they are not evaluated then?

Turned the Logging to debug, but couldn't see anything meaningful. Please let me know what data to provide so I can get some help on that - Trac makes not that much sense if I cannot create new tickets…

[Emmanuel Blot]

This looks like an installation/environment issue.

You'll need to describe which kind of Trac installation you've set up, especially the server type, the authentication backend, and the clients you are using to browse the Trac server.

For example, there are known issues with IE and SSPI authentication, such as in #2826

[izzysoft@…]

Trac is set up here with Apache2 and mod_python. Authentication works (otherwise I couldn't edit tickets) and uses .htpasswd. I tried to create a new ticket using Firefox3 and also Konqueror, both without success. You may try yourself at ​http://projects.izzysoft.de/trac/phpdivelog for example.

Note: I just remember it must have worked a few days ago, since I had some spam tickets in there. I manually deleted those tickets from the database using the statements

DELETE FROM attachment WHERE type='ticket' AND id=${TID};
DELETE FROM ticket_custom WHERE ticket=${TID};
DELETE FROM ticket WHERE id=${TID};

where ${TID} represents the ticket ID. Could that have messed up something? I didn't want those tickets to stay even as closed, since the spam would still be spam then. And I found no other way to remove it.

[izzysoft@…]

I just updated 0.11stable from SVN (r7723), and added a few debug log entries into trac/ticket/model.py for the function which should create the ticket ("def insert" at line 158ff). Set the config to enable debug logging, and tried again to create a new ticket. None of my debug log entries showed up. Since the first line comes immediately at its beginning, this lets me assume this function is not even called? I'm not that familiar with the code (and with Python at all), so it's hard for me to figure out where it should be called from, and where it breaks. Missing debug info contributes to the difficulty.

Nevertheless, found some more hints: As reported before, the Form for some reason uses GET instead of POST - and in trac/ticket/web_ui.py the method _do_create is only called for POST (see line 390) - I wonder how that worked before? What is switching this special request to GET? The form itself says POST!

Anyhow, here's some additional debug output:

2008-12-02 17:27:25,245 Trac[init] DEBUG: SELECT value FROM system WHERE name='discussion_version'
2008-12-02 17:27:25,246 Trac[env] WARNING: base_url option not set in configuration, generated links may be incorrect
2008-12-02 17:27:25,246 Trac[main] DEBUG: Dispatching <Request "GET u'/newticket'">
2008-12-02 17:27:25,387 Trac[svn_fs] DEBUG: Subversion bindings imported
2008-12-02 17:27:25,405 Trac[api] DEBUG: action controllers for ticket workflow: ['ConfigurableTicketWorkflow']
2008-12-02 17:27:25,419 Trac[web_ui] DEBUG: Processing new ticket request via GET
2008-12-02 17:27:25,424 Trac[web_ui] DEBUG: - Populating fields
2008-12-02 17:27:25,424 Trac[web_ui] DEBUG: - Validating submitted data
2008-12-02 17:27:25,425 Trac[chrome] DEBUG: Prepare chrome data for request
2008-12-02 17:27:25,480 Trac[web_ui] DEBUG: - Request not for creation, using Preview
2008-12-02 17:27:25,480 Trac[web_ui] DEBUG: - Updating fields for preview
2008-12-02 17:27:25,489 Trac[session] DEBUG: Retrieving session for ID u'izzy'
2008-12-02 17:27:26,915 Trac[web_ui] DEBUG: ticket.html

Easy to see: It starts as "GET", although the HTML source sais

<form action="/trac/phpdivelog/newticket" method="post" id="propertyform">

Besides, this is a form in a form (without explicit method) in a form (with GET); but as said, it worked before.

• "Processing new ticket…": req.method was queried at the beginning of _process_newticket_request, web_ui.py line 373
• "Request not for creation…": means that self._validate_ticket at line 395 failed

Since the hint "Tickets must contain a summary" appears (though summayry as well as comment have been filled), it seems like either all posted data have been lost on the way - or they are not read from the GET parameters.

Any hints how to get it working again? As for the SQL statements (DELETE) mentioned before: You'll find those in model.py, so it is the way Trac would have deleted them - if I had found a button to do so.

[Emmanuel Blot]

It looks like the old Trac Clearsilver templates were used.

Are you sure the old installation files have been removed - before installing the new "major" version of Trac (0.10 → 0.11)?

[Izzysoft@…]

Well, that is some time ago. And it was already working with 0.11 - so why should that suddenly change? Also strange: After upgrading to the latest SVN code, Trac was using the banner, logo and favicons from the egg directory instead of the shared htdocs directory, though I didn't change the config (it still holds the shared path in the inherit block).

Where should I look for those templates? What should be removed and may have been forgotten? I just rawly remember that some of the CS stuff was still needed, e.g. by some plugins as AccountManager and WikiRename. Trac 0.10 was installed as a package (shipped with Ubuntu), and I removed that package and installed 0.11 then. There should be no remains but the personal files.

Btw: Just also checked with Opera under Windows, problem is exactly the same - so it must be on the server side.

[izzysoft@…]

PS: I just ran a locate - couldn't find any *.cs files where they could be used, except for those from the plugins which need them, plus the footer*, header* and macros* files from the current 0.11 trac installation. And of course the egg-cache and egg-tmp directories. What else could be?

PPS: I just checked one more thing again. On November 27th I had those spam postings in some of the environments (that was when I deleted those tickets), so obviously at that time it was still possible to create new tickets. Except for deleting those tickets, I cannot remember any changes since.

[Emmanuel Blot]

Replying to Izzysoft@…:

Well, that is some time ago. And it was already working with 0.11 - so why should that suddenly change?

Maybe the server configuration changed somehow, or you forgot to restart it when you migrated Trac, or … There could be many reasons.
It really looks like an installation issue.

[anonymous]

Replying to eblot:

Maybe the server configuration changed somehow,

Not that I remember. But I'm open to ideas: What should have changed in the server configuration for a thing like that to happen?

or you forgot to restart it when you migrated Trac,

Half a year ago? And it was working a week ago? In that case it would have been broken from the time of the upgrade, which I doubt (how then came the spam tickets in last week?).

or … There could be many reasons.

If I had an idea how to track that down! It's only broken for new tickets to be created - updating existing tickets works fine.

It really looks like an installation issue.

Any idea what to look for - or what to try to track it down? I'm out of ideas. As I posted above, I even added some debug output to the Trac code - which showed that the form data are not recognized anymore. But why, and what to do about, I have no idea. I have already several "trac environments" running with this installation - so starting from the scratch would be hard.

And again: I cannot remember having made any changes except for running those delete statements after the spam tickets have been created. And I'm pretty sure they cannot be the reason - since the other environments show the very same problem.

[izzysoft@…]

I just tried to manipulate the forms in Firefox using the webdeveloper addon, converting all GET to POST - and guess what? That works! Now I cannot expect all users to have this possibility - but at least it brings me closer to the source of evil.

Remains the question what is causing that mess. Must be some form declaration - so I investigated the page source and found:

<form id="search" action="/trac/phpdivelog/search" method="get">
...
</form>
<form id="content" class="ticket">
<form action="/trac/phpdivelog/newticket" method="post" id="propertyform">
...
</form>
</form>

The first one can be ignored for our case - so it must be the second one. Note that it encapsulates the third form (comparing with the source of a new ticket form here, there are only two forms and no encapsulation). Guess that is the source of evil.

Next, I checked my personal "changes" (i.e. site templates). And in fact, I changed something a while ago based on an article found here, to add an prelude to the new ticket:

    <!--! Ticket prelude -->
    <form py:match="div[@id='content' and @class='ticket']" py:attrs="select('@*')">
      <py:if test="req.environ['PATH_INFO'] == '/newticket' and (not 'preview' in req.args)">
        ${select('h1')}
        <div id="newticketguide">
          <p style="margin-bottom:0;"><b>Before reporting a new ticket, please make sure:</b></p>
          <table border="0" align="center" style="margin-top:0;padding-top:0;border-collapse:collapse;"><tr><td style="text-align:left;"><ul>
           <li>to search for <a href="${href('report/1')}">existing tickets</a></li>
           <li>you checked with the latest release (or repository code)</li></ul></td></tr></table>
        </div>
        ${select('form')}
      </py:if>
      <py:if test="req.environ['PATH_INFO'] != '/newticket' or ('preview' in req.args)">
        ${select('*')}
      </py:if>
    </form>

    ${select('*|text()')}

Looks like that may be causing the trouble. I changed this already a while ago - and the only new tickets I remember since are the spammers, but they may have used the form or not, nobody can say. Can anybody tell what's wrong with that code, and how it should look like to work? As I said before, I'm not very familiar with Python, and with Genshi even less…

Thanx in advance!

[izzysoft@…]

Got it! Must be a typo on the TracInterfaceCustomization page. The fragment I posted above must be corrected to:

    <!--! Ticket prelude -->
    <div py:match="div[@id='content' and @class='ticket']" py:attrs="select('@*')">
...
    </div>

    ${select('*|text()')}

Well, trust your brain - right from the beginning I wondered why I shall match the div by addressing the form… Maybe the Wiki should be corrected concerning this?

One more thing learned: The spammers didn't visit the form page. Cannot be, they couldn't send the spam with the broken page ;)

Suggestion: Someone with write access to the wiki please fix the corresponding part at TracInterfaceCustomization (I would do - but I found no way to register), and then this ticket can be closed.

[ebray]

The wiki is already correct. Look closely. You left the /form off the end of the XPath expression in your original version.

[anonymous]

I left it intentionally. I had it in first, but it did not work - the additional hint was not displayed (it looked exactly like without the modification). Without the /form and changed to <div it works for me now as expected.

[Christian Boos]

Problem solved, it seems.