Confirmed as per the description, but the behavior is correct.

The search dialog is a Split search, but the search results are over Transactions.

The query is to find all (Transactions which contain) Splits which are not the selected account "A".  This will find all of:
- the A->B txn (the "B" split matches)
- the B->C txn (both "B" and "C" splits match)
- the C->A txn (the "C" split matches)

It's confusing in the way negatives are, but it's correct.


Note that if I select all 3 accounts in the "Select Accounts" dialog, then none of the txns appear.

Thank you for your attention to this (minor) issue; but it's not really resolved by your answer.

How could a user get what the person wants: a report listing all the transactions which do not involve account A?

I knew exactly *why* the behavior is what it is, but not how one could get the desired behavior.

Selecting all three accounts would not, of course, produce the desired result.

*** Bug 444746 has been marked as a duplicate of this bug. ***

Let's see what the buttons say:
- [Account] [matches any account] says that:
    you are going to examine the account of the various splits of the txns,
    and that you are going to get all the txns
    whose splits have an account that matches any of the selected accounts
- [Account] [matches no accounts] says that
    you are going to examine the account of the various splits of the txns,
    and that you are going to get all the txns
    whose split (any or all? stricly speaking the button doesn't specify)
    have an account that doesn't match any of the selected accounts

Actually the result of the second option uses the "any" option on the splits that doesn't match. But this way the result is unuseful.

If I perform a search indicating an account or a group of account that must not be matched in the txns, I want to find the txns in which _no split_ has that or those accounts.

Well, I made a mistake. When I wrote:

- [Account] [matches no accounts] says that
    you are going to examine the account of the various splits of the txns,
    and that you are going to get all the txns
    whose split (any or all? stricly speaking the button doesn't specify)
    have an account that doesn't match any of the selected accounts

really I had to write:

- [Account] [matches no accounts] says that
    you are going to examine the account of the various splits of the txns,
    and that you are going to get all the txns
    whose splits (any of them)
    have an account that doesn't match any of the selected accounts

and the search is performed exactly this way.

But again I stress that such a search is unuseful.

We need a search in which

    you are going to examine the account of the various splits of the txns,
    and you are going to get all the txns
    whose accounts, i.e all the accounts of all the splits,
    doesn't match any of the selected accounts

This search would be expressed in term of search dialog buttos as

[All accounts] [match no selected accounts]

I'm putting a US$ 100.00 bounty on this bug.

Is anyone interested in resolving it?

Thank you!

(from https://lists.gnucash.org/pipermail/gnucash-devel/2007-June/020683.html)

I consider that the account search in find dialog has to receive some
polishing:

The [Account] [matches no account] have a bad implementations. This is
explained in bug 150754. Keeping in mind the change requested in that
bug, here I want to discuss something more wide.

Now searching in the account can be performed in three ways:

1. [Account]      [matches any account]
2. [Account]      [matches no accounts]
3. [All accounts] [matches all accounts] (bad grammar, should be
"match")

The two buttons refer to accounts, and the 1st button refers to the
account(s) of the splits of the txns we are searching

However, in case 1 and 2 the accounts of "matches any/no account(s)" are
the account(s) I select as a term of comparison. But in case 3 "matches
all accounts" cannot refer to all the selected accounts. It seems to
refer to all the accounts of the various split of the searched txns.
This in an inconsistency with cases 1 and 2.

Really in the 3rd case we are asking that the accounts of all the splits
of the txns match some of the selected accounts. Then a more simple
"match any account" would be better, and would express the meaning of
the search.

Besides that, however, case 2 should be expressed as
[All accounts]  [matches no accounts]
because when we search for a txn that doesn't contain some account, we
want to get the txns were all the accounts don't match any of the
selected accounts (bug 150754 is about that).

Another observation: I consider that in the text of the buttons it would
be better to clarify when we refer to the accounts of the searched txn
and when we refer to the accounts I selected.

So I propose the following situation (keeping the same sorting as we
have now):

1. [Any account]  [matches any selected account]
2. [All accounts] [match no selected accounts]
3. [All accounts] [match any selected account]

Or maybe we could invert the sorting of 2 and 3:

1. [Any account]  [matches any selected account]
2. [All accounts] [match any selected account]
3. [All accounts] [match no selected accounts]

I think that this way account searching would be much more
understandable.

Q: Would it suffice if bug 361285 and bug 115066 were fixed?  Then you could first search for all transactions (expensive) and then delete those transactions that deal with account A from the result set.

No, anyway the bug persists.

The words in the search dialog doesn't correspond with what the search performs.

GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=150754. Please continue processing the bug there and please update any external references or bookmarks.