[GNC-dev] gnucash.org logins

[David T. via gnucash-devel]

Hello,

I have noticed that the logins for bugs.gnucash.org  
and wiki.gnucash.org  are different. The former 
requires an email address; the latter allows user names. Is there any way to 
have these two logins be the same?

David T.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Normalizing live data, a suggestion for discussion

[David Carlson]

OK, I want to try https://wiki.gnucash.org/wiki/ObfuscateScript but I am
not a computer programmer.  I have no clue how to use it.  Can someone help
me?

David C

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

Re: [GNC-dev] Normalizing live data, a suggestion for discussion

[David Cousens]

Steve,

As Geert pointed out whole of program testing is very difficult and rapidly
reaches a situation where complexity is equal to or greater than  the
program complexity and this is really what gave rise to unit testing where
you test individual components which do a specific function.

One area in which an example file  rather than a test file might be useful
is in developing  the documentation. The guide section on Accounts
Transaction following through to Personal Finances 
in escence constructs a simple file while doing the tutorial. Here though it
is  the process of constructing the data in the file that is useful. A
completed example file is not of great use. 

It is also likely that most problems which are likely to require this depth
of investigation are unlikely to show up in a test file unless you can
execute a series of entries in a scripted manner i.e. interact with the gui
from a script and this is not possible with GnuCash at the moment AFAIK. 
The problem is usually somewhere in the process of getting to the results in
the file and what is in the file is merely a symptom of the problem.

David



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Normalizing live data, a suggestion for discussion

[Frank H. Ellenberger]

Hello Wm

Am 01.02.19 um 14:36 schrieb Wm via gnucash-devel:
> 
> My suggestion is we ask people to save a *copy* of their data in SQLite
> and they then run a script across that copy that munges and obfuscates
> 

Did you see https://wiki.gnucash.org/wiki/ObfuscateScript ?

It is targeting xml files and was uploaded in 2010. So it might be
slightly bit rotten.

Regards
Frank

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

Re: [GNC-dev] [GNC] [MAINT] server upgrade planned Feb 3, 2019 1200-2300 US/EST

[David Carlson]

Isn't there a football game scheduled at 5:30 pm ct?

On Sat, Feb 2, 2019, 3:17 PM Derek Atkins  Hi,
>
> Just a reminder that this is planned for tomorrow.  I'm still not 100%
> sure of the exact timing, but I'll announce on IRC before I start and
> will be available on IRC during the process.  I'll send mail when the
> upgrade is complete!
>
> -derek
>
> Derek Atkins  writes:
>
> > Hi,
> >
> > PLANNED MAINTENANCE
> > WHAT:  Upgrading Operating System on Code
> > WHEN:  Feb 3, 2019  1200-2300 US/EST (1700-0400 UTC)
> >
> >
> > tl;dr: I am planning to upgrade the OS on code.gnucash.org on February
> > 3, 2019 from 1200-2300 US/EDT (1700-0400 UTC).  During this
> > time, git master, wiki, email/mailman, and gncbot/irc logs will
> > all be unavailable.  I'll be on #gnucash IRC for real-time
> > updates and notices.
> >
> >
> > Long version:
> >
> > The GnuCash "everything" server is getting a little long on the tooth,
> > and to enable some upgraded build tools I plan to upgrade the server
> > from Fedora 25 to Fedora 29.  I plan to do this upgrade on Sunday,
> > February 3, 2019, starting somewhere around 12:00 noon US/EST (although
> > my personal schedule might push that back, hense the long maintenance
> > window).  I've upgraded a few systems from F25 -> F29 already, some of
> > them upgraded in an hour, one system took over 4 hours.
> >
> > Code has lots of services so I expect it will take a long time to
> > upgrade and verify that everything is working.
> >
> > During the upgrade window code will be unavailable, and the services
> > running on code will be unavailable.  I will stay on IRC during the
> > upgrade to make real-time announcements.
> >
> > Please let me know if this time frame does not work for you.
> >
> > Thanks,
> >
> > -derek
>
> --
>Derek Atkins 617-623-3745
>de...@ihtfp.com www.ihtfp.com
>Computer and Internet Security Consultant
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Normalizing live data, a suggestion for discussion

