After a bit of struggling in order to understand how this module is currently supposed to be used i would like to point out some usability issues:

  • The module is not designed to be usable as a web-support interface, it requires less work if you want to keep the support through e-mails only. This is because an administrator, in order to give clients the right to create and access their tickets, should create a different role for each and every client. This is a huge issue if the module is to be deployed for a company that has lots of clients.
  • Even though the email-only support takes less configuration in order to create working client accounts, one is still supposed to manually create an email account for each client that needs to access the support.

There are many possible solutions in order to simplify the way this module works. The first two that came to my mind are the following:

  • Remove "clients" and use the drupal user system instead. This way you can group "clients" and, say, "technicians", or "agents", effectively removing the need to have one role for each client. This could be problematic for people who had the system set up to give access to one ticket for multiple clients, though.
  • Set up a single email account to receive all of the support-request emails. Mails could be assigned to the right customer by filtering them through the "email" field linked to the drupal account. In order to correcly manage replies and keep consistency between the tickets, a custom header might be the solution. OTRS does this, an overview of the way this system works can be seen here: http://doc.otrs.org/3.0/en/html/x1793.html

This is a great module already, but it isn't quite that straightforward at the moment. Seeing how crucial support can become for a company, i would like to gather the attention of the interested users in order to focus on making Support an even better support module.

Comments

Ivan Simonov’s picture

Ivan Simonov commented

Agree.
Little bit more about email setup:
#663542: Global Mailbox
see comments.

upuaut’s picture

upuaut commented

Can be easilly solved with the module http://drupal.org/project/user_permissions.

Regards
Petr

dmirtillo’s picture

dmirtillo commented

Could you be more specific?

Also, what's the point of having to install another third party module if there could be a possible solution with just having this one?

joshnorthcott’s picture

joshnorthcott commented

This was really helpful. I've been asking myself a lot of the same questions. Thanks for posting.

killtheliterate’s picture

killtheliterate commented

I'd like to also promote the idea of a more usable module! Decent documentation of how to configure it would also be a great improvement.

izmeez’s picture

izmeez commented

We've been using the Support module for awhile now.

It's great and it's flexibility when combined with other modules is tremendous.

As for documentation, there are snippets of examples in the issue queue but it really depends on your use case.

Just for the moment lets leave out the discussion of how best to handle "project(s)" as work on that is already started and ongoing.

Support uses the term "Client(s)" for its own support ticket access control.

The concept of "Client(s)" and the use cases and content involved may be broader than just tickets.

Other modules such as Organic groups and Taxonomy access modules TAC and TacLite provide tools for creating controlled access space for a variety of content that may be needed.

For example, a site for a variety of clubs may use organic groups or TAC that users can join or be added to. A variety of content may be created and used by each club.

If the support module is added for clubs how might the ticket access control be useful?

For lack of a better word we call these "Desk(s)". We wanted a term that might be generic across groups.

This allows that users with different roles such as members, editors, leaders and managers can have access to specific desks of tickets and some roles can also have access to other desks of tickets.

Having a common naming convention such as desks is helpful when users join other clubs or groups and when new groups are created.

This works for us. There's a patch if anyone is interested, http://drupal.org/node/1262544

jeremy’s picture

jeremy commented
Version: 6.x-1.x-dev » 7.x-1.x-dev

This sort of cleanup is not likely to happen in 6.x. My intention after 7.x-1.x stabalizes is to create a 7.x-2.x branch that makes "clients" a more generic entity type, as well as the underlying "tickets". I also hope to rely on mailhandler for inbound mail, core access control, and perhaps Views for the web interface. Once all this is accomplished module will gain many more dependencies, but will also be much more flexible.

Moving this to 7.x to make this intended roadmap more clear.

izmeez’s picture

izmeez commented

Jeremy, this all sounds good for the future. Meanwhile thanks so much for all the work and an already very useful module.

Jim Ruby’s picture

Jim Ruby commented

I'm trying to setup the support ticketing system and am finding it confusing. I wanted projects that I am working on and one email box that a user could send email to and the support system would either create new ticket or appent to the ticket if one was already created.
I guess this module does not do this yet. In hopes that it will soon I'll keep it installed and pray it is coming soon.

jeremy’s picture

jeremy commented

> I wanted projects that I am working on and one email box that a user
> could send email to and the support system would either create new
> ticket or appent to the ticket if one was already created.

If you're doing this entirely by email, you may get what you want with what already exists. You should start by reading MAIL.txt and then INSTALL.txt (both included with the module), specifically focusing on "integrated clients". You may be able to use one Client and multiple Projects within that one Client to do what you want. Creating/updating emails via email is fully supported, and further enhanced with the support_mailcmd module.

khuram’s picture

khuram commented

I am also trying to setup the Support module, and trying to do the same as mentioned in the previous comment.

"I wanted projects that I am working on and one email box that user(s) could send email to and the support system would either create new ticket or append to the ticket if one was already created."

But in my case I have multiple clients, so there would be multiple users, can I still get this all using only one email address. Using a single address, I want to create and update tickets for any of my clients.

Thanks!

jeremy’s picture

jeremy commented
Status: Active » Closed (works as designed)

The 7.x-2.x branch will be addressing these issues; won't be addressed in the 7.x-1.x branch.