April 2004 - dev - OTRS mailing lists

Re: [dev] Re: message hard wrapping
by Alessandro Ranellucci 15 Apr '04

15 Apr '04

On 15-04-2004 at 20:41, Alessandro Ranellucci wrote: >This would do the job for us: > > use Text::Wrap; > (...) > $Text::Wrap::columns = $NewLine; > $Text::Wrap::huge = 'overflow' #This prevents us from breaking >URLs > $Self->{Body} = wrap( '', '', $Self->Body ); Hmmm... actually this would break quoted text since it will have longer lines because of the "> " prefix. I think that quoted text should be wrapped at $NewLine-2 instead of just $NewLine to prevent this. --Alessandro.

1 0

Re: message hard wrapping
by Alessandro Ranellucci 15 Apr '04

15 Apr '04

On 13-04-2004 at 17:47, Alessandro Ranellucci wrote: >>$Self->{Body} =~ s/(> )?(.{$NewLine}[^\s]*\s)/$2\n/g; Actually that line should be as follow to prevent un-quoting of quoted text: $Self->{Body} =~ s/((> )?.{$NewLine}[^\s]*\s)/$1\n/g; -- Alessandro Ranellucci (HOSTING CENTER) <alex(a)primafila.net> Ph. +39 06 6788489 - Fax +39 06 23315902 - http://www.hostingcenter.it

2 2

Auto Assing Group Rights
by Tyler Hepworth 15 Apr '04

15 Apr '04

My agents authenticate via LDAP and have their accounts created automatically. I would like to also add group rights at the time their account is created. I added the following code to User.pm: At the very start ----------------------------------- use Kernel::System::Group; my %CommonObject = (); $CommonObject{GroupObject} = Kernel::System::Group->new(%CommonObject); Inside of sub UserAdd (just after the user is added) ---------------------------------------------------- $CommonObject{GroupObject}->GroupMemberAdd( UID => $UserID, GID => 1, UserID => 2, Permission => { ro => 0, move_into => 0, create => 0, owner => 0, priority => 0, rw => 1, } ); $CommonObject{GroupObject}->GroupMemberAdd( UID => $UserID, GID => 4, UserID => 2, Permission => { ro => 0, move_into => 0, create => 0, owner => 0, priority => 0, rw => 1, } ); For right now, I want every agent to have access to the FAQ and User groups. Later, if the system grows more complex, I will add logic to this section that will add group rights based off of the groups an Agent belongs to in my LDAP database. So, that is my bright idea, but when I tried to restart apache, it refused to start. There were no errors as to why, so I started commenting out lines of code. The offending code is the first few lines where "CommonObject" is created. Have I specified it correctly? Incorrect? Is what I am trying to do even a good idea? Or will group rights be recreated for the user every time they log in because of the sub SyncLDAP2Database (since it calls UserAdd every time)? Even if rights are created every single time, is that a problem? Any suggestions on how to automatically add group rights?

2 1

message hard wrapping
by Alessandro Ranellucci 13 Apr '04

13 Apr '04

Hello, wrapping should be provided by the CGI (not by the browser) for more consistency with quoted text wrapping and for respecting the char count set in Kernel/Config.pm, so I removed the wrap="hard" attribute from the <textarea> in AgentCompose.dtl and added the following two lines to AgentCompose.pm: [...] >my $NewLine = $Self->{ConfigObject}->Get('ComposeTicketNewLine') || 75; >$Self->{Body} =~ s/(> )?(.{$NewLine}[^\s]*\s)/$2\n/g; # send email if (my $ArticleID = $Self->{TicketObject}->SendArticle( [...] The same thing should be done on AgentBounce.* and AgentForward.*. -- Alessandro Ranellucci (HOSTING CENTER) <alex(a)primafila.net> Ph. +39 06 6788489 - Fax +39 06 23315902 - http://www.hostingcenter.it

1 0

Question about code-contribution
by Dirk Scheer 08 Apr '04

08 Apr '04

