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 647805 - Interdependent report options fail to change state after using apply for a limited number of times
Interdependent report options fail to change state after using apply for a li...
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Reports
git-master
Other Linux
: Normal normal
: ---
Assigned To: gnucash-reports-maint
gnucash-reports-maint
: 506151 724915 777386 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-04-14 18:53 UTC by Joshua
Modified: 2018-06-29 22:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Joshua 2011-04-14 18:53:52 UTC
Overview:

It's possible to select Notes without selecting Memo in the Display Options Dialog for the Transaction Report.  Applying changes with Notes selected and Memo de-selected causes Totals columns to align off to the right of other values.  Other options do the same, though.  See: bug 405750

Steps to Reproduce:

This is the only way I've been able to get this to happen so far, but I know it happens at other time when I'm doing some heavy and fast clicking of options and applying them without closing the options dialog.

1) Open Transaction Report with all options at default.  Choose an account.  Apply changes.  Cancel out of dialog.
2) Reopen options and go to display tab.
3) De-select and Re-select Memo - Notes option should be be un-grayed/grayed out accordingly.
4) Hit Reset Defaults and Apply.
5) Go to step 3.
  
Actual Results:

On every third round of doing steps 3 and 4, the Notes option is un-grayed/grayed correctly, but on the other two rounds the selection of Menu has no effect on Notes.

Expected Results:

Notes should always be grayed out when Menu is not selected.

Build Date & Platform:

svn r44b6981+ on 2011-04-08 with Ubuntu 10.10.

Additional thoughts:

There may be two bugs here.  One with the options dialog and some of the functions in the code at line 859 in transaction.scm:

  ;; Add an option to display the memo, and disable the notes option
  ;; when memos are not included.
  (gnc:register-trep-option
   (gnc:make-complex-boolean-option
    gnc:pagename-display (N_ "Memo")
    "d"  (N_ "Display the memo?") #t
    #f
    (lambda (x) (gnc-option-db-set-option-selectable-by-name
		 gnc:*transaction-report-options*
		 gnc:pagename-display
		 (N_ "Notes")
		 x))))

And another in how the rest of the report process the Memo and Notes options which causes the totals to be misaligned depending on which options are selected (again, see bug 405750).
Comment 1 Carsten Rinke 2013-04-24 12:09:57 UTC
I tried to reproduce this bug with GnuCash 2.5.0 on Ubuntu 12.04, but it did not manage. The notes checkbox is always grayed correctly.

@Joshua: Can you confirm that the bug is gone or still existing?
Comment 2 Joshua 2013-04-24 14:04:05 UTC
I don't have the same version installed anymore, but the options window still behaves as described.

I'm also not on 2.5.0, but I did my quick check with:

A build from r22264M on 2012-09-20
GnuCash 2.4.11
on
Ubuntu 12.10

