Az OTRS 6-ban egy új modul lett hozzáadva a dátum- és időszámításhoz: Kernel::System::DateTime. A Kernel::System::Time modul mostantól elavult, és többé nem szabad használni új kódoknál.

Az új Kernel::System::DateTime modul legfőbb előnye, hogy támogatja a valódi időzónákat (mint például Europe/Berlin) az órákban számított időeltolások (mint például +2) helyett. Ne feledje, hogy a régi Kernel::System::Time modult is továbbfejlesztették az időzónák támogatásához. Az időeltolások teljes mértékben eldobásra kerültek. Ez azt jelenti, hogy az összes olyan kódot, amely időeltolásokat használ a számításokhoz, át kell írni az új DateTime modul használatához. Azok a kódok, amelyek önmaguk nem foglalkoznak az időeltolásokkal, a legtöbb esetben maradhatnak érintetlenül. Mindössze arról kell meggyőződnie, hogy a Kernel::System::Time objektum létrehozásakor érvényes időzóna legyen megadva.

Itt egy példa az időeltolásos kód időzónákra történő átírásához:

# Feltételezzünk egy 0 időeltolást ennél az objektumnál.
my $TimeObject     = $Kernel::OM->Get('Kernel::System::Time');
my $SystemTime     = $TimeObject->TimeStamp2SystemTime( String => '2004-08-14 22:45:00' );
# Általában beállításon vagy paraméteren keresztül van lekérve.
my $UserTimeZone   = '+2';
my $UserSystemTime = $SystemTime + $UserTimeZone * 3600;
my $UserTimeStamp  = $TimeObject->SystemTime2TimeStamp( SystemTime => $UserSystemTime );
            

Az új Kernel::System::DateTime modult használó kód:

# Ez hallgatólagosan beállítja a beállított OTRS időzónát.
my $DateTimeObject = $Kernel::OM->Create('Kernel::System::DateTime');
# Általában beállításon vagy paraméteren keresztül van lekérve.
my $UserTimeZone   = 'Europe/Berlin';
$DateTimeObject->ToTimeZone( TimeZone => $UserTimeZone );
# Ne feledje, hogy az epoch független az időzónától, mindig az UTC-hez lesz kiszámítva.
my $SystemTime    = $DateTimeObject->ToEpoch();
my $UserTimeStamp = $DateTimeObject->ToString();
            

Ne feledje, hogy a Kernel::System::DateTime modulban lévő új Get() függvénnyel visszaadott időértékek vezető nulla nélkül lesznek a Kernel::System::Time modulban lévő SystemTime2Date() függvény által visszaadottak helyett. Az új Kernel::System::DateTime modulban a Format() függvény szövegként adja vissza a dátumot és időt a megadott formátum szerint.

Az OTRS 6-nál egy több mellékletet feltöltő funkcionalitás lett hozzáadva. Ahhoz, hogy a több melléklet feltöltését megvalósítsa az egyéb kiterjesztésekben, a melléklet rész, valamint a JSOnDocumentComplete részek eltávolítása szükséges a sablonfájlokból (AttachmentDelete és AttachmentUpload). Tartsa észben, hogy néhány esetben a JavaScript részek már kihelyezésre kerültek a Core.Agent.XXX fájlokba.

Ahhoz, hogy az új több melléklet feltöltést tartalmazza a sablon, cserélje le a meglévő input type="file" elemet a következő kódra a .tt sablonfájlban:

<label>[% Translate("Attachments") | html %]:</label>
<div class="Field">
[% INCLUDE "FormElements/AttachmentList.tt" %]
</div>
<div class="Clear"></div>
            

Az is szükséges, hogy eltávolítsa az IsUpload változót és az összes egyéb IsUpload részt a Perl-modulból. Az olyan kódrészek nem szükségesek többé, mint a következők:

my $IsUpload = ( $ParamObject->GetParam( Param => 'AttachmentUpload' ) ? 1 : 0 );
            

Ezenkívül a melléklet megjelenítő blokkot is le kell cserélni:

$LayoutObject->Block(
    Name => 'Attachment',
    Data => $Attachment,
);
            

Cserélje le erre a kódra:

push @{ $Param{AttachmentList} }, $Attachment;
            

Ha a modul, ahová integrálni szeretné a többszörös feltöltést, támogatja a szabványos sablonokat, akkor győződjön meg arról, hogy hozzáadott-e egy szakaszt az ember által olvasható fájlméret formátumok megjelenítéséhez közvetlenül azután, hogy a kiválasztott sablon melléklete be lett töltve (nézze meg az AgentTicketPhone modult hivatkozásként):