Hello Developer-Team, I'm currently developing an add-on to implement "Standard Tickets" in the telephone-view. A "Standard Ticket" is a predefined ticket (or a ticket template) to reduce the effort of typing while phoning. Yesterday I thought that I can finsih my work. So I updated my OTRS from CVS to give you suitable patches for the current CVS. I was a little bit surprised, that there was a fundamental change in "Next State" and "Priority" fields on the telephone-view. These fields are now first filled with values after selecting a queue. Why was this done? A "Standard Ticket" is selected in a child window of the browser. Similar to spellchecking this child window can be closed with a <Done> button. Now I've the problem, that I want to set these fields (beside others) automaticaly after pressing the <Done> button. But if there are no values in the "Next State" and "Priority" fields, I've no chance to select anything. When thinking about this problem, I got another question. Who is coordinating the development of programmers like me? Is there any place where I can see, who is doing what (including the core-team)? Wouldn't it be useful, that a programmer have to subscribe anywhere, so that it is possible to coordinate the work. Or is this already done and I've missed something? CU Dirk

1 0

RE: [dev] Auto Assing Group Rights
by Tyler Hepworth 08 Apr '04

08 Apr '04

Tyler Hepworth wrote: > My agents authenticate via LDAP and have their accounts > created automatically. I would like to also add group rights > at the time their account is created. I added the following > code to User.pm: > > At the very start > ----------------------------------- > use Kernel::System::Group; > > my %CommonObject = (); > $CommonObject{GroupObject} = > Kernel::System::Group->new(%CommonObject); > > > Inside of sub UserAdd (just after the user is added) > ---------------------------------------------------- > $CommonObject{GroupObject}->GroupMemberAdd( > UID => $UserID, GID => 1, > UserID => 2, > Permission => { > ro => 0, > move_into => 0, > create => 0, > owner => 0, > priority => 0, > rw => 1, > } > ); > $CommonObject{GroupObject}->GroupMemberAdd( > UID => $UserID, GID => 4, > UserID => 2, > Permission => { > ro => 0, > move_into => 0, > create => 0, > owner => 0, > priority => 0, > rw => 1, > } > ); > > For right now, I want every agent to have access to the FAQ > and User groups. Later, if the system grows more complex, I > will add logic to this section that will add group rights > based off of the groups an Agent belongs to in my LDAP > database. So, that is my bright idea, but when I tried to > restart apache, it refused to start. There were no errors as > to why, so I started commenting out lines of code. The > offending code is the first few lines where "CommonObject" is > created. Have I specified it correctly? Incorrect? Is what > I am trying to do even a good idea? Or will group rights be > recreated for the user every time they log in because of the > sub SyncLDAP2Database (since it calls UserAdd every time)? > Even if rights are created every single time, is that a > problem? Any suggestions on how to automatically add group rights? > Nevermind, I got it worked out. Added the following to sub new: $Self->{GroupObject} = Kernel::System::Group->new(%Param); And the following to sub UserAdd: $Self->{GroupObject}->GroupMemberAdd( UID => $UserID, GID => 1, UserID => 2, Permission => { ro => 0, move_into => 0, create => 0, owner => 0, priority => 0, rw => 1, } ); $Self->{GroupObject}->GroupMemberAdd( UID => $UserID, GID => 4, UserID => 2, Permission => { ro => 0, move_into => 0, create => 0, owner => 0, priority => 0, rw => 1, } ); Works like a champ! :-)

1 0

SQL Server, Unicode, and Storage Capacity
by Tyler Hepworth 07 Apr '04

07 Apr '04

