[PATCH] Impossible to edit or delete a malformed custom query

[dmaraglia at lightfleet.com]

Running trac 10.4 under CentOS 4.5 x86_64

After creating a malformed custom query, it is not possible to delete the report. The normal method for deleting a report is to select the query, waitt for it to finish, and then you are presented with buttons to "Copy", "Edit", and "Delete" report; however, if the query is malformed, you are never presented with these buttons, just the error output.

Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 406, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 237, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.3/site-packages/trac/ticket/report.py", line 88, in process_request
    resp = self._render_view(req, db, id)
  File "/usr/lib/python2.3/site-packages/trac/ticket/report.py", line 346, in _render_view
    value['date'] = format_date(cell)
  File "/usr/lib/python2.3/site-packages/trac/util/datefmt.py", line 68, in format_date
    return format_datetime(t, format, gmt)
  File "/usr/lib/python2.3/site-packages/trac/util/datefmt.py", line 58, in format_datetime
    t = time.localtime(float(t))
ValueError: invalid literal for float(): 3232014-06-15

[Emmanuel Blot]

I though this issue had already been addressed … maybe for 0.11.

[Christian Boos]

A few comments:

1. some errors, like malformed SQL, are correctly trapped and don't prevent the rendering of the page. However, there are simply no row shown and no reporting of the error itself and that should probably be improved.
2. other errors which happen at rendering time only (like trying to convert something as a date when it's not a date) are still shown as internal errors. However, there's a simple enough workaround: simply add ?action=edit to the reporit URL.

Therefore, solving 1. and 2. can be safely post-poned to 0.11.x.

[sid]

#4510 was marked as duplicate of this ticket.

[Christian Boos]

#5635 was closed as duplicate.

See also related #5445 (as we need to trap db errors in a db neutral way).

[Christian Boos]

Well, I meant #6348 instead of #5445.

[kirean@…]

A workaround for this situation is to add ?action=delete to the report url. Like: ​http://myhost.com/trac/report/1?action=delete

[kirean@…]

Replying to kirean@gmail.com:

A workaround for this situation is to add ?action=delete to the report url. Like: ​http://myhost.com/trac/report/1?action=delete

And ?action=edit to be able to edit the report..

[Christian Boos]

#6977 closed as duplicate.

[Christian Boos]

Move high prio tickets from 0.11-retriage to next maintenance release.

[François Terrier <fterrier@…>]

the submitted patch fixes the problem :

• added a new type field in the header variable passed to the template that is supposed to carry the type of the column. Is just set to the same value as col at the moment but maybe it will be used one day (otherwise we can get rid of it)
• for each header, checks if it is a 'reserved' header name (datetime, time, created, modified, …) if it is the case and one of the value is not compatible (not an integer), it just prefixes the type with sql. so it does not get converted in the template, and adds an error message

[Remy Blank]

I would rather add a possibility to edit a report without having to view the report and hence triggering the error. I would suggest we add a column to the list of reports, with links to the ?action=edit pages.

[Christian Boos]

It would be nice to have the link only when one has the REPORT_EDIT permission on the report.

For that, we should be to use a dedicated report_list.html template, instead of continuing to reuse a normal report view for displaying the list of reports, as this "special" report is hard-coded anyway.

[Christian Boos]

… REPORT_MODIFY I meant.

And btw, that's also what #1876 was about. Mark this as duplicate and work on #1876?

[Remy Blank]

Absolutely. Closing as a duplicate of #1876.