for my $Attachment (@TicketAttachments) {
    $Attachment->{Filesize} = $LayoutObject->HumanReadableDataSize(
        Size => $Attachment->{Filesize},
    );
}
            

Mikor Selenium egységteszteket ad az átírt modulokhoz, akkor vessen egy pillantást a Selenium/Agent/MultiAttachmentUpload.t fájlra hivatkozásként.

A Perl-fájlokban lévő POD szerkezete kis mértékben javítva lett, és alkalmazni kell az összes fájlban. A POD mostantól kényszerítve van, hogy szintaktikailag helyes legyen.

Amit korábban SYNOPSIS szakasznak hívtak, azt most DESCRIPTION névre változtatták, mivel a szinopszis jellemzően néhány népszerű kódhasználati példát biztosít, és nem magának a modulnak a leírását. Természetesen megadható további szinopszis. Itt egy példa arra, hogy hogyan:

=head1 NAME

Kernel::System::ObjectManager - Központi egyke kezelő és objektumpéldány előállító

=head1 SYNOPSIS

# Csak felső szintű parancsfájlokban!
local $Kernel::OM = Kernel::System::ObjectManager->new();

# Bárhol: egyke példány lekérése (és létrehozása, ha szükséges).
my $ConfigObject = $Kernel::OM->Get('Kernel::Config');

# Egyke objektumok és az összes függőségük eltávolítása.
$Kernel::OM->ObjectsDiscard(
    Objects            => ['Kernel::System::Ticket', 'Kernel::System::Queue'],
);

=head1 DESCRIPTION

Az objektumkezelő egy központi hely az egyke OTRS objektumok létrehozásához
és hozzáféréséhez (a C<L</Get()>> metóduson keresztül), valamint szabályos
(nem kezelt) objektumpéldányok létrehozásához (a C<L</Create()>> metóduson
keresztül).

            

Abban az esetben, ha a DESCRIPTION nem ad hozzá semmilyen értéket a NAME szakaszban lévő sorhoz, akkor át kell írni vagy teljesen el kell távolítani.

A második fontos változtatás, hogy a függvények mostantól =head2 szakaszként vannak dokumentálva a korábban használt =item helyett.

=head2 Get()

Lekér egy egyke objektumot, és ha még nem létezik, akkor a háttérben létrehoz egyet.

my $ConfigObject = $Kernel::OM->Get('Kernel::Config');

# Második meghíváskor visszaadja ugyanazt a ConfigObject objektumot, mint ami fent van.
my $ConfigObject2 = $Kernel::OM->Get('Kernel::Config');

=cut

sub Get { ... }
            

Ezek a változtatások egy továbbfejlesztett internetes API dokumentációhoz vezetnek, amint az objektumkezelő dokumentációjában is látható az OTRS 5 és az OTRS 6 esetén.

Az OTRS 6 előtt a felhasználói jogosultságok a munkamenetben voltak eltárolva és attribútumként lettek átadva a LayoutObject objektumnak, amely viszont ezután hozzáfért a meghatározott felhasználói jogosultságokhoz, mint például if ($LayoutObject->{'UserIsGroup[admin]'}) { ... }.

Az OTRS 6-tal a jogosultságok többé nincsenek a munkamenetben eltárolva, és nem kerülnek átadásra a LayoutObject objektumnak sem. Cserélje ki a kódjában, hogy a PermissionCheck() metódust hívja meg a Kernel::System::Group modulon (ügyintézőknél) vagy a Kernel::System::CustomerGroup modulon (ügyfeleknél). Itt egy példa:

my $HasPermission = $Kernel::OM->Get('Kernel::System::Group')->PermissionCheck(
UserID    => $UserID,
GroupName => $GroupName,
Type      => 'move_into',
);
            

Az OTRS 6-ban változások történtek a bejegyzés API-n az új Omni Channel infrastruktúra előkészítéséhez.

    my $ArticleObject = $Kernel::OM->Get('Kernel::System::Ticket::Article');

    my %ArticleSenderTypeList = $ArticleObject->ArticleSenderTypeList();
                

my @Articles = $ArticleObject->ArticleList(
    TicketID             => 123,
    CommunicationChannel => 'Email',            # elhagyható, korlátozás egy bizonyos kommunikációs csatornára
    SenderType           => 'customer',         # elhagyható, korlátozás egy bizonyos bejegyzés küldőtípusra
    IsVisibleForCustomer => 1,                  # elhagyható, korlátozás egy bizonyos láthatóságra
    OnlyFirst            => 1,                  # elhagyható, csak az első egyezést adja vissza, vagy
    OnlyLast             => 1,                  # elhagyható, csak az utolsó egyezést adja vissza
);
                

