View source for WishList

'''First of all''' read! '''Please''', try to group similar things and not duplicate requests. If you don't know state of the feature you want, put it into "Unknown state" section.

== Work in progress ==

* Hiding/Suppressing of global scrips per Queue
** This has been done/maintained by [[DirkPape]], you can find it at http://page.mi.fu-berlin.de/~pape/rt3screenshots/.
** '''What about to integrate this to RT main stream?''' -- [[PauloMatos]]
*** I hope this would be integrated in 3.5 with similar wish about [[CFs]] disabling on queue basis. -- [[RuslanZakirov]]
* Porting database connectivity to DB2
** Under investigation. --[[PauloMatos]]
* [[SyncML]] interface. It would be very productive to be able to sync tickets to your calendar/PDA task list. I have seen some posts on rt-commit with syncml in the subject line, but nowhere else in the docs. Is this work in progress? --[[RobertSander]]
* allow ticket responses to be displayed in reverse order.
** implemented in 3.7 and [[ReverseHistoryOrder]] for older

== Wouldn't be implemented ==

* New [[EmailParser]] feature that would rely on from/reply-to fields (e.g. support-%ticket_id%@acme.com) for all correspondence and ticket management. At present, simple change of e-mail subject makes a new ticket.
** you can do this with your MTA, you need wrapper around rt-mailgate script that convert such addresses to variant compliant with RT and fix subject if it's required, I believe that it's possible to do with almost all MTAs. Only thing you need to do in RT is add Reply-To header overriding to all your templates. --[[RuslanZakirov]]
* BUG in Quick Create at bottom of screen. The ticket is created WITHOUT a REQUESTOR.
** requestor != creator
* Triage list - I'd like to be able to go through all unowned tickets and assign them to people, reject them or whatever without having to go through each one individually. Even a "reject" link similar to the "take" link on searches or the "resolve" link on the ticket itself would help.
** Just search for tickets owned by nobody, and used bulk update.

== Unknown state ==

