Best practices for AddOn installation

[StCyr]

Hi,

I've created an AddOn that needs to modify files of an ITSM extension (ITSMConfigurationManagement) to function.

For now, I'm just embedding a customized version of these files in my package, but this is not very flexible and won't easily survive an upgrade of the ITSM extension.

I've googled without success to find how to best solve this probem.

Do any of you have best practices to share on how to solve this problem?

Best regards,

Cyr

[StCyr]

In the end, the question is:

What do you do when your addon needs to modify an existing file?

Do you embed a modified copy of the file in your package? Or, do you modify it on-the-fy?... Or, do you do something else?

Additional question: Do any of you have examples of addon modifying OTRS files? I've search on OPAR without much success; It's like addons never modify files...

Any hints would be appreciated.

Best regards,

Cyr

[reneeb]

You shouldn't modify "on the fly". That would lead to unpredictable results when several add ons do this... On OPAR you'll find just .opms, no idea how you tried to find addons that override framework files (OPAR doesn't provide a code browser - but that might be a good feature to add)...

If you want to provide a modified version of a framework file, just add it to your add on. If you create an add on for OTRS <= 3.2, you'll have to keep in mind that templates had to be in Kernel/Output/HTML/.... For templates the was no "Custom" directory. Other Perl modules should be located under Custom/...

Some examples:

https://github.com/reneeb/otrs-TicketOverviewHooked/
Overrides the ticket overviews. Changes are marked with something like https://github.com/reneeb/otrs-TicketOv ... ll.pm#L215

https://github.com/reneeb/otrs-TicketBarcode/
Changed AgentTicketPrint.pm https://github.com/reneeb/otrs-TicketBa ... etPrint.pm

[StCyr]

Hi Renee,

Thanks for your answer.

When I say "on the fly", I don't mean modifying file "in place", but rather make a copy of the file in the "Custom" directory, and modify it there (taking into account that an existing custom file might already exist).

The issue with providing a (modified) copy of "external" files is that my AddOn will need to be changed every time the external file gets changed. And, worse, this change might be backward compatible.

So, in the end, I might end up with several versions of the AddOn, each being compatible with only some of OTRS versions.

THAT is what I would like to avoid.

But, I'm aware no viable solution might exist; I'm just investigating...

Best regards,

Cyrille

[reneeb]

That's the way it is. Whenever the "core" changes, you have to change your add on (when the core changes affect your add on) and it might lead to different add on versions for different OTRS versions. There is no way around it...

That's why I try to avoid to change the core files and rather use other mechanisms to extend OTRS:

* Event-modules
* Output filter
* pre-application modules
* Override functionality when OTRS provides a way to write a module that can act as a parent class (like modules registered in Ticket::Custom)

Some of those mechanisms have (minor) drawbacks like (minor) performance penalties.

But sometimes it is not possible to use those mechanisms.