2020-04-09 GnuCash IRC logs

00:06:28 *** lcanaska has joined #gnucash
00:08:01 *** jralls has joined #gnucash
00:08:01 *** ChanServ sets mode: +o jralls
00:10:55 *** jralls_afk has joined #gnucash
00:10:55 *** ChanServ sets mode: +o jralls_afk
00:11:01 *** jralls has quit IRC
00:38:57 *** lucas has joined #gnucash
00:50:44 *** omnireq_ has quit IRC
00:50:55 *** omnireq_ has joined #gnucash
00:59:28 *** Cuare has quit IRC
01:14:54 *** sbluhm has joined #gnucash
01:14:54 *** ChanServ sets mode: +v sbluhm
01:15:28 *** lcanaska has quit IRC
01:18:03 *** fell_laptop has joined #gnucash
01:18:04 *** ChanServ sets mode: +o fell_laptop
01:19:46 *** fell has quit IRC
01:28:38 *** Mechtilde has joined #gnucash
01:35:10 *** sbluhm has quit IRC
01:45:20 *** NatashaOakl has joined #gnucash
01:48:30 *** NatashaOakl has quit IRC
01:59:31 *** sbluhm has joined #gnucash
01:59:31 *** ChanServ sets mode: +v sbluhm
02:04:38 *** Mechtilde has quit IRC
02:06:41 *** Mechtilde has joined #gnucash
02:30:38 *** puck has quit IRC
02:32:42 *** puck has joined #gnucash
02:47:25 *** ldir has joined #gnucash
02:47:25 *** ChanServ sets mode: +v ldir
02:48:07 *** o01eg_ has joined #gnucash
02:48:26 *** KevinDB has quit IRC
02:48:43 *** luwum[m] has quit IRC
02:48:52 *** peter-butler[m] has quit IRC
02:48:52 *** ElonSatoshi[m] has quit IRC
02:48:58 *** Couto[m] has quit IRC
02:49:12 *** gbear605 has quit IRC
02:49:13 *** puck has quit IRC
02:49:15 *** Unhammer has quit IRC
02:49:22 *** Yotson has quit IRC
02:49:22 *** o01eg has quit IRC
02:49:27 *** Yotson has joined #gnucash
02:51:21 *** gbear605 has joined #gnucash
02:57:53 *** puck has joined #gnucash
03:03:57 *** Unhammer has joined #gnucash
03:10:13 *** hussam has joined #gnucash
03:10:13 *** ChanServ sets mode: +v hussam
03:17:01 *** suukim has joined #gnucash
03:33:59 *** Mechtilde has quit IRC
03:35:59 *** Mechtilde has joined #gnucash
03:38:28 *** gjanssens has joined #gnucash
03:38:28 *** gncbot sets mode: +o gjanssens
03:38:28 *** ChanServ sets mode: +o gjanssens
04:08:37 *** bertbob has quit IRC
04:11:23 *** bertbob has joined #gnucash
04:11:23 *** ChanServ sets mode: +v bertbob
04:38:40 *** bertbob has quit IRC
04:47:48 *** fell_laptop is now known as fell
04:48:37 *** bertbob has joined #gnucash
04:48:37 *** ChanServ sets mode: +v bertbob
04:57:05 *** luwum[m] has joined #gnucash
05:08:38 *** peter-butler[m] has joined #gnucash
05:27:38 *** ElonSatoshi[m] has joined #gnucash
05:35:27 *** Couto[m] has joined #gnucash
05:42:55 <gjanssens> Well chris I sympathize... Your well intended change to reconcile dates is causing a lot of uproar...
05:42:55 <gncbot> gjanssens: Sent 21 hours ago: <chris> ok; this makes testing eguile templates difficult because they can't be run from build dir
05:43:16 <gjanssens> As for testing you can still install gnucash locally.
05:43:38 <gjanssens> It takes a bit longer but should not be the end of the world
05:44:08 <gjanssens> For your information before cmake that was the *only* way to test...
05:44:21 <gjanssens> Oh wait, did you mean to write unit tests for it?
05:44:59 <gjanssens> Hmm, even that should not assume the build directory mirrors an installation.
05:54:12 *** Aussie_matt has quit IRC
06:01:05 <chris> gjanssens: thank you for the support and absence of vote to revert :)
06:01:35 <chris> the intention is to write unit tests for balsheet-eguile, it's crashing in 3.9
06:02:49 <chris> I suspect some of uproar comes from the bazaar discussion.... may be best do cathedral instead
06:05:13 *** ramontjunior has joined #gnucash
06:11:27 *** User_ has joined #gnucash
06:25:24 <chris> "no good deed goes unpunished"
06:58:34 *** jim has joined #gnucash
07:11:43 *** Gerd has joined #gnucash
07:23:34 *** Aussie_matt has joined #gnucash
07:38:07 *** nnm has joined #gnucash
07:54:13 *** brian_ has joined #gnucash
07:55:07 *** brian_ is now known as epistax
07:55:28 *** ChanServ sets mode: +v epistax
08:01:32 <epistax> Heya! I know the Android gnu cash is separately maintained. I was wondering if there's a best practice for exchanging data between it and the original. I tried QIF and while I didn't lose any data, I ended up with some duplication in the account structure.
08:02:09 <fell> Chris, it is just a question of communication. The users might have a few spare minutes to reconcile their bank account as every day/weekmonth and then strange things happen.
08:02:52 *** MatrixTravelerbot[m] has joined #gnucash
08:04:55 <fell> epistax: I would see it as a general import question. Before you exchange date, verify the account structure is the same.
08:05:16 <fell> date->data
08:06:52 <fell> If the gnucash file is new, it is easy: export the account structure from the old program and import it in gnucash.
08:07:01 <epistax> fell: In this case I thought I was importing into blank. Ideally I'd like to keep the master data in something like dropbox. I'll clear things out and try a re-import
08:36:44 <epistax> So I still have the issue when importing fresh. I'm looking closely at the QIF file. For expenses, I see accounst for both "SExpenses:..." and "NExpenses:..." and these are causing two top-level Expenses accounts. What does the N and S indicate?
08:40:40 <chris> epistax: these are QIF fields
08:40:59 <chris> https://en.wikipedia.org/wiki/Quicken_Interchange_Format#Detail_items
08:41:30 <chris> (maybe)
08:44:42 <epistax> Maybe I'll try exporting and importing with one of the other formats
08:44:52 *** tonysoar has joined #gnucash
08:44:52 <warlord> chris, I dont understand why all the fuss about trying to calculate reconciled balance to the current date? I guess the goal is to be able to reconcile to any arbitrary date, even one in the past before another reconcile date?
08:45:11 <warlord> It seems like a lot of work for something that should happen rarely (if ever)
08:47:01 <chris> warlord: correct. It was acutely needed when 797084 was not fixed. I occasionally needed to fix a past transaction description/memo in a partially reconciled account, and find that it is impossible to re-reconcile.
08:47:39 <chris> I worked on this reconcile past dates for a while then 797084 was slipstreamed in last minute
08:47:50 <warlord> chris, why couldn't you re-reconcile? Just re-reconcile to the last record, or wait for the next statement and include the transactions that got unreconciled by your changes?
08:49:48 <warlord> IMHO, 797084 was a "more important" fix ;)
08:50:06 <warlord> (no offense meant to all the work you've done)
08:50:13 <chris> maybe that could have happened but I theorised that reconciling past statements would/should not be that difficult... worked on it for quite a while
08:51:23 <warlord> little did he know......
08:51:45 <chris> yups
08:53:22 <chris> PR667 was a natural extension of this issue
08:53:35 <warlord> Uhhuh.
08:53:45 <warlord> And the snowball grows ;)
08:53:54 <chris> s/issue/feature
08:54:19 <warlord> One person's feature is another person's issue ;)
08:55:27 <chris> hence my suggestion to allow this feature as an optional flag. i'd quite like to know that my account balances pass a reconciled-balance integrity check.
08:56:01 <chris> but it seems some wish to continue tolerate bad data.
08:58:48 <chris> epistax: if you are finding duplicates in the QIF imports for internal transfers between accounts, there is a very recent fix merged in
09:02:14 <warlord> chris, define "bad data"?
09:02:31 <chris> where recdate=many months/years from today
09:02:45 <warlord> who wants to tolerate that?
09:03:25 <chris> well those who are pushing to an immediate rollback?
09:03:31 <warlord> I have heard "x days/weeks is arbitrary", which is true, but I've still not heard a use-case to support recdate = many months/years into the future.
09:03:52 <chris> well i didn't mean actively *support* but *tolerate*
09:04:10 <warlord> I think the issue there is that people already have bogus data and we don't want to break them.
09:04:15 <chris> fair
09:04:26 <warlord> So we either need to back out the change or correct their data, but correcting their data may be.. hard.
09:04:39 * chris couldn't have imagined it would be easy to insert bad data like that
09:04:53 <warlord> LOL.
09:05:01 <warlord> GnuCash has LOTS of places where you can enter bad data.
09:05:25 <warlord> You can enter data well into the past, too!! (unless you [now] configure it to forbid that, but that's also a recent change)
09:06:06 <chris> No you still can add old data which throws off reconciled balances, and would then magically pop up in my super-duper reconcile-audit-report tool!
09:08:05 <chris> whether we rollback or not, you will be getting warnings when reconciling tomorrow ^_^
09:08:28 <epistax> chris: Thanks, I'll compare versions with the fix
09:09:02 <chris> I wonder if a 3.9a with just this rollback will be useful?
09:10:43 <warlord> You'll have to ask Jralls about that.
09:11:03 <chris> ^ping jralls_afk
09:12:26 <warlord> chris, he is asleep (its 6:12am for him)
09:12:33 <warlord> or at least I presume he is asleep
09:12:51 <chris> I know likely.... it's for irc highlight
09:13:47 *** MatrixTravelerbot[m] has quit IRC
09:13:48 *** ElonSatoshi[m] has quit IRC
09:13:52 *** peter-butler[m] has quit IRC
09:13:53 *** sunyibo[m] has quit IRC
09:13:53 *** mmkodali[m] has quit IRC
09:13:53 *** Couto[m] has quit IRC
09:13:53 *** luwum[m] has quit IRC
09:13:53 *** Julianold[m] has quit IRC
09:15:13 *** storyjesse has quit IRC
09:15:25 *** ElonSatoshi[m] has joined #gnucash
09:17:23 *** Gerd has quit IRC
09:19:02 <chris> instead of correcting their data, my suggestion to have a property/feature which confirms no bogus data
09:23:08 <warlord> I think it is also reasonable to have a scrub function that *will* fix bogus data, but it might need to ask the user how best to correct it.
09:29:16 <chris> In any case I wish to say thanks for piping up "in support" in principle of the recent changes... I didn't come in this to intentionally cause havoc
09:30:15 *** ecdhe has quit IRC
09:37:46 *** Julianold[m] has joined #gnucash
09:37:47 *** Couto[m] has joined #gnucash
09:37:48 *** MatrixTravelerbot[m] has joined #gnucash
09:37:48 *** luwum[m] has joined #gnucash
09:37:48 *** sunyibo[m] has joined #gnucash
09:37:49 *** peter-butler[m] has joined #gnucash
09:37:50 *** mmkodali[m] has joined #gnucash
09:42:31 <gjanssens> chris: of course you didn't create this intentionally. As far as I can tell none of the devs has blamed you for anything so far :)
09:43:33 <gjanssens> What I do take from the user feedback is that where a reconcile would have worked in 3.8 even with bad dates, it doesn't anymore with 3.9.
09:43:48 <gjanssens> From their external point of view I can understand this is discomforting.
09:43:55 <warlord> Agreed.
09:44:06 <warlord> I certainly would not object to a 3.9a that backs out that change.
09:44:49 <gjanssens> I think your detection of this issue is valid. Though as a feature not sufficiently polished.
09:45:08 <chris> phew
09:45:32 <gjanssens> I mean, just telling the user their data is bad without a reasonably easy way to fix it is what causes the distress.
09:46:17 <gjanssens> So in that respect I am inclined to also vote for a reversal until we can also offer a way to fix bad dates. Either via scrub or via a dedicated dialog or whatever.
09:46:36 <chris> I think this will be fine.
09:47:36 <chris> (ideally I'd also want to start logging *good* recdates with their ending_balances as in PR#667 but it is a data upgrade so it can wait)
09:48:28 <chris> the end point is a stronger data integrity check, other than a book with no Orphan or Imbalance accounts
09:49:14 <chris> ledger/beancount have these 'balance assertions' which throws on load if they fail
09:49:39 <chris> gnucash *could* have a 'reconciled balance assertion' which shows red light if they fail
09:52:57 <gjanssens> chris: while reading through all the reactions and feedback I also concluded we are not storing enough information for a foolproof reconcile process.
09:53:20 <chris> how come
09:54:32 <gjanssens> We only store a reconcile date in a split (and whether it's reconciled or not), but in the end there's no way of knowing which reconcile action did reconcile this particular split
09:55:06 <gjanssens> If you run two reconciles with the same date (which can be a good date for the first one and a bad date for the second) there's no way of knowing which ones are correct
09:55:24 <gjanssens> So that is more or less in line with your suggestion of logging good recdates with their ending balances.
09:56:11 <chris> yes I agree... the idea is if stored-reconciled-balance doesn't match account-reconciled-balance, one must look at all the splits reconciled on that particular day.... this is akin to pen-and-paper
09:56:21 <gjanssens> More broadly, other accounting packages I use store "statements", like a bank statement. Which has the statement number, a starting balance and ending balance and a statement date
09:56:53 <gjanssens> Storing that separately allows more granularity in verifying reconciliation issues
09:57:33 <gjanssens> And in that case splits would get a reconcile_id (mapping to the statement id) rather than a reconcile date.
09:58:03 <gjanssens> Anyway, I expect implementation to take some serious effort, so I'm not pushing for it
09:58:16 <gjanssens> At least I won't be able to spend time on it.
09:59:13 <chris> that's ok; PR667 stores enough information, and reconcile-audit-report in my branch has already done it
10:01:05 <chris> see the renderer in topmost commit in https://github.com/christopherlam/gnucash/tree/maint-reconcile-memory-audit-report - job already done
10:01:17 <gjanssens> :)
10:02:16 <chris> it's illus in one https://github.com/Gnucash/gnucash/pull/667 comment
10:02:53 <chris> see first two recdates are fine, third one fails, and renders all offending splits that I'll correlate with bank statement line by line?
10:05:28 <chris> gjanssens doesn't have to lift a finger to have this integrity-check report :)
10:09:34 <gjanssens> Nice :)
10:09:41 <gjanssens> Will try to review if I find time
10:10:22 *** tonysoar has quit IRC
10:15:35 <chris> The reason I'd vote for a book-property is: if user has bogus reconciled-dates in the future, it'd be ok to try fix them. they'll need to rummage old bank statements but it's doable.
10:16:23 <chris> but if they have bogus reconcile-date in the past, then all future reconcile dates will be ok, but re-reconcile won't. it'll be impossible to know what statement-date the split really belongs.
10:16:59 <chris> impossible = not possible until the heat death of universe, to try all combinatorics of splits to try identify their balance meets the statement date.
10:17:37 <chris> so, a "simple" solution is book-property = "I certify all dates are a-OK" ==> enable strict reconciles, enable past reconciliatoin, enable reconcile-audit.
10:18:25 <chris> anyone with bogus old rec-dates would really struggle to fix their rec-data, which is OK because they don't have to
10:18:32 *** ecdhe has joined #gnucash
10:19:25 <chris> note: the reconcile-audit-report *depends* on having the account-old-reconcile-data being present and accurate; therefore it builds upon PR 667. if old-reconcile-data is accutarate, then good things can happen :)
10:27:17 <chris> In addition, toggling the book property can trigger an immediate integrity check, if there are future reconcile_dates then the property CANNOT be set.
10:28:18 <chris> as warlord identifies, having bogus rec-dates in the past will be an unsolvable problem for past-rereconciliations... they'll have to forego it.
10:35:08 *** Jimraehl1 has joined #gnucash
10:37:24 *** Gerd has joined #gnucash
10:38:40 <chris> fwiw jralls_afk 3.9a would need to revert f182d9f91 and also add 7189337b0
10:46:25 *** Aussie_matt has quit IRC
10:47:46 <gjanssens> chris: define bogus reconcile-date in the past ?
10:48:16 *** sbluhm has quit IRC
10:50:26 <gjanssens> How would you detect one ?
10:50:32 *** sbluhm has joined #gnucash
10:54:15 *** Mechtilde has quit IRC
10:59:20 <chris> gjanssens: easy. let's assume I reconcile my statements every 6months. I reconcile 31/12/2006, 30/06/2007, 31/12/2007, 30/06/2008 etc
10:59:51 <chris> let's pretend my finger slips, I reconcile 31/06/2018 instead of 30/06/2008
11:00:07 <chris> all reconciliations after that will be "ok"
11:00:19 <chris> but they will not pass my reconciliation-audit-tool
11:08:11 *** Mechtilde has joined #gnucash
11:10:08 <warlord> Let's say you do that, but you don't run the audit tests until 2020. How would it know that your June 30 2018 (I am assuming you meant that, as June 31 is not a valid date at all) was invalid *at the time*?
11:12:24 <chris> because IIUC the 2008-2018 reconciles would have passed
11:12:36 *** guak has joined #gnucash
11:13:24 <chris> and the 30/06/18 rec_balance check would fail because it counts all those 2008-2018 as well
11:13:46 <chris> ergo the checkbox assertion "I certify all dates are accurate" was 'violated'
11:14:17 <chris> I *know* it's fragile for those who haven't been accurate in their past reconciles
11:14:28 <warlord> That presumes you have that data in the past, which we don't.
11:14:29 <chris> but the idea is to be useful for future books
11:14:42 <chris> hmm true
11:14:48 <chris> so it's not so bad then
11:14:57 <warlord> I agree that maintaining that data going forward makes sense.
11:15:12 <warlord> (provided it is only used for auditing)
11:15:26 <chris> ^ provided they don't input future reconcile-dates in error ;-)
11:18:29 <warlord> Well, let's propose that today we add protections to prevent significantly future recn-date entry.
11:18:42 <warlord> And we also save the recn balance
11:18:59 <warlord> *THEN*, at a future date, we could audit and re-verify that nothing changed.
11:19:21 *** Agfarmer18 has joined #gnucash
11:19:28 <chris> Thats the idea
11:19:48 <warlord> But we need to ensure we don't break existing data.
11:20:59 <chris> my changes haven't broken any data... only has made reconciliation impossible for some 3.9 users
11:21:09 <warlord> And also, when we do run the reconcile process, it should (IMHO) continue to use the computed balance and not the stored balance.
11:21:27 <warlord> Well, technically, that's breaking data -- or at least breaking processing of existing data.
11:21:38 <chris> ok then.
11:22:26 <warlord> Don't feel bad; we've all made changes that broke something else somewhere without really realizing it.
11:23:02 <chris> Tx :)
11:23:38 <chris> my main benefit is: say I am entering data into my current account, dozens and dozens of lines
11:24:23 <chris> suddenly my finger slip, I write eg. 04/09/2019 instead of 09/04/2019, and the last reconcile was in 2018
11:24:51 <chris> I'd do incremental reconciles to try locate the errant split
11:25:34 <chris> anyway I lost my train of thought but you get the idea
11:27:02 <chris> regular reconciliation gives valuable balance assertions and this data can be harnessed to strengthen the data
11:28:08 <warlord> Oh, I've had to do that for mis-entered data in accounts I rarely reconcile..
11:34:51 *** Agfarmer18 has quit IRC
11:36:33 *** Agfarmer18 has joined #gnucash
11:39:15 *** Gerd has quit IRC
11:47:07 *** Agfarmer18 has quit IRC
11:47:46 *** Agfarmer18 has joined #gnucash
11:50:45 *** Mechtilde has quit IRC
11:51:07 *** Mechtilde has joined #gnucash
11:54:05 *** jim has quit IRC
11:56:46 *** Agfarmer18 has quit IRC
12:00:39 *** ArtGravity has joined #gnucash
12:00:39 *** ChanServ sets mode: +v ArtGravity
12:04:56 <jralls_afk> chris, it's way too late for 3.9a. We'd do a snap release and call it 3.10.
12:07:45 *** FridaAasen has joined #gnucash
12:08:40 *** jralls_afk is now known as jralls
12:09:09 *** FridaAasen has quit IRC
12:12:10 <jralls> warlord, I actually wake up at 0600, but around 0612 I'm still brushing my teeth and definitely not sufficiently caffienated to discuss snap releases!
12:12:32 *** calvinct has joined #gnucash
12:14:13 *** calvinct has quit IRC
12:14:43 *** calvinct has joined #gnucash
12:15:42 * jralls likes the idea of a reconcile object guid replacing reconcile_date.
12:17:56 *** Gerd has joined #gnucash
12:18:17 *** jim has joined #gnucash
12:31:02 *** sbluhm has quit IRC
12:31:15 *** Mechtilde has quit IRC
12:31:31 <warlord> jralls, haha. Okay.
12:37:17 *** Mechtilde has joined #gnucash
12:39:49 *** brian_ has joined #gnucash
12:40:54 *** epistax has quit IRC
12:53:07 *** suukim has quit IRC
12:54:09 *** JojoBabie has joined #gnucash
12:57:19 *** JojoBabie has quit IRC
13:04:49 *** brian_ has quit IRC
13:12:34 *** Gerd has quit IRC
13:16:46 *** jim has quit IRC
13:20:52 *** sbluhm has joined #gnucash
13:20:52 *** ChanServ sets mode: +v sbluhm
13:39:14 *** omnireq_ has quit IRC
13:39:24 *** omnireq_ has joined #gnucash
13:42:36 *** ArtGravity has quit IRC
13:49:28 *** calvinct has quit IRC
13:49:33 *** calvinct has joined #gnucash
13:52:47 *** lcanaska has joined #gnucash
13:56:58 *** Mechtilde has quit IRC
14:03:09 *** Agfarmer18 has joined #gnucash
14:04:11 *** Mechtilde has joined #gnucash
14:10:02 *** Agfarmer18 has quit IRC
14:13:25 *** frakturfreak has joined #gnucash
14:13:25 *** ChanServ sets mode: +v frakturfreak
14:15:50 *** Agfarmer18 has joined #gnucash
14:32:24 *** lcanaska has quit IRC
14:42:17 *** Gerd has joined #gnucash
14:43:10 *** Agfarmer18 has quit IRC
14:45:49 *** calvinct has quit IRC
15:00:44 *** omnireq_ has quit IRC
15:00:54 *** omnireq_ has joined #gnucash
15:08:07 *** sbluhm has quit IRC
15:10:14 *** sbluhm has joined #gnucash
15:10:14 *** ChanServ sets mode: +v sbluhm
15:23:52 *** jim has joined #gnucash
15:39:57 *** Agfarmer18 has joined #gnucash
15:47:25 *** Agfarmer18 has quit IRC
15:59:09 *** calvinct has joined #gnucash
16:04:40 *** gjanssens has quit IRC
16:14:48 *** FH_thecat has quit IRC
16:23:02 *** Unhammer has quit IRC
16:23:07 *** User_ has quit IRC
16:23:44 *** sbluhm has quit IRC
16:29:22 *** Mechtilde has quit IRC
16:33:32 *** Unhammer has joined #gnucash
16:33:33 *** ChanServ sets mode: +v Unhammer
16:38:06 *** calvinct has quit IRC
16:40:38 *** sbluhm has joined #gnucash
16:46:43 *** sbluhm has quit IRC
16:52:14 *** omnireq_ has quit IRC
16:52:24 *** omnireq_ has joined #gnucash
16:55:47 *** ChanServ sets mode: +v gbear605
16:56:27 *** jim has quit IRC
17:13:14 *** omnireq_ has quit IRC
17:15:01 *** omnireq_ has joined #gnucash
17:25:12 *** oozer has joined #gnucash
17:41:38 *** Agfarmer18 has joined #gnucash
18:11:43 *** Agfarmer18 has quit IRC
18:14:47 *** jim has joined #gnucash
18:16:27 *** lcanaska has joined #gnucash
18:27:21 *** Agfarmer18 has joined #gnucash
18:31:35 *** jim has quit IRC
18:31:43 *** jim has joined #gnucash
18:41:42 *** jervin has joined #gnucash
18:49:27 *** frakturfreak has quit IRC
18:52:44 *** omnireq_ has quit IRC
18:54:06 *** omnireq has joined #gnucash
18:54:06 *** ChanServ sets mode: +v omnireq
18:54:53 *** Agfarmer18 has quit IRC
19:29:49 *** Gerd has quit IRC
19:30:38 *** BellaHadid has joined #gnucash
19:31:36 *** Gerd has joined #gnucash
19:34:20 *** BellaHadid has quit IRC
19:40:36 *** Gerd has quit IRC
20:00:22 *** bertbob has quit IRC
20:06:27 *** guak has quit IRC
20:19:26 *** bertbob has joined #gnucash
20:19:26 *** ChanServ sets mode: +v bertbob
20:21:36 *** n08l3J has joined #gnucash
20:43:47 <chris> jralls: thankyou for considering snap release, sorry to add to workload. shall i create a branch for it?
20:43:48 *** angel has joined #gnucash
20:44:38 *** angel has left #gnucash
20:46:22 <jralls> chris: No. If we're going to do a snap release then we release what's in maint at the time, just like any other release. So revert the commits that you think need reverting.
20:46:32 <chris> ah ok
20:48:01 <chris> my (small) concern is then the commit 2329c1c50 which is a candidate fix for the budget-liability issue. I *think* it fixes budgets but have had no comprehensive beta testers yet.
20:48:09 <jralls> Or if you'd rather you could just put the call in reconcile-window.c back to xaccGetReconciledBalance and leave the rest.
20:49:01 <jralls> OK, you should probably revert 2329c1c50 then.
20:49:25 <chris> f182d9f91 is the offending commit; is a simple 1-liner
20:49:55 <jralls> If someone pops up who's willing to test it's in a nightly build that they can install and test just for the budget fix.
20:50:48 <chris> Ok.
20:52:32 *** guak has joined #gnucash
20:55:41 <chris> other than these two, my other commits are 100% fine
20:55:47 <chris> (after 3.9)
20:57:49 <jralls> Wasn't there some whining about budgets recently? Was that pre-3.9?
20:57:59 <chris> yes
20:58:08 <chris> 3.7 was fine
20:58:52 <chris> 3.8 had the income/expense/transfer/total changed to income/expense/asset/equity/liability thereby missing the "Remaining to budget" amount
20:59:33 *** guak has quit IRC
20:59:52 <chris> 3.9 was my attempt at returning to 3.7-like behaviour (fixed for unreversed budgets) but the beta tester in #630 gave me incorrect feedback regarding liability amounts
21:00:24 <chris> 3.9+ has (I believe) a correct implemenation but no comprehensive beta testing yet
21:00:32 <chris> now HEAD has reverted to 3.9 behaviour
21:01:10 <chris> ^ correction "3.7 was fine iff reversal=credit-accounts"
21:04:33 <jralls> Well, tell the guy who complained about liability accounts that he has until noon GMT Saturday to test it or it's staying the 3.9 way until 4.0.
21:05:13 <jralls> In retrospect the budget rewiring should have gone to master.
21:07:29 <chris> master would have the unreversed-budgets feature conversion; 3.8+ needed to be taught how to handle both
21:08:34 *** jim has quit IRC
21:14:10 *** jim has joined #gnucash
21:16:26 *** oozer has quit IRC
21:21:42 *** jralls is now known as jralls_afk
21:25:05 <chris> I will raise the issue in devel and ask for any betatesters
21:25:28 *** lcanaska has quit IRC
21:36:27 *** jim has quit IRC
21:42:26 *** jim has joined #gnucash
21:52:08 *** lcanaska has joined #gnucash
21:59:15 *** jim has quit IRC
22:02:26 *** omnireq_ has joined #gnucash
22:03:39 *** omnireq has quit IRC
22:20:28 <fell> chris, I believe not many devs are users of the budget feature. So you should consider to ask on user, too.
22:29:26 *** jervin has quit IRC
22:35:08 <chris> fell: I would think the interested parties are subscribed to both
22:35:48 <chris> jralls_afk: I'm quite interested to know how/why your CC AQB link has random reconciled_dates too... could they be "$today when AQB was run"?
22:38:05 <fell> Gunther got it after fetching the accounr balance.
23:00:03 *** n08l3J has quit IRC
23:39:35 *** lcanaska has quit IRC