We delve into the nuances of programming Request Tracker
Hi, Habrayuzer!
In this topic, I will talk about the principles of building the request tracker from the point of view of programming, because This is a fairly good accounting system and can be used at a large enterprise as a helpdesk system.
Who cares - welcome under cat.
The system is written in perl, works with any (I checked for 2) http-server. The database set with which the system can work is extensive. It is fast enough, page generation occurs on the fly and there are no brakes with the content update. The last two stable branches, 3.8 and 4.11, were considered in detail.
The main differences between the branches touched the interface, with the same set of constructors in the code with minor changes. However, in prototype, the prototype framework is used and ajax is almost not used, while in 4.11 jquery is used (which is much more convenient in my opinion) and ajax constructions are used.
The system uses the Mason package, which allows embedding the perl-code into the document:
You can read about Mason structures here .
Also, the system uses a serious caching mode, which can cause rejection when programming under RT in the first stages, since each time you change the code, you should “kill” the RT session, clear the cache and restart the http server. Of course, these actions can be combined into a script, but there is another option - you should set the option in the RT_Config.pm config file:
')
This option disables object caching, which allows writing under RT using ajax.
The detailed directory structure of the RT is a group of directories named by category of objects. For example:
For the “Ticket” object (application) the structure will be as follows:
Each element directory has an Elements folder, which contains constructors for this type of element.
I will give an example:
This construct calls the header file as a class, with parameters. It seemed to me similar to jquery. Comfortable enough, yes?
When programming, you need to take into account the fact that you can create your own element and connect it as a class. Or use ready-made solutions for design.
The system supports most languages. Find a language pack is not difficult, it is here:
{% RTHOME%} / lib / RT / I18N / *. Po - for RT 3.8
{% RTHOME%} / share / po / *. Po - for RT 4.
The structure of the localization file is extremely simple and to enter your variables or change the existing labor will not make Operand is used to connect the variable:
One caveat should be noted when building ajax constructs: due to the use of Mason, the interpreter does not accept the main function jquery - $. Therefore, in RT 4 you should use:
and in RT 3.8 (because prototype.js is used):
The system has an interface to access the database. In my case, this is the mysql base. To connect to the current RT database, you need to define variables:
Having received the variables, we can (even without using the RT interface to access the database) connect to mysql. For example, using
Here only small knowledge (nuances) in the field of RT programming, obtained as a result of the execution of a project to refine the above described system, is considered. If this topic is interesting, in the future I will write more in-depth knowledge regarding API RT.
Thanks for attention.
In this topic, I will talk about the principles of building the request tracker from the point of view of programming, because This is a fairly good accounting system and can be used at a large enterprise as a helpdesk system.
Who cares - welcome under cat.
Introduction or a little about the system:
The system is written in perl, works with any (I checked for 2) http-server. The database set with which the system can work is extensive. It is fast enough, page generation occurs on the fly and there are no brakes with the content update. The last two stable branches, 3.8 and 4.11, were considered in detail.
The main differences between the branches touched the interface, with the same set of constructors in the code with minor changes. However, in prototype, the prototype framework is used and ajax is almost not used, while in 4.11 jquery is used (which is much more convenient in my opinion) and ajax constructions are used.
Delve into the code:
The system uses the Mason package, which allows embedding the perl-code into the document:
use HTML::Mason You can read about Mason structures here .
Also, the system uses a serious caching mode, which can cause rejection when programming under RT in the first stages, since each time you change the code, you should “kill” the RT session, clear the cache and restart the http server. Of course, these actions can be combined into a script, but there is another option - you should set the option in the RT_Config.pm config file:
')
Set($DevelMode,"1") This option disables object caching, which allows writing under RT using ajax.
The detailed directory structure of the RT is a group of directories named by category of objects. For example:
For the “Ticket” object (application) the structure will be as follows:
- / Ticket
- / Ticket / Attachment
- / Ticket / Elements
- / Ticket / Graphs
- /Ticket/Create.html
- ...
Each element directory has an Elements folder, which contains constructors for this type of element.
I will give an example:
<& /Elements/Header, Title => $title, onload => "function() { ... } " &> This construct calls the header file as a class, with parameters. It seemed to me similar to jquery. Comfortable enough, yes?
When programming, you need to take into account the fact that you can create your own element and connect it as a class. Or use ready-made solutions for design.
About localization
The system supports most languages. Find a language pack is not difficult, it is here:
{% RTHOME%} / lib / RT / I18N / *. Po - for RT 3.8
{% RTHOME%} / share / po / *. Po - for RT 4.
The structure of the localization file is extremely simple and to enter your variables or change the existing labor will not make Operand is used to connect the variable:
<% loc("param") %> Ajax
One caveat should be noted when building ajax constructs: due to the use of Mason, the interpreter does not accept the main function jquery - $. Therefore, in RT 4 you should use:
jQuery.ajax(...) and in RT 3.8 (because prototype.js is used):
new Ajax.Request(....) Briefly about working with Mysql
The system has an interface to access the database. In my case, this is the mysql base. To connect to the current RT database, you need to define variables:
my $dbname = RT->Config->Get('DatabaseName'); # my $dbhost = RT->Config->Get('DatabaseRtHost'); # my $dbuser = RT->Config->Get('DatabaseUser'); # my $dbpass = RT->Config->Get('DatabasePassword'); # Having received the variables, we can (even without using the RT interface to access the database) connect to mysql. For example, using
use DBI::mysql; my $dbh = DBI->connect(...) And in the conclusion of folk wisdom
Here only small knowledge (nuances) in the field of RT programming, obtained as a result of the execution of a project to refine the above described system, is considered. If this topic is interesting, in the future I will write more in-depth knowledge regarding API RT.
Thanks for attention.
Source: https://habr.com/ru/post/190822/
All Articles