Robert, You expressed concern about not having unicode support on SQL Server. I looked into the matter and found that it does support unicode, but setting a datatype up as unicode cuts the effective storage capacity of the column in half. This is because a unicode column allocates two bytes for every character whether the text stored in the column is unicode or not. So, if you want to be able to sort and compare text and have unicode support for it, the best SQL equivalent for the MySQL datatype "MEDIUMTEXT" is "NVARCHAR (4000)". This will allow a maximum of 4000 characters to be stored in the column. I went through the schema and pulled out all of the columns that are specified as "MEDIUMTEXT" and would like your feedback on whether you think that the columns can be converted to NVARCHAR (4000) and still function properly. I will put some of my own thoughts as well. If you disagree, please let me know. Table: Column: My opinion salutation text This should be okay. Who is going to provide a greeting more than 4000 characters in length? signature text This should be okay. Same as previous. article a_from Probably not okay, but I don't know its intended purpose and whether sort/compare is necessary. article a_body Same as previous. article_plain body Same as previous. standard_response text This should be okay. What response is going to be more than 4000 characters in length? auto_response text Same as previous. session value Will session value really take up 4000 characters? standard_attachment content Probably not okay. Will have to find workaround. notifications text This should be okay. Will notifications take more than 4000 characters? faq_item f_keywords Probably okay? faq_item f_field1 ? faq_item f_field2 ? faq_item f_field3 ? faq_item f_field4 ? faq_item f_field5 ? faq_item f_field6 ? The only other data type I had to modify was article_attachment content If you want unicode support for this column, it will be of type NTEXT (which supports maximum of 1,073,741,823 characters (1 GB). You originally had it specified as LONGBLOB (which I believe supports upwards of 4 GB). Is 1 GB of characters enough for this column? If it doesn't have to be unicode, then I can specify it as TEXT and get 2 GB of charaters into it. Let me know what you think. I am excited about this project and want to contribute as much as possible.

1 0

OTRS_MSSQL Web Installer
by Tyler Hepworth 07 Apr '04

07 Apr '04

The OTRS / MSSQL web-installer is working out of the box. Here are the attached files I changed to implement this. Sorry there are no diff files. I have no idea how to use the program (that and programming on windows doesn't help much either :-) ).

1 0

Re: OTRS_MSSQL and Database Design
by Robert Kehl 07 Apr '04

07 Apr '04

On Tuesday, April 06, 2004 7:10 PM Tyler Hepworth <TylerH(a)natr.com> wrote: > everything has worked very well for me. I can create and respond to > tickets, manage users/customers, and send and receive email. I have > not gotten any error messages from the SQL server complaining about > invalid syntax or any of the other problems that I have seen other's > write about on the mailing list. Great! > However, I am concerned about one datatype in SQL compared to MySQL. > There are several places in MySQL that you use the datatype > MEDIUMTEXT. From my understanding, this datatype allows for up to > 16,777,215 characters to be entered into the field. This datatype is > not available in SQL so I had to substitute an approximate > equivalent. The closest thing (capacity wise) I could find was the > NTEXT type. I setup the database with this type, but got horrible > error messages about "SQL cannot do sort or compare operations on > NTEXT, TEXT, or IMAGE datatypes". So, NTEXT did not work because it > cannot be used in sort or compare operations. To work around this > error, I was forced to convert all MEDIUMTEXT types to VARCHAR in > MSSQL. Varchar can be sorted and compared, but it only allows a > maximun of 8000 characters (non-unicode). There is a huge difference > in capacity between MEDIUMTEXT and VARCHAR. I am wondering if this > is going to cause problems with some of the fields you have > constructed and their intended use. Yes, I suppose so. You will have to solve that or you'll run into serious problems. Additionally, the absence of Unicode will concern us on the long run. I had a look at the supported data types in MS SQL Server, and it doesn't look good. NTEXT were the one to choose ime, but we need to sort and compare on it. Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388

1 0

Patch to Kernel/Modules/AdminEmail.pm
by Joerg Friedrich 07 Apr '04

07 Apr '04

Hi, I noticed, that AdminEmails are not mime encoded. Esp. sending german Umlaute and Euro/Cent-Signs is not possible. I did a little Cut'n'Paste from System/Ticket/SendArticle.pm Now it should work. The 'To: Handling is not really cute, but it works :-) -- Jörg Friedrich

2 1