September 2010 - dev - OTRS mailing lists

Feature request: response template -> next ticket state
by Sascha.Rommelfangen＠ses-astra.com 17 Jan '11

17 Jan '11

Hi, I have a suggestion for OTRS, probably someone wants to implement this: When creating a response template (Admin Area -> Responses; AdminResponse.pm), it would be nice to have the possibility to define the next ticket state. For example: I have a 'CloseWithStateExplanation' template, and often people forget to change the next ticket state. The result is a nice explanation about the state ('closed'), but the state is of course still 'open'. Best regards, Sascha Rommelfangen

3 3

Check out my photos on Facebook
by Santosh Singh 25 Sep '10

25 Sep '10

Hi Dev, I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Santosh To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=100001562567694&k=Z6E3Y6R4W2X1YK1JPB63QTSRU… Already have an account? Add this email address to your account: http://www.facebook.com/n/?merge_accounts.php&e=dev%40otrs.org&c=6597b52ddf… ======================================= dev(a)otrs.org was invited to join Facebook by Santosh Singh. If you do not wish to receive this type of email from Facebook in the future, please follow the link below to unsubscribe. http://www.facebook.com/o.php?k=b5e4c2&u=100000216603466&mid=30805cbG5af31d… Facebook, Inc. P.O. Box 10005, Palo Alto, CA 94303

1 0

Group Permissions Queue View
by Dave Wojciechowski 22 Sep '10

22 Sep '10

After upgrading from 2.2 to 2.4 I have found that my old config for group permissions is no longer working. I had my postmaster queue in a group called postmaster, then 2 roles assigned to that group that only had read only access and move access. In the old version they could see the tickets and move them to a working queue. Now the tickets are not visible unless they have full RW what has changed? Disclaimer: This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or taking any action based on it is strictly prohibited.

1 0

Upgrade from 3.0Beta1 to 3.0BetaX
by Thomas Kaltenbrunner 16 Sep '10

16 Sep '10

Hello, after upgrading to the last Beta Version I run into some trouble. I got an error message that Core.UI.Dialog was not found. I digged around and found out that it was because of the wrong order of loading the javascript classes. Yes, I digged on and found the file Framework.xml where a list of javascript files is defined, which are loaded every time. But the order did not match the order which I could see in the source code returned by index.pl. The next I found was the ZZZAAuto.pl with the list of files in the wrong order and the comment "Auto generated". There it is. I renamed the file and tried it again. Ans success the error message disappeared. Don't know, it it is already documented, so I post this little description for everyone else how did not found it until now ;-) Mit freundlichen Grüßen Thomas Kaltenbrunner

2 2

SOAP problem with emailadresses from/to
by Ing. Daniel Heiss 15 Sep '10

15 Sep '10

Hi all, we have the problem that we receive the content of a_from and a_to with SOAP/TicketGET only without the text within the <>. That means at SOAP output from a_from we are missing the email address for example. We are using rpc.pl als interface witht PHP SoapClient(). Database output table Article: +--------+---------------+----------------------------------------+------------------------------------------------+------------------------------------+ |id |ticket_id |a_from |a_to |a_subject | +--------+------------------+---------------------------------------------+---------------------------------------------------------------------------+ |323754 |253786 |6535 | | Test via SOAP and PHP | |323768 |253786 |root <zphone(a)zphone.hall.ag> |"support(a)cnh.at" <support(a)cnh.at>| Helpdesk: Nummer 5865 | +---------+---------------+--------------------------------+------------------------------------------------+------------------------------------+ SOAP-Output: [s-gensym1002] => stdClass Object ( [Subject] => Test via SOAP and PHP [CustomerID] => 6535 [To] => [From] => 6535 ) [s-gensym1004] => stdClass Object ( [Subject] => Helpdesk: Nummer 5865 [CustomerID] => 6535 [To] => "support(a)cnh.at" [From] => root ) Now we tried the json.pl (Iphone interface) also and have the same issue. Json.pl: ["To"]=> string(27) "helpdesk " in OTRS und with offical Iphone app: To: "helpdesk <helpdesk(a)hall.ag>" Does anyone have an idea or solution for us? Many thanks and kind regards Daniel Heiss

1 0

HTML-Body via SOAP
by Ing. Daniel Heiss 15 Sep '10

15 Sep '10

Hi all, We are using OTRS 2.4 and rpc.pl as interface with PHP SoapClient(). As storage modul we use Ticket::StorageModule: ArticleStorageFS, that means instead of saving in DB (article_plain, artichle_attachments, …) the tickets are stored in /opt/otrs/var/article/JAHR/MONAT/TAG/ARTICLEID. Via SOAP/ArticleGET we only get the a_body text (plain) back. Does anyone know a opportunity to get/fetch the HTML content (html body, attachments,..) via SOAP? Many thanks and kind regards Daniel Heiss

1 0

Using UTC time "natively" in OTRS
by Hugh Kelley 01 Sep '10

01 Sep '10

I have been looking at the possibility of changing/configuring OTRS to use UTC time natively. As you may have seen from my posts on the otrs list, I started out thinking it was just a matter of configuration. Getting the UTC values in the database was pretty simple. Getting them back to the user in a localized time (when the DB is in UTC, the server is +/-X TZ and the client browser is in +/-Y TZ) seems to be a bit trickier. For one thing, it appears that the localization of time is actually being applied twice, during both the ticket object retrieval and and during the dtl rendering. It seems like OTRS needs to two timediffs tracked, one for the server-UTC diff and one for the client-UTC diff (or just make sure that the ticket object is pure UTC and only the DTL does conversions). Keeping to the point, has anyone else investigated this and can share insights? Were there any reasons UTC was initially avoided? I'll admit I am running this on SQL Server, IIS, and ActiveState Perl - any of which might cause my results to differ from the "norm". Regards, Hugh

2 1