Closed
Bug 191362
(bz-linkification)
Opened 23 years ago
Closed 13 years ago
Implement custom autolinkification rules
Categories
(Bugzilla :: Bugzilla-General, enhancement, P1)
Bugzilla
Bugzilla-General
Tracking
()
RESOLVED
FIXED
Bugzilla 3.6
People
(Reporter: ceder, Assigned: mkanat)
References
Details
(Whiteboard: [Fixed by blocker])
Attachments
(1 file, 1 obsolete file)
|
999 bytes,
text/plain
|
Details |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
I would like to write "RT 4711" in a comment of a bug, and have Bugzilla
transform it to a link to http://rt.example.com/Ticket/Display.html?id=4711.
(We use a private installation of Bugzilla to track development work, and
RT to track support requests. Sometimes, a support request turns into
development work, and when that happens it would be nice to be able to
refer to the original support request. I expect other sites have similar
needs.)
As a Bugzilla administrator, I would like to have a table where I could
add transformations like the example above. The table would have two
columns: PATTERN and REPLACEMENT. PATTERN would be a regular expression
to look for in the text. If any match is found, it would be enclosed
in <a href="REPLACEMENT">...</a>. Inside REPLACEMENT, you would be able
to reference groups in the match in the usual way via \1, \2 et c.
Example: to get the specific link I want, I would enter "RT\s*(\d+)" as
PATTERN, and "http://rt.example.com/Ticket/Display.html?id=\1" as
REPLACEMENT.
I could edit quoteUrls in globals.pl, but a more generic mechanism would
be easier to use.
Reproducible: Always
Steps to Reproduce:
Comment 2•23 years ago
|
||
My initial thought was "custom site-specific hack," but upon actually reading
the entire comment 0, I agree w/Dave... this sounds really cool. It would even
be helpful to those people who wanna call stuff issues instead of bugs.
Comment 3•23 years ago
|
||
Welllll. The problem is that you can't actually do this. Look at the code in
quoteUrl, which I rewrote some months ago.
Order is important there, and its done that way to avoid having to replace stuff
with placeholders - we can just keep dong /g replacements for almost everything.
This gave a massivly big speedup to the quoteurls timing, and so I'd rather not
regress that. See bug 151871 for the gory details
It may be possible to do this, but you'd have to apply some fairly arbitrary
restrictions about the search patterns. (The major problem being interaction
with other stuff - having a search or replament string containing 'bug' or
'attachment' would cause problems). You also can't have \0, although thats less
of an issue
Comment 4•23 years ago
|
||
Well, we could do it, but we'd have to put warnings on the page about possible
performance decreases if the restrictions where broken, or something. For small
installations, quoteUrls being inefficient isn't a massive deal. We just want to
make it so that b.m.o.'s performance does not regress unless they choose to
regress it by setting up a rule, in full knowledge of what they are doing.
Gerv
Comment 5•23 years ago
|
||
gerv: You missed the point. In order to allow this, we would have to change the
algorithm, thus decreasing performance, even if the option wasn't used.
Or maybe it is possible, for most cases. We could do a subst directly after the
urls are taken out and stuff is htmlquoted. Hmm.
| Reporter | ||
Comment 6•23 years ago
|
||
Would it help the performance issue if all custom links had a common format?
The format could be someting like
\[\[([a-zA-Z0-9])+\s([^]]+)\]\]
where the first group gives the site-specific link scheme, and the second
group is data for the scheme. In my original example, I would have to write
"[[RT 4711]]" instead of "RT 4711". Only three open bugs on bugzilla.mozilla.org
has comment that match this syntax.
Pros: this would be easy to configure. Just specify the site-specific code
("RT" in my example) and the URL, with a "*" (or "\2" or whatever) where
the argument should be substituted
("http://rt.example.com/Ticket/Display.html?id=*" in my example). By using
a fixed syntax, you might get less false matches.
Cons: not as flexible as my initial example: if you want to link to a
system that takes two or more arguments, this won't work. The
"[[token arg]]" syntax is slightly harder to write, and some might think
it looks ugly.
(I was going to propose a "[token arg]" syntax instead of "[[token arg]]",
but there are currently around 1400 open bugs that matches the "[token arg]"
syntax.)
Comment 7•21 years ago
|
||
Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist. This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it. If you
are dealing with this bug, please assign it to yourself.
Assignee: justdave → general
QA Contact: mattyt-bugzilla → default-qa
Comment 8•20 years ago
|
||
*** Bug 292585 has been marked as a duplicate of this bug. ***
Comment 9•20 years ago
|
||
Attachment is easy-to-use for additional, disable, etc.
t -> t transform is to avoid conflict with default comment link.
this may cause problem to old browsers that don't recognize entity.
comment link happens at global.pl about line 910-
addition to existense file is:
global.pl: something like this
require 'ext_link.pl'; $text=&ext_link($text);
I don't figure out where I should put variable but this will be done without
editing global.pl later by using some variable (if defined...)
Comment 10•20 years ago
|
||
Comment on attachment 182597 [details]
sample replacing routine
ugh, this only work this form
bug-org xyz comment abc
Comment 11•20 years ago
|
||
do s/t/t/g; after processing default comment link (in global.pl)
and problem I mentioned(#8) will gone.
(without modify existense routine)
Attachment #182597 -
Attachment is obsolete: true
Comment 12•20 years ago
|
||
*** Bug 276455 has been marked as a duplicate of this bug. ***
| Assignee | ||
Comment 13•20 years ago
|
||
See bug 326971 for my suggested implementation. I can work out a way to make the implementation fast. The "bug X comment Y" stuff will stay hardcoded.
Assignee: general → mkanat
Comment 14•19 years ago
|
||
*** Bug 356664 has been marked as a duplicate of this bug. ***
| Assignee | ||
Updated•19 years ago
|
Alias: bz-linkification
Priority: -- → P1
Updated•16 years ago
|
Summary: custom link rules, similar to "bug X" → Implement custom autolinkification rules
| Assignee | ||
Updated•15 years ago
|
Assignee: mkanat → general
Comment 17•15 years ago
|
||
In localized Bugzilla 3.6 autolinkification works just for terms.bug, which is defined by default in template.pm. Unfortunately in Polish we have the following bug-words for terms.bug (singular): blad, bledu, bledowi, bledem, bledzie.
The same is for attachment and comment. Unfortunately linking of attachments with details link or comments is not working out-of-the-box, same as bug x comment y.
Could those be changed to terms.comment, terms.attachment and pointer to all terms.bug used? This way we could have full localization where users of Bugzilla in language other than English would get clickable links in their comments, without the need of editing template.pm files by Bugzilla administrator.
Comment 18•15 years ago
|
||
hakon: the "terms.bug" system is not intended for localization - it's for English-speaking Bugzillas which have a different word for "bug". If you are localizing Bugzilla, then you probably need to rip that out and replace it with something appropriate to your language.
Gerv
Comment 19•15 years ago
|
||
(In reply to comment #18)
> hakon: the "terms.bug" system is not intended for localization - it's for
> English-speaking Bugzillas which have a different word for "bug". If you are
> localizing Bugzilla, then you probably need to rip that out and replace it with
> something appropriate to your language.
Every localization project (Russian, German, French) do it this way, you know...
Comment 20•15 years ago
|
||
(In reply to comment #19)
> Every localization project (Russian, German, French) do it this way, you
> know...
Not German, no. The German localizaton gives up on this. It simply uses "bug" and "comment" so that standard autolinkification works.
That's because the German localization expects Bugzillas to be multi-lingual; it can't flatly replace the autolinkification code.
Comment 21•15 years ago
|
||
(In reply to comment #20)
> Not German, no. The German localizaton gives up on this. It simply uses "bug"
> and "comment" so that standard autolinkification works.
So I will correct myself - German doesn't :). In the case of comments written in German, you are out of luck and you loose the autolinkification for the German user (when Anhang and Kommentar words are used), also "Anhang x angelegt" is not clickable and without [details] link, which is a nuisance when you have to edit specific attachment in a long thread.
Adding $attachment_word, $comment_word with their translations defined in $terms.comment, $terms.attachment give me localized clickable links in non-English interfaces. I also can define my terms.bug as błąd/defekt/zgłoszenie/usterka/whatever and get those linked perfectly (but only this one form).
Of course when I switch to Polish interface only words written in the language of my choice (in this case błąd/załącznik/komentarz) are clickable links, but for me it is obvious (not a big problem if you don't have installation with multi-language comments).
So, to regain a Bugzilla build-in feature using Polish interface, I have to hack the template.pm file. I don't want to do this.
(If all this can be done just in tmpl files - give me a hint or two :).)
> That's because the German localization expects Bugzillas to be multi-lingual;
> it can't flatly replace the autolinkification code.
You mean multi-lingual interface for English content only? All Bugzilla features just for English users? Hack the code for other languages? I don't like this and that's what my comments are all about...
Comment 22•15 years ago
|
||
At the moment, your only choice is to hack Template.pm.
Basically, what we want to do is linkify all languages. We're talking in English here, but somebody logging in using an Italian interface should see English bugwords linkified.
For this to work, linkification would need to work on a list of words. Once we have that, it's probably easy to add support for several words for a single language.
I'd say that's a different bug, though.
| Assignee | ||
Comment 23•15 years ago
|
||
Yes, being able to linkify across all languages is something that I want, but yes, it would belong to another bug.
Comment 24•15 years ago
|
||
Great that you think about it, hope it will be supported in not so distant future (this bug has already 7 years).
Comment 25•15 years ago
|
||
I am using Bugzilla 3.6.2 on Ubuntu. Can we linkify references to both "bug" and "MR" in Bugzilla? Currently "bug" term is linkified and it works fine. Please let me know steps to linkify both "bug" and "MR" (Modification Request). I knew that Bugzilla 3.6.2 also provides the ability to hook into this mechanism using the bug_format_comment hook, so an admin can extend it to autolinkify any text you like. Please someone can provide an example to linkify term "MR" as well.
Thanks for your quick response.
Comment 27•13 years ago
|
||
This is fixed by bug 364254. Admins can write their own rules in an extension using the bug_format_comment hook. We do not provide any other way to add custom rules.
Assignee: general → mkanat
Status: NEW → RESOLVED
Closed: 13 years ago
Depends on: 364254
Resolution: --- → FIXED
Whiteboard: [Fixed by blocker]
Target Milestone: --- → Bugzilla 3.6
You need to log in
before you can comment on or make changes to this bug.
Description
•