my $ArticleBackendObject = $ArticleObject->BackendForArticle( TicketID => 42, ArticleID => 123 );
                

my $ArticleBackendObject = $ArticleObject->BackendForChannel( ChannelName => 'Email' );
                

my @Articles = $ArticleObject->ArticleList(
    TicketID => $TicketID,
);

ARTICLE:
for my $Article (@Articles) {

    # Győződjön meg arról, hogy lekérte-e a háttérprogram-objektumot ehhez a bizonyos bejegyzéshez.
    my $ArticleBackendObject = $ArticleObject->BackendForArticle( %{$Article} );

    my %ArticleData = $ArticleBackendObject->ArticleGet(
        %{$Article},
        DynamicFields => 1,
        UserID        => $UserID,
    );
    $Article = \%ArticleData;

    # Mellékletindex lekérése (mellékletek nélkül).
    my %AtmIndex = $ArticleBackendObject->ArticleAttachmentIndex(
        ArticleID => $Article->{ArticleID},
        UserID    => $UserID,
    );
    next ARTICLE if !%AtmIndex;

    my @Attachments;
    ATTACHMENT:
    for my $FileID ( sort keys %AtmIndex ) {
        my %Attachment = $ArticleBackendObject->ArticleAttachment(
            ArticleID => $Article->{ArticleID},
            FileID    => $FileID,
            UserID    => $UserID,
        );
        next ATTACHMENT if !%Attachment;

        $Attachment{FileID} = $FileID;
        $Attachment{Content} = encode_base64( $Attachment{Content} );

        push @Attachments, \%Attachment;
    }

    # Mellékletadatok felvétele a bejegyzés kivonatába.
    $Article->{Atms} = \@Attachments;
}
                

Ne feledje, hogy az OTRS 6-ban a rendszerbeállítások API megváltozott, ezért ellenőriznie kell, hogy a metódusok léteznek-e még. Például a ConfigItemUpdate() el lett távolítva. A helyettesítéshez a következő metódusok kombinációját kell használnia:

Abban az esetben, ha frissíteni szeretne egy konfigurációs beállítást egy csomag CodeInstall szakasza közben, akkor használhatja a SettingsSet() metódust. Ez elvégzi a korábban említett összes lépést, és használható egyszerre több beállításnál is.

my $Success = $SysConfigObject->SettingsSet(
    UserID   => 1,                                      # (kötelező) Felhasználó-azonosító.
    Comments => 'Üzembe állítási megjegyzés.',          # (elhagyható) Megjegyzés.
    Settings => [                                       # (kötelező) Frissítendő beállítások listája.
        {
            Name                   => 'Setting::Name',  # (kötelező)
            EffectiveValue         => 'Value',          # (elhagyható)
            IsValid                => 1,                # (elhagyható)
            UserModificationActive => 1,                # (elhagyható)
        },
        ...
    ],
);
            

Ne feledje, hogy a LinkObject kissé módosult az OTRS 6-ban, valamint a LinkList() és a LinkKeyList() metódusok különböző eredményt adhatnak vissza, ha a Direction paramétert használják. Fontolja meg a Direction paraméter megváltoztatását.

Régi kód:

my $LinkList = $LinkObject->LinkList(
    Object    => 'Ticket',
    Key       => '321',
    Object2   => 'FAQ',
    State     => 'Valid',
    Type      => 'ParentChild',
    Direction => 'Target',
    UserID    => 1,
);
            

Új kód:

my $LinkList = $LinkObject->LinkList(
    Object    => 'Ticket',
    Key       => '321',
    Object2   => 'FAQ',
    State     => 'Valid',
    Type      => 'ParentChild',
    Direction => 'Source',
    UserID    => 1,
);
            

Az OTRS 6 e-mail kezelési továbbfejlesztésének részeként egy új naplózó mechanizmus lett hozzáadva az OTRS 6-hoz, kifejezetten a bejövő és kimenő kommunikációk használatához. Az összes levelezési szűrő fel lett javítva ezzel az új kommunikációs napló API-val, amely azt jelenti, hogy a csomagokkal érkező bármely további szűrő is kihasználhatja az új naplózási funkciót.

Ha a csomagja további levelezési szűrőket valósít meg, akkor győződjön meg arról, hogy megismerje az API használati utasításokat. Kap egy példát is azzal kapcsolatban, hogy ezt a naplózási mechanizmust hogyan kell megvalósítani, ha belenéz a Kernel::System::PostMaster::NewTicket kódjába.