(I'm pretty sure this is the packaged version in the Ubuntu 12.10 repository.)

With the memo check-box un-clicked, sometimes the notes check-box is grayed and un-clickable, and sometimes it's not.  I should note that I can get it to leave the Notes option UN-GRAYED while I click and un-click the Memo option as well as leave the Notes option GRAYED while I click and un-click the Memo option.  I'm not sure if it was behaving like that before or not.

Something has changed, however, because I can no longer reproduce the misalignment of columns in the the report.  I'll investigate that a bit and reply on the other bug, but as far as it relates to this issue, the inclusion of a column seems to be controlled by the memo check-box regardless of whether or not the notes check-box is behaving properly, and it looks to me like the intended behaviour is to have a separate column on the right for the totals (which is how it worked in this test).

I'll try to test on version 2.5.0, but it probably won't be until later this week.
Comment 3 Joshua 2013-04-24 14:06:08 UTC
@Carsten: I forgot to ask, is there a specific build version you're using?
Comment 4 Mike Evans 2013-04-25 11:10:14 UTC
I can't reproduce the column mis-alignment but the checkbox bahaviour is definately flaky.  Still is in 2.4.12 and 2.5 trunk.

Changed staus to new.
Comment 5 Carsten Rinke 2013-04-27 10:50:08 UTC
GnuCash tells me "built from git rev f6de8e1+".
I was following the steps from the Wiki and then did a "git checkout 2.5.0".
Comment 6 Geert Janssens 2015-10-10 16:43:11 UTC
*** Bug 724915 has been marked as a duplicate of this bug. ***
Comment 7 Geert Janssens 2015-10-10 16:59:23 UTC
I have changed the bug title because this problem is more general than only the Transaction report.

And the remainder of the report will focus on the inconsistent behaviour of interdependent options. The column alignment should have been fixed by now (tested with 2.6.9 and current master).

I can reproduce the odd option behaviour. And it happens for all options where one option ("master option") controls the active state of one or more other options ("slave options").

Freshly opening a report, and the report options for it, I always follow these precise steps:
1. edit the master option
2. click "Apply"

For me the first time I do this, the slave options properly change active state.
The second and third time nothing happens.
The fourth time it works again and will continue to work until I quit gnucash, regardless of whether I close and reopen the options dialog.

While debugging I have found that at some point the function gnc_option_set_selectable in src/app-utils/option-util.c is called for each slave option after changing the master option.

When looking at the GNCOptionDB the slave options belong to, I find that for the 2nd and 3rd run the GNCOptionDB is a different pointer from all the other runs (however run 2 and 3 use the same pointer). The 1st, 4th and subsequent runs always use the same pointer to the GNCOptionDB.

Unfortunately I'm at a complete loss as to why this is happening. And why only two times ?

That's as far as I got until now. Hopefully this extra information will help figure out what is happening.

At least there is a workaround: if it fails, try two more times.
Comment 8 Chris 2017-09-15 03:58:07 UTC
I've tested my overhauled Sorting tab with more complicated rules on 2.6.17 Win10 and Win7.

It seems to be cycle of approximately 3 master toggles work, 4 master toggles fails, and repeat.

Moreover, for complicated toggles, each master toggle seems to keep tally of how many fails before it decides to work :)
Comment 9 Chris 2017-09-15 04:48:16 UTC
Moreover, for complicated toggles, each master toggle seems to keep *its own* tally of how many fails before it decides to work :)
Comment 10 Geert Janssens 2017-09-15 19:03:09 UTC
I finally figured it out.

On the C side an SCM guile_options object is wrapped in a GNCOptionDB. This is
however a multi-to-one relationship. That is there can be several GNCOptionDBs
wrapping the same SCM guile_options object. This happens for example when
a report is open together with its Options dialog. Both manager their own
GNCOptionDB object while both wrap the same SCM guile_options.

The problem in this bug was caused by a callback function picking the wrong
GNCOptionDB based on the given SCM guile_options object. Which GNCOptionDB
got picked was completely dependent on how g_hash_table_foreach would cycle
through the stored dbs. It appears this is dependent on the in-memory order
of the hash table's values.

By being more selective of which GNCOptionDB we're looking for, this
could be circumvented. The GNCOptionDB we want is the one related to the open
report options dialog. This GNCOptionDB is different from the one managed by
the report tab in that it has callbacks set. So from now on we search for
a GNCOptionDB that wraps the give SCM guile_options and has one particular
callback set.

A longer term solution would be to create a one-on-one relationship between
GNCOptionDB and SCM guile_options (and even better to handle all options
related stuff in C++ and only query it from SCM).

I tried to do this now already but it triggers many subtle issues I decided
to postpone this work until the Options are rewritten.
Comment 11 Mike Evans 2017-09-15 19:55:42 UTC
Just a smily from me :)
Comment 12 John Ralls 2017-09-16 02:22:47 UTC
(In reply to Geert Janssens from comment #10)
> I finally figured it out.

Yay! Good Work!
 
[snip]
> A longer term solution would be to create a one-on-one relationship between
> GNCOptionDB and SCM guile_options 

-1

> (and even better to handle all options
> related stuff in C++ and only query it from SCM).

+1
Comment 13 Geert Janssens 2017-09-16 14:19:18 UTC
*** Bug 506151 has been marked as a duplicate of this bug. ***
Comment 14 Mike Evans 2017-10-25 09:31:46 UTC
*** Bug 777386 has been marked as a duplicate of this bug. ***
Comment 15 John Ralls 2018-06-29 22:56:53 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=647805. Please update any external references or bookmarks.