* On login page protect against brute force attacks
* Support Dashboards on SelfService interface
* On Child Ticket creation - make the created ticked '''not inherit '''the value for TimeWorked.
* Store the Message-ID for each message in the database to enable thread detection via In-Reply-To and References in the mail gateway instead of ticket number ID ([http://cr.yp.to/immhf/thread.html more info])
* Allow for multiple owners of a single ticket
* Add diff style display of changes for custom scrips, conditions and actions. (The unformatted old/new display can be hard to read.)
* A Term::Readline support to bin/rt for command recall and editing
** bin/rt already uses Term::Readline
* [[Blacklist]] feature to prevent emails from being sent to no-respond addresses and receiving bounces.
* Pop-up window to open when a new ticket is opened. This helps in case the RT window is minimised. This will help us assign the tickets faster.
** Alternatively, something to change the favicon &amp;| page title, a la Meebo and various Gmail scripts/extensions for Firefox.
** You'll need to write a client for the popup, and you can use the builtin scrips to send the command on an event.
* "Sleep" option - would set the state of a ticket to stalled and then automatically return it to open state at a set time in the future. Boy, would this be useful. As it is now I have to keep scanning my list of stalled tickets to see which ones have had their external constraints unblocked.
** Use a reminder to reopen it? e.g; with an adaptation of one of the email reminders on [[Contributions]]
* Ability to print a number of tickets in one command in the same way that you can update a number of tickets at the same time.
** Try the "Editable text" link from search results?
* Ability to select any ticket already created, duplicate information in that ticket for a new ticket. -- [[ThomasCraigen]]
** See Dirk Pape's fork on [[Contributions]] for older [[RTs]], or the new port currently at http://www.letu.edu/people/markroedel/RT-Extension-ForkTicket-0.1.tgz
* Ability to create multiple tickets based on users data, not too sure how to handle this. Maybe have a separate create page that gives you the option to select the items that are common and items that would unique. -- [[ThomasCraigen]]
** See Tools/[[OfflineEdits]]
* A feature in rt-mailgate to allow ldap bind to cross check an email address with a valid user
** [[RTx]]::[[ExternalAuth]]?
** If valid user then check the organizational unit the user belongs to and automatically assign it to the appropriate queue else drop the request (probably spam and we don't want outside people to create tickets).
*** Then handle this at the MTA?
** The logic being suitable for a service support for a large company with several WAN links across multiple sites - and LDAP users categorized according to location. The is also probably useful for departments as well.
* When switching a call from one queue to another, if they have different mandatory custom fields, I should be prompted to enter the mandatory information. Currently I can move tickets around without entering mandatory info. This annoys those of us who use mandatory fields to prove a ticket has had at least some troubleshooting before we receive it. This re-assign to a new queue defeats this control method.
* Modify share/html/Admin/Users/Modify.html, to say explicitly state the "Let this user be granted rights" check box means Privileged user, e.g. append the string " (a.k.a. Privileged User)." For any software application like RT that has documentation scattered in multiple places (Wiki, Book, Mailing List, ...) an intuitive interface is helpful. Most of RT is very intuitive, but the text here is unnecessarily cryptic.
* Expand [[SelfService]] so that users can be granted rights to see/reply-to tickets that share a common customfield, or tickets owned by users that share a common customfield (e.g., all of the customers in company XYZ can be tagged to explicitly view tickets submitted by that company without giving them rights to see tickets submitted by people in any other company). Right now, the workarounds are serious headaches!! -- [[BrianWeber]]
* Put the visibility toggle buttons on ticket responses
* Create 'Outgoing ticket' with attachments by a Privileged User
* Let each Queue (and/or User) be configured if the default Resolve Ticket ticket screen should be a Reply to Requestor, or a Comment ("[[UpdateType]]=response" in Elements/Tabs). -- JEB
* Split the "attachments" database.
** If binary attachments must be held in a database, lets get it moved off to a separate one
** this would greatly improve the performance of the current database in RT and would make full body text searching something that one could actually accomplish.
* Move attachments out of the DB and onto local disk?

=== Enhanced [CustomField]s ===

'''Please''', users and testers of the RT 3.5, move items from this list to the "work in progress" section according to changes in 3.5 branch(there is a lot of work on custom fields).

* dynamically populated custom fields. the ability to generate a value for a custom field based on what is entered in other custom fields
* allow default values for custom fields
* allow custom fields dependants default values
* the ability to add a new value for a custom field "in place" (like Movable Type's 'categories' interface) --[[TonyBowden]]
* Linking multiple custom fields (eg SoftwareNameField--&gt;NumberofItems--&gt;TotalpriceField)
* The abilitiy to dynamically create copies of a custom field within a ticket (okay we need to enter another budget code, now another... )
* The abilitiy to dynamically create copies of groups of custom fields within a ticket (okay we need to enter another of whats above, now another... )
* To see what a custom field / form creator can look like, go to http://www.wufoo.com and imagine if RT was coupled to this flat file db / forms creator tool. Build a web form that still allows free form text entry, maps its form fields to RT columns, utilizes RT task manager functions.
* Keyword feature, aka "tagging" or "Web 2.0". See del.icio.us, flickr, Slashdot's "tagging beta", metafilter, digg for examples. Useful for using resolved tickets as an self-organizing non-hierarchical knowledgebase ("This is an Jersey problem; maybe someone resolved a 'jersey' ticket similar to this?"). Faster than searching all text fields for mention of "jersey" (and someone might've spelled it "sweater" instead, or a client might put "wool shirt" in the original subject line.) Best implementation would offer autocompletion of tag words to encourage conformity (a-la the email fields in RT now; try del.icio.us for an example). --moomo
* The ability to create a custom field without an input as a way to quickly customize queue specific screens (e.g. brief directions for filling out a ticket)
* the ability for several other fields to be visible once one is selected and saved. 3% of our tickets need 6 more fields but we don't want to muck the form up for all the other tickets.
*

=== Config and other options as user preferences ===

* Ability to display customized "RT At A Glance" depending on group membership
* Change default sort order
* Option in Personal Preferences to save you home screen Refresh rate so it is preserved during navigation / logins
* Permission to allow user to change their own password only and not Modify everything under their userid such as email address. Seems [[ModifySelf]] is only option right now.
* Configure home screen:
** Allow user-configurable "bookmarks" to queries
*** bookmarks? May be it's [[SavedSearches]] feature?
** Change default queue for "New Ticket" option
*** most useful I think to remember the last choice --[[RuslanZakirov]]
* Completion of the code allowing RT to be configured to send outgoing email directly to a remote smtp-server instead of to a local sendmail
* Set the Default queue within User Prefs (like: [[SelectDefaultQueue]]) but in a easy way without usage of CF's (Torsten Brumm)
* Set the default Refresh as a "global" User Setting within User Prefs (Torsten Brumm)
* A History for Changes for Queues like it is for Users (Torsten Brumm)
* CF's for Queues, which are not displayed within a Ticket of a queue, something like the CF's per User or Group (Torsten Brumm)
* Make Timezone a per-user configurable option --[[AtroTossavainen]]
* Ability to display ticket history by page, e.g. 15 rows/transaction logs per page, with Next, First, Previous, Last buttons/links at the bottom or top. Especially helpful and useful for tickets with huge history/transactions and if using RT from a slow connection.
* UI for end user setting up inbound mail rules, like the MS Outlook Rules Wizard, (Maybe Outlook Express and Thunderbird have these wizards, too. The Outlook one is pretty easy to understand).
* Ability to create permissions (rights) profiles.
** Permissions we grant to our users and groups are generally the same and selecting a profile of permissions would be faster and easier to manage than to have to select several permissions each time. For example, a profile "Read only" with the rights 'See Queue, Show Ticket and Show [[TicketComments]]'.
* Allow users to set their preference for a default display when in a ticket (ie. Basics, as opposed to Display). Not everyone wants to see the full display, they may just want Basics.
** Allow the same preference for the format for the display of ticket dates to also apply to CF Dates.
** Select which Dates are displayed in the Date Box, including CF Dates.

=== Installation &amp; Upgrade ===

* Ease of installation should be a major focus - right now the installation process is so complicated that it's a real barrier to evaluating your software. Why does it have to depend on '''so many''' extra modules?
* Adding a database element to indicate the database revision. This would make upgrades significantly easier (as well as automatable, after a point). --[[B2Pi]]
* Maybe you could provide a RT as [[VMWare]]-Appliance, so we could evaluate your product esay?
* It would be nice or even intresting to supply a build for Windows or Mac OSX

=== REST ===

* '''Add Possibility to set CF Value for Transactions via comment / correspond REST'''
* Correct status code for GET and POST commands (not only in response body).
* Constant date & time format for date-time fields.
* Constant value for empty fields instead of localized string for "Not set".
* Definitive indication of a successful or failed login, when using REST.
** Currently (RT4.0.1), session cookies are issues regardless of login success or failure, and besides parsing the body HTML content for a success or fail, the only other way is to look at the HTTP status (200 OK for a fail, and 302 Found for a success). If there is a definitive way, via HTML body inspection, what string should we be keeping an eye out for? Please update the REST wiki entry with info.

=== Other ===

* Create multi-platform desktop widgets that can be used to perform simple actions on tickets via the web service URL, e.g. quickly resolve a ticket from my Mac OS X dashboard. --[[ChrisHardie]]
* '''Allow users with admin rights to reassign tickets without having to steal them first.'''
* Put a "Save Changes" buttom at the TOP as well as bottom on all Update Pages. ie. Config->Global->Group Rights & Config->Queue->Group Rights.
** Allow the "Group Rights" pages the option of selecting which groups to show/not show. Similar to the list in "QuickSearch".
* I'd like for the SEARCH default fields to be MUCH smaller (Queue,ticket#,status, requestor &amp; owner). anything is really superflous and should be up to the user.
** Add the ability to select multiple columns (at once - hold the control key, etc.) to remove from search results.
** Add "Comments" to the list for Search Results columns. A lot of managers want to see what the ticket owners are saying.
* Rights Matrix needs to allow for one queue and one person. I DON'T need a list five miles wide.
* How about Single-Signon (SSO) authentication for systems which insert variables into the HTTP header to identify the user?
* Quotes in mail from requestors
** Folding quotes - that is, a bit of [[JavaScript]] bound to a link that lets you hide/show quoted text in the email, default to hidden on page load --[[NathanOsullivan]].
** Converting quotes - The javascript fold quote method has the drawback that it still takes a long time to display long threads with lot of quotes. It would make more sense to convert quoted text to attachments. -- Miklos Muller
* How about alternate email addresses for a user? I have an odd situation, with an old UNIX system that handles multiple domains, people who forward their email off to other sites, etc. I'd like to be able to take the user 'bob' ([mailto:bob@example.com bob@example.com]), and add an alternate address that can be considered equivalent ([mailto:bob@mail.example.com bob@mail.example.com]). Not the easiest thing to implement, I'd guess. (as of 3.4, not present)
** If there were custom fields for user objects, this would be fairly easy to implement with a custom field on the user (alternate address) that pointed an overlaid [[CanonicalizeEmailAddress]] to the right address -- could be parsed from the extra info, in absence of custom fields.
** This was discussed on the [[MailingLists]] --[[RuslanZakirov]]
* Another great feature for RT is to have a current overview for logged in user. Somewhat like JIRA's Dashboard feature. JIRA has a saved filters (equivalent to RT's saved search URL), Assigned to me, and in progress... RT should have these + open watches (like ebay allows watch on items) Look www.atlassian.com/software/jira/tour/step1.jsp -- Amit Kulkarni (forestlaw.blogspot.com)
** as variant you can use [[HomePageSavedSearches]] extension
* Modify the homepage for a privileged user that allows easy manipulation of the queues for new, unowned tickets. I think a system that is similiar to how webmail interfaces allow a user to check a group of messages and quickly move them to a folder. Currently, it takes four steps to modify a queue and return to the homepage.
** this extension looks useful only for those who move tickets a lot because of workflow requirement --[[RuslanZakirov]]
** could be done with extending search column map in RT &gt;= 3.4, require only hack on column map --[[RuslanZakirov]]
* support for multiple instances included in base code. Patches are available at [[MultipleInstances]], but I think it would be great if this were part of the sourcetree.
* When updating multiple tickets, use a template solution from the RTFM Database same as you do for a regular ticket resolve/reply
* Gantt view of queue.
* Possibility to emphasize nearly due and overdue tickets by giving them different colors in the list view
* It would also be nice to highlight tickets that you own but were not the last person to make contact with it. It's an easy patch but would be nice to see it main stream.
* RSS/atom feed support for queues
** RSS feed for ticket comments (project manager can subscribe and see what activity is happening overall)
** See [[RssFeed]] for more information about how to use the feeds that are in 3.4
* Rights Inheritance when creating a queue. In the short term, just being able to do something like "Copy rights from queue: xxxxxxx" would be great. Long term, it would be cool if queues could inherit rights dynamically from a specified queue. So you assign rights to 'network-outages' and then create a queue called 'network-maintenance' and tell it to get its rights from 'network-outages' -- [[AndyHarrison]]
** See Queue Wizard in [[Extensions]]
* Speller - Very important for International users on the reply/resolve/comment window. aspell?
** see [[SpellChecking]]
* Linking [[RTs]]. There could be instances where you want to be able to refer to tickets in queue's in another RT installation, or you might want to transfer tickets to another RT. Slightly exotic, but thought I'd put it up here anyhow :-)
** I agree that this would be quite useful
* New sub-pane on left-hand side: tickets recently viewed (handy when establishing ticket dependencies, etc) --[[KevinMurphy]]
* Manage rights to enable access to RTFM content for non-privileged users. --[[OlivierEnault]]
* A checkbox next to tickets in the search results view so that you can do an update all selected tickets at once. This is much faster than using a search at times. With this feature, I could get rid of spam much more easily. --[[GaryWilson]]
** There is bulk update in RT for a long time.
* Hierarchical queues (has been referred to on the list as subqueues), so they could be in a tree structure instead of just a list. This could be done by just storing a parent queue for each queue. A queue with no parent set would be a top-level queue.
* Similarly, a hierarchy of tickets. Using the existing parent/child structure (or the 'dependson' structure, ideally let the user choose), display tickets in a tree view. This would make it much easier to determine what task needs to be done next when working on a large project.
* Give requestors a mass edit screen to set priorities on tickets. The existing mass edit screen would allow for setting a group of tickets to all have the same priority, I'm looking for a screen showing all tickets that meet a criteria (I am the requestor, status is open or new, in queue xyz) with input fields for the priority of each. This allows clients to downgrade tasks that perhaps have been in the queue for some time (and therefore high priority by RT rules) but are not the most important.
* Ability to schedule work in advance and have the ticket display at the Start Time. This is valuable when scheduling projects for future dates.
** could be done with notifications + rt-crontool --[[RuslanZakirov]]
* Favourite feature from similar-product : shortcuts for reply snippets. Configure at a global level a dictionary of shortcut =&gt; text, for example "down" =&gt; "Sorry this service was down, please try again.". Choose which queues to assign snippets to. When typing a reply, entering "down`" (shortcut followed by backquote) would immediately replace "down`" with the full text for down via javascript --[[NathanOsullivan]]
* Bounce detection - file bounces into ticket whose email bounced: http://lists.fsck.com/pipermail/rt-users/2003-March/012729.html
* a new command line interface written in ncurses, accessed by telnet or ssh for advanced users/sys admins, to be fast, light &amp; easy (like the OS/400 GUI) for eg : 'ssh RT.domain.com -l user -p pwd'. the ncurses program interface would be connected either directly on the RT's web site '''or connected on a new abstraction layer virtual interface between the SQL DB &amp; the WEB engine, giving the possibility to access RT by plugins in third party applications''' (lotus notes, XUL, python, java...)
* Custom Field dependencies. Additional code and JavaScript based improvement for WebUI that allow setup CF2 Value only if CF1 was choosen. For eg: CF: Product, CF: Version, Product1 has Version 1,2,3 but Product2 has Version 1 and 2 only.
* Comment/Reply display button on ticket page. Often the only information we want to view about an issue is contained in the Comments or Replies. It might be useful to have a button on the ticket page (like the Basics, History buttons etc) that selects only Comments and Replies for display.

* Allow for reversing the ticket priority. Most other systems I have seen use 0 as the highest priority.
* The ability to "Save Draft". We use RT just like we use email ... a lot. Sometimes tickets require lengthly responses, so the ability to save it as a draft and come back to work on it later would be great.
* The ability to "Open in new window". This is a feature of gmail that I really like. i.e., while reading/replying to an email in gmail, I can click on "New window" and it pops up in another browser window. The ability to do the same in rt would be great.
* The ability to integrate RT with other systems using SOAP (with RT authentication), offering services to at least:
** List queues with ticket counts
** Query tickets
** Get ticket data
** Create/Change ticket
* Define a function/interface to incorporte error logging by other applications (merge user reporting with system reporting)
* Ability to have a Next Action option for each history job, then a Today's Tasks option. ie: note to call customer on Monday on 3 weeks to follow up something, so when that date comes around, you're prompted to do so (option for daily prompt email of your 'to do today' jobs would be awesome as well).
** i.e; the Calendar System (built on Reminders) listed below?
* Ability to use "conversation" (a la gmail) style display in tickets. Currently, long tickets sometimes end up looking like a chain email.
* Someone would like to have rules for workflows implemented. See [[RulesetWorkflow]]

* A "Top" link at the bottom of pages that have enough transactions to run the bottom of the ticket off the screen. As people use different resolutions this might be something that appears regardless of how many transactions appear or set to appear for a static number of transactions.
* Have the take command assign the next available ticket of a given status and queue to a user, who may be one of a group of users logged in at once. So user opens Jumbo screen or single ticket screen and clicks take to start the day. Works ticket to its furthest possible point, saves, then does another take command and the next ticket from the queue appears. User never picks a specific ticket from a list, the queue manager assigns next ticket. May need to be combined with the workflow and tree view of queues, as users would need to be assigned only to certain stages of multi-stage workflow, like passing tickets across queues, possibly.
* A Address Book, one on a User base and also a global/group one. This must be linked into the several update screen where you can add users. Also an Import/export/sync Option would be cool. (Torsten Brumm)
* Add a '&lt;meta name="robots" content="index,nofollow"&gt;' robot exclusion meta tag to every page so that indexing is safer. See: http://www.robotstxt.org/wc/meta-user.html .

* A configuration option to allow Unprivileged users of the same organization to see tickets requested by others of that same organization. This would allow a requestor working for company/department 'A' to see what others within that same company/department 'A' have lodged with the help desk. I would suggest, for simplicity, that this be a universal configuration, such that if enabled all requestors can see tickets raised by members of their own organization. -- [[BenRobson]]

== Bad descriptions ==

* A Calendar System for Scheduling Apointments for a Technician(user of a group) on a Ticket that shows up for all users in a group.
** require more description and/or examples --[[RuslanZakirov]]
** Yes, a Calendar would be great, the Reminders could be listed in a Users Calendar, and also a Queue based Calendar where are all Tickets displayed which have at least Starts and Due defined. Also a Calendar View over all Queues the user has rights too. This on a day, week, month base to keep track of ongoing events.
** I'm not the original proposer but: The ability to add a multiple items in the form of ( datetime,user|group ) to a ticket. And also be able to view as calendar all the items assign to your user and the groups which you belong to . This would be useful for us. Particularly if todays calendar was on the at-a-glance page.
** I think what they are asking for here is something like the calendar feature seen in the OTRS demo. http://otrs.org/demo/ This kind of calendar view would be pretty handy.
** Why not use [[RTx]]::Calendar and/or iCal feeds?
* [[WiKi]] plugin to use with RT?
** RTFM project?
* Regular style pull-down menus instead of small boxes
* Elaboration of "Show Results" link to become a list of recent queries --[[KevinMurphy]]
* I wish there was a painless way to make custom changes to the interface
** [[CleanlyCustomizeRT]], otherwise post your ideas to the [[MailingLists]] --[[RuslanZakirov]]

== Done ==

* Wildcard strings in search text
** RT allow SQL wildcards: '%' - any sequence, '?' - exactly one char. Undocumented feature. Patches, wiki notes are welcome as I think :) --[[RuslanZakirov]]
* Possibility to host several independent "local" sites. One main RT installation, but multiple local parts with fully independent local installations , users , queues. Think of an ASP service for RT.
** It's possible. Read [[MultipleInstances]] --[[RuslanZakirov]]
** However, it's not very host-friendly as you have to load up the RT modules multiple times which creates a significant memory footprint -- [[WilliamMcKee]]
* I'd like to be able to have a 'default Cc: address for newly created tickets' option when creating queues. I always need to add "[mailto:support@companyname support@companyname]" to a newly opened ticket to make sure that my Ops team mailing list gets updated when the RT ticket is commented/replied to, and such a feature would be a small but greatly appreciated timesaver!
** Use Notify Group from [[Extensions]] or use a [[Template]] that overrides To address. --[[RuslanZakirov]]
* Ability to work with custom fields using the 'rt' command (or at least set values on ticket creation/edit) --[[RyanRoland]], --[[BrandonPulsipher]]
** there is patches in rt-devel@ archives and may be changes commited into 3.5
* Per user [[NotifyActor]] option
** RT-3.7
* Allow for reverse comment history -&gt; showing the newest comments first in the list, instead of at the bottom of the list.
** RT-3.7
* Be able to use S/MIME or PGP to encrypt outgoing and incoming email. Since RT 3.4 provides custom fields for users, it would be able to store user certificates in a custom field, just need the glue to use it.
** RT-3.7
* Default display columns for search results. It seems a bit crazy to be able to configure a default At a Glance layout, but not a default set of display columns. My users don't need the 2-line display and I don't want to have to change them all. Plus even if I did change them a new user would end up with the wrong options again
** Make a local customization?
*** You can do this now. Please go to Preferences &gt; Search Options.

=== Features implemented in RT 3.6 ===

These features are available with RT-3.6 stable release.

* Global Custom Fields disabling on queue level
* Required Custom fields. It was discussed many times, but people still want it.
* The ability to modify the user rights specifically by custom field. eg a change is proposed but has to be authorised by the CM Manager. Only that person would have the right to modify the custom "approved" field. Operators could not.
** [[SeeCustomField]] and [[ModifyCustomField]] rights are implemented in RT-3.5 (may be even in 3.4.4, drop this)
* Printer friendly view of tasks and queue.
** This can be done with special CSS rules for printed media
* Option for a javascript or DHTML date selector on date/time fields for faster entry.
* Web front-end customizability via CSS.
** It's partly customizable via CSS in 3.x versions(see webrt.css file)
*** Interface of the RT 3.5 uses CSS all over the places, if it still not enough then file bug report
* Configurable home screen:
** How many tickets to show
** Which queues to show tickets for in lists
** Which lists to have visible (ie. remember the X has been clicked)
* Allow multiple levels of sorting in queries - ie. Order by Status, then by [[LastModified]].
* Search form should be a simple textfield just like google textfield. Advanced customization should be shifted to a "Advanced Search Preferences". A simple note on top of the textfield should state in what order RT will search i.e Owner, Email id, subject, queue, priority etc. With just the subject as a required field. This will be like a C like char * argv parsing. -- Amit Kulkarni (forestlaw.blogspot.com)
* Integrate [[FCKEditor]] for ticket comments/replies. http://www.fckeditor.net/
** 3.7(.82) has this...