January 2014 - dev - OTRS mailing lists

Wiki down
by Rafa Quiñonero Figuerola 28 Jan '14

28 Jan '14

Hi all, I'm trying to install OTRS 3.3.3 in my Ubuntu, but the wiki page that everywhere is pointing to is down. It is down since some days ago. If you could please check it out and fix it, I would really appreciate it, and maybe much more people! Thanks a lot, Greetings. -- Rafa Quiñonero Figuerola Tlf: 0151-61436385 rafakorp(a)gmail.com

1 0

OTRSCodePolicy updates, action required
by Martin Gruner 28 Jan '14

28 Jan '14

Dear all, this message is for those of you who already use the OTRSCodePolicy module from git (https://github.com/OTRS/otrscodepolicy) There were some changes in the directory structure of this module. Please take these steps to keep it usable for you: - Please re-register it as a git hook in your git repositories (/path/to/OTRSCodePolicy/scripts/install-git-hooks.pl). - Please use /path/to/OTRSCodePolicy/bin/otrs.CodePolicy.pl to invoke it manually instead of the former run.pl. The changes were needed to be able to cleanly install this module into a regular OTRS system via the web interface. Regards, mg -- Martin Gruner Senior Developer R&D OTRS AG Europaring 4 94315 Straubing T: +49 (0)6172 681988 0 F: +49 (0)9421 56818 18 I: www.otrs.com/ Geschäftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann (Vorsitzender), Christopher Kuhn, Sabine Riedel Einfache Planung, bessere Übersicht - Mit OTRS 3.3 einfach besseres Service Management - Jetzt downloaden und testen

1 0

All active pull requests for OTRS need to be recreated
by Martin Gruner 27 Jan '14

27 Jan '14

Dear all, today we experienced a technical problem with the git repository on https://github.com/OTRS/otrs which forced us to re-create this repository on github and push the data to it again. The very unfortunate side effect of this is that all pull requests are lost (there were around 18 open PRs). If you sent one of these that was not already merged and is now lost, or you previously created a fork of OTRS on github, you should take the following steps: - Please re-fork OTRS in github to correctly establish the repository link again. - Push all your own branches to your fork from your local clone. No data will be lost! - Re-create the PRs that are still relevant. Please accept my sincere apologies for the overhead this may cause you. Best regards, mg -- Martin Gruner Senior Developer R&D OTRS AG Europaring 4 94315 Straubing T: +49 (0)6172 681988 0 F: +49 (0)9421 56818 18 I: www.otrs.com/ Geschäftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann (Vorsitzender), Christopher Kuhn, Sabine Riedel Einfache Planung, bessere Übersicht - Mit OTRS 3.3 einfach besseres Service Management - Jetzt downloaden und testen

1 0

New CPAN module required for master
by Martin Gruner 27 Jan '14

27 Jan '14

Dear developers, as of today, the master branch of OTRS requires the new modules "Template" and "Template::Stash::XS" (that is part of "Template") to be installed on the system. This is "Template::Toolkit" (http://www.template-toolkit.org/) and replaces the DTL-based templating engine. We also provide a script to automatically convert DTL templates to TT. Please find it in bin/otrs.MigrateDTLtoTT.pl. There might be some small problems in master right now because of the change. If you find any, please let me know. Also, if you have any branches based on master, please pull these changes into your branches to make sure that you will not get merge conflicts later. All DTL files were removed. We will also provide documentation on this change in the developer manual for OTRS 3.4. Best regards, mg -- Martin Gruner Senior Developer R&D OTRS AG Europaring 4 94315 Straubing T: +49 (0)6172 681988 0 F: +49 (0)9421 56818 18 I: www.otrs.com/ Geschäftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann (Vorsitzender), Christopher Kuhn, Sabine Riedel Einfache Planung, bessere Übersicht - Mit OTRS 3.3 einfach besseres Service Management - Jetzt downloaden und testen

1 0

Process Import Samples
by Carlos Rodríguez 20 Jan '14

20 Jan '14

Dear Community Members, I’m re-working on the ProcessManagement ProcessImport functionality, If you have any example of a process that does not import correctly please send it to me in YAML format, This is the format of the process file if you click on “Export” button from the Process Overview table. I will use the processes that you send me as samples to feed a new unit-test that will run here: http://opms.otrs.com/otrs/public.pl?Action=PublicUnitTest All this files will be available in further OTRS releases. Thank you in advance, I will be looking forward for your processes. ((enjoy)) Carlos Rodríguez

1 0

Integrating OTRS with another System
by Wissam Abou Rjeily 20 Jan '14

20 Jan '14

Hello, I want to integrate OTRS with another System which is responsible of remote support. First, I’ve installed OTRS 3.3.3 with all the ITSM modules and it is running perfect with a mySQL database. Here is the scenario: 1. Adding a field to the Tickets (or Change or Problem or Incident) in OTRS. The field, when clicked, will be passing the Ticket’s ID to the remote support system and will redirect the user to the other remote system (using a Link to the remote support system). 2. After connecting with the remote support system, the user will be able to chat with the help desk employee (using an interface of that remote support system which will be opened directly after clicking on the field added to the ticket in 1). 3. At the end of the remote support session, the chat script between the 2 parties should be returned to OTRS and included and saved in the Ticket (or problem or change). I started planning for the integration and thought of the following steps which could be helpful for the integration: 1. Adding a Dynamic Field with value Text and Default value = ‚Link to be used to open the support session with the other remote support system‘ 2. Adding an Outgoing Web Service on OTRS which will be containing the data about the Ticket (ID, notes, Details, Prio, etc…) 3. At the remote support system, I have the ability to store the Ticket ID in an External ID field. That could be getting the ID from step 2 and storing it temporarily on the remote support system. 4. The External ID field filled in 3 will be used to pass the chat script related to that ID (Ticket ID) from the remote support system to the OTRS 5. Adding an Incoming Web Service on OTRS which will be responsible of getting the chat script after ending the session on the remote support system and saving it in the ticket (by referring to the Ticket ID) I am still new to OTRS but I’ve read about the Web Services and the Dynamic fields. Can anyone advise if the integration steps are fine or should I think in another way to get the implementation done? The issue is very urgent and I would appreciate your replies. Thanks in advance. Best Regards, Wissam Wissam Abou Rjeily MBA & Bachelor of Engineering – Technical Consultant ncc solutions GmbH Claudius-Keller-Str. 3b D-81669 München Phone: +49 (0)89 1890436-22 - Fax: +49 (0)89 1890436-11 Web: http://www.ncc-solutions.com<http://www.ncc-solutions.com/> Sie finden uns auf folgenden Veranstaltungen: ** NowForum am 9.10. in Frankfurt ** ** CreateNow Award für die ServiceNow Custom Application geht an ncc solutions ** ** itSMF Kongress am 9./10.12. in Kassel ** Geschäftsleitung: Melhem El-Achkar Amtsgericht München: HRB 173 244 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

2 2

German version of CLA: dev Digest, Vol 34, Issue 8
by Anna Brakoniecka 16 Jan '14

16 Jan '14

Hi Martin, thanks for your response. >> why specifically do you think that a German version would be needed in >> addition to the already available English version? (I'm not on facebook.) When you have German-speaking contributors, then it's of course irrelevant in which language do they contribute. I already mentioned in my last email the reason and argumentation for a German translation: the language gets relevant, when a jurisdiction issue appears (German courts clearly prefer to have documentation in German). If - for example - capeIT as a code contributor would like to contribute in the sense of the mentioned CLA, then it would be really nice to have the German jurisdiction in the case "something went terribly wrong and we need an juridical settlement". As far as everything goes well, there is no need to involve any court, but what if not? Additionally, AFAIK, the most contributors and active community members come indeed from the German-speaking area. The OTRS Community Board (Otterhub) is also a German association that was used to be supported by among all OTRS GmbH (and later by OTRS AG). Then, the already mentioned OTRS Package Archive (OPAR, browseable collection of plugins for the popular OTRS software) was created and has been managed by a German community member Renée Bäcker. Then again, the OTRS AG is a German company (OTRS AG Bad Homburg, Norsk-Data-Str. 1, 61352 Bad Homburg). Finally, it would be really nice gesture to get the CLA in German and honestly, it's not the biggest effort to translate the document. If OTRS AG doesn't have time or other resources to translate it, someone else could do it within the community work. Therefore two questions: 1) can we expect the translation (if yes, when) 2) and if not, will OTRS AG accept the German CLA's translation made by community with the same impact as the English version? If not, then the community work doesn't really make sense. Thanks in advance for your answer. Hope to hear from you soon, Kind reagrds, Anna Brakoniecka ** With KIX4OTRS... one step ahead in service ** ** http://www.cape-it.de/kix4otrs-standard-features.html ** ** http://www.cape-it.de/references.html ** Anna Brakoniecka c.a.p.e. IT® GmbH - ...cape it easy Annaberger Str. 240, D-09125 Chemnitz http://www.cape-it.de Tel: +49 371 5347 620 Fax: +49 371 5347 625 AG Chemnitz - HRB 23192 Geschäftsführer Rico Barth, Thomas Maier -----Ursprüngliche Nachricht----- Von:dev-request@otrs.org Gesendet:Mo 13.01.2014 13:00 Betreff:dev Digest, Vol 34, Issue 8 An:dev@otrs.org; Send dev mailing list submissions to dev(a)otrs.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.otrs.org/cgi-bin/listinfo/dev or, via email, send a message with subject or body 'help' to dev-request(a)otrs.org You can reach the person managing the list at dev-owner(a)otrs.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dev digest..." Today's Topics: 1. Re: Question related to code contribution :: dev Digest, Vol 34, Issue 5 (Martin Gruner) 2. Re: Upgrading password hashes (Martin Gruner) ---------------------------------------------------------------------- Message: 1 Date: Mon, 13 Jan 2014 08:51:20 +0100 From: Martin Gruner <martin.gruner(a)otrs.com> Subject: Re: [dev] Question related to code contribution :: dev Digest, Vol 34, Issue 5 To: Development community of OTRS <dev(a)otrs.org> Message-ID: <52D39AF8.2060305(a)otrs.com> Content-Type: text/plain; charset=ISO-8859-1 Hi Anna, why specifically do you think that a German version would be needed in addition to the already available English version? (I'm not on facebook.) In general, I'm open to the suggestion, but I don't believe we'll translate the CLA to all contributor's languages. Regards, mg Am 08.01.14 14:13, schrieb Anna Brakoniecka: > Hello, > > > > due to the mentioned issue of code contribution, I have a question > related to it. Torsten Thau put the question already in the OTRS > Facebook group, but there is no answer yet, even if some weeks passed > by. The answer is important for (among all) me, because capeIT has been > contributing to the OTRS-project for years > > > > * by delivering bug fixes, code, free additional modules > (ImportExportExtensions, ITSMAttributeCollection, KIX4OTRS, > ConfigureCallHome, etc., the complete list at > http://www.cape-it.de/free-otrs-community-additional-modules.html > and OPAR http://opar.perl-services.de/package/author/CAPEIT ) > > > > * and community work (among all our input in the OTRS forum and > mailing lists). > > > > *My question:* is there a chance of getting the Contributor License > Agreement in German? Until now, the document is only in English. The > German aspect is important due to the German jurisdiction that would be > relevant for German-speaking code contributors. > > > Is there any answer, I could get to this question? Thanks in advance for > any hint. Even a pure "No" would be already helpful. > > Kind regards, > Anna Brakoniecka > > > > ** With KIX4OTRS... one step ahead in service ** > ** http://www.cape-it.de/kix4otrs-standard-features.html ** > ** http://www.cape-it.de/references.html ** > > > Anna Brakoniecka > > c.a.p.e. IT? GmbH - ...cape it easy > Annaberger Str. 240, D-09125 Chemnitz > http://www.cape-it.de > Tel: +49 371 5347 620 > Fax: +49 371 5347 625 > AG Chemnitz - HRB 23192 > Gesch?ftsf?hrer Rico Barth, Thomas Maier > > > > > > > -----Urspr?ngliche Nachricht----- > *Von:*dev-request@otrs.org > *Gesendet:*Di 07.01.2014 12:57 > *Betreff:*dev Digest, Vol 34, Issue 5 > *An:*dev@otrs.org; > Send dev mailing list submissions to > dev(a)otrs.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.otrs.org/cgi-bin/listinfo/dev > or, via email, send a message with subject or body 'help' to > dev-request(a)otrs.org > > You can reach the person managing the list at > dev-owner(a)otrs.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dev digest..." > > > Today's Topics: > > 1. Re: hello again every one Im back and have code to contribute > (Martin Gruner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 07 Jan 2014 10:45:42 +0100 > From: Martin Gruner <martin.gruner(a)otrs.com> > Subject: Re: [dev] hello again every one Im back and have code to > contribute > To: Development community of OTRS <dev(a)otrs.org> > Message-ID: <52CBCCC6.5030506(a)otrs.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Paul, > > great, looking very much forward to your pull requests. > > It is always good if the code does not change the behaviour (output), > but makes it more efficient etc., then it is most easy to integrate > for us. > > In case of the TemplateGenerator I would ask you to first write some > unit tests covering the current behaviour that you want to improve. This > is a module that does not have a good test coverage yet. Then apply your > optimizations and see if the unit tests still work correctly. Please see > scripts/test/TemplateGenerator/ for a very small example, or all the > other test cases in scripts/test. Test driven development is always > highly recommendable IMHO. > > Please let me know if you have any questions about the unit tests. > > Regards, mg > > Am 06.01.14 23:45, schrieb Paul Robert Marino: > > Carlos > > Thank you I'm already familiar with the guidelines since I was very > > active in the community back in 2006-8 when I maintained and developed > > an instance of OTRS for a stock exchange. That said I'll look it over to > > see if any thing other than the ability to submit via Github pull > > request has changed. > > You should expect to see some of my patches in the next couple of days. > > I hope people like them. > > > > > > > > -- Sent from my HP Pre3 > > > > ------------------------------------------------------------------------ > > On Jan 6, 2014 17:33, Carlos Rodr?guez <carlos.rodriguez(a)otrs.com> wrote: > > > > Hi Paul, > > > > You as any other contributor is very welcome to send improvements in the > > code, thank you! > > > > As a suggestion please take a look at the OTRS Development Manual, > > specially in the code style guide > > http://doc.otrs.org/developer/3.3/en/html/code-style-guide.html > > > > Following this guide lines will make easier and faster to integrate your > > contributions. > > > > ((enjoy)) > > > > Carlos Rodr?guez > > > > > > > > > > On Jan 6, 2014, at 4:05 PM, Paul Robert Marino <prmarino1(a)gmail.com > > <mailto:prmarino1@gmail.com>> wrote: > > > >> hello every one > >> Its been quite a few years since I was on this list. Im working now at > >> an other company where we are implementing OTRS. I have been looking > >> over the code and there has been a lot of progress since I last looked > >> at it. > >> That said there are a few things that struck me as inefficient and not > >> as flexible as I would like in Kernel/System/TemplateGenerator.pm > >> > >> Ill be signing the contributors agreement shortly and will do a fork > >> with a push request on github shortly but I wanted to gauge some of > >> the reactions to what I want to submit before I go to far with it. > >> > >> essentially what I would like to change is the handleing of tags like > >> <OTRS_CUSTOMER_SUBJECT[20]> and <OTRS_CUSTOMER_EMAIL[5]> > >> > >> I found an inefficiency in the handling of <OTRS_CUSTOMER_EMAIL[5]> > >> specificly if you set say > >> <OTRS_CUSTOMER_EMAIL[99999999999999999999999999999999]> there is an > >> inefficiency in the loop which is easy to fix with a precheck which > >> I've already written. > >> additionally Ive also made a change where <OTRS_CUSTOMER_EMAIL[]> > >> <OTRS_CUSTOMER_EMAIL> are treated as inset the whole message. > >> the changes I made only added a few lines and a very slight > >> modification to the regex used to match and replace it. > >> > >> I also modified the handling of <OTRS_CUSTOMER_SUBJECT[20]> to work > >> in a similar manner. and made it so if the length of the subject isn't > >> longer than the number of characters specified it will not add the " > >> [...]" suffix to the subject. > >> this was handled by a slight tweak of the regex and the addition of an > >> if statement. > >> > >> > >> What I would like to do eventually is make this functionality a simple > >> set of methods (OO speak for functions) which can be called to handle > >> this for any of these template replace tags as efficiently as > >> possible. we would need more than two because of things like the > >> custom fields. I'm fairly sure I could be handled with just a few > >> methods simple to use methods and I could make the code far more > >> efficient in the process the data. > >> > >> Does any one have any comment, suggestions, or requests on this before > >> I get too deep into writing it? > >> > >> Thank You > >> Paul Robert Marino > >> _______________________________________________ > >> OTRS mailing list: dev - Webpage: http://otrs.org/ > >> Archive: http://lists.otrs.org/pipermail/dev > >> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev > >> > > > > > > > > _______________________________________________ > > OTRS mailing list: dev - Webpage: http://otrs.org/ > > Archive: http://lists.otrs.org/pipermail/dev > > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev > > > > -- > Martin Gruner > Senior Developer R&D > > OTRS AG > Europaring 4 > 94315 Straubing > > T: +49 (0)6172 681988 0 > F: +49 (0)9421 56818 18 > I: www.otrs.com/ > > Gesch?ftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, > USt-Nr.: DE256610065 > Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: Andr? > Mindermann (Vorsitzender), Christopher Kuhn, Sabine Riedel > > Einfache Planung, bessere ?bersicht - Mit OTRS 3.3 einfach besseres > Service Management - Jetzt downloaden und testen > > > ------------------------------ > > _______________________________________________ > dev mailing list > dev(a)otrs.org > http://lists.otrs.org/cgi-bin/listinfo/dev > > > End of dev Digest, Vol 34, Issue 5 > ********************************** > > > > > > _______________________________________________ > OTRS mailing list: dev - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/dev > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev > -- Martin Gruner Senior Developer R&D OTRS AG Europaring 4 94315 Straubing T: +49 (0)6172 681988 0 F: +49 (0)9421 56818 18 I: www.otrs.com/ Gesch?ftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: Andr? Mindermann (Vorsitzender), Christopher Kuhn, Sabine Riedel Einfache Planung, bessere ?bersicht - Mit OTRS 3.3 einfach besseres Service Management - Jetzt downloaden und testen ------------------------------ Message: 2 Date: Mon, 13 Jan 2014 08:54:39 +0100 From: Martin Gruner <martin.gruner(a)otrs.com> Subject: Re: [dev] Upgrading password hashes To: Development community of OTRS <dev(a)otrs.org> Message-ID: <52D39BBF.8040806(a)otrs.com> Content-Type: text/plain; charset=ISO-8859-1 Hi Mike, that is a very good suggestion. Just make sure this fits into the architecture well. I'd check the string as it gets stored, not just the used algorithm. With bcrypt, for example, the cost parameter could change in future, so an update in the DB would also be needed. Please also provide unit tests for this. Thanks a lot in advance! Regards, mg Am 08.01.14 08:16, schrieb Michiel Beijen: > Hi all ;-) > > I am really happy with the bcrypt password hashing mechanism that Martin > and me added to OTRS 3.3. > > That said, one thing that is not so nice is that passwords which already > exists are not upgraded. > > Of course, for upgrading we would need the plain password. So what we > could do is, when a user logs in, compare the encryption mechanism of > the password hash with the configured password mechanism in the > configuration. If the mechanism is not the same, the pasword is set > again but now with the new mechanism. > > I created a small patch for this, does it sound sane? If so, I'll send a > pull request with the code. > -- > Mike > > > > _______________________________________________ > OTRS mailing list: dev - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/dev > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev > -- Martin Gruner Senior Developer R&D OTRS AG Europaring 4 94315 Straubing T: +49 (0)6172 681988 0 F: +49 (0)9421 56818 18 I: www.otrs.com/ Gesch?ftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: Andr? Mindermann (Vorsitzender), Christopher Kuhn, Sabine Riedel Einfache Planung, bessere ?bersicht - Mit OTRS 3.3 einfach besseres Service Management - Jetzt downloaden und testen ------------------------------ _______________________________________________ dev mailing list dev(a)otrs.org http://lists.otrs.org/cgi-bin/listinfo/dev End of dev Digest, Vol 34, Issue 8 **********************************

2 1

Upgrading password hashes
by Michiel Beijen 13 Jan '14

13 Jan '14

Hi all ;-) I am really happy with the bcrypt password hashing mechanism that Martin and me added to OTRS 3.3. That said, one thing that is not so nice is that passwords which already exists are not upgraded. Of course, for upgrading we would need the plain password. So what we could do is, when a user logs in, compare the encryption mechanism of the password hash with the configured password mechanism in the configuration. If the mechanism is not the same, the pasword is set again but now with the new mechanism. I created a small patch for this, does it sound sane? If so, I'll send a pull request with the code. -- Mike

