GNOME Bugzilla – Bug 645786
Fancy invoice report still doesn't use fancy date format preference
Last modified: 2018-06-29 22:55:45 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.
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.
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)
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.
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...
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?
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
(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.
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.
(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.
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.
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.