On 25/02/2019 06:52, David Cousens wrote:
I admit freely I do not have a clear understanding of how the reports (and
much else inside GnuCash) do work in detail and I doubt if I am alone in
that apart from maybe the core development team.
You are expected to be the foil for those that do know, sir :)
GnuCash for whatever historical reasons is only sparsely documented which
increases the difficulty of those of us with some development experience,
but not long term on GnuCash, to contribute effectively. There is a big
learning curve anytime you dig into the code.
That is an understatement, the code is largely opaque comparative to the
relatively simple transactions that occur.
Having worked in development
teams which had very limited resources in the past
[snip] I hear you, I am not that boss here
GnuCash doesn't have the luxury of a systems analysis team and management
structure with oversight either. There is just a minimal team of unpaid
developers, often wearing multiple hats, doing their best. Despite that it
is far more flexible and adaptable than many programs which do have
extensive development teams - hence the escapees from MYOB and Quicken where
cost becomes a very significant factor.
Hint: I am part of a systems analysis team and manage software. I just
don't get used much.
Since I know that I often find myself taking another view.
Does gnc know where it took stuff from and placed it when 3.x was run
for the first time?
Looking at the code which did this, should answer this question. Not easily
though, as the code generates scripts which perform the gconf->gsettings
,dconf migration (forced by the deprecation of g conf) as well as the
changes in the settings location.
some stuff got lost there, continue
My brief excursion into it indicates that
it is as described on the wiki Configuration Locations page. What was
migrated is defined in /usr/local/share/gnucash/migratable-prefs.xml and
processed by /usr/local/share/gnucash/make-prefs-migration-script.xsl to
produce the gsettings from the original gconf settings.
Wow! I admire your faith!
problem is:
the variables are just that, variable
I don't think anyone knows where some of the details went
My experience with the transition from 2.6.19 in my case to v3.0 was that I
lost all of the training for the import matcher - no great problem, a couple
of imports and it was largely back and that solved some historical import
problems which were throwing up accounts which were no longer appropriate.
There is some value in occasionally retraining the import matcher in any
case.
Your report is occasional not substantive. You will hopefully get a
better report. The importer farts when I throw new stuff at it. Expected.
I get by with the basic reports when i need them so i personally had
no problems with reports, but I do appreciate that others may/did/do. I kept
the 2.6 .gnucash preferences folder from 2.6.19 for some time after i
migrated to 3.0in case I went back but unfortunately I decided around 3.3.
that for my purposes things had become stable enough that i no longer needed
to keep it.
Uh oh
If I remember correctly from looking at it at the time I had problems with
the importer, what was in
/home/<username>/.gnucash
was moved to
/home/<username>/.local/share/gnucash
on Linux systems as described in the Wiki page on configuration locations. I
am presuming this is also he case for Windows systems but I don't really
use Windows so can't be sure.
The problem with the gnc code for transition is that it placed no value
on who accessed it first.
This is slightly specious but if the cleaning lady accessed the file
first she'd have all the reports in her private space on her phone
forever! It is that weird.
It is a lot more complicated than you think.
Wm,
2.6 didn't store the saved reports with the book file either, it just stored
them in a different location, so that is clearly not the problem.
The place was identifiable relative to the book. 3.x changed that.
What are the other changes that were introduced going from 2.6 to 3.x which
are causing you problems now in backing up your files that didn't exist with
2.6? You are going to have to be specific if anyone is to diagnose and fix
it.
Other technical people already know. I'll bore you by saying some
reports should be part of or very close to a "book". For the simple
reason that (in the case of my charities for example) only the trustees
are allowed to report on the accounts.
I also agree completely that if a report configuration is tied to a specific
book/set of accounts, i.e. it has been customised or otherwise been modified
to be specific to that book, then its storage location should be with the
data file. What defines this level of customisation for you and for me and
any other user? Could GnuCash this on the basis of the configuration file
contents perhaps decide where a particular report configuartion file should
be located?
Yes, easily.
Just saving a custom version of a standard report does not appear to
introduce any ties to a specific book, i.e. if I save the standard Balance
Sheet as MyBalanceSheet without introducing any references to the account
structure of that set of books, the guids in it only reference the guid of
the new report and its parent.
Which doesn't make any sense.
You have just saved a really personal report which is (from a world
view) risible. You've saved details that are intensely personal to you,
not transferable to anyone else and can never be transferred.
Yay, you should be pleased :)
The other sections in the report
configuration General/Accounts/Dsiplay and Commodities, if populated, may
obviously change this situation. It may be possible to determine at least a
default choice between storage at the book/user/application level based on
content, but giving the user the option to override.
My break
There is perennial
balance between simplicity for a new user through sensible defaults and
flexibility for a more experienced or demanding user.
Hmmn, David, I think with a statement like the above you become a man in
this forum.
Some users may also want to customise reports to be very specific to their
personal individual needs and perhaps apply them to any books they maintain.
I.e. they would want to store them with what are other user specific
preferences. Are ther changes in the saved-reports configuration file which
indicate this?
the current fuckwitted rule is what we were discussing!
I can also see a situation where reports might be customized for a
particular jusisdiction for example and may otherwise be close to the
generic reports and be otherwise useful to other users in that jurisdiction
i.e. their storage perhaps needs to be at an application level.
I don't have a problem with that, I do point out the gnc model doesn't
allow such reports to exist
On the other hand there are the basic standard template reports built in to
GnuCash which possibly need to be stored at an application level storage
location.
I am sure there are possible use cases I haven't thought of as well.
Perhaps we need to identify:
which of these needs Gnucash currently meets;
which it should meet at some future point; and
how we might get there.
I like this approach.
The forum is not really a good way to explore this unassisted because we all
have our own ideas and perspectives floating in our heads and as is fairly
obvious we are not all talking about the same problem from the same point of
view.
Sure. Keep on giving.
Perhaps we need to map out on a wiki page we can all contibute to the report
storage structure as it currently is and what we can agree to about what it
should or could ultimately be and perhaps even arrive at a plan of how to
get there. The wiki pages have discussion pages attached to them to
facilitate.
Don't think that will be required unless you want to tease the seniors.
I can perhaps augment the current wiki Configurations Locations pages with a
heirarchical diagram which makes the relationships between the environment
variables and locations defined there a bit clearer. I can really only
confirm it out for Linux Mint/Ubuntu and Windows.
We'd like that a lot. If it is a good diagram or chart it will help.
All you need to decide is who looks at it first.
I'd be pissed if it was a good pic and it was refused!
DavidC, my instinct is that you should place it on the wiki, give a link
here and see what happens.
Wm,
Even if we can arrive at some sort of plan, it is only a longer term target.
Someone has to implement it. GnuCash is not going to get there overnight,
but at least then we have some agreed general direction to move towards. But
for the moment we are going to have to live with some sort of workaround.
Yes, thing is, DavidC there is a long term plan and it is mainly
technical, are you going to say you aren't aware of the long term plan?
The normal response is rude when I mention it :)
--
Wm
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
