Hi, I am still trying to get this template thing right. I have learnt a
lot about OTRS but am still a noob, so I request someone to please give
me a hand on which files to alter to make my own template. I need to add
some fields and make it look like the company wants. Also renaming some
of the fields.
We are a non profit organization so cost is a huge thing to us.
Your assistance is appreciated.
>>>
From: <[email protected]>
To:<[email protected]>
Date: 2012/08/28 10:08 PM
Subject: otrs Digest, Vol 47, Issue 54
Send otrs mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.otrs.org/cgi-bin/listinfo/otrs
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of otrs digest..."
Today's Topics:
1. Re: Require service/sla (Shawn Beasley)
2. Re: Restricting the self-registration feature
([email protected])
3. Re: Get emails double (Jean BROW)
4. Re: Get emails double (Steven Carr)
----------------------------------------------------------------------
Message: 1
Date: Tue, 28 Aug 2012 20:37:51 +0200
From: Shawn Beasley <[email protected]>
Subject: Re: [otrs] Require service/sla
To: "User questions and discussions about OTRS." <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
you are welcome!
On Aug 28, 2012, at 20:36 , "Gadow, Shawn" <[email protected]> wrote:
> Worked like a charm thank you much
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.otrs.org/pipermail/otrs/attachments/20120828/0c56946d/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 28 Aug 2012 20:40:31 +0100 (BST)
From: "[email protected]"
<[email protected]>
Subject: Re: [otrs] Restricting the self-registration feature
To: "User questions and discussions about OTRS." <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hmm, I think you are missing the point. Our customers (the
organisations) are very well-known to us. The individual users within
those organisations are not. We are contractually committed to give
support to ANY user from within our customer's organisations. For some
of our customers there are literally hundreds of users that we serve
within a single customer organisation. We would kill ourselves if we
were to set up customer users on a person-by-person basis. And it would
probably infuriate our customers to wait for us to do so every time.
There's no way that our customers would hand out anything that looks
like a user registry, e.g LDAP or similar. These are well-guarded
secrets that cannot even be offered to the government unless required to
by law. Corporations treat even the usernames that they use internally
as well-guarded secrets that are not to leave the doorstep of the
organisation. (the idea is that knowing internal user names within a
corporation moves a potential hacker one step closer to his target).
This may all sound as if I cannot use your answer. Far from it. I can
use the CAPTCHA idea and will look into it.
Thank you.
Brian
________________________________
From: Gerald Young <[email protected]>
To: "[email protected]" <[email protected]>;
User questions and discussions about OTRS. <[email protected]>
Sent: Tuesday, August 28, 2012 5:57 PM
Subject: Re: [otrs] Restricting the self-registration feature
http://forums.otterhub.org/viewtopic.php?f=60&t=5941?(reCAPTCHA)
http://forums.otterhub.org/viewtopic.php?f=60&t=6586?(Accept customer
only emails as tickets)
or, ddt (don't do that). "our customers should be able to self serve as
much as possible."
?"our customers" and "self serve" are contradictory in this sense. If
they're your customers, you should already know who they are and have
them as customers (link to or import from existing data source). They
shouldn't have to register themselves if they're known to you. (Personal
opinion). Now, in the case of (large multinational corporation) this may
be a bit difficult to obtain and sync all the customers who will be able
to create tickets with your company, but on the other hand, if you're
that intimate, you may ask to get an ldap connection for Customer
queries. That will be helpful in this case:
1) add/remove users is not up to you
2) password management is customer-side (ldap)
3) customer knows her password is the same as office
4) no registration
5) zero administrative communication when users change
6) list is always uptodate
7) you don't burden your customers with registration
On Tue, Aug 28, 2012 at 11:33 AM, [email protected]
<[email protected]> wrote:
>Maybe I'm thick but I cannot figure this one out:
>
>I really like the self-registration feature. The idea is that our
customers should be able to self serve as much as possible.
>However at the moment anyone can register and I fear that when we go
live there will be lots of self-registration attempts by spammers.
>
>In the company I work for the customer organizations are well-known (a
dozen or so). The users within them are not (several hundreds).
>
>What I would like is that only users (customers) who register with
e-mail domains that are known to the OTRS system are allowed to
self-register on the portal.
>Example : We would allow [email protected] to self-register because
IKEA is a customer of ours and thus "@ikea.com" is a well-known e-mail
domain. Conversely if [email protected] tries to register he should
be rejected. (IKEA is not really a customer of ours in real world :-))
>
>Having the above functionality would of course require that OTRS would
store a list of known e-mail domains for each customer organization.
>
>But, but. There may be other ways to prevent misuse of the
self-registration feature. Perhaps some functionality that already
exist?? Any ideas ?
>
>Thx.
>
>
>Brian
>
>
>
>
>
>---------------------------------------------------------------------
>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.otrs.org/pipermail/otrs/attachments/20120828/719536b9/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 28 Aug 2012 22:00:29 +0200
From: Jean BROW <[email protected]>
Subject: Re: [otrs] Get emails double
To: "User questions and discussions about OTRS." <[email protected]>
Message-ID:
<caprubvponrwdv+6jxifqjt6e8ay09n7ncbmwc0arhmjvxxo...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
We have 2 different companys running on same OTRS version. Sometimes a
customer send email to both companies at same time in the "to" felt.
Shouldn't OTRS send out 2 seperate auto replay then from each e-mail
addresse in the "to" felt?
Thanks
2012/8/28 David Boyes <[email protected]>
> You could check the Message-ID: field in the incoming message against
a
> search of the current tickets in the OTRS postmaster code, but that
would
> be very time-consuming for any volume of mail. I?d go with Gerald?s
> comment: tell them not to do that, and deprecate one of the two
addresses
> and remove it in a systematic way (or turn one into an alias of the
other
> if for some good business reason both still need to exist). ****
>
>
---------------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.otrs.org/pipermail/otrs/attachments/20120828/d17a2579/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 28 Aug 2012 21:06:36 +0100
From: Steven Carr <[email protected]>
Subject: Re: [otrs] Get emails double
To: "User questions and discussions about OTRS." <[email protected]>
Message-ID:
<CALMep07MCF6mL8P=m-kL+TVkoDgrb+1JrjxGiDUuhBRfm3e4=q...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
It will only send out different replies if that's how you have
configured it. For example, if you just have 1 queue and both email
addresses filter into that queue then you are only going to have a
single autoresponse from 1 of the addresses. If you have 2 queues and
each email address filters into it's own queue then you can set the
autoresponse for each queue to the appropriate email address.
Steve
On 28 August 2012 21:00, Jean BROW <[email protected]> wrote:
> We have 2 different companys running on same OTRS version. Sometimes
a
> customer send email to both companies at same time in the "to" felt.
> Shouldn't OTRS send out 2 seperate auto replay then from each e-mail
> addresse in the "to" felt?
>
> Thanks
>
> 2012/8/28 David Boyes <[email protected]>
>>
>> You could check the Message-ID: field in the incoming message
against a
>> search of the current tickets in the OTRS postmaster code, but that
would be
>> very time-consuming for any volume of mail. I?d go with Gerald?s
comment:
>> tell them not to do that, and deprecate one of the two addresses and
remove
>> it in a systematic way (or turn one into an alias of the other if
for some
>> good business reason both still need to exist).
>>
>>
>>
---------------------------------------------------------------------
>> 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
>
>
>
>
---------------------------------------------------------------------
> 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
------------------------------
---------------------------------------------------------------------
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
End of otrs Digest, Vol 47, Issue 54
************************************
______________________________________________________________________
This inbound email has been scanned by the IS Mail Control service.
For more information please visit http://www.is.co.za
______________________________________________________________________
______________________________________________________________________
This outbound email has been scanned by the IS Mail Control service.
For more information please visit http://www.is.co.za
______________________________________________________________________---------------------------------------------------------------------
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