[David Cousens]

Wm,

>> It doesn't end there, payments can be split over multiple invoices, so
>> again 
>> when one randomizes invoice amounts care must be taken to adjust the
>> payments 
>> in proportion to the invoice amount change or fully paid invoices
>> suddenly can 
>> become partially paid or overpaid. 
>
>Not true. 
>
>Geert, I don't want to say this but I believe you are actually wrong, 
>for once. 
>On 02/02/2019 15:24, Geert Janssens wrote:

In what way is what Geert says here not true? 

Payments can be split over multiple invoices. 
A single invoice could also have several payments associated with it.

These sort of situations arise frequently in small businesses where you may
need to micro manage your cash flow.

If, in the randomisation process, you do not apply the same random factor to
all the invoices covered by that payment, then what he says is exactly what
will happen. This means your script will have to detect all of the invoices
related to a payment.  OK it can be dealt with,  but again the script
complexity is increased considerably to do so.

>Most people don't use the business functions

I don't since I retired a few years ago, but I did for 8 years prior to
retiring (and I used MYOB for the 10 years prior to that before escaping). I
am certainly not alone. You could have a proviso that the script won't work
for files using the business functions but that then detracts considerably
from its usefulness as a general diagnostic tool.


Sqlite itself and its availability on Linux is not really an issue. Most
distros have it in their software repositories. What may be more of an issue
is that a lot of people who don't use the database backends because they
don't want the additional hassles of learning to use and maintain databases
may be reluctant to install it. It's not that it is all that difficult if
you're familiar with it, but if you are not, it is an an additional hurdle
and learning curve. I'm retired. Taking an extra half day to learn something
new doesn't worry me as long as it happens before my time is up. But if I am
running a busy lfe and/or a business as I used to, I would be more
reluctant. Again not a show stopper, only a limitation on general
applicability.

David Cousens




-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Normalizing live data, a suggestion for discussion

[Wm via gnucash-devel]

On 02/02/2019 15:24, Geert Janssens wrote:


Yes, if you use business features, you may have entered business identifying
data in File->Properties. It think that's what David is referring to.


I agree, the third party should not be identified.


Similarly there may be customer and vendor data (names addresses) in the book
that should equally be obfuscated. Just random data is fine.


Yes.

Geert, at the moment I am putting guid in place of random, do you think 
that is a wrong way to approach this?


Actually, the nearer we get to complete random the less useful the file 
becomes.  Actual random data is harder than most people think and pretty 
much defeats the purpose if you think about it.



Continuing on that vein, if you have bills and invoices, aside from
randomizing the transaction's split amounts and values you'll also have to do
the same for invoice entries.


I don't think that is true in most situations and even if what you say 
is true, I don't see it as a good argument against *attempting* a 
normalized book for most people.



And to make the book useful for detecting
business data bugs this should happen in such a way that invoice tax and
discount amounts remain consistent after multiplying with random numbers *and*
that the invoice totals continue to match the business transactions amounts in
AR/AP accounts.


There will be situations that involve the person doing the triage 
needing to see actual transactions, I have already commented on that.



And to make that one level more complicated, after that the payment
transactions *also* have to continue to match the new randomized invoice
amount (if the invoice was paid in full).


U, I don't think that is true.  If the munged numbers match (and 
they will, that is what the script will do) the transaction stream will 
be OK.


