On 01/02/2019 19:17, Stephen M. Butler wrote:
Ummm, Stephen M. Butler I don't think you were my intended audience.
Let me put you down gently.
It might be better to have a standardized test file that folks could
download, and run their scenario against.
Nope, we can do that already, I was addressing other realistic situations.
However, there are situations that arise where the only solution is to
look at the original file. In that case some obfuscation would be
helpful. I would think that memos and descriptions would also need to
be randomized.
My suggestion is they are zapped, no personal stuff at all
After a careful read, I realized you did intend to
randomize the transaction amoun ts (which would have to be careful to
ensure the DR/CR remained balanced.
I'm one of the more intelligent people here, the tx will remain balanced.
Otherwise, one could at least get
the total Assets/Liabilities/Income/Expense values known for the
submitter. That may be sensitive information. I know that I've shared
some information that later reflection was "did I really give them that!"
Ummmmm
Now, to the XML vs SQLite argument. Whatever script is applied to one
could easily have a counterpart that would apply to the other. You
wouldn't have to manually (informally) edit the XML. A known script
should provide a known outcome.
Not true in reverse if someone throws in some numbers no other person
knows about. Think about diminishing returns.
I can't correct this fucked up quote below, must be a Mexican border
issue, sigh. Looks like a Trump voter, fucked quotient in general.
>I suspect that many folks are using an
XML back-end and would rather not fiddle with a database back-end.
We know know that, we ask for a specific db when we need to test stuff.
I've given up correcting the quoting, sorry, folks.
I'm
in that camp even though I'm a trained Oracle DBA and spent a couple
decades using that back-end professionally.
We are unimpressed unless you contribute.
Some of us also think training may have been wasted time if you end up
not knowing much about databases.
I think the first step is having a standard test file that a use could
apply to their favorite back-end, run their scenario, check the
results.
Wrong, please read what I said before. Grrrr.
I hate it when someone so obviously doesn't read.
If the problem is verified, then we have pretty good evidence
the problem is in the application. If the problem doesn't show up, then
it indicates the problem may be in the data. That would require a "data
forensic expert" (aka developer or some assistant) to look deeper into
the user's data file. In that case a good obfuscation tool would come
in handy.
I'd say something obviously rude around now but Liz would zap me instead
of the fool if past rules are anything to go by :(
I'd like someone with a clue to attempt an answer.
--
Wm
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
