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?
Grrrrr.
>> 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