It is possible I have missed your point, Geert, but I think it is 
looking like I understand the contents of the gnc files better than you :(



It doesn't end there, payments can be split over multiple invoices, so again
when one randomizes invoice amounts care must be taken to adjust the payments
in proportion to the invoice amount change or fully paid invoices suddenly can
become partially paid or overpaid.


Not true.

Geert, I don't want to say this but I believe you are actually wrong, 
for once.



While this is probably all possible I believe the resulting script will be so
complex that it will become a source of bugs in itself which would divert
developer time to debugging and maintaining this script rather than working on
the effectively reported bug for which a sample data file was asked in the
first place...


H, I accept your point and disagree.


Up until a book with only transactions, no business data at all it sounded
like a useful tool.


Be a brave man, Geert, most people don't use the business functions :)


Oh and we haven't mentioned SXs and budgets yet...


Unless they are material to the file being investigated I suggest we 
just delete all SXs and budget stuff.



As for Colin's question: on Windows and MacOS sqlite is supported out of the
box. On linux it may require the additional installation of a libdbi driver.
Most distros I know have packages for this driver but they may not be
installed by default.


It would be an odd distro that excluded SQLite, it is a requisite for a 
lot of other stuff like browsers.  Thinking aloud: maybe a server only 
install might not have it or someone stupid enough to put their data on 
Amazon might not have it available.  The question then becomes, why was 
the person so stupid?


As far as I am concerned this conversation is ongoing, if only because 
Geert says he still needs a file from me to replicate a basic problem 
that I don't think needs any data from me at all.


--
Wm


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

Re: [GNC-dev] [GNC] [MAINT] server upgrade planned Feb 3, 2019 1200-2300 US/EST

[Derek Atkins]

Hi,

Just a reminder that this is planned for tomorrow.  I'm still not 100%
sure of the exact timing, but I'll announce on IRC before I start and
will be available on IRC during the process.  I'll send mail when the
upgrade is complete!

-derek

Derek Atkins  writes:

> Hi,
>
> PLANNED MAINTENANCE
> WHAT:  Upgrading Operating System on Code
> WHEN:  Feb 3, 2019  1200-2300 US/EST (1700-0400 UTC)
>
>
> tl;dr: I am planning to upgrade the OS on code.gnucash.org on February
> 3, 2019 from 1200-2300 US/EDT (1700-0400 UTC).  During this
> time, git master, wiki, email/mailman, and gncbot/irc logs will
> all be unavailable.  I'll be on #gnucash IRC for real-time
> updates and notices.
>
>
> Long version:
>
> The GnuCash "everything" server is getting a little long on the tooth,
> and to enable some upgraded build tools I plan to upgrade the server
> from Fedora 25 to Fedora 29.  I plan to do this upgrade on Sunday,
> February 3, 2019, starting somewhere around 12:00 noon US/EST (although
> my personal schedule might push that back, hense the long maintenance
> window).  I've upgraded a few systems from F25 -> F29 already, some of
> them upgraded in an hour, one system took over 4 hours.
>
> Code has lots of services so I expect it will take a long time to
> upgrade and verify that everything is working.
>
> During the upgrade window code will be unavailable, and the services
> running on code will be unavailable.  I will stay on IRC during the
> upgrade to make real-time announcements.
>
> Please let me know if this time frame does not work for you.
>
> Thanks,
>
> -derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Normalizing live data

[Wm via gnucash-devel]

On 02/02/2019 13:31, Hendrik Boom wrote:



On 2/1/19 5:36 AM, Wm via gnucash-devel wrote:


[2] as long as the transaction stream balances the actual numbers
don't matter (their will be occasions where the numbers are important
but these tend to be number extremes related to commodities rather
than anyone using gnc to do a Mr Putin vs Mr Trump sports bet).? In
most cases multiplying any matching numbers by the same semi-random
should produce a good file for examination so long as it is done
consistently [4]


If the numbers in the file are integers times some account or
currency-dependent unit, then just clculationg the greatest common
divisor of all the obfuscated numbers will give a good guess as to the
semirandom multiplier.


My test script includes randomness introduced by the user.  Could the 
numbers be worked backwards? Possibly, maybe probably from a purely 
numeric POV.  Will the remote person, having done the work, know what 
each of the numbers mean?  Nope.  That is the point I am suggesting we 
go for, a numerically sensible file that makes no sense to anyone else 
financially.


Will there be times this won't work? Of course, in which case we revert 
to the existing system of having to trust someone with your live data.


All I am offering to do is reduce the number of times someone has to 
trust someone.  If the community decides this isn't worth the effort so 
be it, but I think we should at least think it through.


So, Hendrik, I acknowledge your point but don't think it is significant.

--
Wm

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

Re: [GNC-dev] Normalizing live data, a suggestion for discussion

[Wm via gnucash-devel]

On 02/02/2019 16:11, Geert Janssens wrote:

But I don't know how feasible it is to effectively obfuscate that data withoug
resorting to a complex script


