Re: [GNC-dev] Pie Chart
Most of these issues are not caused by reports but rather webkit/UI issues :) I haven't found way to trigger report drill-down without an intermediate "Load" anchor. Hopefully you can request an enhancement from them. It's an internal webkit issue and too difficult to fix. I think the intermediate "Load" button is a safe approach for now. Try refreshing -- I've increased visibility of this button. I do not think it will be straightforward to skip the 2-step drilldown for now. Will need feedback on various links between reports -- although the links "work", I'm still not 100% sure the links make sense. 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
Wm 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. Also possible any data relating to the owner of the file which is stored in the file/database. 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. 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] End of 'X' date on 3.4-50 (maint)
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 this is not news. ___ 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
On 01/02/2019 13:36, Wm via gnucash-devel wrote: would someone other than idiot Stephen M Butler attempt a reply please TIA ___ 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
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!" Um 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. G. 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
Re: [GNC-dev] Guide Hotkey
On Fri, Feb 1, 2019 at 3:12 PM Frank H. Ellenberger < frank.h.ellenber...@gmail.com> wrote: > Hi David, > > Am 30.01.19 um 23:58 schrieb David Carlson: > > Also, how do you get to the Tutorial and Concepts Guide from the F1 Key? > > The help menu says "ctrl+h" and under Linux the Guide window pops up. > > Regards > Frank > > Thank you . ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Guide Hotkey
Hi David, Am 30.01.19 um 23:58 schrieb David Carlson: > Also, how do you get to the Tutorial and Concepts Guide from the F1 Key? The help menu says "ctrl+h" and under Linux the Guide window pops up. Regards Frank ___ 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
On 2/1/19 5:36 AM, Wm via gnucash-devel wrote: > Situation: someone reports a problem with gnc, at triage it becomes > clear some data is going to be required to identify or solve the > problem. Normal question? Can you give us a file. > > Problem: for any number of reasons ranging from plain old personal > privacy through to people that live in supposed liberal societies > avoiding tax and people in supposed conservative societies avoiding > persecution, sending live data isn't always appropriate. The USA has > become very weird about this and most of our development people are in > the USA so hopefully they'll understand the politics of privacy, > eventually. > > Suggestion: we try to make providing a file easier for people. > > 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 > > 1. account names [1] > > 2. numbers [2] > > [1] people following this will probably be aware that gnc doesn't know > about account names much beyond broad classes in spite of providing > lots of names and not accommodating other accounting concepts such as > the fact there is a level one up [3] My point here is that account > names are important to people but not gnc so why not just randomize > them? Obvious way? copy the actual account name (the guid) to the user > visible one. this is a one way change unless someone has unusual > settings on their SQLite file, if someone has those settings it seems > reasonable to presume they also know how to turn them off and save the > file again. > > [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] > > [3] that is a long argument I am interested in conceptually rather > than personally, it doesn't affect me as a UK person but makes me > think Internationally. > > [4] I don't think a reductive discussion of true vs near true random > [5] is appropriate, the significant point is the person viewing the > data won't be able to work out the original number without significant > effort and in most cases simply won't be able to work it out at all, > we're talking computing assets I doubt anyone here has access to in > order to get back *and* I believe the gnc people are actually > motivated by solving problems, belief in the project and ordinary > stuff like that so they won't even be looking. > > [5] Random is fun if only because there are so many ways of doing it. > > Questions: why SQLite rather than XML? Because if a person runs an > agreed script across their file we can be sure of an outcome. Editing > an XML file informally is scary, it immediately raises questions about > consistency of data. Other SQL formats are not widely used, my > proposal is we go for LCD where we can achieve normalization. > > Normalization will have to be balanced: privacy vs contribution to the > project. > > I definitely want contribution from other people that work well with > SQL, let's think about this together, people, I have written some > scripts that confuse *my* data and I know that Geert is still waiting > for me to send him a file. > > Geert is a good person, I just don't want to show him very personal > stuff in my file. > > I have a plan for making showing a file easier, is anyone interested? > > This is the *start* of a conversation, I welcome thoughts. It might be better to have a standardized test file that folks could download, and run their scenario against. 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. 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. 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!" 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. I suspect that many folks are using an XML back-end and would rather not fiddle with a database back-end. I'm in that camp even though I'm a trained Oracle DBA and spent a couple decades using that back-end professionally. I think the first step is having a standard test file that a use could apply
Re: [GNC-dev] Pie Chart
On 31/01/2019 01:56, Stephen M. Butler wrote: Took me awhile to figure out how to drill down. Ummm, you appear to be less capable than the people trying to help you. To me this is a Trump supporter so obviously. If you follow the conversation, the idiot is Stephen, everyone is trying too help his tiny brain. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Pie Chart
On 27/01/2019 22:22, Stephen M. Butler wrote: But, you didn't ask me for that! What, in particular, would you like me to review? you are giving way to much personal information ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Normalizing live data, a suggestion for discussion
Situation: someone reports a problem with gnc, at triage it becomes clear some data is going to be required to identify or solve the problem. Normal question? Can you give us a file. Problem: for any number of reasons ranging from plain old personal privacy through to people that live in supposed liberal societies avoiding tax and people in supposed conservative societies avoiding persecution, sending live data isn't always appropriate. The USA has become very weird about this and most of our development people are in the USA so hopefully they'll understand the politics of privacy, eventually. Suggestion: we try to make providing a file easier for people. 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 1. account names [1] 2. numbers [2] [1] people following this will probably be aware that gnc doesn't know about account names much beyond broad classes in spite of providing lots of names and not accommodating other accounting concepts such as the fact there is a level one up [3] My point here is that account names are important to people but not gnc so why not just randomize them? Obvious way? copy the actual account name (the guid) to the user visible one. this is a one way change unless someone has unusual settings on their SQLite file, if someone has those settings it seems reasonable to presume they also know how to turn them off and save the file again. [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] [3] that is a long argument I am interested in conceptually rather than personally, it doesn't affect me as a UK person but makes me think Internationally. [4] I don't think a reductive discussion of true vs near true random [5] is appropriate, the significant point is the person viewing the data won't be able to work out the original number without significant effort and in most cases simply won't be able to work it out at all, we're talking computing assets I doubt anyone here has access to in order to get back *and* I believe the gnc people are actually motivated by solving problems, belief in the project and ordinary stuff like that so they won't even be looking. [5] Random is fun if only because there are so many ways of doing it. Questions: why SQLite rather than XML? Because if a person runs an agreed script across their file we can be sure of an outcome. Editing an XML file informally is scary, it immediately raises questions about consistency of data. Other SQL formats are not widely used, my proposal is we go for LCD where we can achieve normalization. Normalization will have to be balanced: privacy vs contribution to the project. I definitely want contribution from other people that work well with SQL, let's think about this together, people, I have written some scripts that confuse *my* data and I know that Geert is still waiting for me to send him a file. Geert is a good person, I just don't want to show him very personal stuff in my file. I have a plan for making showing a file easier, is anyone interested? This is the *start* of a conversation, I welcome thoughts. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