Az OTRS 6 e-mail kezelési továbbfejlesztésének részeként az összes e-mail mostantól aszinkron módon lesz elküldve, amely azt jelenti, hogy egy várakozási sorba lesznek elmentve a későbbi feldolgozáshoz.

Ahhoz, hogy az e-mailektől függő egységtesztek továbbra is megfelelően működjenek, az e-mail várakozási sor feldolgozásának kényszerítése szükséges.

Győződjön meg arról, hogy egy tiszta várakozási sorral indul:

                my $MailQueueObject = $Kernel::OM->Get('Kernel::System::MailQueue');
                $MailQueueObject->Delete();
            

Ha néhány esetben nem tudja teljesen kitakarítani a várakozási sort (például Selenium egységteszteknél), akkor egyszerűen törölje azokat az elemeket, amelyek a tesztek során jöttek létre:

                my $MailQueueObject = $Kernel::OM->Get('Kernel::System::MailQueue');
                my %MailQueueCurrentItems = map { $_->{ID} => $_ } @{ $MailQueueObject->List() || [] };

                my $Items = $MailQueueObject->List();
                MAIL_QUEUE_ITEM:
                for my $Item ( @{$Items} ) {
                    next MAIL_QUEUE_ITEM if $MailQueueCurrentItems{ $Item->{ID} };
                    $MailQueueObject->Delete(
                        ID => $Item->{ID},
                    );
                }
            

Dolgozza fel a várakozási sort azután a kód után, amely várhatóan elküldi az e-maileket:

                my $MailQueueObject = $Kernel::OM->Get('Kernel::System::MailQueue');
                my $QueueItems      = $MailQueueObject->List();
                for my $Item ( @{$QueueItems} ) {
                    $MailQueueObject->Send( %{$Item} );
                }
            

Vagy csak azokat dolgozza fel, amelyek a tesztek során jöttek létre:

                my $MailQueueObject = $Kernel::OM->Get('Kernel::System::MailQueue');
                my $QueueItems      = $MailQueueObject->List();
                MAIL_QUEUE_ITEM:
                for my $Item ( @{$QueueItems} ) {
                    next MAIL_QUEUE_ITEM if $MailQueueCurrentItems{ $Item->{ID} };
                    $MailQueueObject->Send( %{$Item} );
                }
            

Az esettől függően esetleg ki kell takarítania a várakozási sort a feldolgozása után vagy előtt.

A jegynagyítás képernyőn lévő felületi elemek továbbfejlesztésre kerültek, hogy általánosabb módon működjenek. Az OTRS 6-tal mostantól lehetőség van új felületi elemek hozzáadására a jegynagyítás képernyőhöz a rendszerbeállításokon keresztül. Lehetőség van beállítani a használt modult, a felületi elem helyzetét (például oldalsáv) és hogy a tartalmat szinkron módon (alapértelmezett) vagy AJAX kérésen keresztül kell betölteni.

Itt egy beállítási példa az alapértelmezett felületi elemekhez:

<Setting Name="Ticket::Frontend::AgentTicketZoom###Widgets###0100-TicketInformation" Required="0" Valid="1">
    <Description Translatable="1">AgentTicketZoom widget that displays ticket data in the side bar.</Description>
    <Navigation>Frontend::Agent::View::TicketZoom</Navigation>
    <Value>
        <Hash>
            <Item Key="Module">Kernel::Output::HTML::TicketZoom::TicketInformation</Item>
            <Item Key="Location">Sidebar</Item>
        </Hash>
    </Value>
</Setting>
<Setting Name="Ticket::Frontend::AgentTicketZoom###Widgets###0200-CustomerInformation" Required="0" Valid="1">
    <Description Translatable="1">AgentTicketZoom widget that displays customer information for the ticket in the side bar.</Description>
    <Navigation>Frontend::Agent::View::TicketZoom</Navigation>
    <Value>
        <Hash>
            <Item Key="Module">Kernel::Output::HTML::TicketZoom::CustomerInformation</Item>
            <Item Key="Location">Sidebar</Item>
            <Item Key="Async">1</Item>
        </Hash>
    </Value>
</Setting>
            

Az OTRS 5-ben a Kernel/Output/HTML átszerkesztésre került. Az összes Perl modul (kivéve a Layout.pm fájlt) alkönyvtárakba került áthelyezésre (minden modulréteghez egybe). A sablonfájlok (témák) is áthelyezésre kerültek a Kernel/Output/HTML/Standard könyvtárból a Kernel/Output/HTML/Templates/Standard könyvtárba. Végezze el ezeket a költöztetéseket a saját kódjában is.

