date:20120718

Re: [otrs] New generic agent notification module

2012-07-18 Thread Shawn Beasley

Try this one http://www.youtube.com/watch?v=NoJe_6rvVpY

On Jul 9, 2012, at 15:51 , Alvaro Cordero wrote:

> Hello Florian,
> 
> That sounds like the Message of the day motd feature, I haven't see it
> yet but it is logical to have a setting into Sysconfig to do it.
> 
> Regards.
> 
> On Mon, Jul 9, 2012 at 7:14 AM, Florian Houel  wrote:
>> Hi List,
>> 
>> does anyone of you know anything about this 3.1 new feature (from
>> http://www.otrs.com/software/otrs-help-desk/whats-new/):
>> "A new generic agent notification module allows the administrator
>>   to define messages that will be shown in the agent web front-end
>>   when they login."
>> 
>> I've seen nothing in Admin nor Developer Guides and I browsed the list
>> with no luck.
>> Thank you in advance for any clue.
>> 
>> Regards,
>> Florian HOUEL
>> -
>> 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
> 
> 
> 
> -- 
> ___
> Alvaro Cordero Retana
> Consultor de Tecnologias
> Gridshield Monitoreo de Redes e
> Infraestructura.
> 2258-5757 ext 123
> alv...@gridshield.net
> www.gridshield.net
> -
> 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

Re: [otrs] Queue permission

2012-07-18 Thread Gerald Young

>
> Unfortunately, that doesn’t work very well if you are offering multiple
> services to each customer. If I read ITIL correctly, services vs customers
> is potentially a many-to-many relationship, eg services are predefined
> “things you offer” to zero or more consumers (note that in a
> highly-composed service-oriented architecture, the “customer” could be
> another service as well as a company), and there may be zero or more
> consumers that have access to a service. This gets particularly nasty if
> you involve a CMDB of managed objects that provide certain services to
> customers – you need to track the consumer to service mapping to calculate
> who is affected by a service failure, and multiple consumers get mapped to
> a single service.

The first part of this I don't follow because certainly you can create
*Services* CustomerAService  or CustomerA::Service1, CustomerA::Service2
Which you can assign to zero or more consumers. And zero or more customers
may have any, all, or none of the Services created.

The second part I don't follow precisely either, because there isn't any
more a default, "everyone in this queue" any more or less to "everyone with
this service" mapping, is there?

Further, if you want a service ACL, that seems just as reasonable as
creating a whole set of queues for a customer, assigning the appropriate
membership for agents, getting the agents to have that additional queue in
their "My Queues" ... versus, essentially, creating an ACL for services
template .pm file that you copy/modify/paste into Kernel/Config/Files and
establishing that the services Possible are [CompanyName]::Services1,
[CompanyName]::Services2 when matching CustomerID.

That ACL already wins all the time for the Customer, period. No additional
work necessary, independently verifiable. Now, if you have an Agent who
mucks around with that, that's a different issue, but now even if the wrong
checkbox is checked, the customer can't see it, because the ACL wins.

Now you can scan the services by search and see essentially the same
information.

Customers don't belong to queues. A queue belongs to a group. Customers
belong to group(s). Services belong to customers.

This isn't even *my* preference, thought, or anything, it's simply how OTRS
is. There's nothing to a Queue that tells you a queue's membership. I could
definitively tell you which users are assigned a service, and with a simple
(really simple) ACL I can tell you which services any customer can see,
even if an agent clicks the wrong one. For a Queue, I have to determine the
membership of the group to which the queue was assigned, and a big list of
queues and associated tickets for the queues that survive even if the
customer doesn't.

By the way, I'm not arguing for the sake of argument. People ask a bunch of
questions how to get queues to act like (customer-assigned) services and
then they'll ask for types to act like queues (how do I assign permissions
to types? How do I stop autoresponse for a given type? How do I assign
agents to a given type?). If it works that way for some people, great, but
it's really easy to get it done the OTRS way and still do what you want
ITIL wise.

