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! ;-)
_______________________________________________
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
