Support different username/login for different plugin instances about did HOT 7 CLOSED

ACK, I like this idea.
As an aside, if there are no false-positives [1], then the --merge option will be a good workaround here.

[1] I define a false positive in this scenario as a situation when you have two bz accounts for example, and you list both, but you don't want the output from one of them for example, but you do want the output of that email address identity in another plugin. If this isn't an issue, then --merge will solve the problem, even though there's a performance hit of the extra erroneous bz queries.

HTH

from did.

Thanks for filing the issue, Luigi. My thoughts how we could
resolve this problem: Implement a new, extended syntax to the
email detection which would list all special cases by section:

Name Surname <[email protected]>; bz: [email protected]
Name Surname <[email protected]>; gh: other_login
[email protected]; bz: [email protected]; gh: other_login

The User() object would have method email() which would accept
config section name and in this way override the default email. In
addition, we shall support new method login() which will be used
in those plugins which perform queries based on login.

We could possibly also support providing these special cases
directly in individual config sections like this:

[bz]
type = bugzilla
prefix = BZ
url = https://bugzilla.redhat.com/xmlrpc.cgi
email = [email protected]

But we need to primarily support this feature for email (both
command line and config) to allow creating team reports:

--email '[email protected]; gh: x' --email '[email protected]; gh: y'

Does that make sense to you?

from did.

I haven't thought more than 5s on this but it seems complicated...

On Tue, Sep 22, 2015 at 10:43 AM, Petr Šplíchal [email protected]
wrote:

Thanks for filing the issue, Luigi. My thoughts how we could
resolve this problem: Implement a new, extended syntax to the
email detection which would list all special cases by section:

Name Surname [email protected]; bz: [email protected]
Name Surname [email protected]; gh: [email protected]; bz: [email protected]; gh: other_login

The User() object would have method email() which would accept
config section name and in this way override the default email. In
addition, we shall support new method login() which will be used
in those plugins which perform queries based on login.

We could possibly also support providing these special cases
directly in individual config sections like this:

[bz]
type = bugzilla
prefix = BZ
url = https://bugzilla.redhat.com/xmlrpc.cgi
email = [email protected]

But we need to primarily support this feature for email (both
command line and config) to allow creating team reports:

--email '[email protected]; gh: x' --email '[email protected]; gh: y'

Does that make sense to you?

—
Reply to this email directly or view it on GitHub
#36 (comment).

from did.

Complex yes, complicated (hopefully) not. Anyway, I haven't seen
any other option here so I've implemented it in this way :-)

from did.

Documentation available here:
http://did.readthedocs.org/en/latest/modules/#did.base.User

from did.

@psss Thanks for the patch, however my initial feeling (and I'm quite new to this project and code base, so don't give it a lot of weight) would have been to NACK this patch.

What I would have proposed:

each section [bugzilla] [whatever]
could specify an override username, and if that was specified, you would use that instead of the email list at the top.

This solves a few problems:

1. The simple case of one email address for everything is still simple
2. No complex syntax for the email format (eg: bz: foo, etc... looks a bit messy)
3. Solves this problem in a straightforward way.

I hope my comments are valuable. I would have provided them sooner before the patch was merged, but it was written and merged so quickly before there was much discussion, so I'd generally welcome more of than first :)

Thanks again!

from did.

I see your point. Including the custom email/login aliases in
individual sections would make sense, unless you want/need to
support also gathering stats for multiple users. For this use
case it'd be hard to keep such information in config sections.

However, we could support both and add the other option as a
syntactic sugar to make the tool's usability a bit more sweet :)

from did.