Thank you again for your response.

On Wed, Jul 18, 2012 at 3:07 PM, David Boyes  wrote:

> I thank you for the insight, and in my limited view, I'm thinking of
> "Services" to handle the segregation as -- I'd hope -- only the assigned
> services would be available to the customer, meanwhile the queue would be
> the type of thing your agents would generically provide. The Service is
> unique to a customer, and does everything else mentioned here, without need
> for ACL.
>
> ** **
>
> At least, that's what I understand. Every plan is different, to be sure,
> but thinking in terms of what you present here, it seems reasonable that
> the only change you'd need to do to add a new customer would be to add a
> specific service and attach it to the customer. 
>
> ** **
>
> Unfortunately, that doesn’t work very well if you are offering multiple
> services to each customer. If I read ITIL correctly, services vs customers
> is potentially a many-to-many relationship, eg services are predefined
> “things you offer” to zero or more consumers (note that in a
> highly-composed service-oriented architecture, the “customer” could be
> another service as well as a company), and there may be zero or more
> consumers that have access to a service. This gets particularly nasty if
> you involve a CMDB of managed objects that provide certain services to
> customers – you need to track the consumer to service mapping to calculate
> who is affected by a service failure, and multiple consumers get mapped to
> a single service. 
>
> ** **
>
> Now those pesky checkboxes are the thing to bite you in the rear... (No,
> I'm not making fun, I'm serious. It's not extremely obvious that you
> haven't assigned a service to the competitor).
>
> ** **
>
> Yup. And that is exactly what bites you in

[otrs] configuration of multiple nagios with different label

2012-07-18 Thread Bianchi Massimo

Dear all,
I'm trying to configure the systemmonitoring extension to process different 
sources of nagios in parallel.

Step 1 (OK)
i can receive email from nagios source1, and tickets are correctly opened and 
closed.

FromAddressRegExp: sour...@email.com
HostRegExp: \s*Host:\s+(.*)\s*
CloseTicketRegExp: OK|UP
NewTicketRegExp: CRITICAL|DOWN
ServiceRegExp: \s*Service:\s+(.*)\s*
StateRegExp: \s*Stat[eo]:\s+(\S+)

incoing email content is
###
Host: TIM-DIR-SAME(10.1.2.[Descrizione: Descrizione: 8)]

Service:

State: DOWN
###
Step 2 (NOT OK)

I insert another source, which requires a different set of regexp:


FromAddressRegExp: sour...@email.com| 
sour...@email.com
HostRegExp: \s*Host:\s+(.*)\s*|id_unico:\s*(.+)\s*
CloseTicketRegExp: OK|UP|risolto
NewTicketRegExp: CRITICAL|DOWN|aperto
ServiceRegExp: \s*Service:\s+(.*)\s*|tipocaso:\s*(.+)\s*
StateRegExp: \s*Stat[eo]:\s+(\S+)|status:\s*(.+)\s*

Content is like:
##
EMAIL_AUTO
id_unico: 7972047871
rifcliente1: Npo Sistemi (xxx) Tel. email
rifcliente2: SS SP11, 20067 Non definito (ND)
categoria: Allarme
sottocategoria: Mancata Comunicazione
descrizione: - (SG21R0104B) 15.156.153.85 XX
priorita: basso
impatto: basso
livello: basso
urgenza: basso
tipocaso: incident
originecaso: allarme
status: aperto

##

I already tested the regexp with http://regexpal.com/ and they are working.

Apparently the SystemMonitoring recognizes only the first match for stateregexp 
and serviceregexp, and not the alternatives.
The system is working fine for FromAddressRegExp , closeticketregexp and 
openticketregexp.

Every time the system does not recognize this as a "nagios" integration, 
responding with

"Jul 18 17:24:28 npohd02 OTRS-otrs.PostMaster.pl-10[17179]: 
[Notice][Kernel::System::PostMaster::Filter::SystemMonitoring::Run] 
SystemMonitoring Mail: SystemMonitoring: Could not find host address and/or 
state in mail => Ignoring". Looks like it does not identify host or service.

To get it to work I have to force the input to Host/Service/State as a valid 
label.

Any ideas ?

Thanks,
Massimo





Massimo Bianchi

Npo Sistemi S.p.A. - Gruppo Npo
S.S.11 Padana Superiore 28
20063 Cernusco S/Naviglio MI
Tel: +39 02 92596.322
Cell: +39 348 5852275
Fax: +39 02 92140548

Skype: massimo.bianchi
Lync: massimo.bian...@nposistemi.it
Mail: massimo.bian...@nposistemi.it
Web: http://www.nposistemi.it



Massimo Bianchi

Npo Sistemi S.p.A. - Gruppo Npo
S.S.11 Padana Superiore 28
20063 Cernusco S/Naviglio MI
Tel: +39 02 92596.322
Cell: +39 348 5852275
Fax: +39 02 92140548

Skype: massimo.bianchi
Lync: massimo.bian...@nposistemi.it
Mail: massimo.bian...@nposistemi.it
Web: http://www.nposistemi.it

<>-
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

Re: [otrs] Queue permission

2012-07-18 Thread David Boyes

I thank you for the insight, and in my limited view, I'm thinking of "Services" 
to handle the segregation as -- I'd hope -- only the assigned services would be 
available to the customer, meanwhile the queue would be the type of thing your 
agents would generically provide. The Service is unique to a customer, and does 
everything else mentioned here, without need for ACL.

At least, that's what I understand. Every plan is different, to be sure, but 
thinking in terms of what you present here, it seems reasonable that the only 
change you'd need to do to add a new customer would be to add a specific 
service and attach it to the customer.

Unfortunately, that doesn't work very well if you are offering multiple 
services to each customer. If I read ITIL correctly, services vs customers is 
potentially a many-to-many relationship, eg services are predefined "things you 
offer" to zero or more consumers (note that in a highly-composed 
service-oriented architecture, the "customer" could be another service as well 
as a company), and there may be zero or more consumers that have access to a 
service. This gets particularly nasty if you involve a CMDB of managed objects 
that provide certain services to customers - you need to track the consumer to 
service mapping to calculate who is affected by a service failure, and multiple 
consumers get mapped to a single service.

