Re: debbugs-gnu-bugs shows unanswered bugs as handled

[Michael Albinus]

Tino Calancha <address@hidden> writes:

Hi Tino,

> I have found 2 more issues code (added patches at the end of the email).
>
> I)
>    I have noticed the code uses the attributes 'submitter and 'author
>    as synonymous: tipically they have same value but not always.

>    For instance try folowing example:
>
> [OK]
> M-x debbugs-gnu-search RET
> nuisance AND asked RET RET
> ;; list bugs: 19328, 23680
>
> [BAD]
> M-x debbugs-gnu-search RET
> nuisance AND asked RET submitter address@hidden RET RET
> ;; Don't show bugs because author and submitter are not equivalent;
> ;; for instance, in bug#19328, the submitter is address@hidden
> ;; but the author is address@hidden

You are right. `debbugs-search-est' expects :@author, and not
:submitter. I've modified your patch slightly, and we get now

M-x debbugs-gnu-search RET
nuisance AND asked RET RET
;; List bugs: 19328, 23680

M-x debbugs-gnu-search RET
nuisance AND asked RET author address@hidden RET RET
;; List bugs: 19328. There was another error, encoding "@" for the
;; Debbugs::SOAP Perl module, which I have also fixed.

> II)
>    I guess attribute 'status should be handled also in the client side.
>
>    See for instance,
>
> [BAD]
> (setq debbugs-gnu-default-suppress-bugs nil) ; show bugs with status "done"
> M-x debbugs-gnu-search RET
> nuisance AND asked RET status done RET RET
> ;; Don't show any bug

That's not possible. Status is applicable for server-side filtering only
with a non-empty phrase. I've fixed this.

Client-side filtering is applied only for searches with an empty
phrase. Your use case is not foreseen (yet).

In general, client-side filtering should not promoted to the users. It
has bad performance, because it needs to retrieve all bugs first, before
it could start to filter. It's always better to promote server-side
filtering.

> There is other uses of :submitter on that file (e.g. debbugs-get-bugs);
> i am wondering if they also need to be fixed (i didn't look on it).

Haven't looked either, but it shall be OK.

> Regards,
> Tino

Best regards, Michael.