workflow

> Does this sound like something the support module could help with?

With a little work it could perhaps be adapted to what you describe, but it may not be the easiest fit. Perhaps a custom CCK node type is what you need?

> There are several tings in the demo that I don't understand. For example: Who the 'foo' and 'bar'
> users are? It's not clear if they are customers or employees? If employees, are they individual
> users or are they 'departments', like 'enquiries' and 'billing'?

Yeah, good question -- I see now that the example website is quite confusing. I will have to fix that at some point. Currently there is a "foo" client, and a "foo" user which is assigned to the foo client. And there is a "bar" client, and a "bar" user which is assigned to the bar client.

The "foo" and "bar" clients can be anything -- internal departments, external clients, whatever -- they are just logical groups of users that fit your use case. In your specific case, it sounds like you'd only have one client -- and all users on your website would be a member of that client which would only have permission to view the tickets they themselves have created.

> Yes, that sounds good. A client perhaps called 'billing & support', with all authenticated users able to
> create tickets to that client (and only see their own tickets), and with three or four admin users who
> can allocate themselves to tickets and then answer/moderate/maintain them. That seems to be what
> you're describing?

Yes.

> When an authenticated user fills out a webform and it gets emailed to us, instead of just simply
> emailing the user back normally, would one of the admins also be able to create a ticket for that
> user too (so that the user gets his normal email reply, but also has a ticket waiting for him in his
> profile area for further contact/conversation)? Understand, we *don't* need the webform to create
> the ticket when the user contacts us - we need to be able to create the ticket on our first reply
> back to the customer.

Sure, you can do that. You can either auto-create it with the webform if desired, or an admin can manually create it after the fact. The admin will need to have permission to subscribe other users to the ticket. This is one use case the module was designed for.

> NB. If you're going to change the demo and/or docs, you should also think about the word 'client'.
> You seem to be using it in terms of software, like 'email client', 'ftp client', but most people who
> want a ticket system will be thinking of 'client' as a synonym for 'customer' (ie. the person who
> is going to create a support ticket).

'Client' is synonymous with 'customer' in my user case. As a consultant, I have multiple clients -- these clients in turn each have many employees, which are the users that are assigned to the 'client'.

It sounds like you're on your way - closing ticket. Feel free to re-open if you have more questions on this workflow after you've experimented a little.

> You can either auto-create it with the webform if desired
can you please elaborate how to create automated tickets whenever a webform is submitted.

Please review MAIL.txt that comes with the support module. Create a new support "client", integrate it with inbound email, and configure your webform to email this client's ticket email address. Then, whenever a webform is filled out, a ticket will be created.