The script will be seen by others that do understand sql before anyone 
innocent gets to use it, promise.


If the script is well documented (I don't see the point of obfuscated 
sql when we are doing something like this as time is not the major 
issue, getting the problem fixed is) then people that can read will use it.


Further, most of the actual gnc code is so fucking obfuscated it is 
acknowledged only a handful of people can read it, so do you really want 
to raise the issue of obfuscation, Geert?


Seriously, people that don't know how code works are already trusting 
their financial data to code they have no clue about.  Why is my 
suggestion going to increase or decrease trust or increase or decrease 
complexity?


Gr.

>> that may introduce its own set of bugs

My script cannot introduce a bug, we are normalizing data <-- read that 
again, please.



or
inadvertently also obfuscate the actual issue. 


That is a possibility.  I consider this a positive not a negative from a 
triage POV. the user says: "oops, my problem doesn't exist after I ran 
the normalizing script" <-- is this good or bad?  if the script is well 
documented the user can edit it and run it again, possibly solving the 
problem themselves.


> > The latter is quickly tested,

the former is a time waster.


This is a very good point and I repeat, this is not suggested as 
compulsory, this is intended to make things easier not harder for people 
that do want to report things that may be specific to them without 
exposing irrelevant details they may consider private or personal.


--
Wm

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

Re: [GNC-dev] Normalizing live data, a suggestion for discussion

[Wm via gnucash-devel]

On 02/02/2019 15:40, David Carlson wrote:

Wouldn't it be simpler to create a library of template files designed to
exercise various features that a user could find one to illustrate his
concern?


To some extent this is already done in the build process.  Life always 
throws up something unexpected.  Further, users are by definition lazy 
and want the devs to look at *their* data rather than being expected to 
trawl through a set of files containing data not relevant to their real 
life situation in the hope that one of them shows the fault that, by 
definition, shouldn't have existed in the first place.  See the circular 
bit?




Thiswould bypass the need to figure out how to sanitize every possible user
file.


Sanitizing isn't that hard and we don't actually need perfection, just 
sufficient so that people are confident that the devs aren't snooping on 
them.



If the user wants, he could still build his own example file as some users
do now.


The problem is that some people build files that don't work for 
everyone; it does say "normalizing" in the Subject line, none of this is 
ever going to be compulsory.


--
Wm

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

Re: [GNC-dev] Normalizing live data, a suggestion for discussion

[Wm via gnucash-devel]

On 02/02/2019 09:59, Colin Law wrote:

Can all users save files as sqlite?  Does that need anything extra
installed on the OS side that may not be there?  Also what about
different builds of GC, do they all have sqlite?


I'm fairly sure all of the official builds can save SQLite.  If someone 
is rolling their own on a platform without the sqlite libraries then I 
think it would be unusual for them not to also have access to gnc on one 
of the production platforms, the whole idea being that the data should 
be easily transferable.


Even if someone didn't have SQLite my suggestion isn't taking something 
away from from them.  If someone can't save an SQLite file and run a 
script, the existing options are still there.


--
Wm




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

Re: [GNC-dev] End of 'X' date on 3.4-50 (maint)

[David Carlson]

Why didn't Wm Trump Jr. know that?

On Sat, Feb 2, 2019 at 11:14 AM John Ralls  wrote:

>
>
> > On Feb 2, 2019, at 4:19 AM, Herbert Thoma <
> herbert.th...@iis.fraunhofer.de> wrote:
> >
> >
> > Hmm, I would think that the problem is not the backwards US date
> > format. I would rather think that if the start of accounting
> > period is 1/1/2019, then the end should be 12/31/20*19* instead
> > of 12/31/20*20*.
> >
> > This seems to me like a bug.
>
> Yes, it's https://bugs.gnucash.org/show_bug.cgi?id=797073.
>
> Regards,
> John Ralls
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Normalizing live data

[John Ralls]

> On Feb 2, 2019, at 9:44 AM, Hendrik Boom  wrote:
> 
> On Sat, Feb 02, 2019 at 04:30:30PM +0100, Geert Janssens wrote:
>> Op zaterdag 2 februari 2019 14:31:43 CET schreef Hendrik Boom:
 On 2/1/19 5:36 AM, Wm via gnucash-devel wrote:
> [2] as long as the transaction stream balances the actual numbers
> don't matter (their will be occasions where the numbers are important
> but these tend to be number extremes related to commodities rather
> than anyone using gnc to do a Mr Putin vs Mr Trump sports bet).? In
> most cases multiplying any matching numbers by the same semi-random
> should produce a good file for examination so long as it is done
> consistently [4]
>>> 
>>> If the numbers in the file are integers times some account or
>>> currency-dependent unit, then just clculationg the greatest common
>>> divisor of all the obfuscated numbers will give a good guess as to the
>>> semirandom multiplier.
>> 
>> Do you think that still is possible if a different random number was used 
>> for 
>> each transaction ? (That's how I understood Wm's suggestion)
>> 
>> Each transaction will have it's own random number. So for transaction A all 
>> splits may have been multiplied with 450, for Transaction B all numbers may 
>> have been multiplied by 500. 
> 
> That might work.  That way eash transaction balances, but the account 
> balances will be nonsense.
> 
> Still, by finding the gcd you can still produce a lower bound on the 
> transaction values.  And if you, say, split off sales tax into a separate 
> split your lower bound will oftern be the actual value.
> 
> And it's likely that one could also identify income and expense accounts as 
> such by the pattern of debits vs credits.
> 

So maybe we should just forget it and continue the practice of asking users to 
send their account files directly to a developer with the promise of 
confidentiality if they're unable to reproduce the bug in a test file. No one 
has demurred yet.

Regards,
John Ralls

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

Re: [GNC-dev] Normalizing live data

[Hendrik Boom]

On Sat, Feb 02, 2019 at 04:30:30PM +0100, Geert Janssens wrote:
> Op zaterdag 2 februari 2019 14:31:43 CET schreef Hendrik Boom:
> > > On 2/1/19 5:36 AM, Wm via gnucash-devel wrote:
> > > > [2] as long as the transaction stream balances the actual numbers
> > > > don't matter (their will be occasions where the numbers are important
> > > > but these tend to be number extremes related to commodities rather
> > > > than anyone using gnc to do a Mr Putin vs Mr Trump sports bet).? In
> > > > most cases multiplying any matching numbers by the same semi-random
> > > > should produce a good file for examination so long as it is done
> > > > consistently [4]
> > 
> > If the numbers in the file are integers times some account or
> > currency-dependent unit, then just clculationg the greatest common
> > divisor of all the obfuscated numbers will give a good guess as to the
> > semirandom multiplier.
> 
> Do you think that still is possible if a different random number was used for 
> each transaction ? (That's how I understood Wm's suggestion)
> 
> Each transaction will have it's own random number. So for transaction A all 
> splits may have been multiplied with 450, for Transaction B all numbers may 
> have been multiplied by 500. 

That might work.  That way eash transaction balances, but the account 
balances will be nonsense.

Still, by finding the gcd you can still produce a lower bound on the 
transaction values.  And if you, say, split off sales tax into a separate 
split your lower bound will oftern be the actual value.

And it's likely that one could also identify income and expense accounts as 
such by the pattern of debits vs credits.

-- hendrik

> 
> Regards,
> 
> Geert
> 
> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] End of 'X' date on 3.4-50 (maint)

[John Ralls]

> On Feb 2, 2019, at 4:19 AM, Herbert Thoma  
> wrote:
> 
> 
> Hmm, I would think that the problem is not the backwards US date
> format. I would rather think that if the start of accounting
> period is 1/1/2019, then the end should be 12/31/20*19* instead
> of 12/31/20*20*.
> 
> This seems to me like a bug.

Yes, it's https://bugs.gnucash.org/show_bug.cgi?id=797073.

Regards,
John Ralls

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

Re: [GNC-dev] End of 'X' date on 3.4-50 (maint)

[Bob Gustafson]

Whenever I can, I use/convertTo the format 2019-02-02 (unfortunate that 
today is the 2nd of February. Things are less ambiguous near the end of 
months). This format is more native to SQL databases and also will sort 
reasonably when used in flat file names.


I think the US Govt issues passports with expiration dates in the last 
half of the month - just to cut down the confusion. (This may have 
changed though..)


Decades ago I searched for 24hr watches - smart phones have eliminated 
that need.


Have fun - Bob G

On 2/2/19 6:19 AM, Herbert Thoma wrote:

Am 02.02.19 um 00:27 schrieb Wm via gnucash-devel:

On 30/01/2019 01:54, Stephen M. Butler wrote:

I compiled origin/maint (gnucash 3.4-50) and noticed that the end of
accounting period was at 12/31/2020 while the start of accounting 
period

is at 1/1/2019.

Checked:

* Today:  1/29/2019


what the fuck do you expect if you are using american dates


Hmm, I would think that the problem is not the backwards US date
format. I would rather think that if the start of accounting
period is 1/1/2019, then the end should be 12/31/20*19* instead
of 12/31/20*20*.


this is not news.


This seems to me like a bug.


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


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

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

Re: [GNC-dev] Normalizing live data, a suggestion for discussion

[Geert Janssens]

Op zaterdag 2 februari 2019 16:40:34 CET schreef David Carlson:
> Wouldn't it be simpler to create a library of template files designed to
> exercise various features that a user could find one to illustrate his
> concern?
> 
> Thiswould bypass the need to figure out how to sanitize every possible user
> file.
> 
> If the user wants, he could still build his own example file as some users
> do now.

Both approaches have benefits and drawbacks.

The number of possible ways something can go wrong in gnucash is near 
infinite. Sometimes the problems only appear purely due to the amount of data, 
sometimes it comes from migration issues (migration from older gnucash 
versions,...). It would be equally hard to come with a set of template files 
that would cover all of those.
>From that point of view the idea to be able to look at the user's own data 
file is attractive as that is known to illustrate the problem.

But I don't know how feasible it is to effectively obfuscate that data withoug 
resorting to a complex script that may introduce its own set of bugs or 
inadvertently also obfuscate the actual issue. The latter is quickly tested, 
the former is a time waster.

Geert


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

Re: [GNC-dev] Normalizing live data, a suggestion for discussion

[David Carlson]

On Sat, Feb 2, 2019, 9:25 AM Geert Janssens  Op zaterdag 2 februari 2019 10:19:02 CET schreef Wm via gnucash-devel:
> > On 02/02/2019 00:16, David Cousens wrote:
> > > As well as the account names you might also want to munge data in the
> > > description/memo fields. This can contain identifying information for
> > > customers/vendors.
> >
> > How about we just zap the stuff in description/memo fields by default?
> > They're not mathematically significant and rarely cause double entry
> > problems unless someone introduces unusual UI stuff in which case they
> > should be able to provide an example.
> >
> > > Also possible any data relating to the owner of the file
> > > which is stored in the file/database.
> >
> > Does your file/database have an obvious owner?  Mine doesn't apart from
> > the name of the file which is the first and obvious thing to change
> > before you send it off for someone else to look at.
> >
> > If you mean bits of text in reports they wouldn't be included in an
> > SQLite file.
> >
> > If you mean bits of text in outbound documents I think we've already
> > zapped them.
> >
> > Have I missed your point?
> >
>
> Yes, if you use business features, you may have entered business
> identifying
> data in File->Properties. It think that's what David is referring to.
> Similarly there may be customer and vendor data (names addresses) in the
> book
> that should equally be obfuscated. Just random data is fine.
>
> Continuing on that vein, if you have bills and invoices, aside from
> randomizing the transaction's split amounts and values you'll also have to
> do
> the same for invoice entries. And to make the book useful for detecting
> business data bugs this should happen in such a way that invoice tax and
> discount amounts remain consistent after multiplying with random numbers
> *and*
> that the invoice totals continue to match the business transactions
> amounts in
> AR/AP accounts.
>
> And to make that one level more complicated, after that the payment
> transactions *also* have to continue to match the new randomized invoice
> amount (if the invoice was paid in full).
>
> It doesn't end there, payments can be split over multiple invoices, so
> again
> when one randomizes invoice amounts care must be taken to adjust the
> payments
> in proportion to the invoice amount change or fully paid invoices suddenly
> can
> become partially paid or overpaid.
>
> While this is probably all possible I believe the resulting script will be
> so
> complex that it will become a source of bugs in itself which would divert
> developer time to debugging and maintaining this script rather than
> working on
> the effectively reported bug for which a sample data file was asked in the
> first place...
>
> Up until a book with only transactions, no business data at all it sounded
> like a useful tool.
>
> Oh and we haven't mentioned SXs and budgets yet...
>
> As for Colin's question: on Windows and MacOS sqlite is supported out of
> the
> box. On linux it may require the additional installation of a libdbi
> driver.
> Most distros I know have packages for this driver but they may not be
> installed by default.
>
> Geert
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Wouldn't it be simpler to create a library of template files designed to
exercise various features that a user could find one to illustrate his
concern?