Az OTRS 5-tel többé nincs támogatás a pre kimenetszűrőkhöz. Ezek a szűrők azelőtt változtatták meg a sablon tartalmát, mielőtt az feldolgozásra került volna, és potenciálisan rossz teljesítményproblémákhoz vezethettek, ugyanis a sablonokat többé nem lehetett gyorstárazni, és minden alkalommal fel kellett dolgozni és le kellett fordítani.

Egyszerűen váltson a pre kimenetszűrőről a post kimenetszűrőre. A tartalom lefordításához futtathatja közvetlenül a $LayoutObject->Translate() függvényt. Ha egyéb sablonszolgáltatásokra van szüksége, akkor egyszerűen határozzon meg egy kis sablonfájlt a kimenetszűrőhöz, és használja azt a tartalom megjelenítéséhez, mielőtt beültetné azt a fő adatokba. Néhány esetben hasznos lehet a jQuery DOM műveletek használata is a képernyőn lévő tartalom sorrendjének megváltoztatásához vagy cseréjéhez a reguláris kifejezések használata helyett. Ebben az esetben láthatatlan tartalomként kellene beültetnie az új kódot valahova az oldalba (például a Hidden osztállyal), majd ezután áthelyezni a jQuery használatával a megfelelő helyre a DOM-ban, és megjeleníteni azt.

Az utó-kimenetszűrők használatának megkönnyítéséhez létezik egy új mechanizmus is a HTML megjegyzéshorgok lekéréséhez bizonyos sablonoknál vagy blokkoknál. Hozzáadhatja a modulbeállító XML-be a következőhöz hasonlóan:

<ConfigItem
Name="Frontend::Template::GenerateBlockHooks###100-OTRSBusiness-ContactWithData"
Required="1" Valid="1">
    <Description Translatable="1">Generate HTML comment hooks for
the specified blocks so that filters can use them.</Description>
    <Group>OTRSBusiness</Group>
    <SubGroup>Core</SubGroup>
    <Setting>
        <Hash>
            <Item Key="AgentTicketZoom">
                <Array>
                    <Item>CustomerTable</Item>
                </Array>
            </Item>
        </Hash>
    </Setting>
</ConfigItem>
            

Ez azt fogja okozni, hogy az AgentTicketZoom.tt fájlban lévő CustomerTable blokk át lesz alakítva a HTML megjegyzésekben minden alkalommal, amikor megjelenítésre kerül:

<!--HookStartCustomerTable-->
... blokk kimenet ...
<!--HookEndCustomerTable-->
            

Ezzel a mechanizmussal minden csomag csak azokat a blokkhorgokat kérheti, amelyekre szüksége van, és következetesen kerülnek megjelenítésre. Ezek a HTML megjegyzések használhatók ezután a kimenetszűrőben az egyszerű reguláris kifejezés illesztéshez.

Az IE 8 és IE 9 támogatást eldobták. Eltávolíthat minden kerülőmegoldást a kódjából, amelyet ezekhez a platformokhoz készített, valamint az összes olyan régi <CSS_IE7> vagy <CSS_IE8> betöltő címkét, amely még esetleg megbújik az XML beállítófájljaiban.

A TicketGet() művelet másképpen ad vissza dinamikus mező adatokat a jegyből és a bejegyzésből mint az OTRS 4-ben. Mostantól ezek tisztán el vannak választva a többi statikus jegy- és bejegyzésmezőktől - innentől kezdve csoportosítva vannak egy DynamicField nevű listába. Eszerint alakítson át minden olyan alkalmazást, amely ezt a műveletet használja.

# megváltoztatva erről:

Ticket => [
{
    TicketNumber       => '20101027000001',
    Title              => 'valamilyen cím',
    ...
    DynamicField_X     => 'x_ertek',
},
]

# erre:

Ticket => [
{
    TicketNumber       => '20101027000001',
    Title              => 'valamilyen cím',
    ...
    DynamicField => [
        {
            Name  => 'valamilyen név',
            Value => 'valamilyen érték',
        },
    ],
},
]
            

Az új statisztikák grafikus felhasználói felülete egy előnézetet biztosít a jelenlegi beállításhoz. Ezt meg kell valósítani a statisztikák moduljaiban, és általában hamis vagy véletlenszerű adatokat adnak vissza sebességi okokból. Így minden olyan dinamikus (mátrix) statisztikánál, amely a GetStatElement() metódust biztosítja, hozzá kell adnia egy GetStatElementPreview() metódust is, valamint minden olyan dinamikus (tábla) statisztikánál, amely a GetStatTable() metódust biztosítja, hozzá kell adnia egy GetStatTablePreview() metódust ennek megfelelően. Egyébként az új statisztikák grafikus felhasználói felületén lévő előnézet nem fog működni a saját statisztikáinál. Példamegvalósításokat találhat az alapértelmezett OTRS statisztikákban.

