Invalid ticket references must be rendered safely (to allow viewing the rest of the content)

[anonymous]

Also an invalid ticket reference in a wiki page now prevents further editing of that page (while adding or removing a single character is enough to restore access to the page factually without data loss).

Examples:
Try to open the wiki:InterTrac page in a newly created trac environment (#234, see the attached screenshot).
Or tracini/ticket page in the Admin web panel (#4).
The second one is easy to eliminate for the user itself - just creating 4 (even dummy) tickets. But creating 234 or 1234, or arbitrary number of dummy tickets just for viewing a text in a wiki page or in a misspelled ticket-comment is unthinkable.

It's not a rare situation especially in a newly created trac environment and I wonder why there is no ticket for this bug and also why it's not fixed yet (I guess it was probably present for many years!).

The only related ticket I found was #2641 but I think it was solved as a particular case and at a higher level.
This ticket is more general and fixing it could mitigate a range of current and future issues.

---

The solution I propose is invalid tickets to be rendered as text, possibly accompanied with an empty link or with a link to a proper info/resource instead of returning an error which prevents the whole page content from being shown to the user.
Another possibility is a small dedicated warning message box to be safely embedded in the page body at the place where the invalid ticket reference #NNN! is detected.
A warning message could be also shown at the top of the page (in the manner of messages shown after ticket/wiki/configuration/etc. update).

[anonymous]

screenshot

[Remy Blank]

Replying to anonymous:

It's not a rare situation especially in a newly created trac environment and I wonder why there is no ticket for this bug and also why it's not fixed yet (I guess it was probably present for many years!).

Maybe one reason is that we can't reproduce the issue? I have just created a new environment, went to the InterTrac page, and the page displays correctly.

Did you by any chance define a trac: intertrac prefix that points to your own trac?

Could you please check your trac.log and see if you can find the traceback corresponding to the issue (for example, for InterTrac)?

[dnedelchev <dbn@…>]

Thank you for the response, I'll check it today. I thought it was a real bug since I could reproduce it with 100% chance both at our Windows and linux trac installations.
There are no intertrac prefixes defined in my trac environments yet (but I plan doing it in the near future). All happens in a single trac environment and concerns local environment resources… or maybe I didn't understand the question?

[dnedelchev <dbn@…>]

I've attached a log excerpt. There are no errors, just an HTTP:404 trac warning…
(I do these test on my Windows experimental environment) This was the content of my test-page:

in this trac environment 
#127 exist 
#128 not yet 

I've added an intertrac section in my trac.ini:

[intertrac]
# -- Example of setting up an alias:
t = trac
pr = proba
tst = test
# -- Link to an external Trac:
trac.title = Edgewall's Trac for Trac
trac.url = http://trac.edgewall.org
proba.title = This Local Trac Test Environment
proba.url = http://localhost:81/proba
test.title = Another Local Trac Test Environment
test.url = http://localhost:81/test

When I wrote proba:#128 in a wiki page, all went normal. No errors, no warnings.
But when I wrote #128, the error occurred again and again with no exception.
Off course I could still diff the page revision and retrieve my data if I need it, then delete the revision and proceed again with edit. But that's not an option for the pages outside the wiki (in admin web panel etc.)

If you need more information or tests, I'll try to provide them.

P.S. Personally I can live with this problem and I just wanted to help you improve Trac.

[dnedelchev <dbn@…>]

installation details

[dnedelchev <dbn@…>]

Ooops! That's not a Trac issue[[BR]] I've just located it's caused by SensitiveTicketsPlugin[[BR]]

I'm closing this issue as invalid since it's not related to Trac itself.

[dnedelchev <dbn@…>]

Just to mention. It's already fixed there: ​th:#7082, ​th:#5308

I've upgraded my plugin installation and it's OK already.