Feature suggestion: Links in the Results widget

Hi all,

especially when creating a new ticket via the quick creation form, I
would love to have links in the Results widget at the top of the page.
In this specific example, this would mean that the ticket number and,
optionally, the queue name would be hyperlinks.

I am sending this to the list first to get some feedback before filing a
whislist item.

Richard

Hi all,

especially when creating a new ticket via the quick creation form, I
would love to have links in the Results widget at the top of the page.
In this specific example, this would mean that the ticket number and,
optionally, the queue name would be hyperlinks.

I am sending this to the list first to get some feedback before
filing a
wishlist item.

This would be lovely, but a bit of a bear to implement. Those messages
bubble up from fairly deep in RT’s library layer, which makes
htmlification not super easy.

-j

This would be lovely, but a bit of a bear to implement. Those messages
bubble up from fairly deep in RT’s library layer, which makes htmlification
not super easy.

I feared as much. Maybe chalk it up with the other logging/event/error
notification stuff we were talking about, recently? If that part of the code is
ever touched, all could be done at once.
Alternatively, a really really ugly parser could sprinkle hyperlinks over the
message when it is being displayed. That would be a truly ugly hack, though.

RIchard

This would be lovely, but a bit of a bear to implement. Those
messages
bubble up from fairly deep in RT’s library layer, which makes
htmlification
not super easy.

I feared as much. Maybe chalk it up with the other logging/event/error
notification stuff we were talking about, recently? If that part of
the code is
ever touched, all could be done at once.
Alternatively, a really really ugly parser could sprinkle hyperlinks
over the
message when it is being displayed. That would be a truly ugly hack,
though.

It’d be impressive if you could get it to handle localized versions as
well.

[…sips coffee…]

Now, I just had a really fearsome idea.

We could replace the strings with some sort of “multi-format string”
object. It would have overloaded stringification which returned the
plain-text alternative. But if you were in-the-know and called
as_html, it gave you back HTML. At that point, I might recommend
baking the localization into the multistring object such that it only
got translated at output time.

Is there one of these on CPAN yet? If not, why not?

Jesse, who really needs to stop sipping the coffee

Is there one of these on CPAN yet? If not, why not?

i18n stuff does exist on CPAN. It has been ages since I
last poked those, though.

RIchard

Is there one of these on CPAN yet? If not, why not?

i18n stuff does exist on CPAN. It has been ages since I
last poked those, though.

This isn’t really I18N per-se. It’s more about ‘multi-valued strings’.
And I’m pretty sure there isn’t something like this :wink: