Plugin Architecture: Allow Signal on threadentry.rendered

[t-oster]

Hi. In order to make all my addons for OsTicket suitable for other users, I want do distribute them as Plugins. I need some more interface than the existing Signals, so I will provide some pull requests, which just add more signals to the core code.

Please merge them or tell me how you would like me to proceed, so I can soon create more powerful plugins.

This particular PR contains just one Signal: threadentry.rendered. It comes with the ThreadEntry Object and a hashmap containing the html code.

A possible plugin would be one to fix broken HTML (ebay sometimes sends such mails), which crash the ticket-view page otherwise.

Another use-case is replacing order-numbers in tickets with links to the ERP system, or amazon-order numbers with links to the seller-central, ebay names with links to the ebay customer etc.

[protich]

@t-oster - I absolutely agree signals should be expanded to cover most of actions that might be of interest to plugins. We just have to make sure we follow some convention similar to variables we use in email templates.

[t-oster]

Thank you for your answer. I agree conventions make sense.
Please guide me with the following questions:

• When to use Signal::send vs the manager::register pattern used in many places?
• What are naming conventions for the signal and its parameters?
• How can plugins hook into templates (.tmpl.php files). One could insert signal send and the plugin can use echo,but that seems dirty
• Is it OK for signals to have null as object if no useful object exists in the case

[t-oster]

@protich could you please answer the questions, so I can update the pull-request accordingly?

[t-oster]

@protich sorry, but you did not answer. I really would like to develop a bunch of useful plugins, but I need more signals/hooks whatever you call them in order to add custom html, javascript and php logic.

[t-oster]

closed in favor of #5693