Re: mailgw argument parsing

On Wed, Nov 23, 2022 at 10:58:02AM -0500, John P. Rouillard wrote:
> >My current implementation ignores these calls when the classname does
> >not match.
> 
> Do you think it should log instead? Something like:
> 
>    ignoring -S option foo.private=true as message is for class keyword

No, a better wording would have been that the class is now matched
exactly. So you no longer specify -C issue but use the real class name
which is your issue class (e.g. -S support:prop=value). And you now can 
have several different issue-like classes and specify (different) -S
option for all of them.

> Even though -S is used rarely, I can see debugging this being an issue.
> Also what happens if you have to issue classes:
> 
>   bug and feature
> 
> with the same set of properties. If a subject [bug12345] comes in and
> you have:
> 
>   -S feature.status=low
> 
> it should be ignored. Right??

Yes. It is, see above: You now specify

-S bug.bugprop=v1 -S feature.feaprop=v2

you no longer specify issue-type but the real class name.
And you can even have -S keyword.prop=v and when someone composes a
message with Subject: [keyword1] it will be applied :-)

> 
>   -S status=low
> 
> what happens? Applied??

Applied to the default 'msg'. If the classname is left out of the -S
option it defaults to msg.

> This could lead to a lot of logging. Maybe a flag to enable debug
> logging and put these "ignoring -S option foo...." options behind it?
> Thoughts?

See above: For each message only a subset of all possible -S options are
used, I guess the debug logging would confuse more than help. I'm also
using a dict for the various classes where I put all -S options for that
class, so it would take an additional iteration to log the unused
classes.

And if what you're doing with the -S option becomes really complicated,
using an auditor instead should be considered.

> Also it looks like the 'Mail gateway script command line' is
> documented in user-guide.txt. Any idea why? Maybe after your changes
> we can move the revised command line/setup info into admin-guide. This
> still leaves more technical mailgw stuff in the user guide but is a
> start to cleaning it up.

Probably historical reasons, I agree it should be moved to the admin
guide. Maybe we can even come up with a way to re-use the mailgw help
(it's now implemented as the epilog argument of ArgumentParser): This is
(almost) the same text as in the current section in the user guide. It
had drifted apart considerably and one of the things I did was to
consolidate the two. But it should really be a common source.
ArgumentParser has options for how the epilog is formatted,
unfortunately none for formatting ReStructuredText...

Thanks, a great week to you, too!
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [email protected]