Thiswould bypass the need to figure out how to sanitize every possible user
file.

If the user wants, he could still build his own example file as some users
do now.

David Carlson

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

Re: [GNC-dev] Normalizing live data

[Geert Janssens]

Op zaterdag 2 februari 2019 14:31:43 CET schreef Hendrik Boom:
> > On 2/1/19 5:36 AM, Wm via gnucash-devel wrote:
> > > [2] as long as the transaction stream balances the actual numbers
> > > don't matter (their will be occasions where the numbers are important
> > > but these tend to be number extremes related to commodities rather
> > > than anyone using gnc to do a Mr Putin vs Mr Trump sports bet).? In
> > > most cases multiplying any matching numbers by the same semi-random
> > > should produce a good file for examination so long as it is done
> > > consistently [4]
> 
> If the numbers in the file are integers times some account or
> currency-dependent unit, then just clculationg the greatest common
> divisor of all the obfuscated numbers will give a good guess as to the
> semirandom multiplier.

Do you think that still is possible if a different random number was used for 
each transaction ? (That's how I understood Wm's suggestion)

Each transaction will have it's own random number. So for transaction A all 
splits may have been multiplied with 450, for Transaction B all numbers may 
have been multiplied by 500. 

Regards,

Geert


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

Re: [GNC-dev] Normalizing live data, a suggestion for discussion

[Geert Janssens]

Op zaterdag 2 februari 2019 10:19:02 CET schreef Wm via gnucash-devel:
> On 02/02/2019 00:16, David Cousens wrote:
> > As well as the account names you might also want to munge data in the
> > description/memo fields. This can contain identifying information for
> > customers/vendors.
> 
> How about we just zap the stuff in description/memo fields by default?
> They're not mathematically significant and rarely cause double entry
> problems unless someone introduces unusual UI stuff in which case they
> should be able to provide an example.
> 
> > Also possible any data relating to the owner of the file
> > which is stored in the file/database.
> 
> Does your file/database have an obvious owner?  Mine doesn't apart from
> the name of the file which is the first and obvious thing to change
> before you send it off for someone else to look at.
> 
> If you mean bits of text in reports they wouldn't be included in an
> SQLite file.
> 
> If you mean bits of text in outbound documents I think we've already
> zapped them.
> 
> Have I missed your point?
> 

Yes, if you use business features, you may have entered business identifying 
data in File->Properties. It think that's what David is referring to. 
Similarly there may be customer and vendor data (names addresses) in the book 
that should equally be obfuscated. Just random data is fine.

Continuing on that vein, if you have bills and invoices, aside from 
randomizing the transaction's split amounts and values you'll also have to do 
the same for invoice entries. And to make the book useful for detecting 
business data bugs this should happen in such a way that invoice tax and 
discount amounts remain consistent after multiplying with random numbers *and* 
that the invoice totals continue to match the business transactions amounts in 
AR/AP accounts.

And to make that one level more complicated, after that the payment 
transactions *also* have to continue to match the new randomized invoice 
amount (if the invoice was paid in full).

It doesn't end there, payments can be split over multiple invoices, so again 
when one randomizes invoice amounts care must be taken to adjust the payments 
in proportion to the invoice amount change or fully paid invoices suddenly can 
become partially paid or overpaid.

While this is probably all possible I believe the resulting script will be so 
complex that it will become a source of bugs in itself which would divert 
developer time to debugging and maintaining this script rather than working on 
the effectively reported bug for which a sample data file was asked in the 
first place...

