Suggestions for new Callback locations?

RT Developers
1

This is probably a question really for @Jim_Brandt and the Best Practical folk, but others may have opinions. We’re in the process of looking to move our production RT to 5.0.5 later this year, which is a big job as its a large (>700,000 tickets) database and we’ve done lots of tinkering with it over the years. I’m currently going through and porting our local modifications one at time to a test 5.0.5 install, and refactoring them as I go.

Where possible I’m trying to use Callbacks, as they’re one of RT’s strongest customisation features and they compartmentalise my local modifications in a neat, easily maintainable location.

However sometimes there just isn’t a Callback in the right place even though I just need to tweak a parameter being passed to a component later, so I end up with a local copy or overlay of one or more Mason components. These are more of a pain because I need to work out what is local customisation rather than just release changes and then graft it into a local copy of the file from the 5.0.5 release. And when we upgrade again in the future I’ll need to do that again too.

So the question: if I spot a location in a distributed Mason file where a Callback would be really handy, is this something that Best Practical would like to know about to add into future releases? I wouldn’t help me at the moment, but might in the future. If so, where’s the best place to communicate this to the team? Or is there a plan for where/when new Callbacks will be added already (for example only if existing files are heavily reworked between releases)?

FWIW what kicked this off was looking at /Articles/Article/Search.html, where I’ve got a local copy that just adds CustomField.{Content} to the $format variable. There’s no Callbacks in this file at all!

2

When doing development like this, the first approach you might take is to add the callback yourself and maintain the diff as a patch in your extension, perhaps in a “patches” or “etc” directory. That allows you to stick to callbacks rather than overlays. You still have a customization, but it’s a small patch you can re-apply when you upgrade. If it eventually doesn’t apply because of possible changes in RT, it’s much easier to re-position a one-line callback than go through an entire overlay file line by line to merge local vs. RT changes.

If you think a callback might be of general use, you can certainly submit it for us to take a look. You can open a PR on github with the changes. For simple branches like adding callbacks, we can usually review fairly quickly and either merge or give feedback. (The big backlog of other PRs mostly are more involved, so they require more work to fix or review, that’s why there are many open PRs.)

Callbacks are fairly simple, but there are some guidelines when adding them. Mostly look at other existing callbacks and try to be consistent. Many templates have similar callbacks at common locations, like “Initial” right at the beginning of the INIT block. Also, try to pick a good spot where other users might benefit from changing something, even if it means moving your ideal location up or down a bit. Lastly, try to include variables in the context of the code via references, even if you don’t need them all for your use case. This includes usually providing an ARGSRef to make ARGS available.

2 Likes
3

Thanks - that sounds like a great approach.