Now those pesky checkboxes are the thing to bite you in the rear... (No, I'm 
not making fun, I'm serious. It's not extremely obvious that you haven't 
assigned a service to the competitor).

Yup. And that is exactly what bites you in the ass without ACLs that permit 
independent auditing. Having customer A see only one queue (or a small set of 
queues) and having agents scan the customer-dedicated queues for specific 
services (easy to do with a predefined query) they're trained for (or you can 
also pull those skills from a CMDB entry for a "Person"). It'd be a very nice 
option to have OTRS support such a multidimensional security model out of the 
box, but that's a lot of work for them for a fairly small community of users.
-
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

Re: [otrs] hide queue in web interface

2012-07-18 Thread Gerald Young

I don't know if this is good or bad. Obviously, it's not what you want, but
one line of thinking is that the ACL restricts the only queues that the
Customer can be moved to. Given that, you could give q2 as a Possible
option but restrict it from displaying by customer group nonmembership (for
instance, agent escalation).

On Wed, Jul 18, 2012 at 5:41 AM, Stefano Ricci  wrote:

> i find a problem...
> now an agent can not move the ticket in a queue filtered by acl...
>
> for example..
>
> in the queue list i set: q1 and q3... the customer can see only these..
>
> the agent that have the permission on q1,q2,q3, can not move the ticket
> from q1/q3 to q2...
>
>
>
> On 16 July 2012 13:13, Gerald Young  wrote:
>
>> You can't do it per ldap, but you can do it via ACL for something that
>> ldap knows.
>>
>> For instance, let's say you have UserLogin mapped to userPrincipalName
>> instead of sAMAccountName (highly recommended if you are expecting
>> collisions between usernames accross the different backends).
>> userPrincipalName would be username@login-domain
>>
>> Include userPrincipalName where you see:  CustomerKey =>
>> 'sAMAccountName',
>> and in the map
>> 'UserLogin', 'Username', 'userPrincipalName'
>> Then you can employ an ACL in Config.pm like this:
>>
>> $Self->{TicketAcl}->{'Unique-Descriptive-Name-for-ldap1'} = {
>>Properties => {
>>   CustomerUser => {
>>  UserLogin => ['[RegExp]login-domain$'],
>>   },
>>},
>>Possible => {
>>   Ticket => {
>>  Queue => ['Queue1', 'Queue2'],
>>   },
>>},
>> };
>> http://doc.otrs.org/3.1/en/html/ch18s03.html
>>
>> (This is not tested. It should work according to documentation, but may
>> have a syntax error.)
>>
>> Use at your own risk. Changing the sAMAccountName to userPrincipalName
>> could make old tickets for a given username inaccessible unless you use
>> Generic Agent to mass update: find old tickets with username x set
>> username= x@domain. Of course, if you've already had username
>> collisions, this would be a problem.
>>
>> Regards,
>> Gerald
>>
>> On Mon, Jul 16, 2012 at 4:05 AM, Stefano Ricci <
>> stefano.ri...@riccimatic.com> wrote:
>>
>>> hi to all i have this problem segregate customers to particolare
>>> queues...
>>>
>>> now i see that is impossible in the same istance but, it's possible,
>>> in the config.pm, the possibility to HIDE the queue in function of the
>>> login... for example... the user CUSTOMER1 logged in with active direcotry
>>> MYDOMAIN, have to see only in the web interface the queue1 and queue3
>>>
>>> -
>>> 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
>
-
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