Az OTRS 5-ig a PDF::API2 Perl modul nem volt megtalálható minden rendszeren. Ezért létezett egy tartalék HTML nyomtatási mód. Az OTRS 5-tel a modul mostantól mellékelve van, és a HTML nyomtatás eldobásra került. A $LayoutObject->PrintHeader() és a PrintFooter() többé nem érhető el. Távolítsa el a tartalék HTML nyomtatást a kódjából, és változtassa meg a PDF előállításához, ha szükséges.

Az OTRS 5-ig a lefordítható szövegeket nem lehetett kinyerni a Perl kódból és az adatbázis XML meghatározásokból. Ez mostantól lehetséges, és elavulttá tette az olyan üres sablonokat, mint például az AAA*.tt sablont. A részletekért nézze meg ezt a szakaszt.

Az OTRS 4-ig az objektumokat mind központilag, mind helyileg létre kellett hozni, és ekkor az összes objektumot le kellett kezelni a konstruktornak átadva azokat. Az OTRS 4-es és későbbi verzióinál mostantól létezik egy ObjectManager objektum, amely központosítja az egyke objektum létrehozását és hozzáférését.

Ez mindenek előtt azt fogja igényelni, hogy változtassa meg az összes felső szintű Perl parancsfájlt (csak a .pl fájlokat!) az ObjectManager betöltéséhez és biztosításához az összes OTRS objektumnál. Példaként nézzük meg az otrs.CheckDB.pl parancsfájlt az OTRS 3.3-ból:

use strict;
use warnings;

use File::Basename;
use FindBin qw($RealBin);
use lib dirname($RealBin);
use lib dirname($RealBin) . '/Kernel/cpan-lib';
use lib dirname($RealBin) . '/Custom';

use Kernel::Config;
use Kernel::System::Encode;
use Kernel::System::Log;
use Kernel::System::Main;
use Kernel::System::DB;

# a szokásos objektumok létrehozása
my %CommonObject = ();
$CommonObject{ConfigObject} = Kernel::Config->new();
$CommonObject{EncodeObject} = Kernel::System::Encode->new(%CommonObject);
$CommonObject{LogObject}    = Kernel::System::Log->new(
    LogPrefix    => 'OTRS-otrs.CheckDB.pl',
    ConfigObject => $CommonObject{ConfigObject},
);
$CommonObject{MainObject} = Kernel::System::Main->new(%CommonObject);
$CommonObject{DBObject}   = Kernel::System::DB->new(%CommonObject);
            

Láthatjuk, hogy rengeteg kódot használnak a csomagok betöltéséhez és a gyakori objektumok létrehozásához, amelyet a parancsfájlban át kell adni a használandó OTRS objektumoknak. Az OTRS 4-gyel ez egy kicsit máshogy néz ki:

use strict;
use warnings;

use File::Basename;
use FindBin qw($RealBin);
use lib dirname($RealBin);
use lib dirname($RealBin) . '/Kernel/cpan-lib';
use lib dirname($RealBin) . '/Custom';

use Kernel::System::ObjectManager;

# a szokásos objektumok létrehozása
local $Kernel::OM = Kernel::System::ObjectManager->new(
'Kernel::System::Log' => {
    LogPrefix => 'OTRS-otrs.CheckDB.pl',
},
);

# az adatbázis-objektum lekérése
my $DBObject = $Kernel::OM->Get('Kernel::System::DB');
            

Az új kód egy kicsivel rövidebb mint a régi. Többé nem szükséges az összes csomag betöltése, elég csak az ObjectManager objektumot. Azután a $Kernel::OM->Get('Sajat::Perl::Csomag') használható az objektumok példányainak lekéréséhez, amelyeket csak egyszer kell létrehozni. A LogPrefix beállítás vezérli azokat a naplóüzeneteket, amelyeket a Kernel::System::Log ír ki, így az szintén elhagyható.

Ebből a példából kikövetkeztetheti az általános átírási irányelvet is, amikor az objektumok hozzáférése jön: többé ne tárolja azokat a $Self változóban (hacsak bizonyos okokból ez nem szükséges). Egyszerűen kérje le és használja az objektumokat igény szerint, úgymint $Kernel::OM->Get('Kernel::System::Log')->Log(...). Ennek megvan az az előnye is, hogy a Log objektumot csak akkor kell majd létrehozni, ha valamit naplózni kell. Néha hasznos lehet helyi változókat is létrehozni, ha egy objektumot többször használnak egy függvényben, mint például a fenti példában lévő $DBObject objektumot.

