June 2004 - dev - OTRS mailing lists

Deafult Charset set to UTF-8 - article_plain problem
by boris＠goldenmyth.co.il 12 Jun '04

12 Jun '04

Dear List, my system: Debian Sid. PostgreSQL 7.4 (UNICODE) Perl 5.8.4 OTRS 1.2.3 (DefaultCharset->utf-8) I noticed a problem that mainly consists of any message's MIME source *NOT* being properly recoded to UTF-8 before it is INSERTed into the article_plain table of OTRS. This problem makes the "plain" artice view unreadable. (encodings tested hebrew iso-8859-8 and cyrillic iso-8859-5, cyrillic koi-8-r) To work around this problem i've done the following change to OTRS code: Kernel::System::EmailParser->GetPlainEmail(); sub GetPlainEmail { my $Self = shift; return $Self->{EncodeObject}->Decode( Text => $Self->{Email}->as_string(), From => $Self->GetCharset() ); } I would like to receive comments on this issue. Kind Regards, Boris Ratner. ps. this is a repost from the [otrs] mailing list.

1 0

Proposal to add support for multiple customer ids
by Tyler Hepworth 11 Jun '04

11 Jun '04

I would like to propose adding support for multiple customer ids being assigned to one user. I believe it is problematic that a user can only have one customer id because this forces a ticket to be either completely private (viewable by one individual only) or completely public (viewable by a group of people that share the same customer id). I believe each user should be be able to have both "private" and "public" tickets. I have reprogrammed several of the modules to allow for this support and have attached a diff file with my changes. My initial testing shows it to work properly, but I would be interested in feedback (especially if you can find bugs). Here is the philosphy. A user should be able to have a primary (private) id and multiple secondary (public) ids. These ids will be stored as a single string in either the OTRS local "Customer ID" field, or in an LDAP field that allows for arbitrary strings. For example, I use an LDAP customer backend. I use the 'url' field for my customer id field: # abbreviated for ease of reading $Self->{CustomerUser} = { Name => 'LDAP Source', Module => 'Kernel::System::CustomerUser::LDAP', CustomerID => 'url', # This line! Map => [ [ 'UserCustomerID', 'CustomerID', 'url', 0, 1, 'var' ], # This line! ], }; The single string stored in 'url' will be in the format of primaryid;sec_id1;sec_id2;etc. Example: I want to submit private tickets under the id of 'tylerh(a)natr.com'. I also want to submit tickets that groups of people can see. The different groups are 'web' and 'qa'. My customer id string would be: 'tylerh(a)natr.com;web;qa'. I can get access to each customer id by using "split" to split up the UserCustomerID string after it is read into the program. See the diff file for details. FAQ: Q: How does the system decide which id to use for the creation of new tickets? A: All tickets created via "Phone View" "Compose Email" or self submitted by the user default to the primary id. X-OTRS headers and manual intervention can be used to change the id. Q: Will these changes break existing installations of OTRS? A: No. Current users will see no change and notice no difference in the performance of their systems. This code only adds the ability to support multiple customer ids if the user so desires to implement it. Q: Is there anything wrong with the changes made? A: Yes, there are some aesthetic problems with the way tickets are displayed in the customer panel. The panel does not show which customer id a ticket belongs to. Also, even though all tickets with different ids display, they display in clumps. Example: id WEB: ticket numbers: 10, 8, 6 id QA: ticket numbers: 9, 7, 5 Displays as: 10,8,6,9,7,5 Regardless of which type of sort is applied each group of tickets stays in its group. I know why this occurs, but I am not sure how to make it different. Any help/advice/opinions on how to display the customer id of each ticket and intermix the tickets regardless of id would be appreciated. Please take a look at the diffs and let me know what you think. Thanks, Tyler Hepworth

1 0

Re: [otrs] live chat support in OTRS? {Scanned}
by Patrik Forsberg 11 Jun '04

11 Jun '04

