This module has always used the term 'Client' to distinguish tickets because that is the use case of the developer. However, in our organization where we use the module for tracking tickets by function (eg. IT, Accounting, HR etc.) the term 'Client' was not so suitable and we wanted to use the term 'Queue' instead.

The attached patch provides a more generic implementation of ticket categories. It provides a field (defaulting to 'Client') for administrators to configure the term that works best for their use case. The value of this field is then used in the 'create ticket' form and elsewhere in the code where 'Client' is output to the user. In addition, it adds a new token !ticket_category that can be used when generating notification emails from the system.

Please consider this patch for integration with the module.

Thanks

Comments

jeremy’s picture

Title: A more generic implementation of ticket categories » Make 'Client' a configurable name

The title of this ticket made it difficult to locate -- renaming. I'll review this after 6.x-1.5 is released, but likely will hold off on merging and instead will focus on turning "Clients" and "Tickets" into configurable entity types for 7.x-2.x.

I hesitate to merge this, as "client" is still rather hard-coded into the module, and so there will be some confusion to developers.

izmeez’s picture

We are also using a different name for "client(s)". Will check out this patch. Thanks.

izmeez’s picture

Status: Active » Needs work
StatusFileSize
new4.33 KB

Thanks for changing the title and bumping this to bring it to our attention.

This is a great idea although it may be an alternative to http://drupal.org/node/676044 implement "clients" as entity type.

I applied the patch to the dev release 2011-09-21 and two hunks failed. Attached is a new patch fixing that. Note that hunk

@@ -2103,7 +2105,7 @@ function support_status_form(&$form_stat
   if (!$available) {
     drupal_set_message(t('A site administrator must !create a client before you can create support tickets.', array('!create' => l(t('create and enable'), 'admin/support/clients/add'))), 'error');
   }
-  $clients = array('- select client -') + $clients;
+  $clients = array('- select ' . t(strtolower(variable_get('support_ticket_category_title','Client'))) . ' -') + $clients;
   if ($available == 1 ||
       (!user_access('can select client') &&
        !user_access('administer support'))) {

the original patch uses

-  $clients = array(0 => '- select client -') + $clients;
+  $clients = array(0 => '- select ' . t(strtolower(variable_get('support_ticket_category_title','Client'))) . ' -') + $clients;

This only partially addresses the segments of code that need to be patched.

1. On support settings there is a new field for the ticket_category and changing this does change the node edit/create support selection box title and default, "- select xyz -"

However if on the support settings page the ticket_category field is cleared and left blank on the node edit/create form the selection title and default text do not have a default.

2. Changing the support ticket_category does not change menus, titles and description text for admin/support/clients page and admin/support/clients/add page

The ticket http://drupal.org/node/1262544 to change UI name client to desk is closed in favour of this configurable approach. The patch in that queue http://drupal.org/files/issues/support_ui_rename_as_desks.patch may help to identify the sections of the module code that also require changes for this to work.

I'd be happy to help more on this later.

izmeez’s picture

Before I forget, item 2 in comment #3 might also be a good place for the nodereference_url_widget

jeremy’s picture

Status: Needs work » Closed (won't fix)

While anyone is welcome to locally apply this patch, I do not intend to add this complexity in the 6.x branch. This will be solved in 7.x by turning clients into entities (an effort that is already started):
#676044: Implement "clients" as an entity type

izmeez’s picture

Status: Closed (won't fix) » Needs work

Jeremy,

Thanks for explaining your thoughts in comment#5 and for all the effort that has gone into this module.

It is understandable that this feature is not on your horizon for the 6.x branch but I wonder if you would mind leaving the ticket open and as needs work so that others in the community can contribute if they wish. This could be an elegant way for the 6.x branch to provide the renaming option while lacking the 7.x entities.

Izzy

izmeez’s picture

Just in case there is any interest in working on this further I have attached a more complete patch in http://drupal.org/node/1262544#comment-5048016 that may help to identify where changes will be needed.

purencool’s picture

Issue summary: View changes
Status: Needs work » Closed (outdated)