How to override a class method without __name__ attribute (model, wizard or report)?

Hi guys!,
I’m trying to make a customization to put an additional property in tryton configuration file… in order to do so I want to override the RecordTagHandler::characters method (in the file) in my custom module…
I found a good guide on how to override models, wizards or reports …however I’ve not found so far any clue on how to override (or filter) a method in a class like this… I don’t even know if that is possible… any guidance?


There is no mean for such customization.
You should maybe explain what you try to achieve, they may be other ways or it could be considered as a new feature that could be implemented in standard.

Thank you Cedric!..
What I’m trying to do is to have several instances of tryton… each with its own database and sharing a common code base (every instance symlinked to that common code base in order to avoid files duplication)… however I want to allow every instance to have customized reports… therefore the “standard location” for the report is not an option since one instance would overwrite the other one…

what I’ve done is to include a new config file attribute that points to the reports-templates location (for each instance)… but so far I’ve modified a couple of official methods (RecordTagHandler::characters and ActionReport::get_report_content) what I know is not a good practice from updates management point of view… so the idea is to have a module that overrides those methods …

You can start different processes from the same code base, there is no need for symlinks.

Customized report can be stored in the database directly by editing the The template in the database has priority over the file.
Also you can have custom module activated only for a specific database.

1 Like

If you need start many instances and modify code directory for each one, you may prefer hard links instead. As explained, reports are not the stake.
I’ve done so in a far past but today my multi-tenants (several hundreds per admin unit) have fully replicated code and it is not a problem, even on SSDs.

1 Like

Thank you Dominique!.. I appreciate your advice, I will explore that option… I originally considered but I was afraid of the upgrade process (n times)… however in the other side that can be considered an advantage if I don’t want to upgrade all instances at the same time…

How had been your experience on that regard?


All depends on the service you plan and the number of services you need. My solution initially targets 50<n<10000 segment and the main constraint is that end users decide on the versions and the customs.

It is fully automated, so updating the code is not a problem. Updating databases is more tricky because it may fail. It needs a detection and a backward path.

Thank you very much Dominique, I really appreciate your advice!..


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.