> I agree: Bringing in a link full of information leading to an > IRC client > shouldn't be the hardest Part. The connection back to OTRS > would require > the IRC client of either being capable of sending emails, or elsewhere > communicate with OTRS. This could be a bot sitting in the channel. > reacting on commands from Admins and users of that very channel. It shouldent be to hard to make the irc-client aculy log to a file or send a conversation via email. This would be prefered sense you could never make a irc-bot that catches a private conversation between a customer and the agent. It could be done by messing around with a irc-server even if I think that would be to make it more complicated then nessesary. A key, command or something like it that the agent can activate to make the client log to a file for later import into OTRS would be the prefered way I think ? and wouldent demend to much work over a already working client. > > My thinking is that one would want to inititate the IRC session from > > inside an existing ticket - or consequently initiating IRC would > > create a new ticket if none was open. That would be solved by the above way ie. to have something that activates the logging function for later import to OTRS. Regards, Patrik

1 0

Authentication through URL params
by Adrián Deccico 10 Jun '04

10 Jun '04

Hi, I want to authenticate customers through the URL vars because I want to integrate OTRS with another system. The idea is to call customer.pl in that way Customer.pl?user=name&password=key Is it possible? Thank you for reading and for any advice Best regards Adrián Deccico

3 2

Re: [otrs] live chat support in OTRS? {Scanned}
by Robert Kehl 10 Jun '04

10 Jun '04

On Thursday, June 10, 2004 4:44 PM unbekennt X <pentaetn(a)hotmail.com> wrote: > The ability for OTRS to append an IRC log to a ticket would imo be a > huge benefit, and since there are GNU/GPL IRC clients available > already, it would perhaps not be a very difficult thing to achieve. I agree: Bringing in a link full of information leading to an IRC client shouldn't be the hardest Part. The connection back to OTRS would require the IRC client of either being capable of sending emails, or elsewhere communicate with OTRS. This could be a bot sitting in the channel. reacting on commands from Admins and users of that very channel. > My thinking is that one would want to inititate the IRC session from > inside an existing ticket - or consequently initiating IRC would > create a new ticket if none was open. We shouldn't open a ticket unless the IRC client (ie., the bot) answers us. He'll do so on behalf of the agent talking to the customer on IRC. So far, Robert Kehl PS: I splitted your other questions up to different threads. Please do so in future, too. -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388

1 0

survey tool integration
by Robert Kehl 10 Jun '04

10 Jun '04

On Thursday, June 10, 2004 4:44 PM unbekennt X <pentaetn(a)hotmail.com> wrote: > The second thing I am thinking about is a way to integrate a survey > tool with OTRS so that support quality and customer opinions can be > recorded. For example the customer gets a questionnaire after a > ticket is closed or during it's lifecycle to ask how we are doing, > etc. Interesting idea, although somewhat out of the main focus of a ticket request system in my eyes. Would be more suitable as an Add-On module. How would you realize the idea then? Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388

1 0

capturing voice into tickets
by Robert Kehl 10 Jun '04

10 Jun '04

On Thursday, June 10, 2004 4:44 PM unbekennt X <pentaetn(a)hotmail.com> wrote: > On a different tack, there are two other areas that I am looking > into: I would like to see about capturing voice into tickets - since > I now work at a company that does voice-apps this was kinda > no-brainer. So two aspects of this would be capturing telephone > conversations with customers and appending the voice phone session to > the ticket, and the other aspect being allowing voice control of OTRS > (you could telephone OTRS and log a ticket etc.) We're eagerly looking forward for some APIs to connect to and/or some perly modules that would allow performing the. As this would become a greater project, I would like you to contact ((otrs.de)) to coordinate things. You can be quite sure that we did think about this already, but I can't say much about a prioritisation right now, but don't expect anything real soon. Regards, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388

1 0

X-OTRS-Headers handle in followups
by Stefan Berder 08 Jun '04

08 Jun '04

Hi dev team, I'm playing with OTRs for several days for now and I'm trying to set the status via a special word match in the subject. I know it's really a lack of security but is it possible to include a X-OTRS-State check in Kernel/System/PostMaster/FollowUp.pm ? In the worse case I'll use my own cvs to propagate my modifications to the new versions of code. Of course I'd prefer not to modify the code, so I won't haev to patch the sources on each new version ... Stefan -- #=- Stefan Berder tel : 6 14 80 -=# #=- Ingénieur système et réseau 01 53 95 14 80 -=# #=- TRANSPAC / CSIG-SIS-ISS mail : sbe(a)oleane.net -=# #=- /(bb|[^b]{2})/ stefan.berder(a)francetelecom.com -=#