Up until a book with only transactions, no business data at all it sounded 
like a useful tool.

Oh and we haven't mentioned SXs and budgets yet...

As for Colin's question: on Windows and MacOS sqlite is supported out of the 
box. On linux it may require the additional installation of a libdbi driver. 
Most distros I know have packages for this driver but they may not be 
installed by default.

Geert


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

[GNC-dev] Normalizing live data

[Hendrik Boom]

> On 2/1/19 5:36 AM, Wm via gnucash-devel wrote:
> >
> > [2] as long as the transaction stream balances the actual numbers
> > don't matter (their will be occasions where the numbers are important
> > but these tend to be number extremes related to commodities rather
> > than anyone using gnc to do a Mr Putin vs Mr Trump sports bet).? In
> > most cases multiplying any matching numbers by the same semi-random
> > should produce a good file for examination so long as it is done
> > consistently [4]

If the numbers in the file are integers times some account or 
currency-dependent unit, then just clculationg the greatest common 
divisor of all the obfuscated numbers will give a good guess as to the 
semirandom multiplier.

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

Re: [GNC-dev] End of 'X' date on 3.4-50 (maint)

[Herbert Thoma]

Am 02.02.19 um 00:27 schrieb Wm via gnucash-devel:

On 30/01/2019 01:54, Stephen M. Butler wrote:

I compiled origin/maint (gnucash 3.4-50) and noticed that the end of
accounting period was at 12/31/2020 while the start of accounting period
is at 1/1/2019.

Checked:

* Today:  1/29/2019


what the fuck do you expect if you are using american dates


Hmm, I would think that the problem is not the backwards US date
format. I would rather think that if the start of accounting
period is 1/1/2019, then the end should be 12/31/20*19* instead
of 12/31/20*20*.


this is not news.


This seems to me like a bug.


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


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

Re: [GNC-dev] Pie Chart

[Wm via gnucash-devel]

On 29/01/2019 18:12, stephen.m.butler51 wrote:

My first problem is figuring why my compile script stopped working.   I was out 
most of yesterday and out most of today.
Yes, the first round didn't show any anomalies.


Why the Trump do you think anyone is interested in your day to day 
movements you self obsessed buffoon?


If you want to tell someone you went to the toilet use Facebook, FFS
--
Wm

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

Re: [GNC-dev] Pie Chart

[Wm via gnucash-devel]

On 01/02/2019 16:05, David Carlson wrote:

Wm,

you are at it again.  We need to help your tiny brain.


Liz!  Help!  the bad people are talking amongst themselves!

FFS, grow up dullard.

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

Re: [GNC-dev] Normalizing live data, a suggestion for discussion

[Colin Law]

Can all users save files as sqlite?  Does that need anything extra
installed on the OS side that may not be there?  Also what about
different builds of GC, do they all have sqlite?Colin

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

Re: [GNC-dev] Normalizing live data, a suggestion for discussion

[Wm via gnucash-devel]

On 02/02/2019 00:16, David Cousens wrote:


As well as the account names you might also want to munge data in the
description/memo fields. This can contain identifying information for
customers/vendors. 


How about we just zap the stuff in description/memo fields by default? 
They're not mathematically significant and rarely cause double entry 
problems unless someone introduces unusual UI stuff in which case they 
should be able to provide an example.



Also possible any data relating to the owner of the file
which is stored in the file/database. 


Does your file/database have an obvious owner?  Mine doesn't apart from 
the name of the file which is the first and obvious thing to change 
before you send it off for someone else to look at.


If you mean bits of text in reports they wouldn't be included in an 
SQLite file.


If you mean bits of text in outbound documents I think we've already 
zapped them.


Have I missed your point?

Always possible, don't be put off by my rough and tumble impression of 
the idiot Trump, I do actually care.



The combination of the above would
probably be considered commercially sensitive information and at a personal
level what banks/service companies etc you deal with might be a possible
problem if it is in the public domain.


Ummm, that isn't really our problem, David.  If you subscribe to the 
"I'm an American and the government supports me" foolishness I'm 
wondering why the fuck any of you voted for the imbecile in charge at 
the moment!


Any banking account details have already been removed.

Next?

--
Wm





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