Awesome, I will test when I get some free time (likely by the end of 
the year) (or this weekend, in place of something else that I don't 
want to do :)

This is now implemented in HEAD. It requires the latest Whups HEAD also.

I was going to agree with Kevin that this should be a hook when I 
re-read Jan's reply and remembered the whole reason I wrote the 
Registry system in the first place - something other than Whups can 
implement tickets/add. So Kevin, for your case, you can just put a 
simple stub into registry.php and a wrapper for whatever ticket system 
you have. It's probably not much more work than a hook, and it's 
simpler for the case of someone who's actually using Whups.

I think I could make the same argument for interfacing with an 
external ticket system that you made for interfacing with whups, Jan.   
If there is an API available, it should be used.



Email probably is the lowest common denominator when it comes to 
trouble ticket systems but its fraught with the same set of problems I 
described with using the mail-filters script - it generally requires 
manual intervention (in ours, my secretary has to assign the ticket 
out of the email queue and into a "live" queue), and there's no way to 
enforce things like queue, priority, type of ticket, etc.  And even 
though our ticket system does support email, we only have that enabled 
for receiving tickets for legacy/backwards compatibility issues, 
namely that we used to have a number of generic tech support email 
addresses and even though we migrated to a new web-based ticket 
system, it takes a while before everyone comes around to using it.



I only suggested that it be hookable because that would be the easiest 
way to allow someone to write code to interface with a third-party 
ticket system.  You're right about it not being a preference - I'd 
think it should be a configuration option, and tend to lump all config 
options generically together as "preference".  conf.php options are 
sysadmin preferences :)



The reason I offer any sort of response to this is I know we're going 
to end up writing something to interface with our ticket system here, 
and a number of school districts have already asked for the same 
thing.  Email works, but it is a quick and dirty and not so elegant 
way to submit tickets.  So I hope you'll reconsider :)

This won't be a preference, preferences are for users, and a hook 
isn't necessary either.



If there is a tickets/add API method, use that, otherwise the current 
email code. Other systems can use an email account to interface with 
this system.

Chuck,



Your suggestion would work for a small second beta group, like we're 
about to embark down the road with.  But you've got the problem of 
getting a message that you may well generate from within Horde, 
through IMP, into a file, that you have to manually or through a 
scheduler invoke another script to get it into a database.  That 
doesn't scale very well, and you have to have clear protocols defined 
for user submission of tickets via email (i.e. spell out priorities, 
what queue, how you attach or include a file or screenshot, etc.).



Invoking the whups API from the problem report icon solves all of 
that.  Using a script could be viewed as more of an import feature 
(still very useful).  But if a native method exists, use that.  And if 
it whups isn't installed, use the existing mechanism of generating an 
email.



Going off on a tangent, it would be even nicer to have problem 
submission be a preference that you could hook.  That way you'd end up 
with three options:



1)  Default submit via form to generate an email,

2)  Invoke whups API if its available and problem_submission method is 
whups, or

3)  Run problem informaton submission through a hook, to interface 
with external ticket systems (Bugzilla, OTRS, WebHelpDesk [which is 
what we use and which has a forms based submission API], etc.)

The question was not to me, but I think it would make much more sense, 
ie. wouldn't be as complicated to setup, if problems.php would add a 
ticket through the API.

What don't you like about my proposed mail-filter.php solution for this?

Have the Horde Problem Report icon in the menu invoke whups, if whups 
is installed, else use the current services/problem.php behavior if not.