2 2

Oracle Patches for OTRS
by Pascal Gienger 08 Jun '04

08 Jun '04

I completed my first try to get OTRS with Oracle working. Problem: Oracle text fields do have a 4000 char limit (VARCHAR2(4000)). With a CLOB (character Large OBject) you can avoid this limitation but the column then is NOT searchable NOR indexable. To be able to put a LOB, you have to do a normal INSERT and then reSELECT the row FOR UPDATE. To achieve this you need a clear SELECT criterium. Because ticketid is triggered you cannot use this, so I also inserted 5 lines so that articles without message id do get a unique one. My path was this one: a) create a ORADoLob method as a substitute for the Do-Method in System/DB.pm. This method gets called when an INSERT involving LOBs is to be done. b) Change the tables so that there is a 4000 char-short-column for the lob field (with an index to search) and the LOB itself (containing the full content). c) Change Ticket/Article.pm and Ticket/ArticleStorageDB.pm. d) Create a modified sql schema (with triggers for the missing auto_increment or serial feature of oracle) e) Create a modified initial insert script. To use it: 1) Create a tablespace for OTRS. 2) Create an Oracle User "otrs" and give him the tablespace. 3) Install Oracle Client on your OTRS machine. You need the Oracle Caller Interface 8 (C-Client) and the sqlplus program. Don't forget to set ORACLE_HOME! 4) Install DBD::Oracle 5) Gunzip and untar the attachment It contains: -rw-r--r-- pascal/staff 12789 2004-06-08 10:41:03 otrs-oracle.patch -rw-r--r-- pascal/staff 42343 2004-06-08 10:12:56 otrs-schema.oracle.sql -rw-r--r-- pascal/staff 47467 2004-06-08 10:12:12 initial_insert.oracle 6) Run sqlplus to apply initial scripts: sqlplus otrs/password@databasehost < otrs-schema.oracle.sql Errors complaining about unexisting sequences are harmless. I included the DROPs to be able to call the script more than once. Then type: sqlplus otrs/password@databasehost < initial_insert.oracle 7) Apply patches to otrs: cd /your/path/to/otrs patch -p1 < /where/you/have/your/otrs-oracle.patch Result should be: patching file Kernel/System/DB.pm patching file Kernel/System/Ticket/Article.pm patching file Kernel/System/Ticket/ArticleStorageDB.pm 8) Modify System/Config.pm to reflect your Oracle Setup (use the oracle example). 9) Start Apache and Perl module (if existent). Happy ride! Known problems: - In System/DB.pm, there is a line: LongReadLen => 1000*1024, When retrieving LOBs via SELECT, then the maximum number of bytes returned per column is defined by this Parameter. So at the moment, an attachment with 1 MB base64-coded is the maximum- longer ones get truncated (without error). You may make the value higher but keep in mind that - when using the perl module for Apache - Apache eats more RAM when you set the value higher. It is also possible to put binary attachments into BLOBs (Binary Large OBjects) but they are quite uncomfortable to handle and they are not retrieveable by sqlplus for test runs - so I stuck with base64-encodings and CLOBs. - I used LOBs only for article storage and attachments. FAQs are still limited to 4000 chars per field. TODO: - Modules/AgentTicketPrint.pm DOES NOT WORK - You can not GROUP BY a LOB. I work on this. - You can't do a full body search at the moment - I am working on this too. Patches are attached. They are provided without warranty. Patches are done against Version 1.2.3 as I don't possess the CVS version nor CVS access... I hope it is helpful for some people ;-) Yours, Pascal Gienger

1 0

Escalation time exclusion
by Joerg Friedrich 05 Jun '04

05 Jun '04

Hi! There is another feature if the escalation time could be 'limited' like UncountedUnlockTime, so that a ticket can only run into escalation during 'official work time'. -- Jörg Friedrich There are only 10 types of people: Those who understand binary and those who don't.

3 2