Re: [otrs] Packages dependencies on SLES11

[Martin Gruner]

Hello Marki,

thanks for the hint. I removed the package »bash-completion« from the 
dependency list, future packages will be fixed.

Martin Gruner
Team Lead R&D

OTRS AG
Bahnhofplatz 1a
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

Mobile Kommunikation und transparente Prozesse - Mit der OTRS Business 
Solution™ Managed 5 schnell und ohne eigene IT-Ressourcen starten  - Jetzt neue 
Features entdecken und bestellen
https://www.otrs.com/neu-in-otrs-business-solution-5-mobile-kommunikation-transparente-prozesse/?lang=de

> Am 09.05.2016 um 01:34 schrieb jm+o...@roth.lu:
> 
> It doesn't seem to be a big showstopper but nevertheless bash-completion is a 
> dependency that cannot be fulfilled:
> 
> # zypper install otrs-5.0.9-01.noarch.rpm
> Loading repository data...
> Reading installed packages...
> Resolving package dependencies...
> 
> Problem: nothing provides bash-completion needed by otrs-5.0.9-01.noarch
> Solution 1: do not install otrs-5.0.9-01.noarch
> Solution 2: break otrs-5.0.9-01.noarch by ignoring some of its dependencies
> 
> Choose from above solutions by number or cancel [1/2/c] (c): 2
> Resolving dependencies...
> Resolving package dependencies...
> 
> The following NEW packages are going to be installed:
>  apache2-mod_perl otrs perl-AppConfig perl-Convert-ASN1 perl-Crypt-SSLeay 
> perl-Encode-HanExtra perl-File-HomeDir perl-Net-DNS perl-Net-IP
>  perl-Template-Toolkit perl-Text-CSV_XS perl-Tie-IxHash perl-XML-LibXSLT 
> perl-ldap
> 
> The following packages are not supported by their vendor:
>  otrs perl-Encode-HanExtra perl-Template-Toolkit perl-Text-CSV_XS 
> perl-XML-LibXSLT
> 
> 14 new packages to install.
> 
> -
> 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

Re: [otrs] How to translate a message in Kernel/System/*.pm

[Martin Gruner]

Hello Ur,

this looks broken. I believe that Translate() should be used on this string, 
and it should be changed to have a placeholder replaced by Translate() with the 
process name.

Martin Gruner
Team Lead R&D

OTRS AG
Bahnhofplatz 1a
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

Mobile Kommunikation und transparente Prozesse - Mit der OTRS Business 
Solution™ Managed 5 schnell und ohne eigene IT-Ressourcen starten  - Jetzt neue 
Features entdecken und bestellen
https://www.otrs.com/neu-in-otrs-business-solution-5-mobile-kommunikation-transparente-prozesse/?lang=de

> Am 07.04.2016 um 23:13 schrieb Úr Balázs :
> 
> Hi,
> 
> I imported a process named "Egyedi megrendelés", and this notification
> appeared (see attached picture):
> "Process Egyedi megrendelés and all its data has been imported successfully."
> 
> This string is located here:
> https://github.com/OTRS/otrs/blob/master/Kernel/System/ProcessManagement/DB/Process.pm#L1764-L1766
> 
> Martin Gruner explained, why can not translate these kind of strings
> in backends:
> https://github.com/OTRS/otrs/pull/1037#issuecomment-198247289
> 
> If a string has no parameter, Translatable() can mark it for
> translation, and somewhere else in the .tt files will be translated.
> 
> But what about if a string has a parameter? Neither Translatable(),
> nor $LanguageObject can not be used in backend files. How to translate
> this kind of strings?
> 
> Regards,
> Balázs
> -
> 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

Re: [otrs] Memory usage rising from 4.x -> 5.0.9

[Martin Gruner]

Hello Ralf,

this is strange. The biggest changes would have to be expected when upgrading 
to OTRS 4, because there we added a centralized in-memory cache which should 
increase performance but partly also could lead to higher memory usage. For 
OTRS 5 there should be no such effect.

How big are your apache processes? Which worker do you use (prefork)? What’s 
the maximum requests per child setting for the processes?

Best regards, 

Martin Gruner
Team Lead R&D

OTRS AG
Bahnhofplatz 1a
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

Mobile Kommunikation und transparente Prozesse - Mit der OTRS Business 
Solution™ Managed 5 schnell und ohne eigene IT-Ressourcen starten  - Jetzt neue 
Features entdecken und bestellen
https://www.otrs.com/neu-in-otrs-business-solution-5-mobile-kommunikation-transparente-prozesse/?lang=de

> Am 20.04.2016 um 16:16 schrieb Ralf Hildebrandt :
> 
> I successfully upgraded from the most recent 4.x version of OTRS to
> 5.0.9 and noticed a sudden increase in memory usage:
> 
> The machine starts to use swap, and when checking which processes
> are using the most swap I'm seeing:
> 
> otrs:~#  { date;for f in /proc/[0-9]*/status; do awk '{k[$1]=$2} END { if 
> (k["VmSwap:"]) print
> k["Pid:"],k["Name:"],k["VmSwap:"];}' $f 2>/dev/null; done | sort 
> -n ; }
> 
> Mi 20. Apr 15:55:05 CEST 2016
> 1 init 600
> ...
> 26138 otrs.Daemon.pl 8240
> 26169 /usr/sbin/apach 4964
> 26243 /usr/sbin/apach 4832
> 26311 /usr/sbin/apach 4916
> 26835 /usr/sbin/apach 5136
> 27219 /usr/sbin/apach 5136
> 27701 /usr/sbin/apach 8528
> 27711 /usr/sbin/apach 5108
> 27746 /usr/sbin/apach 5256
> 27747 /usr/sbin/apach 8532
> 
> So it's apache/mod_perl. Is that normal?
> 
> 
>
> 
> -- 
> Ralf Hildebrandt   Charite Universitätsmedizin Berlin
> ralf.hildebra...@charite.deCampus Benjamin Franklin
> http://www.charite.de  Hindenburgdamm 30, 12203 Berlin
> Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
> -
> 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

