On 28/02/2019 00:04, David Cousens wrote:
Wm

Diagrams are up https://wiki.gnucash.org/wiki/Configuration_Locations. The
wkiki markup is crude but works. I will try later to implement a scroll box
to better accommodate narrow width monitors and mobile devices. Geert
pointed out a few corrections re what are merely labels for locations and
what are actual definable environmental variables which are now
incorporated.

DavidC I like what you are doing a lot.  Keep doing it.

The original text on the wiki did not distinguish too clearly between what
were labels for locations and what can be actually set as locations. It was
there but obscure. In the diagrams these are distinguished as clearly as I
am able to.

Your use of words is good, "as I am able to". The point is we don't actually know where significant data is. That isn't a good thing for an accounting prog to know or not know.

On Linux at least those environment variables (not the ones which are merely
labels) are not created on installation. They can be and then GnuCash should
use the locations defined by them (I haven't verified this mainly because I
don't have the need to use it). In principle at least you could define
GNC_DATA_HOME and GNC_CONFIG_HOME to point to the book location or a
subdirectories of the directory containing the book.

Yes, the problem is the movement of significant files wasn't forewarned. I really don't know where some of my charity files are now!

The problem with the gnc code for transition is that it placed no value
on who accessed it first.

Why would it? GC is not designed as a multiuser program for a multiuser
environment.

True. I am not saying it should be. My argument is about data integrity and cohesion.

It has no user structure to define authorization levels and no
code to restrict access to specific functionality.

I don't see why you are presenting this argument.

While there is perhaps an
ambition to move in this direction longer term, it is nowhere near there
yet.

Rinse and repeat.

Admittedly the release notes for V3 only obliquely mention the relocation of
the user configuration location and that in hindsight should perhaps have
been highlighted more.  But it came up pretty quickly in the forum
http://gnucash.1415818.n4.nabble.com/GNC-Saved-Report-Configurations-Missing-After-Upgrade-to-v3-td4700786.html#a4700793
along with the cure of renaming saved-reports-2.4 to saved-reports-2.8 in
the new directory.

I'm still using 2.4 are you sure the 2.8 message got out?

It is possible I missed a message but a significant change in the reports should have caught my attention since I do have some knowledge about them.

The place was identifiable relative to the book. 3.x changed that.

To a place which is also identifiable relative to the book.

Nope.

The changes going to V3 also make it possible (at least in principle) to
co-locate the configuration with the book by defining  GNC_DATA_HOME and
GNC_CONFIG_HOME which was not possible under V2.6.

In principle, yes.

Again you missed the point that the Save and Save As options in the reports
toolbar and menu don't or at least shouldn't save the report per se, but
save only the configuration information for a report. What level of personal
information gets saved in the configuration is not clear to me.

I am not sure why you are arguing here if you don't understand that saved reports contain very specific account information and because of that are not transferable from one book to another.

I can conceive of a situation where a number of books use a stock standard
account heirarchy and one configures a report to depend on that heirarchy
but if account guids are incorporated this becomes of limited usefulness wrt
the ability to transfer reports.

Yes!  The reports are useless if separated from the book!

The question is this: who thought it was a good idea to separate the reports from the book?

I think it was Geert but may be wrong.

The report configuration should not contain the information directly and
only have pointers to locate the information which is contained only in the
book. Is that not the case?

Nope, the reports contain actual internal account references, my report won't work for you and vice versa because your accounts and my accounts have different internal references.

Do you see why the placement of relevant files further away from the data makes less sense or not?

Maybe someone is still on Geert's side?

--
Wm




_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to