Helpdesk

definitely subscribe ..

I think the difference between what is done and what you want is you don't want to set up clients, you just want everyone to be their own client? So if user A submits a ticket, and then user B submits a ticket, only user A (and admins) can view user A's tickets, and only user B (and admins) can view user B's tickets. Is that correct?

That could be more or less emulated, however you would have to first set up User A as Client A, and User B as Client B. With that manual step done, you would have what you need.

The only other possibility is that you may be able to build what you want with the Jobtrack Views integration module. I do not know if it would be possible, but it's worth exploring.

Otherwise, patches are welcome but this is not something I'm likely to implement myself anytime soon, sorry. Moving into a postponed state until you either report back that you've gotten it working with Views, or someone submits a patch.

I also am looking for what JonoB is seeking. I run a Technical Support site with over 10K registered users and growing. So manually entering User A to Client A and User B to Client B is out of the question.

The back end of your module is almost 100% perfect for what I need. But I need to figure out how to change the front end so that a user could enter their question/request, select a technical area (instead of selecting a Client) and then have the module automatically assign the question/request to a predetermined support person based upon which technical area the user selects.

Any suggestions or hints would be greatly appreciated.

+1 here.

I even think selecting clients is redundant, since it's the assigned user field that fires the e-mail and basically the entire process.

it's an usability matter.

moreover, there could be a finer granulation on two aspects:

1) assign ticket: if you're user A and I'm user B, you don't ask me to fix stuff. you ask user C, who is support. so the assign to dropdown would have to be populated with supportstaff, not regular site users (but then again I don't know if that's because I installed a patch found here: http://drupal.org/node/402918).

2) a certain website might need all dropdowns, but then again they could all be optional. for example, if there's only one support email, there's no need for the assign to dropdown - or even the client dropdown. another case is when a regular site user may not change ticket states, but might still see them.

speaking of seeing, I miss being able to check a ticket's state when I'm viewing it. this can only be done in the ticket list page or when you add a comment. btw "add a comment" should be renamed to "reply to this solution" or "reply to this ticket" based on whether you're the user who fired the request or a support member reviewing it.

anyways I'm not just asking but also giving; I intend to chip in on this module once a client gives me the green light on a project.

cheers,
Luciano

This feature has landed in the form of a new "only view own tickets" permission. From INSTALL.txt:

   Users with "only view own tickets" permissions can only view tickets that
   they have created themselves.  They still need to be assigned to a client,
   however if there are multiple users creating tickets for that client that
   all have "only view own tickets" permissions, each user will only be able
   to see the tickets that they themselves have created.  Users with "administer
   jobtrack" permissions are not affected by the "only view own tickets"
   permission.

Thus, to do what you want:
1) create role Foo, create Client Foo, assign 'access Foo tickets' and 'only view own tickets' permissions to Foo role
2) create role Admin, assign 'access Foo tickets' to Admin role

Now, any user in role Foo can create Foo tickets, but they can only see the tickets they themselves have created. (This is true for all ticket views, including search.) Any user in the Admin role can view all Foo tickets, not just tickets they themselves have created.

If you want to have multiple departments, create multiple Clients: "Foo, Bar, etc...". Now, override the name "Client" in your theme or with the locale module, and make it "Department" or whatever you wish it to be viewed as. Give role Foo access to all of these clients. Now, when creating a ticket they can chose which "Department" it is for. Create multiple admin roles, one for each "department".

This feature is in the -dev tarball now for testing, and will be part of the eventual 1.4 release.

Sounds great! Could you please let me know how to override the name "Client" in your theme?

Thanks.

Sounds great.

I am not sure if I understand 'departments' in the sense you are using it, but is it possible to assign separate email addresses to each department? For instance, sales@example.com (Sales), billing@example.com (Billing), support@example.com (Customer Service) so that tickets can be created for that department merely by sending to that relevant email address. This would be similar to the way tickets can now be created for globally defined domains with inbound email integration enabled.

Re-opening ticket to review remaining issue.

The "only view own tickets" permission is actually a restriction rather than a permission. I think the logical way would be to handle it vice versa - the permission should be something like "view other user's tickets".

I agree with leevester 100%. This is exactly the functionality I am looking for as well.

@JimV: see comment #6, this is implemented already in the -dev tarball.

Great Module. Would there be any possiblity for a Drupal 5 port. Especially since Ubercart is mainly for Drupal 5 right now and it would be nice for an online store.

@RikiB: Your comment has absolutely nothing to do with this ticket. Please stay on topic. To discuss your question, try this issue: #408526: backport module to Drupal 5

My apologies.

there's no patch for review here... is this fixed?

I too find the permissions to be a little odd for my use as a system whereby a residential customer can register, login and immediately create a new help ticket. I don't need them to be able to assign the ticket, nor do I need them to choose a client. I'd like for each individual user to have created for them a Client name corresponding to his/her "Real Name" info captured on the registration form. This one combined task would make this module indispensable.

Not sure if Jeremy can do that or not. I know it's possible and I could hack my way through it in 6 months if I tried, but ...

Anyway, for the minute I am not really going to use ticket assignments for anything other than self assigning it to the creator. I took like 4 lines out of the .module file and while the field is still there, the creator's name is the defaulted and sole entry in the combobox. Once my site is live I'll post a link and a test.

Posting that shortened module here if anyone finds that small feature particularly useful.

Check out http://drupal.org/node/446318.

Najibx has written a patch to the jobtrack.module that allows you to control who gets to see the State, Priority and Assigned Fields based upon role permissions.

With the correct permission settings, users that opening a new ticket will only see the Client field. and on later comments, they cannot see the fields to make changes that could interrupt the workflow. ie: re-assigning the ticket or determining that their ticket should be High Priority.

Addressed the remaining issue in #8 by adding a new "hide ticket status bar" permission (to the ever growing list of permissions that this module has). It is documented in INSTALL.txt as follows:

Users with "hide ticket status bar" permissions will not see the State, Priority, Client or Assigned select menus for tickets (unless they have "administer jobtrack", "administer state" permissions, or "can assign tickets to other users" permissions).

Tracked in this issue: #446318: Hide status, priority, assigned options