Nem kell sokkal többet tudnia az olyan csomagok átírásakor, amelyeknek betölthetőnek kell lenniük az ObjectManager használatával. Meg kell határozniuk azokat a modulokat, amelyeket használnak (a $Kernel::OM->Get() függvényen keresztül) ehhez hasonlóan:

our @ObjectDependencies = (
'Kernel::Config',
'Kernel::System::Log',
'Kernel::System::Main',
);
            

Az @ObjectDependencies meghatározás szükséges az ObjectManager objektumhoz a helyes sorrend megtartásához az objektumok megsemmisítésekor.

Nézzük meg a Valid.pm fájlt az OTRS 3.3-ból és a 4-ből, hogy lássuk a különbséget. A régi:

package Kernel::System::Valid;

use strict;
use warnings;

use Kernel::System::CacheInternal;

...

sub new {
my ( $Type, %Param ) = @_;

# új kivonat lefoglalása az objektumhoz
my $Self = {};
bless( $Self, $Type );

# a szükséges objektumok ellenőrzése
for my $Object (qw(DBObject ConfigObject LogObject EncodeObject MainObject)) {
    $Self->{$Object} = $Param{$Object} || die "Nincs $Object!";
}

$Self->{CacheInternalObject} = Kernel::System::CacheInternal->new(
    %{$Self},
    Type => 'Valid',
    TTL  => 60 * 60 * 24 * 20,
);

return $Self;
}

...

sub ValidList {
my ( $Self, %Param ) = @_;

# gyorsítótár olvasása
my $CacheKey = 'ValidList';
my $Cache = $Self->{CacheInternalObject}->Get( Key => $CacheKey );
return %{$Cache} if $Cache;

# lista lekérése az adatbázisból
return if !$Self->{DBObject}->Prepare( SQL => 'SELECT id, name FROM valid' );

# az eredmény lekérése
my %Data;
while ( my @Row = $Self->{DBObject}->FetchrowArray() ) {
    $Data{ $Row[0] } = $Row[1];
}

# gyorsítótár beállítása
$Self->{CacheInternalObject}->Set( Key => $CacheKey, Value => \%Data );

return %Data;
}
            

Az új:

package Kernel::System::Valid;

use strict;
use warnings;

our @ObjectDependencies = (
'Kernel::System::Cache',
'Kernel::System::DB',
'Kernel::System::Log',
);

...

sub new {
my ( $Type, %Param ) = @_;

# új kivonat lefoglalása az objektumhoz
my $Self = {};
bless( $Self, $Type );

$Self->{CacheType} = 'Valid';
$Self->{CacheTTL}  = 60 * 60 * 24 * 20;

return $Self;
}

...

sub ValidList {
my ( $Self, %Param ) = @_;

# gyorsítótár olvasása
my $CacheKey = 'ValidList';
my $Cache    = $Kernel::OM->Get('Kernel::System::Cache')->Get(
    Type => $Self->{CacheType},
    Key  => $CacheKey,
);
return %{$Cache} if $Cache;

# adatbázis-objektum lekérése
my $DBObject = $Kernel::OM->Get('Kernel::System::DB');

# lista lekérése az adatbázisból
return if !$DBObject->Prepare( SQL => 'SELECT id, name FROM valid' );

# az eredmény lekérése
my %Data;
while ( my @Row = $DBObject->FetchrowArray() ) {
    $Data{ $Row[0] } = $Row[1];
}

# gyorsítótár beállítása
$Kernel::OM->Get('Kernel::System::Cache')->Set(
    Type  => $Self->{CacheType},
    TTL   => $Self->{CacheTTL},
    Key   => $CacheKey,
    Value => \%Data
);

return %Data;
}
            

Láthatja, hogy meg vannak határozva a függőségek, és az objektumok csak igény szerint vannak lekérve. A következő szakaszban a CacheInternalObject objektumról fogunk beszélni.

Mivel a Kernel::System::Cache mostantól képes a memóriában is gyorstárazni, a Kernel::System::CacheInternal eldobásra került. Nézze meg az előző példát, hogy a kódot hogyan kell átköltöztetni: a globális Cache objektumot kell használnia, és át kell adnia a Type beállítást a Get(), Set(), Delete() és CleanUp() függvények minden egyes hívásához. A TTL paraméter mostantól elhagyható, és alapértelmezetten 20 nap, így csak akkor kell megadnia a Get() függvényben, ha eltérő TTL értékre van szüksége.

Az ütemező háttérprogram fájljai áthelyezésre kerültek a Kernel/Scheduler mappából a Kernel/System/Scheduler mappába. Ha valamilyen egyéni feladatkezelő moduljai vannak, akkor azokat is át kell helyeznie.

