https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
--- Comment #79 from Henrik Krohns <apa...@hege.li> --- (In reply to Michael Storz from comment #71) > I think the whole approach of this rewording is suboptimal. I would strongly > suggest to separate the renaming from the aliases management. The aliases > should be managed by an extra plugin. For this, the plugin must provide two > new commands: > > add_eval_alias ALIAS SOURCE > add_command_alias ALIAS SOURCE > > Example: > add_eval_alias check_from_in_whitelist check_from_in_welcomelist > add_command_alias whitelist_from welcomelist_from Thanks for the ideas, though I assume the code and inner workings of this would get wayy to complicated for any benefits it would give. The set_default_commands/aliases method already exists and is more than sufficient for this purpose. > These alias commands must be written in a central .pre file or in the > respective .pre file of the plugin after the loadplugin statement. > > This approach has a number of advantages: > - After renaming, the plugins' code does not need to be touched. It's no problem to touch distributed plugins. And remember that we are only talking about backwards compatible aliases for some functions, it doesn't make much difference when they are actually physically removed (if at all). > - If someone would rather use allowlist/denylist or acceptlist/rejectlist > for their rules instead of welcomelist/blocklist, they could simply set > aliases accordingly. Would would we want to compilicate things further by allowing people to rename things randomly? They can do what they want with their own plugins, but what we distribute is what they should use. > an alias should simply be set in the symbol table: > *check_from_in_whitelist = \&check_from_in_welcomelist; > Then the two functions behave identically. This was good hint and I used it, cheers. -- You are receiving this mail because: You are the assignee for the bug.
