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 645786 - Fancy invoice report still doesn't use fancy date format preference
Fancy invoice report still doesn't use fancy date format preference
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Reports
git-master
Other All
: Normal normal
: ---
Assigned To: Christian Stimming
gnucash-reports-maint
Depends on: 736139
Blocks:
 
 
Reported: 2011-03-26 23:27 UTC by Mark Haanen
Modified: 2018-06-29 22:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fancy invoice, no fancy date format (96.12 KB, image/png)
2011-03-26 23:27 UTC, Mark Haanen
Details

Description Mark Haanen 2011-03-26 23:27:33 UTC
Created attachment 184328 [details]
Fancy invoice, no fancy date format

For some reason, the "Fancy Invoice" business report does not use the "Fancy Date Format" that is set in the Business section of the Book Options. Judging from the scm source this isn't the intended behaviour.

The attached screenshot illustrates the problem. I temporarily removed the .mo translation file to eliminate this as the source. I then opened the Book Options dialog after opening a new non-customized Fancy Invoice window. The settings in the book options are unchanged from the values that were active when I opened the invoice.
Comment 1 Bert 2011-05-17 16:53:33 UTC
As Mark indicated, this seems intentional behaviour:

(define (make-date-row! table label date)
  (gnc:html-table-append-row!
   table
   (list
    (string-append label ": ")
    ;; oli-custom - modified to display a custom format
    ;; for the invoice date/due date fields
    ;; I could have taken the format from the report options, but... ;)
    (string-expand (strftime (gnc-default-strftime-date-format)
                             (localtime (car date)))
                   #\space " ")
    ;;(string-expand (gnc-print-date date) #\space " ")
    )))

As mentioned in the comment, this seemed like a good idea for oli. However, it may not be what is expected from other people who set the custom format.
Comment 2 richtripped 2014-08-01 03:03:49 UTC
I have reproduced this on Windows 7, GNUCash 2.6.3.

I would very much like my invoices to use a non-ambiguous date format for all dates (ISO 8601)
Comment 3 Mike Evans 2014-08-02 08:36:57 UTC
I've no idea what Oli's reasoning was there.

Mark, Bert.  Have you tried editing your fancy-invoice.scm to change the behaviour?

Just comment out (with ;;) the 3 lanes after "but... ;)" in comment 1 and remove the semicolons from the next line to see if you now get the desired date format.  

If that fixes it I'll add them to the next update.
Comment 4 Mark Haanen 2014-08-27 18:38:43 UTC
I tested Mike E's suggestion. This changes the date format to the date format chosen in my general preferences (in my case, Europe's dd.mm.yyyy) rather than the date format I entered into the fancy date formatting in the book options setting (in my case: %e %B %Y). 

While this is preferred to the current setting, I'd rather get the fancy setting with the full month in letters...
Comment 5 Mike Evans 2014-08-29 09:32:34 UTC
it seems then that either the settings in the Date/Time tab of preferences override the Fancy date format in the Business tab of Book Options or the reports are not using the correct format.

Are there any reports that DO use the format set in Book Options?
Comment 6 Geert Janssens 2015-02-11 17:17:51 UTC
I have traced this a bit. It appears the Fance Date Format as set in File->Properties isn't used anywhere in the code at all.

The only place a fancy date format is used is in printing cheques, but it has its own implementation of this.

Technical stuff to eventually deal with this:
The fancy date format as configured via File->Properties is stored in a kvp ("Fancy Date Format") in the book. The only way to retrieve this information in the reports is via calls to
qof-book-get-slots and kvp-frame-get-slot-path-gslist

A similar example can be found in easy-invoice.scm for company name which is configured and stored exactly the same way.

The issue with this approach is that direct kvp access is deprecated and will be disabled in the unstable release. So trying to use this to enable fancy date formats in the invoices is a dead end street. The proper solution is probably to define a "book" object in the engine like any other serializable object (accounts, transactions, splits, invoices,...) and have object manage these book related properties.

Bug 736139 tracks all issues related to direct kvp access. Since the fancy dates can't be used until the kvp handling is resolved I'll mark this bug as dependent on bug 736139
Comment 7 John Ralls 2015-02-12 00:34:20 UTC
(In reply to Geert Janssens from comment #6)
 
> The issue with this approach is that direct kvp access is deprecated and
> will be disabled in the unstable release. So trying to use this to enable
> fancy date formats in the invoices is a dead end street. The proper solution
> is probably to define a "book" object in the engine like any other
> serializable object (accounts, transactions, splits, invoices,...) and have
> object manage these book related properties.
> 

QofBook is already a serializable object, it's just in libqof/qof instead of engine. We should probably rename it GncBook (or maybe Gnc::Book ;-) ) and move it to engine, but that's a separate discussion.
Comment 8 John Ralls 2015-02-12 02:37:54 UTC
I don't see what 736139 has to do with this: Yes, it's stored in kvp, but that storage is in the optiondb loaded and saved by qof_book_[load|save)_options. There's no need to query the kvp directly, just write a lookup function for it in app-utils/business-options.c like the other ones.
Comment 9 Geert Janssens 2015-02-12 09:51:15 UTC
(In reply to John Ralls from comment #8)
> I don't see what 736139 has to do with this: Yes, it's stored in kvp, but
> that storage is in the optiondb loaded and saved by
> qof_book_[load|save)_options. There's no need to query the kvp directly,
> just write a lookup function for it in app-utils/business-options.c like the
> other ones.

Well, yes. A lookup function has to be written. That's not "just" write however.

The way I understand it the lookup functions in app-utils/business-options.c provide the c code access to options defined in guile code. The book options on the other hand are not exposed in guile at all (yet) so it would currently not be possible to write the lookup functions like the ones you refer to.

In addition qof_book_load blatantly exposes the kvp architecture behind the book properties: it takes a function as argument that should parse the slots which are stored in the book. Example usage (in c, not in scheme) can be found in app-utils/business-helpers.c and gnome/assistant-hierarchy.c.

Hence the link to bug 736139. I prefer to hold this one off until we have a proper encapsulation of the kvp stuff and expose the options via direct getters/setters like the other engine objects. The options handling is messy enough as it is already.

Whether the base object should be the book or some more generic GncProperty is just an implementation detail for this particular bug.
Comment 10 Geert Janssens 2015-08-04 13:39:46 UTC
With the recent rewrite of qofbook and the newly introduced
qof_book_get_option function nothing is blocking this
feature request anymore.

I have just pushed the necessary changes to our master branch
so this feature will appear in the next major release (2.8).

I have altered all business reports to make use of the
fancy date format for Bill/Invoice/Job date, Due date
and Today's date (where used). The separate option to
specify today's date format which appeared on some
reports has been removed as a result.

I was tempted to make similar changes in the current stable
series as well (2.6.x) using the old kvp method but chose
not to do so in the end. My main motivation is that the changes
may alter the default appearance of the reports without the
user's explicit action. That's a behaviour change that's not
welcome in a stable series. So it has to wait for 2.8.
Comment 11 John Ralls 2018-06-29 22:55:45 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=645786. Please update any external references or bookmarks.