Re: [otrs] Svar: Re: Diff between PendingDate and Due date?

Hi Michiel!
I am very well, thank you. We are starting our migration to 3.1 in the near future, but currently are in testing phases with 3.0. I had some issues with malformed UTF-8 chars when I went from 3.0 to 3.1, so I had to go back again on my test system. I have some idea what may be the reason, but nothing definite yet.
We have been looking a bit at your feature addons, but can we get these by themselves?
It seems I can't use all my ZZAuto.pm from 2.4 after updating to 3.0.
Customer search is broken at least.
Starting anew fixes this, but I saw no caveat about this in the upgrade docs.
Are you still teaching classes in OTRS?
Regards,
/Martin
Den 01/02/2012 kl. 19.47 skrev "Michiel Beijen
Hi Martin, how are you!
What would be possible is to use the GenericAgent to set a field to the color you want, this can be a free text field or a 3.1.x-style DynamicField. You can then use this color in a custom DTL template as a value to use this color in a certain field. This would involve the use of DTL, but there would be no Perl involved... Hope this helps,
Mike.
2012/1/26 Martin Møller
: That seems quite interesting. Thank you for bringing it to my attention ;)
I haven't had time to try anything yet, but I came to the conclusion that I would be able to handle this via
if need be, where I could call a script to convert the due date and the current date to timestamps and return a number of seconds I could do 'ge' or 'lt' operations on. It may not need to come to that now, but my Perl knowledge is unfortunately quite limited.
I will peruse this new fountain of knowledge for a bit!
/Martin.
Juan Manuel Clavero Almirón
26. januar 2012 13:09 >>> Hi,
we use the package TicketOverviewHooked [http://opar.perl-services.de/bin/index.cgi/package/R/RE/RENEEB/TicketOvervie...], to colorize tickets according to their type... maybe you could use it to colorize according to proximity to DueTime
Juan Clavero Almirón
De: Martin Møller [mailto:mmo@itq.dk] Enviado el: miércoles, 25 de enero de 2012 13:00 Para: User questions and discussions about OTRS. Asunto: [otrs] Svar: Re: Diff between PendingDate and Due date?
Are there any plans for making Due date something that can actually be actioned on without needing to code a lot of Perl?
Like, for example, a ticket going yellow X days before due date is reached, orange Y days before and red when due date has been missed.
If the case is closed, due date should be ignored, unless reopened.
It would lend a nice immediacy to the field that we would very much like here.
If not implemented in OTRS as such, is it possible, via <dtl if > or similar, to check how far the due date is from today? If so, I should be able to do the coloring in the templates from there...
It would also be nice if you could use Due date as a trigger in the Message (Event) setup...
Regards,
/Martin.
Nils Leideck - ITSM
4. oktober 2010 13:16 >>> Hi, The pending date is used for the “pending *” status.
The Due Date is just another timestamp on the ticket
On 04.10.2010, at 23:43, Pradumna Maheshwari wrote:
Hello,
Can you tell me, what is difference between 'PendingDate' and 'Due date'?
Under what situation, should each one be used ?
thanks...
Pradumna Maheshwari
Cheers
Nils Leideck
— Nils Leideck Senior Consultant
http://webint.cryptonode.de / a Fractal project
--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Hi Martin,
Op 1 feb. 2012 20:34 schreef "Martin Møller"
I am very well, thank you. We are starting our migration to 3.1 in the near future, but currently are in testing phases with 3.0. I had some issues with malformed UTF-8 chars when I went from 3.0 to 3.1, so I had to go back again on my test system. I have some idea what may be the reason, but nothing definite yet.
Well, if you find out, please let me know.
We have been looking a bit at your feature addons, but can we get these by themselves?
You should really discuss this with our sales team, but typically, yes, feature add-ons are for subscription customers. Drop them a line at sales@otrs.com.
It seems I can't use all my ZZAuto.pm from 2.4 after updating to 3.0. Customer search is broken at least. Starting anew fixes this, but I saw no caveat about this in the upgrade docs.
Ah, I don't know, it *could* be that a config option that you modified was also changed in the switch between 2.4 and 3.0. You might be able to find out which one, typically it should "Just Work". If you find out the problem, feel free to file a bug report.
Are you still teaching classes in OTRS?
Absolutely, and doing consulting stuff as well. And in fact, next week, I'll be back in Denmark again! On Monday in Kopenhagen and I'll fly up north for a workshop at a customer on Tuesday. So I'm afraid very little time to meet.. -- Mike

Hi Michiel and others, Without having yet migrated to 3.1, I have at least done some sleuthing on a system that is born with 3.0 and upgraded to 3.1, and I have a stong feeling that YAML is the issue... On my original 2.4 system, the previous administrator have installed YAML through CPAN in site_perl. This version is 0.70 Now, with 3.1, you package YAML yourselves, and I guess that the site_perl catalog is checked before cpan-lib, so it sees the old version of YAML, not version 0.73 that OTRS delivers. Would it sound reasonable that an older version of YAML might choke on certain things in OTRS 3.1? It is working correctly on 3.0.11, where you don't distribute your own YAML: 3.1 test system, perl version 5.10.0: otrs3:~ # rpm -qpl otrs-3.1.0.beta1-01.noarch.rpm | grep YAML /opt/otrs/Kernel/cpan-lib/YAML /opt/otrs/Kernel/cpan-lib/YAML.pm /opt/otrs/Kernel/cpan-lib/YAML/Any.pm /opt/otrs/Kernel/cpan-lib/YAML/Base.pm /opt/otrs/Kernel/cpan-lib/YAML/Dumper /opt/otrs/Kernel/cpan-lib/YAML/Dumper.pm /opt/otrs/Kernel/cpan-lib/YAML/Dumper/Base.pm /opt/otrs/Kernel/cpan-lib/YAML/Error.pm /opt/otrs/Kernel/cpan-lib/YAML/Loader /opt/otrs/Kernel/cpan-lib/YAML/Loader.pm /opt/otrs/Kernel/cpan-lib/YAML/Loader/Base.pm /opt/otrs/Kernel/cpan-lib/YAML/Marshall.pm /opt/otrs/Kernel/cpan-lib/YAML/Node.pm /opt/otrs/Kernel/cpan-lib/YAML/Tag.pm /opt/otrs/Kernel/cpan-lib/YAML/Types.pm otrs3:~ # rpm -qpl otrs-3.0.11-03.noarch.rpm | grep YAML /opt/otrs/Kernel/cpan-lib/YAML /opt/otrs/Kernel/cpan-lib/YAML/Dumper /opt/otrs/Kernel/cpan-lib/YAML/Loader 3.0 test system: kbh-otrs02:/opt/otrs/Kernel # find /usr/lib/perl5/site_perl/5.8.8/YAML* /usr/lib/perl5/site_perl/5.8.8/YAML /usr/lib/perl5/site_perl/5.8.8/YAML/Any.pm /usr/lib/perl5/site_perl/5.8.8/YAML/Loader.pm /usr/lib/perl5/site_perl/5.8.8/YAML/Base.pm /usr/lib/perl5/site_perl/5.8.8/YAML/Dumper /usr/lib/perl5/site_perl/5.8.8/YAML/Dumper/Base.pm /usr/lib/perl5/site_perl/5.8.8/YAML/Dumper.pm /usr/lib/perl5/site_perl/5.8.8/YAML/Loader /usr/lib/perl5/site_perl/5.8.8/YAML/Loader/Base.pm /usr/lib/perl5/site_perl/5.8.8/YAML/Marshall.pm /usr/lib/perl5/site_perl/5.8.8/YAML/Tag.pm /usr/lib/perl5/site_perl/5.8.8/YAML/Error.pm /usr/lib/perl5/site_perl/5.8.8/YAML/Types.pm /usr/lib/perl5/site_perl/5.8.8/YAML/Node.pm /usr/lib/perl5/site_perl/5.8.8/YAML.pm Regards, /Martin.
Michiel Beijen
1. februar 2012 22:40 >>> Hi Martin,
Op 1 feb. 2012 20:34 schreef "Martin Møller"
I am very well, thank you. We are starting our migration to 3.1 in the near future, but currently are in testing phases with 3.0. I had some issues with malformed UTF-8 chars when I went from 3.0 to 3.1, so I had to go back again on my test system. I have some idea what may be the reason, but nothing definite yet.
Well, if you find out, please let me know.
We have been looking a bit at your feature addons, but can we get these by themselves?
You should really discuss this with our sales team, but typically, yes, feature add-ons are for subscription customers. Drop them a line at sales@otrs.com.
It seems I can't use all my ZZAuto.pm from 2.4 after updating to 3.0. Customer search is broken at least. Starting anew fixes this, but I saw no caveat about this in the upgrade docs.
Ah, I don't know, it *could* be that a config option that you modified was also changed in the switch between 2.4 and 3.0. You might be able to find out which one, typically it should "Just Work". If you find out the problem, feel free to file a bug report.
Are you still teaching classes in OTRS?
Absolutely, and doing consulting stuff as well. And in fact, next week, I'll be back in Denmark again! On Monday in Kopenhagen and I'll fly up north for a workshop at a customer on Tuesday. So I'm afraid very little time to meet.. -- Mike --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Hi Martin,
2012/2/8 Martin Møller
On my original 2.4 system, the previous administrator have installed YAML through CPAN in site_perl. This version is 0.70
Now, with 3.1, you package YAML yourselves, and I guess that the site_perl catalog is checked before cpan-lib, so it sees the old version of YAML, not version 0.73 that OTRS delivers.
Would it sound reasonable that an older version of YAML might choke on certain things in OTRS 3.1? It is working correctly on 3.0.11, where you don't distribute your own YAML:
You don't mention which kind of issues you are experiencing, so it would be very difficult to tell whether or not YAML causes these. We bundle some Perl modules in Kernel/cpan-lib for two reasons: you'll have to install less dependencies if you will set up OTRS, and second, we can control the version that OTRS uses; we do not need to bother about distribution X shipping version 0.1 and distribution Y shipping with version 0.9 of the same module; it gives us more control. Apart from that, typically OTRS will always use the version in Kernel/cpan-lib, even if you have installed a different version on your system using CPAN, yum or apt-get. Also, the rest of your system (everything else but OTRS) will not use these modules, so you will not have to worry that OTRS will break the rest of your system by shipping its own set of libraries. So that's why I think it would be very unlikely that the YAML version you installed via CPAN and the version you'll get with OTRS will actually cause issues here. Of course, it *could* be that somewhere in the OTRS code we don't properly check Kernel/cpan-lib before searching the rest of the system, but again, that would be unlikely I think. Also, the YAML code is only used in few places; for instance in saving the configuration for the new OTRS web services. So if you can share the error message you ran in to, maybe we can help you pin-point the exact cause. -- Mike

Hi there,
You could easily rename the installed version of YAML and then perl will
use your version.
If you cannot find the problem, please post a detailed bug report with
files that I can look at and I will try and reproduce the problem.
thanks,
mike
On Fri, Feb 10, 2012 at 10:18 AM, Michiel Beijen
Hi Martin,
2012/2/8 Martin Møller
: On my original 2.4 system, the previous administrator have installed YAML through CPAN in site_perl. This version is 0.70
Now, with 3.1, you package YAML yourselves, and I guess that the site_perl catalog is checked before cpan-lib, so it sees the old version of YAML, not version 0.73 that OTRS delivers.
Would it sound reasonable that an older version of YAML might choke on certain things in OTRS 3.1? It is working correctly on 3.0.11, where you don't distribute your own YAML:
You don't mention which kind of issues you are experiencing, so it would be very difficult to tell whether or not YAML causes these. We bundle some Perl modules in Kernel/cpan-lib for two reasons: you'll have to install less dependencies if you will set up OTRS, and second, we can control the version that OTRS uses; we do not need to bother about distribution X shipping version 0.1 and distribution Y shipping with version 0.9 of the same module; it gives us more control.
Apart from that, typically OTRS will always use the version in Kernel/cpan-lib, even if you have installed a different version on your system using CPAN, yum or apt-get. Also, the rest of your system (everything else but OTRS) will not use these modules, so you will not have to worry that OTRS will break the rest of your system by shipping its own set of libraries.
So that's why I think it would be very unlikely that the YAML version you installed via CPAN and the version you'll get with OTRS will actually cause issues here. Of course, it *could* be that somewhere in the OTRS code we don't properly check Kernel/cpan-lib before searching the rest of the system, but again, that would be unlikely I think.
Also, the YAML code is only used in few places; for instance in saving the configuration for the new OTRS web services. So if you can share the error message you ran in to, maybe we can help you pin-point the exact cause. -- Mike --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
-- James Michael DuPont Custom Engineering/Research & Development OTRS AG Norsk-Data-Straße 1 D-61352 Bad Homburg T: +49 (0) 9421 56818 0 F: +49 (0) 9421 56818 18 I: http://www.otrs.com/ Geschäftssitz: Bad Homburg, Amtsgericht Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann (Vorsitzender), Christopher Kuhn

I will give it a go next chance I get. It seemed to happen a lot in cronjobs. It also seemed to happen, when I opened a ticket from the Dashbord or Ticket overview (in which case I also got a 500 error, as far as I recall). As far as I can tell, the changes to the database should not be able to cause the issue, so most likely it is somewhere in the code... I will report back when I have tried these suggestions. /Martin.
James Michael DuPont
11. februar 2012 08:49 Hi there, You could easily rename the installed version of YAML and then perl will use your version. If you cannot find the problem, please post a detailed bug report with files that I can look at and I will try and reproduce the problem. thanks, mike
On Fri, Feb 10, 2012 at 10:18 AM, Michiel Beijen
On my original 2.4 system, the previous administrator have installed YAML through CPAN in site_perl. This version is 0.70
Now, with 3.1, you package YAML yourselves, and I guess that the site_perl catalog is checked before cpan-lib, so it sees the old version of YAML, not version 0.73 that OTRS delivers.
Would it sound reasonable that an older version of YAML might choke on certain things in OTRS 3.1? It is working correctly on 3.0.11, where you don't distribute your own YAML:
You don't mention which kind of issues you are experiencing, so it would be very difficult to tell whether or not YAML causes these. We bundle some Perl modules in Kernel/cpan-lib for two reasons: you'll have to install less dependencies if you will set up OTRS, and second, we can control the version that OTRS uses; we do not need to bother about distribution X shipping version 0.1 and distribution Y shipping with version 0.9 of the same module; it gives us more control. Apart from that, typically OTRS will always use the version in Kernel/cpan-lib, even if you have installed a different version on your system using CPAN, yum or apt-get. Also, the rest of your system (everything else but OTRS) will not use these modules, so you will not have to worry that OTRS will break the rest of your system by shipping its own set of libraries. So that's why I think it would be very unlikely that the YAML version you installed via CPAN and the version you'll get with OTRS will actually cause issues here. Of course, it *could* be that somewhere in the OTRS code we don't properly check Kernel/cpan-lib before searching the rest of the system, but again, that would be unlikely I think. Also, the YAML code is only used in few places; for instance in saving the configuration for the new OTRS web services. So if you can share the error message you ran in to, maybe we can help you pin-point the exact cause. -- Mike --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs -- James Michael DuPont Custom Engineering/Research & Development OTRS AG Norsk-Data-Straße 1 D-61352 Bad Homburg T: +49 (0) 9421 56818 0 F: +49 (0) 9421 56818 18 I: http://www.otrs.com/ Geschäftssitz: Bad Homburg, Amtsgericht Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann (Vorsitzender), Christopher Kuhn
participants (3)
-
James Michael DuPont
-
Martin Møller
-
Michiel Beijen