Hi Hugh,
the link to the customer user database is defined by setting a customer user
login, not by customer id.
When you are connected to an Active Directory the customer user login is the
samaccountname.
On 19.10.2010, at 01:30, Hugh Kelley wrote:
> I've implemented the Postmaster-based assi
I've implemented the Postmaster-based assignment of X-OTRS-CustomerNo, which
works fine for setting the customer ID (email address). Unfortunately, the
user name, telephone, etc. are still mine.
I don't know if this is relevant, but this user has never sent a ticket via
email or logged into the p
I like postmaster-based assignment of customers described earlier. I may
try to implement that too, but my issue is with ownership.
One of my coworkers made the excellent point that this auto-assigning method
will break down as soon as an agent goes on vacation (assuming the
postmaster logic does
A standard function of emailing is the redirect function.
In Outlook this is called “Send again”.
In OTRS this function is called “Bounce”
I don’t like both terminologies tbh. but this is another discussion :-)
If you use this function, then the Email to OTRS is still send “From” the
original cu
If a user had sent me a ticket-worthy request, I'd forward the email to the
ticket email with my code word in the body.
#customer customerem...@domain.tld
The postmaster filter gets it then the ticket gets created and assigned to
the customer.
http://wiki.otrs.org/index.php?title=Create_a_ticket_i
I'm a bit at loss here, what is it exactly that you propose?
--
Mike
On Fri, Oct 15, 2010 at 3:09 PM, Hugh Kelley wrote:
> I agree about that goal.
>
> However, at least in my organization, there are a few users who
> hesitate to use the support system at all - they just email agents
> directly.
I agree about that goal.
However, at least in my organization, there are a few users who
hesitate to use the support system at all - they just email agents
directly. Then, as you well know, it is impossible for anyone else in
the team to participate in the support.
I thought this might be a way t
Actually, there was a design reason behind it; it's that we think it's
bad practice to assign tickets to a named user; you should rather
assign it to a single group.
That said, there probably can be use cases for not having this restriction.
Michiel Beijen
Senior Consultant
OTRS BV
Schipholweg 1
So far that seems like the best approach. I'll perform a ticket search for
all tickets owned by 1 and with a (human) agent-created article.
The last agent to contribute will probably become the lucky owner.
It seems that the ACL and Generic Agents can't search/filter by owner ID.
Out of curiosit
Hi,
Unfortunately this can’t be searched by OTRS directly.
You could write a simple SOAP script for that, which you could then execute by
Cron or the GenericAgent.
The SOAP script can also assign a new user if wanted.
The logic is then up to you or actually up to the script writer ;-)
On 04.1
That's an interesting idea. Unfortunately, I'm not sure the postmaster
can determine programatically who the owner should be.
Is there any way to edit the "before closing" validation so that I
could check there
(owner ID != 1)?
Hugh
On 10/2/10, Nils Leideck - ITSM wrote:
> Hi,
>
> You could us
Hi,
You could use the GenericAgent to change the owner.
On 02.10.2010, at 02:19, Hugh Kelley wrote:
> We have a relatively "open" permission model for our tickets. Most agents
> can add notes or replies without owning the ticket. As a result, some
> tickets go all the way to resolution witho
We have a relatively "open" permission model for our tickets. Most agents
can add notes or replies without owning the ticket. As a result, some
tickets go all the way to resolution without having the ID changed.
This means that some get closed with the root user (#1) as the owner. Is
there a wa
13 matches
Mail list logo