Re: [otrs] hide queue in web interface

2012-07-18 Thread Stefano Ricci

i find a problem...
now an agent can not move the ticket in a queue filtered by acl...

for example..

in the queue list i set: q1 and q3... the customer can see only these..

the agent that have the permission on q1,q2,q3, can not move the ticket
from q1/q3 to q2...



On 16 July 2012 13:13, Gerald Young  wrote:

> You can't do it per ldap, but you can do it via ACL for something that
> ldap knows.
>
> For instance, let's say you have UserLogin mapped to userPrincipalName
> instead of sAMAccountName (highly recommended if you are expecting
> collisions between usernames accross the different backends).
> userPrincipalName would be username@login-domain
>
> Include userPrincipalName where you see:  CustomerKey => 'sAMAccountName',
> and in the map
> 'UserLogin', 'Username', 'userPrincipalName'
> Then you can employ an ACL in Config.pm like this:
>
> $Self->{TicketAcl}->{'Unique-Descriptive-Name-for-ldap1'} = {
>Properties => {
>   CustomerUser => {
>  UserLogin => ['[RegExp]login-domain$'],
>   },
>},
>Possible => {
>   Ticket => {
>  Queue => ['Queue1', 'Queue2'],
>   },
>},
> };
> http://doc.otrs.org/3.1/en/html/ch18s03.html
>
> (This is not tested. It should work according to documentation, but may
> have a syntax error.)
>
> Use at your own risk. Changing the sAMAccountName to userPrincipalName
> could make old tickets for a given username inaccessible unless you use
> Generic Agent to mass update: find old tickets with username x set
> username= x@domain. Of course, if you've already had username collisions,
> this would be a problem.
>
> Regards,
> Gerald
>
> On Mon, Jul 16, 2012 at 4:05 AM, Stefano Ricci <
> stefano.ri...@riccimatic.com> wrote:
>
>> hi to all i have this problem segregate customers to particolare
>> queues...
>>
>> now i see that is impossible in the same istance but, it's possible,
>> in the config.pm, the possibility to HIDE the queue in function of the
>> login... for example... the user CUSTOMER1 logged in with active direcotry
>> MYDOMAIN, have to see only in the web interface the queue1 and queue3
>>
>> -
>> 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

