Support

The first few warnings come from Joomla! core code, namely JApplicationCli. I have seen that before. It means that you are accidentally using the PHP CGI (Common Gateway Interface - used to serve web pages) binary instead of the PHP CLI (Command Line Interface - used to run command-line scripts) binary. The fatal error you get is also linked to the above. Please ask your host to give you the path to the PHP 5.3 (or 5.4) CLI binary and use that in your CRON job.

> Also, is it normal that I had to set permissions to 744 for ats-mail-fetch.php in order to run it?

No. Normally you only need 0644 permissions. This may also be related to you using the PHP CGI binary instead of the PHP CLI binary.

> One more, unrelated thing: can you please notify me too when the "private tickets only" feature will be available?

It's already there in version 1.2.0 :) Go to the ATS Category editor page and you'll see a new option called "Allow only". Set it to "Private". Done!

Um... can you please try installing the latest dev release? It seems that the ticket creation by email was FUBAR.

These warnings come from the Joomla! core and can be ignored.

> I have two more issues with ATS, about the sender identity and how tickets are identified when received by email: basically I would like to have the sender identity configurable and not forced to be the Joomla! installation mail address and I would like tickets to be identified by the subject instead of the line in the mail body. If you wish I can open a new ticket about those two...

Neither is possible.

OK, let me give more info.

> I would like to have the sender identity configurable

Nope. This is something I am not going to implement because it would require that most users also provide different connection information to their mail server. I'd have to add 13 new fields per subscription category. It's not impossible to do, it's just insanely complicated for everyone: me, you, other users...

> I would like tickets to be identified by the subject instead of the line in the mail body

Worst idea ever. This is how this feature started up with. Then I noticed that mail clients may add "re" "RE" "Re" "Antwort" "AW" "Απ" "Απάντηση" or any other localised "reply" prefix OR SUFFIX (for crying out loud!!!) in the message subject. And then again I have noticed many people changing the subject of the email so much that it ain't fun to try to parse that. So, between resorting to different email addresses per category and me ending up in the asylum, guess which alternative I chose. So, no, I'm not going to get crazy trying to solve an unsolvable problem :)

> If you allow ticket creations by e-mail and a user makes a mistake answering to an open ticket erasing the magical line... puff! A new ticket is created, and not having the possibility to merge tickets this can become quite a mess.

Actually, there is an invisible email header that is preserved by most email clients. If this header is present the message will become a reply, not a new ticket. I've tried very hard to fix stupid :)

> Another problem is that some mail UA (e.g. Thunderbird) by default *appends* replies to the original text, so if the user makes a mistake you can easily get an empty reply...

And the email reads: Reply above this line. If the user is so dumb that they can't understand what that means you're better off not reading their reply to the ticket.

> I understand why you did the way you did: to not have replies littered by the original text. But also keep in mind that some UA (Microsoft Outlook) prepend the whole email header to the text when answering, so you have the reply littered by the header anyway. Thunderbird is nicer but it too litters the reply with a: "on [this date] [this user] wrote", and that too comes into the answer.

Again, that's why it reads reply ABOVE and not BELOW this line.

> So, IMHO, it would be quite a good idea to have *also* the possibility to dispatch tickets answers received by email via the subject field. At the end of the day this how most ticketing systems work...

Wrong assumption. If this is how a ticketing system works its developer is either in the asylum or going there very fast. Most commercial ticket systems –e.g. GitHub– work based on a customised email address per ticket. Unfortunately this is not an option for a Joomla! component. The other trick commonly used is the thread ID in the mail server which again is not an option. This leaves us with a hidden email header (check!) and a reply above line (check!). In fact, I didn't invent this method. Many services use it, like Assembla's ticket system.

> I would not insist further but, as I said, I've already seen you doing the impossible, so I can still keep a hope...

I know how to pick my battles with impossible tasks :) I only deal with those that have a fair chance of conquering. When a battle is already fought and lost I am not willing to fight it again. And, you bet, I have already thought of what you said, I've already tried it, it didn't work and I came to the existing solution.

You know why I wrote the don't run this more frequently than 5 minutes instruction in the docs? It's because this will happen :) What is most likely going on is that the second CRON job would start when the first one was still running. This causes huge CPU and memory usage.

Best ticket reply EVER!

Damn, that's the exact reason why I don't like creating tickets by email :( You can disable the email for new and invalid tickets, but this may screw up legitimate users trying to send a ticket from the wrong email address. It's also impossible to detect mailer daemon messages because every one uses a slightly different format. Having to use a special keyword in the subject or body was another thing that crossed my mind, but it all starts becoming very complicated very fast :(

I guess the movie reference is "Paris, Texas".

Anyway, I guess there should be some solution, I just don't have it (yet?)