[otrs] Manually fetch the emails is not working

[JAOUEN Egareg]

Hi all, 

I've just migrated from OTRS v4.0.8 on windows appliance to OTRS v5.0.10 on a 
Fedora 23 station. 
All seems to be fine. 

Except... fetching the emails manually. 
When I try to fetch the emails with the link on the postmaster page in Admin 
zone, I receive the error below. 

I wonder if there are differences in fetching emails methods between v4 and v5 
? And between fetching emails manually with that link and fetching 
automatically with the cronjob / daemon ? 
Indeed, the emails are correctly fetched and sorted in the corresponding 
tickets automatically. 

Does someone encounter the same behavior ? 
Thanks ! 

The error I noticed : 
An error occurred.
Message d'Erreur: IMAPS: Can't connect to clean.o2switch.net
.
Vous pouvez Envoyer un rapport de bug ou Revenir à la page précédente.
Détails de l'erreur
Backend ERROR: OTRS-CGI-0 Perl: 5.22.1 OS: linux Time: Wed Jun  8 09:49:02 2016

 Message: IMAPS: Can't connect to clean.o2switch.net

 RemoteAddress: 37.58.171.139
 RequestURI: 
/otrs/index.pl?Action=AdminMailAccount;Subaction=Run;ID=5;ChallengeToken=NFXCXFFiiZqmJakGtjgdzlAXJNEMJ1ID;

 Traceback (15683): 
   Module: Kernel::System::MailAccount::IMAP::_Fetch Line: 142
   Module: Kernel::System::MailAccount::IMAP::Fetch Line: 86
   Module: Kernel::System::MailAccount::MailAccountFetch Line: 440
   Module: Kernel::Modules::AdminMailAccount::Run Line: 60
   Module: Kernel::System::Web::InterfaceAgent::Run Line: 1053
   Module: 
ModPerl::ROOT::ModPerl::Registry::opt_otrs_bin_cgi_2dbin_index_2epl::handler 
Line: 40
   Module: (eval) (v1.99) Line: 207
   Module: ModPerl::RegistryCooker::run (v1.99) Line: 207
   Module: ModPerl::RegistryCooker::default_handler (v1.99) Line: 173
   Module: ModPerl::Registry::handler (v1.99) Line: 32

Egareg  JAOUEN
Ingénieur Recherche&Développement
Tel : +33 2 31 35 34 81 │ egareg.jao...@elitt.com


8 rue Léopold Sédar-Senghor - 14460 Colombelles - France │ www.elitt.com

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

[otrs] Dynamic Fields... direct access in the DB

[Olivier Macchioni]

Hello dear list,

I’m trying to export a list of tickets directly from the OTRS DB - I’m 
computing 20 columns, there are 7 joins… the request is not that small…

And it takes approx. 50 seconds to generate 5’000 rows I need. Knowing that I 
will eventually need to export much more than 5’000 rows, this is not 
acceptable.

If I remove *only* the 4 columns where I compute the value of some “Dropdown” 
dynamic fields linked to tickets, the times drops down to 3 seconds…

So I must be doing something wrong in the way I compute the value of dynamic 
fields…. or maybe the design of the DB itself is suboptimal?

The best solution I’ve found so far is a poor man’s parser on the YAML content 
of dynamic_field.content:

SELECT id,
  (SELECT regexp_replace(config, '.*' || dynamic_field_value.value_text || ': 
([^\n]+)\n.*', '\1')
   FROM dynamic_field_value
   JOIN dynamic_field ON dynamic_field.id = dynamic_field_value.field_id
   WHERE dynamic_field_value.object_id = ticket.id
 AND object_type = 'Ticket'
 AND dynamic_field.name = 'Category') AS "Category"
FROM ticket
WHERE ticket.tn = '10479715'

Does anyone have a better idea?

Thanks,

Olivier

P.S. I’m using PostgreSQL - it would have been nicer to store the data in JSON 
format, which is natively supported, it could have save some precious CPU 
cycles but well...


signature.asc
Description: Message signed with OpenPGP using GPGMail
-
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

Re: [otrs] Dynamic Fields... direct access in the DB

[Renee B]

Hi,

I would do it that way:

* Create a new table  wingo_df_values (field_id, field_key, field_value) 
with unique (field_id, field_key)
* change the backend module for Dropdown fields where the possible 
values are stored to the new table (every time the dynamic field is changed)

* use that new table in the SQL query

- Renée

Am 10.06.2016 um 14:13 schrieb Olivier Macchioni:

Hello dear list,

I’m trying to export a list of tickets directly from the OTRS DB - I’m 
computing 20 columns, there are 7 joins… the request is not that small…

And it takes approx. 50 seconds to generate 5’000 rows I need. Knowing that I 
will eventually need to export much more than 5’000 rows, this is not 
acceptable.

If I remove *only* the 4 columns where I compute the value of some “Dropdown” 
dynamic fields linked to tickets, the times drops down to 3 seconds…

So I must be doing something wrong in the way I compute the value of dynamic 
fields…. or maybe the design of the DB itself is suboptimal?

The best solution I’ve found so far is a poor man’s parser on the YAML content 
of dynamic_field.content:

SELECT id,
   (SELECT regexp_replace(config, '.*' || dynamic_field_value.value_text || ': 
([^\n]+)\n.*', '\1')
FROM dynamic_field_value
JOIN dynamic_field ON dynamic_field.id = dynamic_field_value.field_id
WHERE dynamic_field_value.object_id = ticket.id
  AND object_type = 'Ticket'
  AND dynamic_field.name = 'Category') AS "Category"
FROM ticket
WHERE ticket.tn = '10479715'

Does anyone have a better idea?

Thanks,

Olivier

P.S. I’m using PostgreSQL - it would have been nicer to store the data in JSON 
format, which is natively supported, it could have save some precious CPU 
cycles but well...


-
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



--
Perl / OTRS development: http://perl-services.de
OTRS AddOn repository: http://opar.perl-services.de

-
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

Re: [otrs] Dynamic Fields... direct access in the DB

[Olivier Macchioni]

Hello Renée,

Thank you for your idea.

This is definitely an option - I could even create this table automatically at 
the beginning of my SQL query using WITH 
 or something 
similar. Although doing this purely in SQL is not a super-exciting idea…

I’ll post something here if I can make this work.

Olivier




> On 10 Jun 2016, at 14:32, Renee B  wrote:
> 
> Hi,
> 
> I would do it that way:
> 
> * Create a new table  wingo_df_values (field_id, field_key, field_value) with 
> unique (field_id, field_key)
> * change the backend module for Dropdown fields where the possible values are 
> stored to the new table (every time the dynamic field is changed)
> * use that new table in the SQL query
> 
> - Renée
> 
> Am 10.06.2016 um 14:13 schrieb Olivier Macchioni:
>> Hello dear list,
>> 
>> I’m trying to export a list of tickets directly from the OTRS DB - I’m 
>> computing 20 columns, there are 7 joins… the request is not that small…
>> 
>> And it takes approx. 50 seconds to generate 5’000 rows I need. Knowing that 
>> I will eventually need to export much more than 5’000 rows, this is not 
>> acceptable.
>> 
>> If I remove *only* the 4 columns where I compute the value of some 
>> “Dropdown” dynamic fields linked to tickets, the times drops down to 3 
>> seconds…
>> 
>> So I must be doing something wrong in the way I compute the value of dynamic 
>> fields…. or maybe the design of the DB itself is suboptimal?
>> 
>> The best solution I’ve found so far is a poor man’s parser on the YAML 
>> content of dynamic_field.content:
>> 
>> SELECT id,
>>   (SELECT regexp_replace(config, '.*' || dynamic_field_value.value_text || 
>> ': ([^\n]+)\n.*', '\1')
>>FROM dynamic_field_value
>>JOIN dynamic_field ON dynamic_field.id = dynamic_field_value.field_id
>>WHERE dynamic_field_value.object_id = ticket.id
>>  AND object_type = 'Ticket'
>>  AND dynamic_field.name = 'Category') AS "Category"
>> FROM ticket
>> WHERE ticket.tn = '10479715'
>> 
>> Does anyone have a better idea?
>> 
>> Thanks,
>> 
>> Olivier
>> 
>> P.S. I’m using PostgreSQL - it would have been nicer to store the data in 
>> JSON format, which is natively supported, it could have save some precious 
>> CPU cycles but well...
>> 
>> 
>> -
>> 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 
>> 
> 
> --
> Perl / OTRS development: http://perl-services.de 
> OTRS AddOn repository: http://opar.perl-services.de 
> -
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
-
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

Re: [otrs] Dynamic Fields... direct access in the DB

[Olivier Macchioni]

Hops… answer to myself

SELECT id,
   name,
   trim(regexp_replace(line, '.*:([^:]*)', '\1')) as value_text,
   trim(regexp_replace(line, '([^:]*):.*', '\1')) as display_name
FROM
  (SELECT dynamic_field.id,
  dynamic_field.name,
  regexp_split_to_table(dynamic_field.config, '\n') AS line
   FROM dynamic_field
   WHERE object_type = 'Ticket'
 AND name = 'Category') AS foo
WHERE line LIKE ' %’;

-> will generate a table with:

dynamic_field.id (to be linked with dynamic_field_value.field_id)
dynamic_field.name
value_text (to be linked with dynamic_field_value.value_text)
display_name is the human-readable format of value_text

This will allow to populate a temp. table before doing the main query and speed 
up the said main query.

And now let’s hope that the structure in dynamic_field.config won’t change too 
often (this code is for OTRS 4)




> On 10 Jun 2016, at 14:59, Olivier Macchioni  
> wrote:
> 
> Hello Renée,
> 
> Thank you for your idea.
> 
> This is definitely an option - I could even create this table automatically 
> at the beginning of my SQL query using WITH 
>  or something 
> similar. Although doing this purely in SQL is not a super-exciting idea…
> 
> I’ll post something here if I can make this work.
> 
> Olivier
> 
> 
> 
> 
>> On 10 Jun 2016, at 14:32, Renee B > > wrote:
>> 
>> Hi,
>> 
>> I would do it that way:
>> 
>> * Create a new table  wingo_df_values (field_id, field_key, field_value) 
>> with unique (field_id, field_key)
>> * change the backend module for Dropdown fields where the possible values 
>> are stored to the new table (every time the dynamic field is changed)
>> * use that new table in the SQL query
>> 
>> - Renée
>> 
>> Am 10.06.2016 um 14:13 schrieb Olivier Macchioni:
>>> Hello dear list,
>>> 
>>> I’m trying to export a list of tickets directly from the OTRS DB - I’m 
>>> computing 20 columns, there are 7 joins… the request is not that small…
>>> 
>>> And it takes approx. 50 seconds to generate 5’000 rows I need. Knowing that 
>>> I will eventually need to export much more than 5’000 rows, this is not 
>>> acceptable.
>>> 
>>> If I remove *only* the 4 columns where I compute the value of some 
>>> “Dropdown” dynamic fields linked to tickets, the times drops down to 3 
>>> seconds…
>>> 
>>> So I must be doing something wrong in the way I compute the value of 
>>> dynamic fields…. or maybe the design of the DB itself is suboptimal?
>>> 
>>> The best solution I’ve found so far is a poor man’s parser on the YAML 
>>> content of dynamic_field.content:
>>> 
>>> SELECT id,
>>>   (SELECT regexp_replace(config, '.*' || dynamic_field_value.value_text || 
>>> ': ([^\n]+)\n.*', '\1')
>>>FROM dynamic_field_value
>>>JOIN dynamic_field ON dynamic_field.id = dynamic_field_value.field_id
>>>WHERE dynamic_field_value.object_id = ticket.id
>>>  AND object_type = 'Ticket'
>>>  AND dynamic_field.name = 'Category') AS "Category"
>>> FROM ticket
>>> WHERE ticket.tn  = '10479715'
>>> 
>>> Does anyone have a better idea?
>>> 
>>> Thanks,
>>> 
>>> Olivier
>>> 
>>> P.S. I’m using PostgreSQL - it would have been nicer to store the data in 
>>> JSON format, which is natively supported, it could have save some precious 
>>> CPU cycles but well...
>>> 
>>> 
>>> -
>>> 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 
>>> 
>> 
>> --
>> Perl / OTRS development: http://perl-services.de 
>> OTRS AddOn repository: http://opar.perl-services.de 
>> -
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
-
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