The new parameter showdescription creates a row spanned over the complete table width (colspan) containing the description of the referenced ticket. This can be used to for creating overviews of ticket contents.

This is a modified version of code originally contributed by Itamar Ostricher.
I felt like improving usability by replacing the input field for old tag(s)
with a select box containing all currently defined tags, where even multiple
selection and tag mass deletion is possible now.

It looks tiny, still any Component implementing ITagProvider should
be updated to fully support new capabilities. This is sensible at least,
if its realm knows about tag changes like Trac tickets does, where we use
the keywords field, that has changes recorded like other ticket fields
in Trac db table ticket_change.

Sep 3, 2011:

Code threw an AttributeError: username exception when attempting to change
tags on tickets. Couldn't find another occurance of req.username in any
other plugin nor in Trac core itself.

Turns out this flaw has been specific to the 0.6 release introduced by the
first development code in changeset [2953] back in 2008 - wow. I stumbled
upon this when attempting to implement tag mass replacement - a lucky catch.
Lucky again for finding get_reporter_id, that has been avaiable since
earliest days - 2004, and it works very well.

As outlined by Odd (osimons) in comment 4 of #9059
the usual first argument self is omitted from Interface definitions
intentionally; cite:

Interface class declarations in Trac (and plugins) are always defined
without adding self to the template methods. It has no real functional
meaning, other than established practice to specify the essence of the API
without implementation details + prevent that someone by accident makes an
instance of the Interface class and tries to call it (if so it should fail).

Sep 1, 2011:

This work is based on code contributed/tested by Itamar Ostricher and sika.

Had a hard time myself to understand the consequences of wiki rename in
Trac 0.12 i.e. for attachments, but now I favor this approach, even regarding
naming conventions.

So I preferred reparent_resource_tags over rename_resource because the
former is what we actually do while the latter has already been done, whenIWikiChangeListener method wiki_page_renamed is triggered. Other details
regarding the latest patch by Itamar have been discussed in #9059 before.