2 1

Question related to code contribution :: dev Digest, Vol 34, Issue 5
by Anna Brakoniecka 13 Jan '14

13 Jan '14

Hello, due to the mentioned issue of code contribution, I have a question related to it. Torsten Thau put the question already in the OTRS Facebook group, but there is no answer yet, even if some weeks passed by. The answer is important for (among all) me, because capeIT has been contributing to the OTRS-project for years * by delivering bug fixes, code, free additional modules (ImportExportExtensions, ITSMAttributeCollection, KIX4OTRS, ConfigureCallHome, etc., the complete list at http://www.cape-it.de/free-otrs-community-additional-modules.html and OPAR http://opar.perl-services.de/package/author/CAPEIT ) * and community work (among all our input in the OTRS forum and mailing lists). My question: is there a chance of getting the Contributor License Agreement in German? Until now, the document is only in English. The German aspect is important due to the German jurisdiction that would be relevant for German-speaking code contributors. Is there any answer, I could get to this question? Thanks in advance for any hint. Even a pure "No" would be already helpful. Kind regards, Anna Brakoniecka ** With KIX4OTRS... one step ahead in service ** ** http://www.cape-it.de/kix4otrs-standard-features.html ** ** http://www.cape-it.de/references.html ** Anna Brakoniecka c.a.p.e. IT® GmbH - ...cape it easy Annaberger Str. 240, D-09125 Chemnitz http://www.cape-it.de Tel: +49 371 5347 620 Fax: +49 371 5347 625 AG Chemnitz - HRB 23192 Geschäftsführer Rico Barth, Thomas Maier -----Ursprüngliche Nachricht----- Von:dev-request@otrs.org Gesendet:Di 07.01.2014 12:57 Betreff:dev Digest, Vol 34, Issue 5 An:dev@otrs.org; Send dev mailing list submissions to dev(a)otrs.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.otrs.org/cgi-bin/listinfo/dev or, via email, send a message with subject or body 'help' to dev-request(a)otrs.org You can reach the person managing the list at dev-owner(a)otrs.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dev digest..." Today's Topics: 1. Re: hello again every one Im back and have code to contribute (Martin Gruner) ---------------------------------------------------------------------- Message: 1 Date: Tue, 07 Jan 2014 10:45:42 +0100 From: Martin Gruner <martin.gruner(a)otrs.com> Subject: Re: [dev] hello again every one Im back and have code to contribute To: Development community of OTRS <dev(a)otrs.org> Message-ID: <52CBCCC6.5030506(a)otrs.com> Content-Type: text/plain; charset=ISO-8859-1 Hi Paul, great, looking very much forward to your pull requests. It is always good if the code does not change the behaviour (output), but makes it more efficient etc., then it is most easy to integrate for us. In case of the TemplateGenerator I would ask you to first write some unit tests covering the current behaviour that you want to improve. This is a module that does not have a good test coverage yet. Then apply your optimizations and see if the unit tests still work correctly. Please see scripts/test/TemplateGenerator/ for a very small example, or all the other test cases in scripts/test. Test driven development is always highly recommendable IMHO. Please let me know if you have any questions about the unit tests. Regards, mg Am 06.01.14 23:45, schrieb Paul Robert Marino: > Carlos > Thank you I'm already familiar with the guidelines since I was very > active in the community back in 2006-8 when I maintained and developed > an instance of OTRS for a stock exchange. That said I'll look it over to > see if any thing other than the ability to submit via Github pull > request has changed. > You should expect to see some of my patches in the next couple of days. > I hope people like them. > > > > -- Sent from my HP Pre3 > > ------------------------------------------------------------------------ > On Jan 6, 2014 17:33, Carlos Rodr?guez <carlos.rodriguez(a)otrs.com> wrote: > > Hi Paul, > > You as any other contributor is very welcome to send improvements in the > code, thank you! > > As a suggestion please take a look at the OTRS Development Manual, > specially in the code style guide > http://doc.otrs.org/developer/3.3/en/html/code-style-guide.html > > Following this guide lines will make easier and faster to integrate your > contributions. > > ((enjoy)) > > Carlos Rodr?guez > > > > > On Jan 6, 2014, at 4:05 PM, Paul Robert Marino <prmarino1(a)gmail.com > <mailto:prmarino1@gmail.com>> wrote: > >> hello every one >> Its been quite a few years since I was on this list. Im working now at >> an other company where we are implementing OTRS. I have been looking >> over the code and there has been a lot of progress since I last looked >> at it. >> That said there are a few things that struck me as inefficient and not >> as flexible as I would like in Kernel/System/TemplateGenerator.pm >> >> Ill be signing the contributors agreement shortly and will do a fork >> with a push request on github shortly but I wanted to gauge some of >> the reactions to what I want to submit before I go to far with it. >> >> essentially what I would like to change is the handleing of tags like >> <OTRS_CUSTOMER_SUBJECT[20]> and <OTRS_CUSTOMER_EMAIL[5]> >> >> I found an inefficiency in the handling of <OTRS_CUSTOMER_EMAIL[5]> >> specificly if you set say >> <OTRS_CUSTOMER_EMAIL[99999999999999999999999999999999]> there is an >> inefficiency in the loop which is easy to fix with a precheck which >> I've already written. >> additionally Ive also made a change where <OTRS_CUSTOMER_EMAIL[]> >> <OTRS_CUSTOMER_EMAIL> are treated as inset the whole message. >> the changes I made only added a few lines and a very slight >> modification to the regex used to match and replace it. >> >> I also modified the handling of <OTRS_CUSTOMER_SUBJECT[20]> to work >> in a similar manner. and made it so if the length of the subject isn't >> longer than the number of characters specified it will not add the " >> [...]" suffix to the subject. >> this was handled by a slight tweak of the regex and the addition of an >> if statement. >> >> >> What I would like to do eventually is make this functionality a simple >> set of methods (OO speak for functions) which can be called to handle >> this for any of these template replace tags as efficiently as >> possible. we would need more than two because of things like the >> custom fields. I'm fairly sure I could be handled with just a few >> methods simple to use methods and I could make the code far more >> efficient in the process the data. >> >> Does any one have any comment, suggestions, or requests on this before >> I get too deep into writing it? >> >> Thank You >> Paul Robert Marino >> _______________________________________________ >> OTRS mailing list: dev - Webpage: http://otrs.org/ >> Archive: http://lists.otrs.org/pipermail/dev >> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev >> > > > > _______________________________________________ > OTRS mailing list: dev - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/dev > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev > -- Martin Gruner Senior Developer R&D OTRS AG Europaring 4 94315 Straubing T: +49 (0)6172 681988 0 F: +49 (0)9421 56818 18 I: www.otrs.com/ Gesch?ftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: Andr? Mindermann (Vorsitzender), Christopher Kuhn, Sabine Riedel Einfache Planung, bessere ?bersicht - Mit OTRS 3.3 einfach besseres Service Management - Jetzt downloaden und testen ------------------------------ _______________________________________________ dev mailing list dev(a)otrs.org http://lists.otrs.org/cgi-bin/listinfo/dev End of dev Digest, Vol 34, Issue 5 **********************************

2 1

hello again every one Im back and have code to contribute
by Paul Robert Marino 08 Jan '14

08 Jan '14

hello every one Its been quite a few years since I was on this list. Im working now at an other company where we are implementing OTRS. I have been looking over the code and there has been a lot of progress since I last looked at it. That said there are a few things that struck me as inefficient and not as flexible as I would like in Kernel/System/TemplateGenerator.pm Ill be signing the contributors agreement shortly and will do a fork with a push request on github shortly but I wanted to gauge some of the reactions to what I want to submit before I go to far with it. essentially what I would like to change is the handleing of tags like <OTRS_CUSTOMER_SUBJECT[20]> and <OTRS_CUSTOMER_EMAIL[5]> I found an inefficiency in the handling of <OTRS_CUSTOMER_EMAIL[5]> specificly if you set say <OTRS_CUSTOMER_EMAIL[99999999999999999999999999999999]> there is an inefficiency in the loop which is easy to fix with a precheck which I've already written. additionally Ive also made a change where <OTRS_CUSTOMER_EMAIL[]> <OTRS_CUSTOMER_EMAIL> are treated as inset the whole message. the changes I made only added a few lines and a very slight modification to the regex used to match and replace it. I also modified the handling of <OTRS_CUSTOMER_SUBJECT[20]> to work in a similar manner. and made it so if the length of the subject isn't longer than the number of characters specified it will not add the " [...]" suffix to the subject. this was handled by a slight tweak of the regex and the addition of an if statement. What I would like to do eventually is make this functionality a simple set of methods (OO speak for functions) which can be called to handle this for any of these template replace tags as efficiently as possible. we would need more than two because of things like the custom fields. I'm fairly sure I could be handled with just a few methods simple to use methods and I could make the code far more efficient in the process the data. Does any one have any comment, suggestions, or requests on this before I get too deep into writing it? Thank You Paul Robert Marino

3 4