[Rt-devel] How to add a custom column like the "Take" one to the "N newest unowned tickets" search

[John Line]

Over the last few months, I've been working on migrating our existing 
customisation from RT 3.6.5 to RT 4 (currently 4.0.1), and adding a few 
new features that are required. One of the new features turns out to be 
unexpectedly problematic.

That requirement is to add a "Junk" link (similar to the existing "Take" 
links) to the "N newest unowned tickets" section of the RT at a Glance 
home page (and potentially any other displays there or in user 
dashboards), which would provide an easy way to move tickets (created by 
obvious email spam) to our "Junk" queue.

I started out thinking that I would just need to add code similar to the 
code for the standard "Take" links (in particular, in 
[local/]html/Search/Elements/BuildFormatString and ElementsEditFormat).

That looked easy, but unless I've overlooked something, it appears that 
the Edit facility in the various home page search displays is misleading.

It looks like you just need to select a column (from the Add Columns" 
selector and then select a Take link in the Format column and add the 
result to the columns for display. That "sort of works", but gives you a 
column with e.g. the ticket id as the link description (if you select the 
id column and a Take link), rather than having "Take" as the link 
description, which would be confusing for users (having a different effect 
from the standard column of ticket numbers which are linked to display the 
tickets). The link URL would be picked up from the prefix defined for 
Take in BuildFormatString.

As far as I can see, the only way to set up a column of these "special" 
links (with static text as link description rather than a value from the 
database) is by updating the search format definition in the database. For 
example, by extracting the relevant definition from @Attributes in the RT 
initialdata file for the "Search - Unowned Tickets" search), editing that 
to end the format with a line like

                  . qq{'<A HREF="__WebPath__/Ticket/Display.html?Action=Junk&id=__id__&Queue=$junk_id">__loc(Junk)__</a>/TITLE:NBSP'},

, deleting the existing search definition from the database and then using 
"rt-setup-database --action insert --datafile edited.format -dba postgres" 
to add the edited version. (That approach based on ideas from 
http://requesttracker.wikia.com/wiki/RepairSearches.)

Now my questions:

(1) Is it really true that you cannot add "Take" (or other) links to the 
results of e.g. the "N newest unowned tickets" or other search blocks (in 
the RT home page or dashboards) by using the Edit link and have them shown 
with matching, self-explanatory link descriptions like the standard Take 
links?

If true, is that shortcoming (bug or feature?) likely to be fixed any time 
soon (possibly with code already committed that I could back-port to 
4.0.1)?

If false (i.e. it can be done), what did I miss - how do you do it?

(2) If link columns with fixed link text like "Take" cannot be added by 
the Edit facility, is there any better approach than editing initialdata 
(or the specific search extracted from that) and using that to update the 
"master" definition in the database?

The problem with doing it that way is that users cannot duplicate it for 
themselves on other searches, and would not see it and could not add it if 
they'd heavily customised the searches in their RT at a Glance page, or 
private dashboards.

(3) I originally intended to show my "Junk" links only for tickets where 
it was relevant (i.e. ticket not already on the Junk queue, and user had 
privilege to move it there). However, it is unclear whether there is 
anywhere that I could reasonably check ticket details and user privileges 
while also being able to see which column of the results table is being 
generated and apply the tests only when building my "Junk" column, AND 
after all that, influence what (if anything) appears in that table cell. 
Any suggestions?

Or is the preferred approach in RT *not* to hide facilities that are not 
available or not relevant, and leave users to try them and then get an 
error if not allowed?

 				John Line

-- 
John Line - web & news development, University of Cambridge Computing Service