Re: mailgw argument parsing

On Wed, Nov 23, 2022 at 03:26:45PM -0500, John P. Rouillard wrote:
> >> 
> >>    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.
> 
> Sorry, I don't understand which class? The one specified by -c (issue
> by default) or the one in the -S?

The one with -S. The previous -C always used 'issue'.

> 
> >So you no longer specify -C issue but use the real class name
> >which is your issue class (e.g. -S support:prop=value).
> 
> But that's not all -C did. The -C and -S did what couldn't be done
> from the option/attribute setting on the subject line. They changed
> the properties not of the issue but of the msg created by sending the
> email to the issue.

Yes, that is still there. These are different calls to the matching
method.

> 
> It would be the equivalent subject setting mechanism as if we had
> implemented:
> 
>    [msg-1:msgtype=reply]
> 
> in the subject command line, if that makes sense.
> 
> In theory you could have created a timelog entry (how, TBD) from the
> email.  So emailing:
[...]

That is one of the cases that get too hard to understand where I would
use an auditor :-)

> >And you now can have several different issue-like classes and specify
> >(different) -S option for all of them.
> 
> Sorry, I'm not getting it. How would I rewrite my existing
> roundup-mailgw alias from:
> 
>   roundup-mailgw -c issue -C msg -S msgtype=reply
> 
> that:
> 
>   takes an incoming email
>   creates a new message with a msgtype of reply
>   adds the id of the new msg to the messages propery of the issue

This has not changed. It's now

roundup-mailgw -c issue -S msg.msgtype=reply
or shorter:
roundup-mailgw -c issue -S msgtype=reply

The changes that I made is *only* for issue.
You can have different issue-like classes and use their real names (not
only 'issue'), e.g.

roundup-mailgw -c support -S support.sprop=v1 -S it_issue.iprop=v2

which would not have been possible with the previous implementation.


> 
> Would
> 
>   roundup-mailgw -c issue -S msgtype=reply
> 
> be correct? If somebody sent in an email with the subject
> 
>     Subject: [issueA2] some subject
> 
> the -S option would be ignored since issueA (an alternate issue class)
> doesn't match what is specified by "-c issue"?

I think the code did not depend on the class name. There would not be
any match for the class itself (if no -S issueA... exists) but I think
the msg, file, user code is called in every case where a link is
detected. But we should test for this. And we should decide how to match
this. The code *does* call get_class_arguments with class_type=issue and
classname=issueA but I'm not sure how the msg/file/user matching is
done.


> 
> While
> 
>     Subject: [issue2] some other subject
> 
> will set the msgtype on the msg created by the email to the issue as
> expected?

Yes.

> What happens if I use:
> 
>   roundup-mailgw -c issue -S msg.msgtype=reply
> 
> is it the same as with -S msgtype-reply?

Yes.

> >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 :-)
> 
> Hmm, I am not sure that's a good thing. I need to think about it.  I
> claim that subject should result in a bounce since a keyword is not an
> issue like thing.

The previous code did that, too. In the test-cases where we have
[keyword1] in the subject, the get_class_arguments method is called with
class_type=issue and classname=keyword. And it would happily try to
apply the -C issue -S issueprop=val options to it. I don't know if this
would result in an error (or was silently ignored), we did not test this.

The decistion what is an issue-like thing is only clear on creation (via
the -c option). The user can write what they like into the Subject.
I don't know if there is/was code to detect if this is 'issue-like' and
apply msg/file/user options.

> 
> >>   -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.
> 
> Understood. So the only way to change a property on the msg is to not
> set a classname. Also it will apply to whatever issue type is
> specified with -c (issue by default)?

You can also set 'msg' explicitly, e.g.

-S msg.prop=value
is equivalent to
-S prop=value

I'm not sure about the -c, see above. I don't think the -c option ever
had any influence on what the code thought was an 'issue' (except for
creation of a new one).


> What happens if the designator is [keyword23]? Keywords don't have
> messages so it's ignored?

I think so, yes. I don't know if we have a test for this.
It *does* ignore the title (subject).

> >And if what you're doing with the -S option becomes really complicated,
> >using an auditor instead should be considered.
> 
> I'm not sure you can do that. IIUC the inbound email address is gone
> by the time the auditor gets involved. You could add a
> "received_address" property to the message and use -S to set it. Then
> that might be usable from an auditor somehow?? You wouldn't want to
> add it to the issue as that would just churn that field on every
> email.
Hmm I think I'm doing this but I *have* modified the mailgw
processing... and I think I keep the incoming email header as a new
property.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [email protected]