Re: [otrs] OTRS 3.1.7 New phone ticket URL with phonenumber as parameter

2012-07-18 Thread Wisniewski Jonas

Hi Michiel,

thanks for this fast answer!
But that don't solve my problem :-(
The link 
(otrs/index.pl?Action=AgentTicketPhone&Subaction=StoreNew&ExpandCustomerName=2&CustomerUser=122112)
 provided by Carlos already works with my 3.1.7 but for this link, I have to 
know the "customer ID" (CustomerUser =122112).
But in my case, I only know the phone number.



Mit freundlichen Grüßen
Jonas Wisniewski
Netzwerktechnik
___



EDUARD NEWERKLA BÜROMASCHINEN e.K.
Röntgenstr. 22
73431 Aalen
Telefon (0 73 61) 57 09-75
Fax  (0 73 61) 92 59-75
E-Mail jonas.wisniew...@newerkla.de 
Internet http://www.newerkla.de 

Amtsgericht Ulm HRA 500626
Sitz: Aalen

-Ursprüngliche Nachricht-
Von: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] Im Auftrag von 
Michiel Beijen
Gesendet: Mittwoch, 18. Juli 2012 08:59
An: User questions and discussions about OTRS.
Betreff: Re: [otrs] OTRS 3.1.7 New phone ticket URL with phonenumber as 
parameter

Hi Jonas,

This has already been fixed by Carlos Rodriguez in upcoming OTRS 3.1.8
- see this bug report which also has pointers at which files to replace for 
OTRS 3.1.7:
http://bugs.otrs.org/show_bug.cgi?id=8230

Michiel Beijen
Senior Consultant

OTRS BV
Schipholweg 103
2316 XC Leiden
The Netherlands

T: +31 71 8200 255
F: +31 71 8200 254
I: http://www.otrs.com

Get Connected ! Everything in sync with OTRS 3.1- Be an early bird with our 
special offer: http://j.mp/xN9wk1


On Wed, Jul 18, 2012 at 8:43 AM, Wisniewski Jonas 
 wrote:
>
> Hi everybody,
>
>
>
> I’m searching a way to create an URL so our Agents can use it with our CTI 
> software, where the caller number is given as a parameter to search for.
>
> In OTRS 3.0 it was possible with a link like this: 
> http://otrs/otrs/index.pl?Action=AgentTicketPhone&Subaction=StoreNew&E
> xpandCustomerName=1&From=(phonenumber)
>
> But the “..&From=” seems not to work anymore.
>
> I already read in the otterhub forum that this is caused by the 
> customer multiselect function (that we don’t need) but I haven’t found 
> any workaround yet L
>
> Is it possible to directly link to the popup window where I can select a 
> customer with caller number already filled in the searchfield?
>
> Or has anyone an idea how to solve this problem?
>
>
>
>
>
> Mit freundlichen Grüßen
>
> Jonas Wisniewski
>
> Netzwerktechnik
>
> ___
>
>
>
>
>
> EDUARD NEWERKLA BÜROMASCHINEN e.K.
>
> Röntgenstr. 22
>
> 73431 Aalen
>
> Telefon (0 73 61) 57 09-75
>
> Fax  (0 73 61) 92 59-75
>
> E-Mail jonas.wisniew...@newerkla.de
>
> Internet http://www.newerkla.de
>
>
>
> Amtsgericht Ulm HRA 500626
>
> Sitz: Aalen
>
>
>
>
> -
> 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

Re: [otrs] New generic agent notification module

Re: [otrs] Queue permission

[otrs] configuration of multiple nagios with different label

Re: [otrs] Queue permission

Re: [otrs] hide queue in web interface

Re: [otrs] hide queue in web interface

Re: [otrs] OTRS 3.1.7 New phone ticket URL with phonenumber as parameter

7 matches

Site Navigation

Mail list logo

Footer information