Newbie questions (ticket sorting, old tickets, backup, etc)
Hi, I'm currently evaluating OTRS for deployment in our (small) company. We are having several persons answer the support inquiries and a system like OTRS would definitely make life easier. Reading the manual and parts of the user mailing list, there are still a few questions unanswered. Thanks in advance for your help. * How do I access closed tickets? I sent myself a test questions, got a ticket assigned, answered it and then closed it. Now I do not see where I can get a list of closed tickets to access previous ones, except when I search for them. * When a customer replies to an email without keeping the ticket number (either by removing it or by mangling it), his response is not properly sorted into OTRS (a new ticket is created). What would be nice is a way to move a new ticket to an already existing ticket. (This is suggested several times on the mailing list archive, so I just want to say "me too" on this feature :-)) * In reference to the previous item, I wonder whether you are aware of another way to sort in tickets - the "in-reply-to" header of the mail. Assuming that the mta on both sides does not mangle the message ids, it would be possibly to extract the messsage-id of the mail that the customer replied to. If OTRS's outgoing mails used a message-id of "ticketnumber+mailcount+checksum", this would provide a way to sort customer replys with changed subjects or missing ticket numbers. * For references, it would be nice to be able to put references to other tickets with similiar problems to a new ticket. * The feature list mentions the possibility of different frontends. The console and web frontend are included, are there any other frontends (like X11)? * For backup reasons I would like to keep each and every mail going in and out in a separate folder in plain mbox format. This is not the best solution, but better than nothing. While I can sort incoming customer mails into appropriate folders using procmail, it's a bit more complicated to do this with outgoing mails. Can OTRS provide an "auto-bcc" field for outgoing mails? * I did not find in the manual what the "Split/Divide" ("Teilen") action (for example displayed in the zoom view) is supposed to do. And finally a more fundamental question (possibly more related to mysql and not to OTRS per se): we are hosting our website at a remote location on a non-dedicated server). While our package includes php, perl and mysql, there are several reasons we do not want to put OTRS exclusively on our website (security, disk space, cpu utilization and most importantly speed and control). So we would put OTRS on our local server behind a firewall without the possibility for our customers to access their tickets via web. Has anybody been facing the same problem and what would be a recommended solution? -- Mit freundlichen Gruessen / With best regards Daniel Seifert 79bmedia GmbH * Chausseestr. 1 10115 Berlin * Germany * Tel. +49 (0)178 8775642
Hello Daniel :-) If its okay, I will answer between the quotet parts. Am Sonntag, 27. Juli 2003 10:33 schrieb Daniel Seifert:
I'm currently evaluating OTRS for deployment in our (small) company. We are having several persons answer the support inquiries and a system like OTRS would definitely make life easier.
Good choice.
* How do I access closed tickets? I sent myself a test questions, got a ticket assigned, answered it and then closed it. Now I do not see where I can get a list of closed tickets to access previous ones, except when I search for them.
I think using the search form to get access to closed or individual tickets is a very efficient way and its IMHO the only one.
* When a customer replies to an email without keeping the ticket number (either by removing it or by mangling it), his response is not properly sorted into OTRS (a new ticket is created). What would be nice is a way to move a new ticket to an already existing ticket. (This is suggested several times on the mailing list archive, so I just want to say "me too" on this feature
Sure.
* In reference to the previous item, I wonder whether you are aware of another way to sort in tickets - the "in-reply-to" header of the mail. Assuming that the mta on both sides does not mangle the message ids, it would be possibly to extract the messsage-id of the mail that the customer replied to. If OTRS's outgoing mails used a message-id of "ticketnumber+mailcount+checksum", this would provide a way to sort customer replys with changed subjects or missing ticket numbers.
Isn't it the same way, SuSE Linux AG (e.g.) does? I would prefer this option too; or better: a point of choice where you can set the method you want. Dry anyway: you are right. It would make life much more better.
* The feature list mentions the possibility of different frontends. The console and web frontend are included, are there any other frontends (like X11)?
I don't think so.
* For backup reasons I would like to keep each and every mail going in and out in a separate folder in plain mbox format. This is not the best solution, but better than nothing. While I can sort incoming customer mails into appropriate folders using procmail, it's a bit more complicated to do this with outgoing mails. Can OTRS provide an "auto-bcc" field for outgoing mails?
You could. Just edit the needed files. :-)
* I did not find in the manual what the "Split/Divide" ("Teilen") action (for example displayed in the zoom view) is supposed to do.
The "Split/Divide" possibility helps you to share several tickets with different operators. Just give it a try an you will find out.
And finally a more fundamental question (possibly more related to mysql and not to OTRS per se): we are hosting our website at a remote location on a non-dedicated server). While our package includes php, perl and mysql, there are several reasons we do not want to put OTRS exclusively on our website (security, disk space, cpu utilization and most importantly speed and control). So we would put OTRS on our local server behind a firewall without the possibility for our customers to access their tickets via web. Has anybody been facing the same problem and what would be a recommended solution?
Regards, - Dan -- usgang.de GmbH | Am Frankenturm 5 - 7 | D-50667 Köln Fon +49 221 355 472 0 | Fax +49 221 355 472 11
Am Son, 2003-07-27 um 15.22 schrieb Daniel Schönland: Hi,
If its okay, I will answer between the quotet parts.
That's the prefered way :-)
* In reference to the previous item, I wonder whether you are aware of another way to sort in tickets - the "in-reply-to" header of the mail. Assuming that the mta on both sides does not mangle the message ids, it would be possibly to extract the messsage-id of the mail that the customer replied to. If OTRS's outgoing mails used a message-id of "ticketnumber+mailcount+checksum", this would provide a way to sort customer replys with changed subjects or missing ticket numbers.
Isn't it the same way, SuSE Linux AG (e.g.) does? I would prefer this option too; or better: a point of choice where you can set the method you want. Dry anyway: you are right. It would make life much more better.
I do not see this option as a standalone option, but rather in combination with the ticket number printed in the subject.
* For backup reasons I would like to keep each and every mail going in and out in a separate folder in plain mbox format. This is not the best solution, but better than nothing. While I can sort incoming customer mails into appropriate folders using procmail, it's a bit more complicated to do this with outgoing mails. Can OTRS provide an "auto-bcc" field for outgoing mails?
You could. Just edit the needed files. :-)
While I hope to know Perl well enough to do so as a quick hack, it's probably not good enough to contribute it to the official source and I'd have to tamper around with the source code again with every release. Asking the question in a broader term: except for the usual backups of the mysql database files etc, what is the recommendation from the OTRS team to handle backups? Our OTRS system will contain some important mails we do not want to lose and reading about table corruption etc I think it would be a good idea to have at least a basic additional backup (mbox format) for emergencies. -- Mit freundlichen Gruessen / With best regards Daniel Seifert 79bmedia GmbH * Chausseestr. 1 10115 Berlin * Germany * Tel. +49 (0)178 8775642
Hi, On Sun, Jul 27, 2003 at 06:45:40PM +0200, Daniel Seifert wrote:
* In reference to the previous item, I wonder whether you are aware of another way to sort in tickets - the "in-reply-to" header of the mail. Assuming that the mta on both sides does not mangle the message ids, it would be possibly to extract the messsage-id of the mail that the customer replied to. If OTRS's outgoing mails used a message-id of "ticketnumber+mailcount+checksum", this would provide a way to sort customer replys with changed subjects or missing ticket numbers.
Isn't it the same way, SuSE Linux AG (e.g.) does? I would prefer this option too; or better: a point of choice where you can set the method you want. Dry anyway: you are right. It would make life much more better.
I do not see this option as a standalone option, but rather in combination with the ticket number printed in the subject.
The problem of using the ticket-number in the messsage-id is that no customer can change it. -=> E. g. a customer want's to write a new email to the system and is using an old OTRS email (by using the reply function), then the customer is just able to remove the ticket number from the subject (currently a new ticket will be created) but if we use also the in-reply-to header then the new request will be added to the old one. That's not what we want. All customers need to know that the ticket number in the subject is the reference.
* For backup reasons I would like to keep each and every mail going in and out in a separate folder in plain mbox format. This is not the best solution, but better than nothing. While I can sort incoming customer mails into appropriate folders using procmail, it's a bit more complicated to do this with outgoing mails. Can OTRS provide an "auto-bcc" field for outgoing mails?
You could. Just edit the needed files. :-)
While I hope to know Perl well enough to do so as a quick hack, it's probably not good enough to contribute it to the official source and I'd have to tamper around with the source code again with every release.
Asking the question in a broader term: except for the usual backups of the mysql database files etc, what is the recommendation from the OTRS team to handle backups? Our OTRS system will contain some important mails we do not want to lose and reading about table corruption etc I think it would be a good idea to have at least a basic additional backup (mbox format) for emergencies.
Backup the database (e. g. by mysqldump) and backup the OTRS $OTRS_HOME/var/ files. That's all. There are two files for this scripts/backup.sh and scripts/restore.sh. PS: If you want to backup all incoming/outgoing email the you should do this for incoming emails with procmail ($OTRS_HOME/.procmailrc) and for outgoing emails by adding the following to your Kernel/Config.pm for an archiv account: [...] # SendmailBcc # (Send all outgoing email via bcc to... # Warning: use it only for external archive funktions) $Self->{'SendmailBcc'} = ''; [...]
Mit freundlichen Gruessen / With best regards
Daniel Seifert
79bmedia GmbH * Chausseestr. 1 10115 Berlin * Germany * Tel. +49 (0)178 8775642
Martin -- Martin Edenhofer - <martin at edenhofer.de> - http://martin.edenhofer.de/ -- Noch 44 Tage bis zum Gäubodenvolksfest! ;-)
Am Fre, 2003-08-01 um 11.25 schrieb Martin Edenhofer: Hi,
aware of another way to sort in tickets - the "in-reply-to" header of the mail. Assuming that the mta on both sides does not mangle the message ids, it would be possibly to extract the messsage-id of the mail that the customer replied to. If OTRS's outgoing mails used a message-id of "ticketnumber+mailcount+checksum", this would provide a way to sort customer replys with changed subjects or missing ticket numbers.
[] I do not see this option as a standalone option, but rather in combination with the ticket number printed in the subject.
The problem of using the ticket-number in the messsage-id is that no customer can change it.
-=> E. g. a customer want's to write a new email to the system and is using an old OTRS email (by using the reply function), then the customer is just able to remove the ticket number from the subject (currently a new ticket will be created) but if we use also the in-reply-to header then the new request will be added to the old one. That's not what we want.
All customers need to know that the ticket number in the subject is the reference.
Good argument. What worries me is that customers might remove/change the ticket number in the subject, thus creating a new ticket even though it's a reply to a previous one. I do not recall an easy way to fix this in the GUI, e.g. having a new ticket I cannot merge this new ticket with a previous ticket (if I knew the number anyway). Maybe, although this is probably problematic as well, the following would work: if a in-reply-to field with a valid ticket number exists but no ticket number is in the subject, a new ticket will be created but it will have a note "reply to ticket xyz" and a link to merge this new ticket back into ticket xyz.
mails. Can OTRS provide an "auto-bcc" field for outgoing mails?
[] Asking the question in a broader term: except for the usual backups of the mysql database files etc, what is the recommendation from the OTRS team to handle backups? Our OTRS system will contain some important
Backup the database (e. g. by mysqldump) and backup the OTRS $OTRS_HOME/var/ files. That's all. There are two files for this scripts/backup.sh and scripts/restore.sh.
Of course.
PS: If you want to backup all incoming/outgoing email the you should do this for incoming emails with procmail ($OTRS_HOME/.procmailrc) and for outgoing emails by adding the following to your Kernel/Config.pm for an archiv account:
[...] # SendmailBcc # (Send all outgoing email via bcc to... # Warning: use it only for external archive funktions) $Self->{'SendmailBcc'} = ''; [...]
Thanks, I'll give this a try. -- Mit freundlichen Gruessen / With best regards Daniel Seifert 79bmedia GmbH * Chausseestr. 1 10115 Berlin * Germany * Tel. +49 (0)178 8775642
Hi Daniel, On Sat, Aug 02, 2003 at 06:23:35PM +0200, Daniel Seifert wrote:
[...] The problem of using the ticket-number in the messsage-id is that no customer can change it.
-=> E. g. a customer want's to write a new email to the system and is using an old OTRS email (by using the reply function), then the customer is just able to remove the ticket number from the subject (currently a new ticket will be created) but if we use also the in-reply-to header then the new request will be added to the old one. That's not what we want.
All customers need to know that the ticket number in the subject is the reference.
Good argument. What worries me is that customers might remove/change the ticket number in the subject, thus creating a new ticket even though it's a reply to a previous one. I do not recall an easy way to fix this in the GUI, e.g. having a new ticket I cannot merge this new ticket with a previous ticket (if I knew the number anyway). Maybe, although this is probably problematic as well, the following would work: if a in-reply-to field with a valid ticket number exists but no ticket number is in the subject, a new ticket will be created but it will have a note "reply to ticket xyz" and a link to merge this new ticket back into ticket xyz.
The merge-function is on the todo list... but at the moment you need to do this manually. PS: I would add an auto-reply to your queues with the important info that the ticket number in the subject line is the reference and should not be removed. This is a normal way to inform your customers after a ticket is created. .-)
Daniel Seifert
79bmedia GmbH * Chausseestr. 1 10115 Berlin * Germany * Tel. +49 (0)178 8775642
Martin -- Martin Edenhofer - <martin at edenhofer.de> - http://martin.edenhofer.de/ -- Noch 0 Tage bis zum Gäubodenvolksfest! ;-)
Am Freitag, 08.08.03 um 08:54 Uhr schrieb Martin Edenhofer: Hi,
Good argument. What worries me is that customers might remove/change the ticket number in the subject, thus creating a new ticket even though it's a reply to a previous one. I do not recall an easy way to fix this in the GUI, e.g. having a new ticket I cannot merge this new ticket with a previous ticket (if I knew the number anyway). Maybe, although this is probably problematic as well, the following would work: if a in-reply-to field with a valid ticket number exists but no ticket number is in the subject, a new ticket will be created but it will have a note "reply to ticket xyz" and a link to merge this new ticket back into ticket xyz.
The merge-function is on the todo list... but at the moment you need to do this manually.
How would I do this?
PS: I would add an auto-reply to your queues with the important info that the ticket number in the subject line is the reference and should not be removed. This is a normal way to inform your customers after a ticket is created. .-)
I already did :) Though having done support to end-customers for a few years now, I know that there will be issues in any way ;) With best regards / Mit freundlichen Grüßen Daniel Seifert
participants (3)
-
Daniel Schönland -
Daniel Seifert -
Martin Edenhofer