Bug Description

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

affects /products/malone
done

I was trying to close 7906, and LP said:

<email address hidden> writes ("Submit Request Failure"):
> You tried to edit bug 7906 via email, but it couldn't be determined in
> which context you wanted the changes to occur. The bug is reported in 2
> different contexts, and you have to specify which one by using the
> affects command.

I went to look at this bug and the problem seems to be that Malone
thinks I might want to try to close the Debian bug.

As previously discussed, no-one should close a Debian bug via Malone
until this has been discussed with and agreed by Debian. Furthermore,
I personally will never want to close a Debian bug via Malone (and I
suspect this is true of most other Debian developers).

Furthermore, AIUI the feature of manipulating bugs in Debian is in any
case not implemented yet.

So Malone should be able to figure out that I don't want to close the
Debian bug and should close the Ubuntu one.

MaloneEmailInterfaceUserDoc fails to explain that `affects' must be
used and fails to contain the text which I read somewhere else about
what the default is for `affects'. But IIRC according that text it
makes a difference that I'm a Debian maintainer. I assure you that
the overwhelming majority of the Debian maintainers will prefer to
manipulate Debian bugs via the Debian BTS.

Yes, I agree. It shouldn't be possible to close Debian bugs through Malone. We currently don't actually 'watch' remote bugs, instead they look like normal bugs, and it's possible to edit them in Malone, which is quite confusing. I'm going to work on this soon, making it possible to edit a bug only if the product/distro actually uses Malone as its bug tracker.

And I think it makes sense for the email interface to assume that you don't want to edit a Debian bug or something like that.

This bug can be fixed by smartening up guess_bugtask() which is used to get the bugtask when it was not explicitly stated. guess_bugtask() does not use proper zope security checks; anyone working in this function could update it so that drivers, bug supervisors, and security contacts can perform the same updates that they can use API or UI.