After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 150754 - Find "matches no accounts" has confusing (and nearly useless) semantics
Find "matches no accounts" has confusing (and nearly useless) semantics
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Register
git-master
Other Linux
: Normal normal
: ---
Assigned To: David Hampton
Chris Shoemaker
: 444746 (view as bug list)
Depends on:
Blocks: 478463
 
 
Reported: 2004-08-22 06:07 UTC by Thomas Bushnell, BSG
Modified: 2018-06-29 20:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Thomas Bushnell, BSG 2004-08-22 06:07:10 UTC
On a fresh data file, create three accounts, a, b, and c.  Create three
transactions: a->b, b->c, c->a.

Now from an account register open a Find dialog.  Make one criterion; Account,
"matches no accounts", select account a, and click Find.  All three transactions
will be found.  Apparently each transaction includes an account which is not a.
 "matches no accounts" on a is being treated as "matches any account" on b and
c, but this does not match the meaning of the English phrase.

There is no way I can think of to get the search in question to happen correctly
using the facilities in the Find dialog.

See Debian http://bugs.debian.org/239613.

This has been verified on the 1.8.9 release and the 1.8 CVS branch with the most
recent ChangeLog entry labelled: 2004-18-21  Derek Atkins  <derek@ihtfp.com>.
Comment 1 Josh Sled 2007-04-21 15:43:32 UTC
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.
Comment 2 Thomas Bushnell, BSG 2007-05-02 00:09:08 UTC
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.
Comment 3 Josh Sled 2007-06-06 15:20:39 UTC
*** Bug 444746 has been marked as a duplicate of this bug. ***
Comment 4 Paolo Benvenuto 2007-06-06 17:34:07 UTC
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.
Comment 5 Paolo Benvenuto 2007-06-06 18:10:04 UTC
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]
Comment 6 Paolo Benvenuto 2007-09-20 10:28:16 UTC
I'm putting a US$ 100.00 bounty on this bug.

Is anyone interested in resolving it?

Thank you!
Comment 7 Paolo Benvenuto 2007-10-02 18:09:50 UTC
(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.
Comment 8 Andreas Köhler 2008-02-10 21:25:37 UTC
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.
Comment 9 Paolo Benvenuto 2008-02-10 21:56:28 UTC
No, anyway the bug persists.

The words in the search dialog doesn't correspond with what the search performs.
Comment 10 John Ralls 2018-06-29 20:46:33 UTC
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.