Az SOPM fájlokban lévő kódcímkéket is frissíteni kell. Többé ne használja a $Self változót. Régebben ezt használták az olyan OTRS objektumokhoz való hozzáféréshez, mint például a MainObject. Mostantól használja az ObjectManager objektumot. Itt egy példa a régi stílusra:

<CodeInstall Type="post">

# függvénynév meghatározása
my $FunctionName = 'CodeInstall';

# a csomagnév létrehozása
my $CodeModule = 'var::packagesetup::' . $Param{Structure}->{Name}->{Content};

# a modul betöltése
if ( $Self->{MainObject}->Require($CodeModule) ) {

# új példány létrehozása
my $CodeObject = $CodeModule->new( %{$Self} );

if ($CodeObject) {

    # metódus elindítása
    if ( !$CodeObject->$FunctionName(%{$Self}) ) {
        $Self->{LogObject}->Log(
            Priority => 'error',
            Message  => "Nem sikerült meghívni a(z) $FunctionName() metódust ebben: $CodeModule.pm."
        );
    }
}

# hibakezelés
else {
    $Self->{LogObject}->Log(
        Priority => 'error',
        Message  => "Nem sikerült meghívni a new() metódust ebben: $CodeModule.pm."
    );
}
}

</CodeInstall>
            

Most ezt a következővel kell helyettesíteni:

<CodeInstall Type="post"><![CDATA[
$Kernel::OM->Get('var::packagesetup::SajatCsomag')->CodeInstall();
]]></CodeInstall>
            

Az OTRS 4-gyel a DTL sablonmotort a Template::Toolkit váltotta. A részletekért nézze meg a sablonozó szakaszt, hogy hogyan néz ki az új sablonszintaxis.

Ezek azok a változtatások, amelyet alkalmaznia kell, amikor a meglévő DTL sablonokat az új Template::Toolkit szintaxisra alakítja át:

Létezik egy bin/otrs.MigrateDTLtoTT.pl segítő parancsfájl is, amely automatikusan át fogja írni önnek a DTL-fájlokat a Template::Toolkit szintaxisra. Sikertelen lehet, ha hibák találhatók a DTL-jében, ezért először javítsa ki ezeket, és azután futtassa újra a parancsfájlt.

Van még további néhány dolog, amelyet tudomásul kell vennie a kód átírásakor az új sablonmotorra:

Az OTRS 4-gyel egy új verzióra frissítettük a FontAwesome betűkészletet is. Ennek következtében az ikonok CSS-osztályai megváltoztak. Miközben a korábbi ikonok egy icon-{ikonnév} szerű sémával voltak meghatározva, ezt mostantól a fa fa-{ikonnév} formában kell megadni.

Ezen változtatás miatt meg kell győződnie arról, hogy frissítette-e az összes olyan egyéni előtétprogram-modul regisztrációit, amelyek ikonokat használnak (például a felső navigációs sávnál) az új séma használatához. Ez igaz az olyan sablonoknál is, ahol ikonelemeket használ, mint például <i class="icon-{ikonnév}"></i>.

Az OTRS 4-gyel az egységtesztekben a $Self többé nem szolgáltat olyan gyakori objektumokat, mint például a MainObject. Mindig a $Kernel::OM->Get('...') függvényt használja ezen objektumok lekéréséhez.

Ha bármilyen egyéni jegy előzmény típusokat használ, akkor két lépést kell elvégeznie, hogy azok helyesen legyenek megjelenítve az OTRS 4+ AgentTicketHistory képernyőjén.

Először regisztrálnia kell az egyéni jegy előzmény típusait a rendszerbeállításokon keresztül. Ez így nézhet ki:

<ConfigItem Name="Ticket::Frontend::HistoryTypes###100-MyCustomModule" Required="1" Valid="1">
<Description Translatable="1">Controls how to display the ticket history entries as readable values.</Description>
<Group>Ticket</Group>
<SubGroup>Frontend::Agent::Ticket::ViewHistory</SubGroup>
<Setting>
    <Hash>
        <Item Key="MyCustomType" Translatable="1">Added information (%s)</Item>
    </Hash>
</Setting>
</ConfigItem>
            

A második lépés az egyéni jegy előzmény típusnál biztosított angol szöveg lefordítása a nyelvi fájljaiban, ha szükséges. Ennyi!

Ha érdeklődik a részletek iránt, akkor nézze meg ezt a véglegesítést azon változtatásokkal kapcsolatos további információkról, amelyek az OTRS-ben történtek.