
Hello to all, I have a problem with LDAP/Active Directory. The fact is that the ticket is created with customer_id set to user.name@domain.com when the real address is User.Name@domain.com - this is because Ticket.pm sets the id to lc(id) - why is this so? I have removed the lc() for now, could this cause me any trouble? Thanks, Iustin Pop ########################################### The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. Orange Romania SA is neither liable for the proper, complete transmission of the information contained in this communication nor any delay in its receipt. ###########################################

Hi Iustin, On Thu, Jun 17, 2004 at 03:31:09PM +0300, Iustin Pop wrote:
I have a problem with LDAP/Active Directory. The fact is that the ticket is created with customer_id set to user.name@domain.com when the real address is User.Name@domain.com - this is because Ticket.pm sets the id to lc(id) - why is this so? I have removed the lc() for now, could this cause me any trouble?
I don't know your problem but the lc(id) isn't a problem because LDAP/Active Directory is case insensitive. PS: The lc(id) in Ticket.pm is used to have unique customer_ids because perl is case sensitive.
Thanks, Iustin Pop
Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!

On Thu, 2004-06-17 at 15:50, Martin Edenhofer wrote:
Hi Iustin,
On Thu, Jun 17, 2004 at 03:31:09PM +0300, Iustin Pop wrote:
I have a problem with LDAP/Active Directory. The fact is that the ticket is created with customer_id set to user.name@domain.com when the real address is User.Name@domain.com - this is because Ticket.pm sets the id to lc(id) - why is this so? I have removed the lc() for now, could this cause me any trouble?
I don't know your problem but the lc(id) isn't a problem because LDAP/Active Directory is case insensitive. Sorry for not being clear, the problem is that the customer can't see his own tickets in customer.pl - the SQL filters on customer_id which doesn't match. So it's not an operational problem - the LDAP is indeed ok, only the retrieval of tickets based on User.Name@domain.com is wrong. My question was if my change - removal of lc() could impact other areas of OTRS.
PS: The lc(id) in Ticket.pm is used to have unique customer_ids because perl is case sensitive. So as long as I'm sure there aren't conflicting (User / user / uSER) entries in LDAP I can take it out of there, right?
Thanks again, Iustin Pop ########################################### The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. Orange Romania SA is neither liable for the proper, complete transmission of the information contained in this communication nor any delay in its receipt. ###########################################

On Thu, Jun 17, 2004 at 03:53:51PM +0300, Iustin Pop wrote:
I have a problem with LDAP/Active Directory. The fact is that the ticket is created with customer_id set to user.name@domain.com when the real address is User.Name@domain.com - this is because Ticket.pm sets the id to lc(id) - why is this so? I have removed the lc() for now, could this cause me any trouble?
I don't know your problem but the lc(id) isn't a problem because LDAP/Active Directory is case insensitive. Sorry for not being clear, the problem is that the customer can't see his own tickets in customer.pl - the SQL filters on customer_id which doesn't match. So it's not an operational problem - the LDAP is indeed ok, only the retrieval of tickets based on User.Name@domain.com is wrong. My question was if my change - removal of lc() could impact other areas of OTRS.
Ok. Now. :) Ok. This could be a problem if your database is case sensitive in where options. So you can remove lc() or add it to Kernel/System/Ticket.pm -> SearchTicket ~ line 1390 (so also all db customerid queries are lc). PS: What database do you use?
PS: The lc(id) in Ticket.pm is used to have unique customer_ids because perl is case sensitive. So as long as I'm sure there aren't conflicting (User / user / uSER) entries in LDAP I can take it out of there, right?
Jepp.
Thanks again, Iustin Pop
Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!

On Thu, 2004-06-17 at 16:12, Martin Edenhofer wrote:
Ok. Now. :)
Ok. This could be a problem if your database is case sensitive in where options. So you can remove lc() or add it to Kernel/System/Ticket.pm -> SearchTicket ~ line 1390 (so also all db customerid queries are lc). Ok, I see now. I think it's easier to remove the lc than add lower in SQL queries since they are spread all over - for example in Kernel/Modules/CustomerTicketOverView.pm, where you retrieve @ViewableTickets - this is where I started my exploration of the code.
PS: What database do you use?
Postgresql v 7.4.3
PS: The lc(id) in Ticket.pm is used to have unique customer_ids because perl is case sensitive. So as long as I'm sure there aren't conflicting (User / user / uSER) entries in LDAP I can take it out of there, right?
Jepp.
Ok, that clears it for me! Thanks, Iustin Pop ########################################### The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. Orange Romania SA is neither liable for the proper, complete transmission of the information contained in this communication nor any delay in its receipt. ###########################################
participants (2)
-
Iustin Pop
-
Martin Edenhofer