Re: [otrs] Need to set customers/agents's auth witn LDAP.
On 27.02.2013 00:10, Gerald Young wrote: On Tue, Feb 26, 2013 at 2:37 PM, Vadim S. Goncharov vgoncha...@nic.ru mailto:vgoncha...@nic.ru wrote: On 08.02.2013 18:20, Gerald Young wrote: My Company Tickets -- everyone who needs them should have the same CustomerId. http://forums.otterhub.org/__viewtopic.php?f=60t=7531 http://forums.otterhub.org/viewtopic.php?f=60t=7531 http://forums.otterhub.org/__viewtopic.php?f=60t=7531 http://forums.otterhub.org/viewtopic.php?f=60t=7531 For instance: Everyone in a department has the same CustomerId. Multi-department managers have a CustomerIds of depta,deptb,deptc. Done. From where have you obtained this information you've posted on forum? Docs, e.g. http://doc.otrs.org/3.2/en/__html/external-backends.html#__multi-customer-ids-ldap http://doc.otrs.org/3.2/en/html/external-backends.html#multi-customer-ids-ldap - don't say anything about CustomerID is really CompanyID and that way will work. Only comma-delimited field is described. OTRS docs had always been bad, though... From where? The code. The code says that customer_id is the value that is checked for the tickets that can be seen by a customer in Company Tickets. There is no such thing as Company ID but unofficially, I and others call customer_id CompanyID as it is essentially what customer_id represents. It is an attribute in free text attached to the ticket in the ticket table. This is not somewhat obvious from it's name. As I said, official docs doesn't mention this way, it gives the impression that this task is solved by comma-delimited way only. Can you guarantee that changing `customer_id` on all tickets (or what I supposed to do to enable this feature?) will break nothing, and that developers won't change this mechanism in future versions? I've digged a lot of OTRS code, but not all, I'm not sure even about current state, not even future. No guarantees. If it breaks, you get to keep both pieces. But seriously, you CAN break it by overloading fields or something. I'm not going to tell you what it will or will not break for you, but I will tell you that customer_id is primarily used for two purposes: 1) linking a company (when company support is enabled) to a customer and 2) to determine the tickets visible in Company Tickets. Guarantees roughly means officially documented (so this won't be something that will change suddenly breaking existing installations). Or at least word from developers we just forgot to document it, but yes, this is true, it is intended for exactly this use. With regard to the conflicting notification systems, you did that to yourself. Or, more accurately, your corporate policy did that to you. That's not a good approach to describe why things are so broken and then do nothing instead of thinking how to reach the goals - to fix them. There is nothing very special in this corporate policy, and it could easily be implemented, if some more options in OTRS had existed. This is a special policy. You are the first and only person who has presented in public forum in the past 3 years I've watched this that you are corporately required to send all outbound-to-customer responses to all agents in a queue. This is unique to you. It may not be special, but it's We use this OTRS install strictly for inside-company tickets (requests), and each queue usually corresponds to each working group of people (less than 10, usually). So it is quite logical here that people in each subdivision must know what their colleagues do on behalf of sibdivision's work. definitely not something that *generally* makes any sense to implement for the rest/majority of us. It does not necessary require some specific implementing - event-based notification is enough. There are just not enough events, and processing of existing event is somewhat broken. Here's another bad thing about OTRS - I've proposed Guys, I could do this work for you and contribute, just say what are your plans in this area to have no conflicts there in bug report. But the bug remains in NEW state for already THREE months! We need the following behaviour: when one agent replies something to customer in a ticket via Web-interface - that is, 'SendAnswer' via 'AgentTicketCompose' page - then all agents subscribed to this queue must receive mail notification with that text Really? That's not OTRS fault. It is. OTRS not send a notification about notification it has already automatically generated itself. Or have I say thanks to this being only just one garbage message instead of infinite loop of them? :) Who does that? You might as well yell at Microsoft because distribution group members don't receive emails sent by one of the
Re: [otrs] Need to set customers/agents's auth witn LDAP.
it is quite logical here that people in each subdivision must know what
their colleagues do on behalf of sibdivision's work.
Yes, but they don't *have* to be told that it happens. Also, what's the
point? Can they do anything about it? No, they just get told hey, somebody
replied to a ticket ... The same information, if they cared, they could
see from OTRS. But they don't, because it's not their ticket.
There are just not enough events
Do tell. What kind of event is missing? Or, how many events do you need
before you consider there are enough events?
processing of existing event is somewhat broken
Ambiguous statement is ambiguous.
Do you really propose sending dirty hacks as bugfixes? Seriously? (btw,
I've already had to fix another broken part, 'coz patch is, um, dirty).
The alternative being to complain that it's not fixed correctly? Even if
the hack is dirty, it's actually your responsibility to provide it to
anyone who asks who uses your code. (GPL)
Just because you hacked it doesn't mean that it has to be accepted and
incorporated as core code verbatim. You're not QC. You're simply giving
your version of, I fixed it this way. Yes, provide the dirty hacks as
bugfixes. If it works for you, it might work for someone else. Until
something official/better comes along, your code *is* (likely) the best way
to handle it.
For Guarantees:
Kernel/Modules/CustomerTicketOverview.pm CompanyTickets searches CustomerID.
If the current user has a CustomerID or one of CustomerIDs, that matches
that stored with the ticket $Self-{UserObject}-CustomerIDs( User =
$Self-{UserLogin} ), it will be shown in Company Tickets.
CustomerIDs is in Kernel/System/CustomerUser.pm and referenced in
CustomerUser/DB.pm and CustomerUserLDAP.pm
Whether delimited with semicolons, commas, or pipes:
# used separators
for my $Split ( ';', ',', '|' )
the values of customer_ids are obtained and then on that array, pushed the
CustomerID.of the current customer.
# use also the primary customer id
if ( $Data{UserCustomerID} !$Self-{ExcludePrimaryCustomerID} ) {
push @CustomerIDs, $Data{UserCustomerID};
}
This array/list is then sent to the CustomerTicketOverview module, which
searches against that list.
What happens if you change the customer_id in a historical ticket? Not
much, ticket-wise. (This based also on personal experience). It won't
prevent a user from accessing her own ticket, but may change her
permissions regarding visibility in Company Tickets
Do you think they'll change this paradigm? No. Not that I'm 100% sure on
this, but considering how integral it is to accomplishing this goal, I
can't imagine that they'll change it any time soon.
Look at what the CustomerID *does*, especially with what happens when
CustomerCompanySupport is enabled. This is a critical function to just
arbitrarily change for the sake of New version, let's just throw this
out.
But no documentation ok. read
thishttp://doc.otrs.org/3.0/en/html/x2282.html#multi-customer-ids-dband
then understand that the default mechanism of OTRS is that everyone
has
a different customer_id. There are essentially three ways to make Company
Tickets work in practice.
1) A real pain in the butt, but a Supervisor has a customer_ids field of
all the individual customer_id whom he watches.
2) Everyone in a company or department has the same customer_id (and sees
all everyone's-with-the-same-customer_id tickets in Company Tickets)
3) Everyone in a company or department has the same customer_id, but only
the Supervisor or Department Manager sees Company Tickets
(CustomerGroupMembership for access privileges) and multi-department
supervisors have customer_ids of departmentA,departmentB
Look at the code. If the result of CustomerIDs includes all of the
current customers' customer_ids (if exist) AND the customer_id, and this is
what's being used for TicketSearch for Company tickets.
OK, so the ability to reuse customer_id is undocumented. I figured it out,
so I'm sharing the knowledge. Until something official/better comes along,
my post is (likely) the best way to handle 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] Need to set customers/agents's auth witn LDAP.
On 01.03.2013 21:47, Gerald Young wrote:
it is quite logical here that people in each subdivision must know what
their colleagues do on behalf of sibdivision's work.
Yes, but they don't *have* to be told that it happens. Also, what's the
point? Can they do anything about it? No, they just get told hey, somebody
replied to a ticket ... The same information, if they cared, they could see
from OTRS. But they don't, because it's not their ticket.
That's simply not true, because it depends on workflow. Our agents receive
full text copy, not just somebody replied. As an example, just today I saw
messages of the ticket locked by another agent in one of my queues, and
decided to care, and helped that agent and originator. I was forced to leave
note-external, though, because ticket was locked and I couldn't answer, but
that's another story about another flaw.
There are just not enough events
Do tell. What kind of event is missing? Or, how many events do you need
before you consider there are enough events?
Are you trolling? I told this several times already, referring to text of
bug#8953, in which I described possible solution.
processing of existing event is somewhat broken
Ambiguous statement is ambiguous.
Do you really propose sending dirty hacks as bugfixes? Seriously? (btw,
I've already had to fix another broken part, 'coz patch is, um, dirty).
The alternative being to complain that it's not fixed correctly? Even if the
hack is dirty, it's actually your responsibility to provide it to anyone
who asks who uses your code. (GPL)
Of course my patch is available to everyone in my company. You missing the
point that complain is not about not fixed, but rather they don't give me
information about preferred way to change that subsystem. That's a
difference between I want them to do the work and I want to hear there
are no barriers for me to this work for them.
Just because you hacked it doesn't mean that it has to be accepted and
incorporated as core code verbatim. You're not QC. You're simply giving your
version of, I fixed it this way. Yes, provide the dirty hacks as bugfixes.
If it works for you, it might work for someone else. Until something
official/better comes along, your code *is* (likely) the best way to handle it.
Once again, there are not just 2 alternatives they fix vs my dirty hack,
but I prefer 3rd I could do better, if given some info. It is really much
simpler to write several paragraphs of me, and I will code, rather than do
the work themselves, right?
For Guarantees:
Kernel/Modules/CustomerTicketOverview.pm CompanyTickets searches CustomerID.
If the current user has a CustomerID or one of CustomerIDs, that matches
that stored with the ticket $Self-{UserObject}-CustomerIDs( User =
$Self-{UserLogin} ), it will be shown in Company Tickets.
CustomerIDs is in Kernel/System/CustomerUser.pm and referenced in
CustomerUser/DB.pm and CustomerUserLDAP.pm
Whether delimited with semicolons, commas, or pipes:
# used separators
for my $Split ( ';', ',', '|' )
the values of customer_ids are obtained and then on that array, pushed the
CustomerID.of the current customer.
# use also the primary customer id
if ( $Data{UserCustomerID} !$Self-{ExcludePrimaryCustomerID} ) {
push @CustomerIDs, $Data{UserCustomerID};
}
This array/list is then sent to the CustomerTicketOverview module, which
searches against that list.
What happens if you change the customer_id in a historical ticket? Not
much, ticket-wise. (This based also on personal experience). It won't
prevent a user from accessing her own ticket, but may change her permissions
regarding visibility in Company Tickets
Do you think they'll change this paradigm? No. Not that I'm 100% sure on
this, but considering how integral it is to accomplishing this goal, I can't
imagine that they'll change it any time soon.
Look at what the CustomerID *does*, especially with what happens when
CustomerCompanySupport is enabled. This is a critical function to just
arbitrarily change for the sake of New version, let's just throw this out.
But no documentation ok. read this
http://doc.otrs.org/3.0/en/html/x2282.html#multi-customer-ids-db and then
understand that the default mechanism of OTRS is that everyone has a
different customer_id. There are essentially three ways to make Company
Tickets work in practice.
Surely I read this doc. And I referred to it several times already in this
flame (though you skip the quoting). The problem is that this doc does not
_imply_ that CustomerID is non-unique, and it is actually a CompanyID.
Instead, it forces the impression that your way #1:
1) A real pain in the butt, but a Supervisor has a customer_ids field of all
the individual customer_id whom he watches.
...is the only possible way to solve the problem. This is not even something
obvious if you even read some code, because OTRS is big, and nobody reads
all relevant code at once. E.g. I didn't ever dig
Re: [otrs] Need to set customers/agents's auth witn LDAP.
that's a story about another flaw
No, it's just not what you would do, but it's the way the system works.
It's not your ticket to fix. It's the locked owner's ticket to fix. It's
specifically so you don't barge in there confusing both the agent and the
customer on who, exactly, is handling the ticket.
The proper way to do what you want is to create a Ticket Event. It's not a
bug. Nobody but you needs it, and it's not necessary in core code, and will
likely keep across upgrades.
how?
http://forums.otterhub.org/viewtopic.php?f=60t=10090
Psuedo code:
Check for ArticleSend
Get the queue for the ticket.
Get the queuegroup
Get the members of the group
Get the message that's being sent
Send to the members of the group
It's all nice, neat, tidy, and yours.
On Fri, Mar 1, 2013 at 1:34 PM, Vadim S. Goncharov vgoncha...@nic.ruwrote:
On 01.03.2013 21:47, Gerald Young wrote:
it is quite logical here that people in each subdivision must know what
their colleagues do on behalf of sibdivision's work.
Yes, but they don't *have* to be told that it happens. Also, what's the
point? Can they do anything about it? No, they just get told hey,
somebody
replied to a ticket ... The same information, if they cared, they could
see
from OTRS. But they don't, because it's not their ticket.
That's simply not true, because it depends on workflow. Our agents receive
full text copy, not just somebody replied. As an example, just today I
saw messages of the ticket locked by another agent in one of my queues, and
decided to care, and helped that agent and originator. I was forced to
leave note-external, though, because ticket was locked and I couldn't
answer, but that's another story about another flaw.
There are just not enough events
Do tell. What kind of event is missing? Or, how many events do you need
before you consider there are enough events?
Are you trolling? I told this several times already, referring to text of
bug#8953, in which I described possible solution.
processing of existing event is somewhat broken
Ambiguous statement is ambiguous.
Do you really propose sending dirty hacks as bugfixes? Seriously? (btw,
I've already had to fix another broken part, 'coz patch is, um, dirty).
The alternative being to complain that it's not fixed correctly? Even if
the
hack is dirty, it's actually your responsibility to provide it to anyone
who asks who uses your code. (GPL)
Of course my patch is available to everyone in my company. You missing the
point that complain is not about not fixed, but rather they don't give
me information about preferred way to change that subsystem. That's a
difference between I want them to do the work and I want to hear there
are no barriers for me to this work for them.
Just because you hacked it doesn't mean that it has to be accepted and
incorporated as core code verbatim. You're not QC. You're simply giving
your
version of, I fixed it this way. Yes, provide the dirty hacks as
bugfixes.
If it works for you, it might work for someone else. Until something
official/better comes along, your code *is* (likely) the best way to
handle it.
Once again, there are not just 2 alternatives they fix vs my dirty
hack, but I prefer 3rd I could do better, if given some info. It is
really much simpler to write several paragraphs of me, and I will code,
rather than do the work themselves, right?
For Guarantees:
Kernel/Modules/**CustomerTicketOverview.pm CompanyTickets searches
CustomerID.
If the current user has a CustomerID or one of CustomerIDs, that matches
that stored with the ticket $Self-{UserObject}-**CustomerIDs( User =
$Self-{UserLogin} ), it will be shown in Company Tickets.
CustomerIDs is in Kernel/System/CustomerUser.pm and referenced in
CustomerUser/DB.pm and CustomerUserLDAP.pm
Whether delimited with semicolons, commas, or pipes:
# used separators
for my $Split ( ';', ',', '|' )
the values of customer_ids are obtained and then on that array, pushed the
CustomerID.of the current customer.
# use also the primary customer id
if ( $Data{UserCustomerID} !$Self-{**ExcludePrimaryCustomerID}
) {
push @CustomerIDs, $Data{UserCustomerID};
}
This array/list is then sent to the CustomerTicketOverview module, which
searches against that list.
What happens if you change the customer_id in a historical ticket? Not
much, ticket-wise. (This based also on personal experience). It won't
prevent a user from accessing her own ticket, but may change her
permissions
regarding visibility in Company Tickets
Do you think they'll change this paradigm? No. Not that I'm 100% sure on
this, but considering how integral it is to accomplishing this goal, I
can't
imagine that they'll change it any time soon.
Look at what the CustomerID *does*, especially with what happens when
CustomerCompanySupport is enabled. This is a critical function to just
arbitrarily change for the sake of New version,
Re: [otrs] Need to set customers/agents's auth witn LDAP.
On 08.02.2013 18:20, Gerald Young wrote: My Company Tickets -- everyone who needs them should have the same CustomerId. http://forums.otterhub.org/viewtopic.php?f=60t=7531 http://forums.otterhub.org/viewtopic.php?f=60t=7531 For instance: Everyone in a department has the same CustomerId. Multi-department managers have a CustomerIds of depta,deptb,deptc. Done. From where have you obtained this information you've posted on forum? Docs, e.g. http://doc.otrs.org/3.2/en/html/external-backends.html#multi-customer-ids-ldap - don't say anything about CustomerID is really CompanyID and that way will work. Only comma-delimited field is described. OTRS docs had always been bad, though... Can you guarantee that changing `customer_id` on all tickets (or what I supposed to do to enable this feature?) will break nothing, and that developers won't change this mechanism in future versions? I've digged a lot of OTRS code, but not all, I'm not sure even about current state, not even future. With regard to the conflicting notification systems, you did that to yourself. Or, more accurately, your corporate policy did that to you. That's not a good approach to describe why things are so broken and then do nothing instead of thinking how to reach the goals - to fix them. There is nothing very special in this corporate policy, and it could easily be implemented, if some more options in OTRS had existed. Here's another bad thing about OTRS - I've proposed Guys, I could do this work for you and contribute, just say what are your plans in this area to have no conflicts there in bug report. But the bug remains in NEW state for already THREE months! We need the following behaviour: when one agent replies something to customer in a ticket via Web-interface - that is, 'SendAnswer' via 'AgentTicketCompose' page - then all agents subscribed to this queue must receive mail notification with that text Really? That's not OTRS fault. It is. OTRS not send a notification about notification it has already automatically generated itself. Or have I say thanks to this being only just one garbage message instead of infinite loop of them? :) Who does that? You might as well yell at Microsoft because distribution group members don't receive emails sent by one of the distribution group member to someone who's not a distribution group member. Speaking of -- that is the solution to your problem. Create an email distribution group for each of the queues and cc or bcc that queue's distribution group when sending the Answer. And then every agent on every answer must fill Cc:/Bcc: by hand? Why ever men should bother about things machine could easily do? Why should I put more work on people because of bug? It won't stop doubling, though. Turn off notifications in agent preferences. You didn't read carefully, doubling was fixed in bug#7407, now it just one garbage message (body solely of '-' char) to agents on autoreply to client. Actually, for our agents not even so, because I fixed this with a dirty one-line patch to appropriate .pm. I don't submit it, though, because it is not a solution to a broken system but the crutches to local situation (solutions were proposed in bug report). P.S. BTW, your mail client's quoting is broken: On Fri, Feb 8, 2013 at 9:03 AM, Vadim S. Goncharov vgoncha...@nic.ru mailto:vgoncha...@nic.ru wrote: On 08.02.2013 17:21, Steven Carr wrote: On 8 February 2013 13:05, Israel Garciaiga3...@yahoo.com mailto:iga3...@yahoo.com wrote: OK Steve, so I should edit /opt/otrs/Kernel/Config.pm, add my LDAP settings, restart OTRS and volia!? Also, I have seen in Admin/SysConfig/Frontend::__Customer::Auth the same parameters I have added to /opt/otrs/Kernel/Config.pm, should I edit them using this web page or editing directly the /opt/otrs/Kernel/Config.pm file? Don't quite know about the voila, more like cross your fingers and hope it doesn't collapse in a heap. One of my big issues with OTRS is the configuration is utter crap. Too There are many places in OTRS which are crappy. E.g. different conflicting notification systems (see e.g. bug #8953), and, on-topic, customer groups. We have group attibute in LDAP for customers, and simple intuitive and SCALABLE solution would be just use that word of customer to regulate access. But My Company tickets in OTRS requires comma-delimited list of user1,user2,...user100500 for EVERY user. Brain-damaged. many places to configure things, everything should really be just configured through Sysconfig instead of having to mess about with text files (and perl based text files at that), and ideally stored in the database to make upgrades a lot easier than worrying about which config files you need and don't need.
Re: [otrs] Need to set customers/agents's auth witn LDAP.
On Tue, Feb 26, 2013 at 2:37 PM, Vadim S. Goncharov vgoncha...@nic.ruwrote: On 08.02.2013 18:20, Gerald Young wrote: My Company Tickets -- everyone who needs them should have the same CustomerId. http://forums.otterhub.org/**viewtopic.php?f=60t=7531http://forums.otterhub.org/viewtopic.php?f=60t=7531 http://forums.otterhub.org/**viewtopic.php?f=60t=7531http://forums.otterhub.org/viewtopic.php?f=60t=7531 For instance: Everyone in a department has the same CustomerId. Multi-department managers have a CustomerIds of depta,deptb,deptc. Done. From where have you obtained this information you've posted on forum? Docs, e.g. http://doc.otrs.org/3.2/en/**html/external-backends.html#** multi-customer-ids-ldaphttp://doc.otrs.org/3.2/en/html/external-backends.html#multi-customer-ids-ldap- don't say anything about CustomerID is really CompanyID and that way will work. Only comma-delimited field is described. OTRS docs had always been bad, though... From where? The code. The code says that customer_id is the value that is checked for the tickets that can be seen by a customer in Company Tickets. There is no such thing as Company ID but unofficially, I and others call customer_id CompanyID as it is essentially what customer_id represents. It is an attribute in free text attached to the ticket in the ticket table. Can you guarantee that changing `customer_id` on all tickets (or what I supposed to do to enable this feature?) will break nothing, and that developers won't change this mechanism in future versions? I've digged a lot of OTRS code, but not all, I'm not sure even about current state, not even future. No guarantees. If it breaks, you get to keep both pieces. But seriously, you CAN break it by overloading fields or something. I'm not going to tell you what it will or will not break for you, but I will tell you that customer_id is primarily used for two purposes: 1) linking a company (when company support is enabled) to a customer and 2) to determine the tickets visible in Company Tickets. With regard to the conflicting notification systems, you did that to yourself. Or, more accurately, your corporate policy did that to you. That's not a good approach to describe why things are so broken and then do nothing instead of thinking how to reach the goals - to fix them. There is nothing very special in this corporate policy, and it could easily be implemented, if some more options in OTRS had existed. This is a special policy. You are the first and only person who has presented in public forum in the past 3 years I've watched this that you are corporately required to send all outbound-to-customer responses to all agents in a queue. This is unique to you. It may not be special, but it's definitely not something that *generally* makes any sense to implement for the rest/majority of us. Here's another bad thing about OTRS - I've proposed Guys, I could do this work for you and contribute, just say what are your plans in this area to have no conflicts there in bug report. But the bug remains in NEW state for already THREE months! We need the following behaviour: when one agent replies something to customer in a ticket via Web-interface - that is, 'SendAnswer' via 'AgentTicketCompose' page - then all agents subscribed to this queue must receive mail notification with that text Really? That's not OTRS fault. It is. OTRS not send a notification about notification it has already automatically generated itself. Or have I say thanks to this being only just one garbage message instead of infinite loop of them? :) Who does that? You might as well yell at Microsoft because distribution group members don't receive emails sent by one of the distribution group member to someone who's not a distribution group member. Speaking of -- that is the solution to your problem. Create an email distribution group for each of the queues and cc or bcc that queue's distribution group when sending the Answer. And then every agent on every answer must fill Cc:/Bcc: by hand? Why ever men should bother about things machine could easily do? Why should I put more work on people because of bug? Yes, this is your policy. It's not normal. Read my paragraph above. You are asking for exactly the same thing as what I posted. How would you make Outlook behave according to this? This is not a bug. This is a feature request. It won't stop doubling, though. Turn off notifications in agent preferences. You didn't read carefully, doubling was fixed in bug#7407, now it just one garbage message (body solely of '-' char) to agents on autoreply to client. Actually, for our agents not even so, because I fixed this with a dirty one-line patch to appropriate .pm. I don't submit it, though, because it is not a solution to a broken system but the crutches to local situation (solutions were proposed in bug report). So, you are part of the problem for not submitting it?
Re: [otrs] Need to set customers/agents's auth witn LDAP.
From the manual, I see I have to add all these lines to get agents and customers authenticating with ldap (AD), but not sure if we have to add it to /opt/otrs/Kernel/Config.pm or /opt/otrs/Kernel/Config/Default.pm? Or in other place. /opt/otrs/Kernel/Config.pm - your settings/overrides go in here /opt/otrs/Kernel/Config/Default.pm - you should not modify this config file *at all* OK Steve, so I should edit /opt/otrs/Kernel/Config.pm, add my LDAP settings, restart OTRS and volia!? Also, I have seen in Admin/SysConfig/Frontend::Customer::Auth the same parameters I have added to /opt/otrs/Kernel/Config.pm, should I edit them using this web page or editing directly the /opt/otrs/Kernel/Config.pm file? Thaanks! Regards, Israel.- 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] Need to set customers/agents's auth witn LDAP.
On 8 February 2013 13:05, Israel Garcia iga3...@yahoo.com wrote: OK Steve, so I should edit /opt/otrs/Kernel/Config.pm, add my LDAP settings, restart OTRS and volia!? Also, I have seen in Admin/SysConfig/Frontend::Customer::Auth the same parameters I have added to /opt/otrs/Kernel/Config.pm, should I edit them using this web page or editing directly the /opt/otrs/Kernel/Config.pm file? Don't quite know about the voila, more like cross your fingers and hope it doesn't collapse in a heap. One of my big issues with OTRS is the configuration is utter crap. Too many places to configure things, everything should really be just configured through Sysconfig instead of having to mess about with text files (and perl based text files at that), and ideally stored in the database to make upgrades a lot easier than worrying about which config files you need and don't need. I'm not sure the order in which the settings are applied but I would guess that anything you put in Kernel/Config.pm will override anything you configure in SysConfig (someone can correct me if I'm wrong). So just make your changes in one place and one place only and they will be added to the overall config. Steve - 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] Need to set customers/agents's auth witn LDAP.
On 08.02.2013 17:21, Steven Carr wrote: On 8 February 2013 13:05, Israel Garciaiga3...@yahoo.com wrote: OK Steve, so I should edit /opt/otrs/Kernel/Config.pm, add my LDAP settings, restart OTRS and volia!? Also, I have seen in Admin/SysConfig/Frontend::Customer::Auth the same parameters I have added to /opt/otrs/Kernel/Config.pm, should I edit them using this web page or editing directly the /opt/otrs/Kernel/Config.pm file? Don't quite know about the voila, more like cross your fingers and hope it doesn't collapse in a heap. One of my big issues with OTRS is the configuration is utter crap. Too There are many places in OTRS which are crappy. E.g. different conflicting notification systems (see e.g. bug #8953), and, on-topic, customer groups. We have group attibute in LDAP for customers, and simple intuitive and SCALABLE solution would be just use that word of customer to regulate access. But My Company tickets in OTRS requires comma-delimited list of user1,user2,...user100500 for EVERY user. Brain-damaged. many places to configure things, everything should really be just configured through Sysconfig instead of having to mess about with text files (and perl based text files at that), and ideally stored in the database to make upgrades a lot easier than worrying about which config files you need and don't need. I'm not sure the order in which the settings are applied but I would guess that anything you put in Kernel/Config.pm will override anything you configure in SysConfig (someone can correct me if I'm wrong). Yes. Actually, Config.pm is applied TWO times: before SysConfig, and once again after. So just make your changes in one place and one place only and they will be added to the overall config. That's not always possible :) -- Vadim Goncharov vgoncha...@nic.ru RU-Center NET Departmenthttp://www.nic.ru NET-SYS Group phone:+7(495)737-7646 (ext.4019) - 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] Need to set customers/agents's auth witn LDAP.
My Company Tickets -- everyone who needs them should have the same CustomerId. http://forums.otterhub.org/viewtopic.php?f=60t=7531 For instance: Everyone in a department has the same CustomerId. Multi-department managers have a CustomerIds of depta,deptb,deptc. Done. With regard to the conflicting notification systems, you did that to yourself. Or, more accurately, your corporate policy did that to you. We need the following behaviour: when one agent replies something to customer in a ticket via Web-interface - that is, 'SendAnswer' via 'AgentTicketCompose' page - then all agents subscribed to this queue must receive mail notification with that text Really? That's not OTRS fault. Who does that? You might as well yell at Microsoft because distribution group members don't receive emails sent by one of the distribution group member to someone who's not a distribution group member. Speaking of -- that is the solution to your problem. Create an email distribution group for each of the queues and cc or bcc that queue's distribution group when sending the Answer. It won't stop doubling, though. Turn off notifications in agent preferences. On Fri, Feb 8, 2013 at 9:03 AM, Vadim S. Goncharov vgoncha...@nic.ruwrote: On 08.02.2013 17:21, Steven Carr wrote: On 8 February 2013 13:05, Israel Garciaiga3...@yahoo.com wrote: OK Steve, so I should edit /opt/otrs/Kernel/Config.pm, add my LDAP settings, restart OTRS and volia!? Also, I have seen in Admin/SysConfig/Frontend::**Customer::Auth the same parameters I have added to /opt/otrs/Kernel/Config.pm, should I edit them using this web page or editing directly the /opt/otrs/Kernel/Config.pm file? Don't quite know about the voila, more like cross your fingers and hope it doesn't collapse in a heap. One of my big issues with OTRS is the configuration is utter crap. Too There are many places in OTRS which are crappy. E.g. different conflicting notification systems (see e.g. bug #8953), and, on-topic, customer groups. We have group attibute in LDAP for customers, and simple intuitive and SCALABLE solution would be just use that word of customer to regulate access. But My Company tickets in OTRS requires comma-delimited list of user1,user2,...user100500 for EVERY user. Brain-damaged. many places to configure things, everything should really be just configured through Sysconfig instead of having to mess about with text files (and perl based text files at that), and ideally stored in the database to make upgrades a lot easier than worrying about which config files you need and don't need. I'm not sure the order in which the settings are applied but I would guess that anything you put in Kernel/Config.pm will override anything you configure in SysConfig (someone can correct me if I'm wrong). Yes. Actually, Config.pm is applied TWO times: before SysConfig, and once again after. So just make your changes in one place and one place only and they will be added to the overall config. That's not always possible :) -- Vadim Goncharov vgoncha...@nic.ru RU-Center NET Departmenthttp://www.nic.ru NET-SYS Group phone:+7(495)737-7646 (ext.4019) --**--**- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/**pipermail/otrshttp://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/**listinfo/otrshttp://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] Need to set customers/agents's auth witn LDAP.
OK.. Thanks!! De: Gerald Young cryth...@gmail.com Para: User questions and discussions about OTRS. otrs@otrs.org Enviado: Viernes 8 de febrero de 2013 15:20 Asunto: Re: [otrs] Need to set customers/agents's auth witn LDAP. My Company Tickets -- everyone who needs them should have the same CustomerId. http://forums.otterhub.org/viewtopic.php?f=60t=7531 For instance: Everyone in a department has the same CustomerId. Multi-department managers have a CustomerIds of depta,deptb,deptc. Done. With regard to the conflicting notification systems, you did that to yourself. Or, more accurately, your corporate policy did that to you. We need the following behaviour: when one agent replies something to customer in a ticket via Web-interface - that is, 'SendAnswer' via 'AgentTicketCompose' page - then all agents subscribed to this queue must receive mail notification with that text Really? That's not OTRS fault. Who does that? You might as well yell at Microsoft because distribution group members don't receive emails sent by one of the distribution group member to someone who's not a distribution group member. Speaking of -- that is the solution to your problem. Create an email distribution group for each of the queues and cc or bcc that queue's distribution group when sending the Answer. It won't stop doubling, though. Turn off notifications in agent preferences. On Fri, Feb 8, 2013 at 9:03 AM, Vadim S. Goncharov vgoncha...@nic.ru wrote: On 08.02.2013 17:21, Steven Carr wrote: On 8 February 2013 13:05, Israel Garciaiga3...@yahoo.com wrote: OK Steve, so I should edit /opt/otrs/Kernel/Config.pm, add my LDAP settings, restart OTRS and volia!? Also, I have seen in Admin/SysConfig/Frontend::Customer::Auth the same parameters I have added to /opt/otrs/Kernel/Config.pm, should I edit them using this web page or editing directly the /opt/otrs/Kernel/Config.pm file? Don't quite know about the voila, more like cross your fingers and hope it doesn't collapse in a heap. One of my big issues with OTRS is the configuration is utter crap. Too There are many places in OTRS which are crappy. E.g. different conflicting notification systems (see e.g. bug #8953), and, on-topic, customer groups. We have group attibute in LDAP for customers, and simple intuitive and SCALABLE solution would be just use that word of customer to regulate access. But My Company tickets in OTRS requires comma-delimited list of user1,user2,...user100500 for EVERY user. Brain-damaged. many places to configure things, everything should really be just configured through Sysconfig instead of having to mess about with text files (and perl based text files at that), and ideally stored in the database to make upgrades a lot easier than worrying about which config files you need and don't need. I'm not sure the order in which the settings are applied but I would guess that anything you put in Kernel/Config.pm will override anything you configure in SysConfig (someone can correct me if I'm wrong). Yes. Actually, Config.pm is applied TWO times: before SysConfig, and once again after. So just make your changes in one place and one place only and they will be added to the overall config. That's not always possible :) -- Vadim Goncharov vgoncha...@nic.ru RU-Center NET Department http://www.nic.ru NET-SYS Group phone:+7(495)737-7646 (ext.4019) - 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] Need to set customers/agents's auth witn LDAP.
One of my big issues with OTRS is the configuration is utter crap. Too many places to configure things, everything should really be just configured through Sysconfig instead of having to mess about with text files (and perl based text files at that), and ideally stored in the database to make upgrades a lot easier than worrying about which config files you need and don't need. Amen, brother. Software this complex needs to have settings in one, migrateable place with clear exit points for customized processing of those settings. The database is the only logical place for that information to live. - 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] Need to set customers/agents's auth witn LDAP.
The database is the only logical place for that information to live Static connection information? Maybe not. Configuration? ... I'd be inclined to concur. The problem with the database method with a table based data source is the freeform data. Move it to something non-sql, like perhaps ldap or other NoSQL, and this should be much better handled as desired. On Fri, Feb 8, 2013 at 10:29 AM, David Boyes dbo...@sinenomine.net wrote: One of my big issues with OTRS is the configuration is utter crap. Too many places to configure things, everything should really be just configured through Sysconfig instead of having to mess about with text files (and perl based text files at that), and ideally stored in the database to make upgrades a lot easier than worrying about which config files you need and don't need. Amen, brother. Software this complex needs to have settings in one, migrateable place with clear exit points for customized processing of those settings. The database is the only logical place for that information to live. - 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] Need to set customers/agents's auth witn LDAP.
On 8 February 2013 15:55, Gerald Young cryth...@gmail.com wrote: The database is the only logical place for that information to live Static connection information? Maybe not. Configuration? ... I'd be inclined to concur. The problem with the database method with a table based data source is the freeform data. Move it to something non-sql, like perhaps ldap or other NoSQL, and this should be much better handled as desired. Yes I agree that there does need to be a level of configuration that needs to be maintained like database for the initial connection, but other than that I don't really care what is used as the backend storage for the config. They can continue to use flat files, but it must be a single location: db, single file or folder (containing live config and live config only, no other random backup or crap files) that can be picked up and dropped into another system to make upgrades easier. I've fallen into the pit of despair in v2.x by customising OTRS heavily then spend 3 months trying to upgrade it and fix the previous customisation, so now with v3 I tend to stick with stock OTRS, but even then it's still a right PITA to upgrade as it's so intertwined with the data and config that it consumed, no clear boundary. Steve - 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] Need to set customers/agents's auth witn LDAP.
Actually, it's not that bad. At the most basic level, you can treat the static info as an array of text lines and read/interpret them sequentially. That at least doesn't bind the information to a file on a specific server and gives you much more granular control of configuration management on operating systems that have essentially only two privilege levels (root/non-root). As an interim step on that clustered OTRS system I mentioned in another thread, we've stored the config files in git and modified the OTRS startup script to check out the configuration files from the git server based on the node id at startup and a current configuration tag. The basic principle is sound (and you get very detailed configuration control) - it wouldn't be too hard to migrate to storing the static info in a table. Where do you see the big problems? From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of Gerald Young Sent: Friday, February 08, 2013 10:56 AM To: User questions and discussions about OTRS. Subject: Re: [otrs] Need to set customers/agents's auth witn LDAP. The database is the only logical place for that information to live Static connection information? Maybe not. Configuration? ... I'd be inclined to concur. The problem with the database method with a table based data source is the freeform data. Move it to something non-sql, like perhaps ldap or other NoSQL, and this should be much better handled as desired. - 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] Need to set customers/agents's auth witn LDAP.
On 02/08/2013 11:22 AM, Steven Carr wrote: On 8 February 2013 15:55, Gerald Young cryth...@gmail.com wrote: The database is the only logical place for that information to live Static connection information? Maybe not. Configuration? ... I'd be inclined to concur. The problem with the database method with a table based data source is the freeform data. Move it to something non-sql, like perhaps ldap or other NoSQL, and this should be much better handled as desired. Yes I agree that there does need to be a level of configuration that needs to be maintained like database for the initial connection, but other than that I don't really care what is used as the backend storage for the config. They can continue to use flat files, but it must be a single location: db, single file or folder (containing live config and live config only, no other random backup or crap files) that can be picked up and dropped into another system to make upgrades easier. I've fallen into the pit of despair in v2.x by customising OTRS heavily then spend 3 months trying to upgrade it and fix the previous customisation, so now with v3 I tend to stick with stock OTRS, but even then it's still a right PITA to upgrade as it's so intertwined with the data and config that it consumed, no clear boundary. Steve It is a real problem that some config data is in both places. States for instance are defined in the database but are also in Sysconfig based on the text of the state. So you can change the state new to New and now suddenly when you go to create a ticket since the default state in Sysconfig is new things break. -- Stephen Clark - 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] Need to set customers/agents's auth witn LDAP.
On 8 February 2013 16:37, David Boyes dbo...@sinenomine.net wrote: Actually, it’s not that bad. At the most basic level, you can treat the static info as an array of text lines and read/interpret them sequentially. That at least doesn’t bind the information to a file on a specific server and gives you much more granular control of configuration management on operating systems that have essentially only two privilege levels (root/non-root). As an interim step on that clustered OTRS system I mentioned in another thread, we’ve stored the config files in git and modified the OTRS startup script to check out the configuration files from the git server based on the node id at startup and a “current configuration” tag. The basic principle is sound (and you get very detailed configuration control) – it wouldn’t be too hard to migrate to storing the static info in a table. Where do you see the big problems? With all due respect David your system is highly customised and you must have the people power (or skills) to maintain your custom setup. I don't want to have to do any of that custom piece, and more to the point I shouldn't have to do that. I want OTRS to focus on putting an enterprise/more manageable/maintainable slant on things, rather than it still feeling very much like a pet project that needs constant nurturing. And yes there is the argument that it is free/open source so take it or leave it, but even the paid version doesn't really offer any advantages other than 101 unnecessary add-ons and someone on the end of a phone to answer questions, and I'm technically competent enough not to need to pay someone for that. Since the change of hands it's beginning to feel very much like a closed application they just happen to release the code to, the community development side of the project has gone leaving very little ability to request/influence development. Steve - 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] Need to set customers/agents's auth witn LDAP.
-Original Message- From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of Steven Carr Sent: Friday, February 08, 2013 12:48 PM To: User questions and discussions about OTRS. Subject: Re: [otrs] Need to set customers/agents's auth witn LDAP. On 8 February 2013 16:37, David Boyes dbo...@sinenomine.net wrote: Actually, it’s not that bad. At the most basic level, you can treat the static info as an array of text lines and read/interpret them sequentially. That at least doesn’t bind the information to a file on a specific server and gives you much more granular control of configuration management on operating systems that have essentially only two privilege levels (root/non-root). As an interim step on that clustered OTRS system I mentioned in another thread, we’ve stored the config files in git and modified the OTRS startup script to check out the configuration files from the git server based on the node id at startup and a “current configuration” tag. The basic principle is sound (and you get very detailed configuration control) – it wouldn’t be too hard to migrate to storing the static info in a table. Where do you see the big problems? With all due respect David your system is highly customised and you must have the people power (or skills) to maintain your custom setup. I don't want to have to do any of that custom piece, and more to the point I shouldn't have to do that. I want OTRS to focus on putting an enterprise/more manageable/maintainable slant on things, rather than it still feeling very much like a pet project that needs constant nurturing. And yes there is the argument that it is free/open source so take it or leave it, but even the paid version doesn't really offer any advantages other than 101 unnecessary add- ons and someone on the end of a phone to answer questions, and I'm technically competent enough not to need to pay someone for that. Since the change of hands it's beginning to feel very much like a closed application they just happen to release the code to, the community development side of the project has gone leaving very little ability to request/influence development. Steve - 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] Need to set customers/agents's auth witn LDAP.
On 8 February 2013 16:37, David Boyes dbo...@sinenomine.net wrote: Actually, it’s not that bad. With all due respect David your system is highly customised and you must have the people power (or skills) to maintain your custom setup. I don't want to have to do any of that custom piece, and more to the point I shouldn't have to do that. I think you misinterpreted my reply. I was replying to Gerard's note on the difficulty level of storing connection info with the not that bad comment to illustrate that a solution like we're discussing wouldn't be that hard to implement. I'm totally with you on the we shouldn't have to invent hacks like this -- that idea with git is a workaround, and for enterprise-grade infrastructure such as OTRS purports to be, hacks like that shouldn't be necessary. We're not breaking new ground here; most of what we're discussing has long ago been done in other tools, and there's little excuse for not learning from the past. (I'm coming from a mainframe background, so the fact we have to do any of this HA stuff at the application level continues to amaze -- the mainframe world had this kind of basic system integrity stuff in 1982 for *everything*, not just single apps inventing it as they go along. ) I tossed out the git idea as one way we worked around the problem. It's fugly, but it does work as a stopgap solution. There is some unavoidable formalism that it assumes in terms of administrative practice, but nothing that you wouldn't expect from good practice where downtime has a substantial price attached to it. We built it on git precisely because we didn't have to invent the management of the configuration versioning, and we used it elsewhere, and it didn't require modifying OTRS beyond a simple init script change, which is easily managed (in fact, if I were doing it now, I'd pull that step out of the OTRS init script and put it into a new script with appropriate dependencies). It shouldn't be necessary, but it lets us cope with the problem without rewriting the universe. There are a lot of things I'd like to see added for HA and system resilience in OTRS. Matter of time and resources, I'd say. It probably would be a good idea to discuss it here, and help them define some requirements for what a really resilient enterprise OTRS system would look like. My starter list would be: 1) tolerate/exploit clustered database engines 2) explicit interaction with load balancing solutions (start with LVS, move on to the hardware solutions later) 3) rationalization of configuration data 4) management of configuration data 5) work on lock management in the database (there are a lot of places where a table-level lock is used by default that could be much more efficiently use row-level locks) 6) More work on index definition for high-use tables 7) Allow explicit use of different database extent storage pools in the database scripts to tune data placement (indexes on SSD, data on slower disk, for example). 8) More formal work on the SOAP interface. XML-RPC only goes so far. 9) a instrumentation interface to determine how well the application is performing (per-request timing, transaction overhead would be a good start) - 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] Need to set customers/agents's auth witn LDAP.
don't change defaults.pm only config.pm
On Thu, Feb 7, 2013 at 11:56 AM, Israel Garcia iga3...@yahoo.com wrote:
HI,
From the manual, I see I have to add all these lines to get agents and
customers authenticating with ldap (AD), but not sure if we have to add it
to /opt/otrs/Kernel/Config.pm or /opt/otrs/Kernel/Config/Default.pm? Or in
other place.
For agents:
# This is an example configuration for an LDAP auth. backend.
# (Make sure Net::LDAP is installed!)
$Self-{'AuthModule'} = 'Kernel::System::Auth::LDAP';
$Self-{'AuthModule::LDAP::Host'} = 'israelDC2.israel.NET';
$Self-{'AuthModule::LDAP::BaseDN'} =
'cn=otrs_allow_company,ou=generics,ou=usuaris,ou=israel,dc=israel,dc=net';
$Self-{'AuthModule::LDAP::UID'} = 'uid';
# Check if the user is allowed to auth in a posixGroup
# (e. g. user needs to be in a group xyz to use otrs)
$Self-{'AuthModule::LDAP::GroupDN'} =
'ou=generics,ou=usuaris,ou=israel,dc=israel,dc=net';
$Self-{'AuthModule::LDAP::AccessAttr'} = 'memberUid';
# for ldap posixGroups objectclass (just uid)
# $Self-{'AuthModule::LDAP::UserAttr'} = 'UID';
# for non ldap posixGroups objectclass (with full user dn)
# $Self-{'AuthModule::LDAP::UserAttr'} = 'DN';
# The following is valid but would only be necessary if the
# anonymous user do NOT have permission to read from the LDAP tree
$Self-{'AuthModule::LDAP::SearchUserDN'} = 'otrs_ldap';
$Self-{'AuthModule::LDAP::SearchUserPw'} = 'OTRisrael24';
# in case you want to add always one filter to each ldap query, use
# this option. e. g. AlwaysFilter = '(mail=*)' or AlwaysFilter =
'(objectclass=user)'
$Self-{'AuthModule::LDAP::AlwaysFilter'} = '';
# in case you want to add a suffix to each login name, then
# you can use this option. e. g. user just want to use user but
# in your ldap directory exists user@domain.
#$Self-{'AuthModule::LDAP::UserSuffix'} = '@israel.domain';
# Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)
$Self-{'AuthModule::LDAP::Params'} = {
port = 389,
timeout = 120,
async = 0,
version = 3,
};
For customers:
# This is an example configuration for an LDAP auth. backend.
# (make sure Net::LDAP is installed!)
$Self-{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP';
$Self-{'Customer::AuthModule::LDAP::Host'} = 'israelDC2.israel.NET';
$Self-{'Customer::AuthModule::LDAP::BaseDN'} =
'cn=otrs_allow_israel,ou=generics,ou=usuaris,ou=israel,dc=israel,dc=net';
$Self-{'Customer::AuthModule::LDAP::UID'} = 'uid';
# Check if the user is allowed to auth in a posixGroup
# (e. g. user needs to be in a group xyz to use otrs)
$Self-{'Customer::AuthModule::LDAP::GroupDN'} =
'ou=generics,ou=usuaris,ou=israel,dc=israel,dc=net';
$Self-{'Customer::AuthModule::LDAP::AccessAttr'} = 'memberUid';
# for ldap posixGroups objectclass (just uid)
$Self-{'Customer::AuthModule::LDAP::UserAttr'} = 'UID';
# for non ldap posixGroups objectclass (full user dn)
#$Self-{'Customer::AuthModule::LDAP::UserAttr'} = 'DN';
# The following is valid but would only be necessary if the
# anonymous user does NOT have permission to read from the LDAP tree
$Self-{'Customer::AuthModule::LDAP::SearchUserDN'} = 'otrs_ldap';
$Self-{'Customer::AuthModule::LDAP::SearchUserPw'} = 'OTRisrael24';
# in case you want to add always one filter to each ldap query, use
# this option. e. g. AlwaysFilter = '(mail=*)' or AlwaysFilter =
'(objectclass=user)'
$Self-{'Customer::AuthModule::LDAP::AlwaysFilter'} = '';
# in case you want to add a suffix to each customer login name, then
# you can use this option. e. g. user just want to use user but
# in your ldap directory exists user@domain.
#$Self-{'Customer::AuthModule::LDAP::UserSuffix'} = '@israel.domain';
# Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)
$Self-{'Customer::AuthModule::LDAP::Params'} = {
port = 389,
timeout = 120,
async = 0,
version = 3,
};
Thanks once more.
regards
Israel.
-
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] Need to set customers/agents's auth witn LDAP.
On 7 February 2013 16:56, Israel Garcia iga3...@yahoo.com wrote: HI, From the manual, I see I have to add all these lines to get agents and customers authenticating with ldap (AD), but not sure if we have to add it to /opt/otrs/Kernel/Config.pm or /opt/otrs/Kernel/Config/Default.pm? Or in other place. /opt/otrs/Kernel/Config.pm - your settings/overrides go in here /opt/otrs/Kernel/Config/Default.pm - you should not modify this config file *at all* Steve - 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
