Opened 14 years ago
Closed 8 years ago
#7559 closed defect (wontfix)
SQL query messed up
Reported by: | dnedelchev | Owned by: | Ryan J Ollos |
---|---|---|---|
Priority: | high | Component: | BackLinksMacro |
Severity: | normal | Keywords: | |
Cc: | Trac Release: | 0.12 |
Description
If you write the following in a wiki page:
see #1 and #2 and #3, probably #4; maybe #5- and #6 #7:eventually ticket:8, ticket:9 and [ticket:10] ?
then only tickets 2 and 10 would be detected by the macro. The reason is the quiery is only for tickets referred in the following form:
'#3 '
(i.e. a trailing space is mandatory!)'[ticket:3]'
(i.e. a trailing space is mandatory!)
If the trailing space as well as enveloping brackets are just removed, all tickets except ticket 1 are detected. But then references like these:
other_trac:#3
other_trac:ticket:3
will also be detected while they obviously shouldn't be.
(I didn't investigated yet why ticket 1 is handled different - in some cases it's missed when other tickets referenced in the same form are detected normally)
In short: I think the SQL query have to be rewritten from the beginning since I think it should be made much more clean.
I'll try to un-ravel it a bit more if I have time but I'm not too much in that matter and I'm sure someone else can do it much better than me.
(see also #7299)
Attachments (0)
Change History (6)
comment:1 Changed 14 years ago by
comment:2 Changed 12 years ago by
Owner: | changed from David Francos Cuartero to Ryan J Ollos |
---|---|
Status: | new → assigned |
#7299 closed as a duplicate.
comment:3 Changed 12 years ago by
comment:5 Changed 12 years ago by
Component: | TicketBackLinksMacro → BackLinksMacro |
---|
Functionality is being merged into the BackLinksMacro.
comment:6 Changed 11 years ago by
Status: | assigned → new |
---|
comment:7 Changed 8 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Plugin will be rewritten to use TracBackLinkPlugin.
Ticket 1 is not different, my test page also contained reference to ticket 123 etc. and the LIKE operator can not be set precisely... The second condition (NOT LIKE) evaluates true because
#123
is found along the#1
in the same wiki page...I'm not sure the LIKE operator is suitable for the intended purpose. If REGEXP was implemented it would be trivial but it's not (and even worse - not expected to be done soon: trac:#8914).