2018-06-30 GnuCash IRC logs
00:07:55 *** badger92 has joined #gnucash
00:44:55 *** fell has quit IRC
00:46:11 *** Mechtilde has joined #gnucash
00:58:02 *** gour has joined #gnucash
01:36:24 *** bertbob has quit IRC
01:43:10 *** bertbob has joined #gnucash
02:05:25 *** O01eg has quit IRC
02:12:57 *** puck has quit IRC
02:16:08 *** gjanssens has joined #gnucash
02:16:08 *** ChanServ sets mode: +o gjanssens
02:16:20 <gjanssens> .
02:19:52 *** puck has joined #gnucash
02:22:05 *** luwum[m] has quit IRC
02:22:14 *** DiogoGomes[m] has quit IRC
02:34:22 *** Cuare has quit IRC
02:35:56 *** fekepp has joined #gnucash
03:00:04 *** luc14n0 has quit IRC
03:20:44 *** harshitaneja has joined #gnucash
03:35:25 *** harshitaneja has quit IRC
03:42:41 *** DiogoGomes[m] has joined #gnucash
04:09:47 *** harshitaneja has joined #gnucash
04:11:54 *** luwum[m] has joined #gnucash
04:23:18 <gjanssens> I'm still getting mail messages from gnome bz about bugs being migrated to gnucash. Looks like the gnome's mailserver is severely overloaded...
04:35:47 *** pilotauto has quit IRC
05:04:14 *** fabior has joined #gnucash
05:22:07 *** O01eg has joined #gnucash
05:51:14 <chris> bikeshedding in balsheet-pnl :(
06:04:18 *** gour has quit IRC
06:05:28 *** gour has joined #gnucash
06:08:09 *** Aussie_matt has joined #gnucash
06:47:17 *** O01eg has quit IRC
06:57:51 <gjanssens> chris: that's ok. It increases the user's sense of involvement which is a good thing
06:58:27 <gjanssens> Unless you have received mails I haven't yet it looks like your last iteration is close to what is desired.
06:58:39 *** gjanssens is now known as gjanssens_afk
07:10:33 *** fabior has quit IRC
07:22:45 <warlord> gjanssens_afk: either that or the script it taking a long while.
08:15:41 *** ncv has joined #gnucash
08:17:03 *** boldstripe has joined #gnucash
08:37:10 *** fell has joined #gnucash
08:37:24 *** gncbot sets mode: +o fell
08:38:05 *** Jimraehl1 has joined #gnucash
08:38:28 *** Jimraehl1 has left #gnucash
08:40:30 *** gjanssens_afk is now known as gjanssens
08:40:38 <gjanssens> Would it still be running you think warlord ?
08:41:13 <gjanssens> Hmm, no. The mails are dated around midnight
08:41:25 <gjanssens> So before I disabled mail reception for my account
08:47:33 *** oozer has joined #gnucash
08:58:13 *** boldstripe_ has joined #gnucash
08:58:34 *** boldstripe has quit IRC
08:58:34 *** boldstripe_ is now known as boldstripe
08:59:00 *** fabior has joined #gnucash
09:03:26 <fell> gjanssens: The overload exists, because the dutch speaking users got no announcement about the changes. ;-)
09:04:24 <gjanssens> Oh, right. That's a huge and very active userbase on gnome bz :D
09:04:54 <gjanssens> Seriously though you are referring to the gnucash-nl mailing list ?
09:05:11 <fell> Yep
09:05:16 <gjanssens> I am not really involved in that although my native language is Dutch
09:06:11 <gjanssens> So I don't feel it's up to me to translate announcements for the few users on that list :(
09:07:03 <fell> That is the reason, I am watching it if I have some time.
09:09:32 <Robert847> It looks like the bugs are being updated in numerical order. I got an announcement for 481774 about 45 minutes ago. There is still quite a ways to go.
09:10:26 <fell> BTW: How good is your french? I got a note about https://bugs.gnucash.org/show_bug.cgi?id=750153
09:13:01 *** chris has quit IRC
09:17:10 *** chris has joined #gnucash
09:17:35 <chris> I speak french
09:17:42 *** RASSRQ has joined #gnucash
09:25:14 <fell> chris, I believe google translate gave me the intention. I am writing now...
09:27:52 <gjanssens> Robert847: I believe the updates are done, but the gnome servers can't cope with the huge amount of mails to send.
09:28:02 <gjanssens> That's why you are still getting mails now
09:28:18 <gjanssens> fell: I just finished replying to that bug.
09:28:30 <gjanssens> (And I closed it)
09:28:46 <gjanssens> Feel free to amend my reply though
09:29:02 <gjanssens> Note I wrote in English as that's the default language for the bug tracker
09:29:45 <gjanssens> And the reporter states he's from Canada (Québec area in that case) so he's likely to understand English as well.
09:45:43 *** RASSRQ1 has joined #gnucash
09:45:47 *** RASSRQ has quit IRC
09:55:32 *** boldstripe_ has joined #gnucash
09:56:12 *** boldstripe has quit IRC
09:56:12 *** boldstripe_ is now known as boldstripe
09:56:16 *** User__ has joined #gnucash
09:58:26 <fell> I watch some strange behavior at bugs.gnucash.org:
10:00:33 <gjanssens> fell: for kicks I have run an msgmerge on all our current *.po files and then an msgfmt --statistics
10:00:55 <gjanssens> Do you know why the numbers it reports can be different from what the translation project reports ?
10:01:03 <fell> After Geerts update, setting Status|RESOLVED, Resolution|NOTABUG I refreshed my browser window (my comment was kept, I had not touched the status)
10:01:48 <fell> and now it shows status Resolved:Fixed.
10:02:02 <gjanssens> For example the Spanish translation on tp indicates (5185/5204) however my local result is 4598 translated, 92 fuzzy.
10:02:56 <gjanssens> fell: if I reload that bug it's still RESOLVED NOTABUG
10:03:06 <gjanssens> so that's odd
10:03:07 <fell> TP did no update for 3.x because there were no changes in gnucash.pot.
10:03:24 <fell> at least for x= 0, 1
10:03:26 <gjanssens> fell: no it currently has the 3.2 pot file
10:03:53 <gjanssens> And that's what I'm comparing with current maint (which doesn't have translation changes yet compared to 3.2
10:03:56 <gjanssens> )
10:06:41 *** User__ has quit IRC
10:07:23 <gjanssens> oh nevermind. I'm merging with the wrong pot file :x
10:09:00 <gjanssens> fell: reloading the bug page doesn't change anything for me.
10:09:15 <gjanssens> The status remains RESOLVED NOTABUG
10:11:03 <fell> yes, I believe you, but it gets not sync'ed for me - after several reloads.
10:11:58 <fell> I will save without touching the state and we will see how it behaves then.
10:12:25 <gjanssens> Nasty :(
10:13:45 <fell> Resolution NOTABUG FIXED
10:14:21 <fell> So we found a bug in bugzilla :)(
10:18:54 <gjanssens> Wow it seems to arbitrarily change names even! That's one for warlord to get involved...
10:19:27 <fell> where?
10:20:36 *** ncv has quit IRC
10:25:17 <fell> Another issue for warlord: After reassigning Component: User Interface General -> Translations, ui@gnucash.bugs is not removed.
10:25:42 <fell> from the cc list
10:29:47 <fell> and a minor issue: at gnome we had roles like [GnuCash developer] behind the name in comment titles.
10:33:15 <gjanssens> fell: my reaction was based on your text. You first had RESOLVED FIXED and then you reported NOTABUG FIXED. That seemed quite odd
10:33:39 * gjanssens has just sent out a plea for translators
10:33:54 <gjanssens> Hopefully it will encourage a few to jump in...
10:37:20 <gjanssens> Note I consciously invite new potential translators to contact us as they may need some handholding to get started
10:37:30 <gjanssens> Trying to lower barriers this way...
10:38:28 <fell> a nd a link to https://wiki.gnucash.org/wiki/Translation?
10:39:06 <gjanssens> That would be one of the first things I would point out if someone speaks up
10:39:09 <fell> (which could get several improvements)
10:41:05 *** altong has joined #gnucash
10:43:31 *** Aussie_matt has quit IRC
10:52:49 <gjanssens> fell: I already made a first start at improving the wiki page (just a minor edit though)
10:53:20 <gjanssens> Tbh I think there's way too much info there for one wiki page.
10:53:52 <gjanssens> A translator will be overwhelmed by the sheer amount of info.
10:54:19 <gjanssens> At first glance I would move the "Tips for Developers" to its own page.
10:55:16 <gjanssens> Obviously also in the translation category so it remains linked to translation work.
10:55:36 <gjanssens> But I should be doing other stuff right now... :(
10:57:32 <chris> "Show exchange rates used" https://screenshots.firefox.com/p7Qm4X6fAhSEcQC9/null
10:57:49 <fell> NP.
11:00:33 <gjanssens> chris: cool
11:00:47 <gjanssens> And I continue to be a nitpick :)
11:01:07 <chris> notice no GBP/USD therefore GBP amounts are unconverted yet are accounted for in the grand-total above
11:01:14 <gjanssens> Is there also an option to *not* display the amounts in the non-common currency ?
11:01:38 <gjanssens> eg you have an exchange rate for FUND so can you have the stock line only display in $ ?
11:01:49 <chris> ah 'hide original currency', yes
11:01:58 <gjanssens> Ok even more cool
11:01:58 <chris> but GBP will remain GBP because there's no USD
11:02:26 <gjanssens> I think that is better than what it does currently, so approved as far as I'm concerned
11:02:32 <gjanssens> It will give less confusion
11:02:35 <chris> well yea
11:04:01 <chris> this is why for the topmost account (which includes children accounts) I didn't use xaccAccountBalanceIncludeChildren - I used xaccAccountBalance instead on all descendants, ideally converted to common-currency, added them all up using a collector, and render the collector
11:06:28 <gjanssens> What's xaccAccountBalanceIncludeChildren doing wrong that you can't use it ?
11:08:20 <chris> ahem I meant xaccAccountGetBalanceAsOfDateInCurrency with include-children=true ... I wasn't sure it could handle missing prices correctly
11:15:13 <gjanssens> As far as I can see from a cursory scan I *think* it would treat amounts with missing prices as 0 so it should work for how you want to count
11:18:01 <chris> ah this will then require interrogating the pricedb for missing prices, then xaccAccountGetBalanceAsOfDateinCurrency onto common-currency & all missing prices... just another way of doing it
11:19:27 <gjanssens> Agreed. you still would have to add code for the entries with missing prices
11:19:40 <gjanssens> I don't know which would be fastest.
11:19:59 <gjanssens> I'd expect c code to recurse faster than guile, but that is purely subjective
11:22:26 <chris> much more important imo is whether my code is intelligible to yourself, or any wannabe hacker in the future...
11:22:49 <chris> purely functional approach
11:23:15 <gjanssens> :)
11:23:46 <gjanssens> We need to clean up our api's indeed...
11:23:55 <gjanssens> Where on my list should I put that :(
11:29:26 <chris> I haven't found API too difficult... the C is extremely sparse & easy to read (but not to write :P)
11:29:45 <chris> it's the scheme part that's a mess -- i'm sure you're aware old code has lots of different scheme styles... (car x) (cdr x) from The Little Schemer...
11:30:14 <chris> lots of accumulators (for-each (lambda (s) (coll 'add (monetary-amount s)) splitlist)
11:30:49 <chris> I'm trying to convert to functional, much much nicer (apply + (map split->value splitlist))
11:38:27 <gjanssens> Ok, a worthy effort :)
11:38:50 <gjanssens> I find our current scheme code pretty hard to decipher indeed.
11:39:15 <gjanssens> Given enough time I usually manage, but I welcome simplifications
11:39:40 <gjanssens> The accumulators have always been a pain for me
11:40:40 <chris> amen
11:40:47 *** guilherme has joined #gnucash
11:40:58 <chris> I did find a way to convert accumulator to functional: https://github.com/christopherlam/gnucash/blob/56f7958b14305119c1fe312ff1b1476dec252886/gnucash/report/standard-reports/balsheet-pnl.scm#L373
11:43:42 <gjanssens> BZ bug notification mails are still seeping through... I'm now getting mails that were sent around midnight here (around 18:00 at warlord's)
11:49:28 <gjanssens> chris: I can read that :)
12:05:20 <gjanssens> ... as in much better readability
12:07:22 <chris> cool
12:08:42 *** oozer has quit IRC
12:33:11 *** storyjesse has quit IRC
13:35:24 <jralls> warlord: Watching watchers doesn't work, so all-bugs as a global watcher won't either.
13:38:32 <CDB-Man_> hmm, so I get the feeling the finance::quote is failing to update some of my securities prices, becuase I have _too many_ securities to quote and alphavantage cannnot handle that much (and finance quote doesn't buffer, perhaps)
13:38:37 <warlord> jralls: then how did it work in GnomeBZ?
13:38:48 *** CDB-Man_ is now known as CDB-Man
13:39:00 <warlord> or is all-bugs a "new" construct.
13:39:06 <jralls> warlord: https://bugzilla.gnome.org/show_activity.cgi?id=314554 had its milestone removed in 2013 when I cleaned out old milestones.
13:39:07 <warlord> Does it not work as a "Global Watcher"?
13:42:04 *** guilherme has quit IRC
13:42:41 <warlord> fell: changing components wont adjust the CC list automatically. There is no logic that I know of to make that change.
13:43:13 *** guilherme has joined #gnucash
13:44:11 *** guilherme has quit IRC
13:44:44 <jralls> warlord: There was no all-bugs on GnomeBZ, just the per-topic pseudo/meta-users.
13:44:49 *** guilherme has joined #gnucash
13:45:01 <warlord> jralls: Strange -- when I got the email last night about that bug when you added the new comment, it also sent about removing the target milestone.
13:46:23 <warlord> jralls: hmm. so it's just an all-bugs thing. But the "Watch" other users does not seem to imply the lack of watching recursion.
13:47:31 <jralls> I know. That's why I first tried to have all-bugs watch all of the other pseudos. As we know, that didn't work.
13:47:41 <warlord> another alternative would have been to set up a mailman list for all-bugs.
13:47:54 <warlord> Did you try setting it up as a global in the Preferences?
13:50:37 <warlord> BTW, is mail back on for GncBZ?
13:50:46 <jralls> No, but consider what the "watcher" description says: "If you watch a user, it is as if you are standing in their shoes for the purposes of getting email. Emails is sent or not according to your preferences for their relationship to the bug (e.g. Assignee).
13:50:53 *** guilherme has quit IRC
13:51:00 *** guilherme has joined #gnucash
13:51:19 <jralls> warlord: Yes, I've gotten a dozen overnight/this morning.
13:52:19 <jralls> Anyway, if the watchee has no relationship to the bug--and watching would seem not to be a relationship--then it generates no mail for watchers.
13:55:03 <warlord> That's... odd.
13:55:06 <jralls> That makes sense if you think about it: Suppose someone watches me, expecting to see my activity on bugs. They'll be a bit surprised to get mail for every bug on BZ. Or even worse, suppose they watched someone like André Klapper or Olav Vitters who as admins were probably in that Preferences>General field, being admins of Gnome's BZ. It would be a bit of an overload for the poor watcher to suddenly be inundated with hundreds of bugs a day.
13:55:50 <warlord> jralls: I would that that if all-bugs is a "global watcher" -- it's defined as a "user that gets all emails" --- one would think that watching that user would get you everything.
13:57:05 <jralls> Well, we can test it easily enough with a new pseudo.
13:57:32 <warlord> true.
13:57:33 <warlord> True.
13:58:28 <warlord> I kind of wish we had tested it beforehand, so we didn't have to globally modify every bug after the import.
13:58:37 <warlord> I worked hard to keep the last-modified time intact!
13:59:46 <jralls> Yeah, me too. We should be able to delete the history items with SQL so that the change history is restored.
14:03:08 <warlord> jralls: the problem would be determining the correct last_modified date -- and history. I'm not sure exactly how to do that.
14:03:19 <warlord> (especially considering there have been modifications since).
14:03:24 *** frakturfreak has joined #gnucash
14:03:53 <warlord> I can revert back. But then we lose whatever changes have occurred in the past day.
14:03:56 <jralls> OK, I created test-all@gnucash.bugs and set globalwatchers to that. You watch test-all, I've got some bugs to reply to...
14:04:11 <warlord> Give me a minute.
14:04:21 <jralls> Can you set up phpmyadmin on the DB?
14:05:34 <warlord> OKay, I am watching test-all
14:06:01 <warlord> I'd rather not set up phpmyadmin -- there are TONS of security bugs in it and it's being attacked all the time.
14:06:02 <jralls> OK.
14:06:37 <jralls> gjanssens: Maybe we should close https://bugs.gnucash.org/show_bug.cgi?id=550232 "won't fix"?
14:07:27 <gjanssens> jralls: yeah probably. Go ahead and do so. I'm about to leave.
14:07:42 <gjanssens> Bye
14:07:48 *** gjanssens has quit IRC
14:07:52 <warlord> dammit
14:08:07 <warlord> I was going to ask geert what the deal was with the status issue they were talking about this monring.
14:08:34 <warlord> @tell gjanssens I don't quite understand the status issue with bugzilla you were talking about (with fell) earlier today. Could you explain more what the issue is?
14:08:34 <gncbot> warlord: The operation succeeded.
14:10:37 <warlord> jralls: let me know after you make your first modification.
14:10:43 <jralls> Just did.
14:10:50 *** Mechtilde has quit IRC
14:11:34 <jralls> And another.
14:11:55 <jralls> warlord: How about ssh access to the mysql command-line tool?
14:13:16 <warlord> I'm not getting any of these emails. Nor am I seeing anything.
14:13:39 <warlord> 3 messages sent to test-all. NOne sent to me.
14:14:03 <jralls> Yeah, that's what I expected.
14:14:30 <warlord> I'm actually surprised.
14:14:47 <warlord> based on the documentation, I would have expected *this* to work.
14:15:27 <jralls> Where does the documentation say that watchers are supposed to recurse?
14:17:21 <warlord> Well, it says a watcher gets all the email that the watched user does. And the global watcher says "receives all emails".
14:18:10 <warlord> FWIW, I'm up to 587436 for email notifications from GnomeBZ
14:18:30 <warlord> Dated Friday at 6:23pm!
14:21:24 <jralls> 18:23 EDT? When I went to make dinner at 17:00 PDT the script was still running. I didn't check to see how many it had done then, the last time was at 16:12 when it had done 6657. It was doing around 37/min.
14:21:49 <jralls> So I imagine it finished somewhere around 17:30 PDT.
14:24:20 <jralls> I just refreshed the search page. It finished at 17:12 PDT.
14:26:29 <jralls> Back to the database. The schema is coded at https://github.com/bugzilla/bugzilla/blob/5.0/Bugzilla/DB/Schema.pm.
14:30:24 <fell> warlord, 13:42:41: while changeing the component by default assignee&QA get reset to default (from new component). IIRC at gnome assignee and QA were no longer in the CC list, but see Andrés change in https://bugs.gnucash.org/show_activity.cgi?id=750153
14:30:56 <fell> The mistake: the defaults get added to the CC list, too.
14:31:47 <fell> And so they do not disappear after reassigning the component.
14:39:43 <fell> 14:08:34 <warlord>: we both opened that bug and started commenting, gjanssens committed his comment together with a changed status. I refreshed my browser window and Geerts comment was inserted before my draft, but the status became slightly different - neither the previous nor Geerts.
14:39:46 <jralls> fell: I don't see a way to change that in the preferences or admin settings, either.
14:40:28 <fell> I commited my comment and the status was changed, too.
14:44:40 *** Robert847 has left #gnucash
14:45:08 <fell> jralls: e.g. https://bugs.gnucash.org/editcomponents.cgi?product=Documentation: IMHO having documentation@gnucash.bugs also in Default CC list is not, what we want.
14:47:46 <jralls> fell: Hmm, my idea was that it enables changing the assignee and qa and not break watching.
14:48:22 <fell> After you commented, you are alreaady cced.
14:50:59 <jralls> You can override that, both in preferences and per-bug. But that's not the point. Suppose you're watching documentation@gnucash.bugs. I take "assigned" on a doc bug to let everyone know I'm working on it. gjanssens takes QA to let everyone know that he's going to review my change. If documentation@gnucash.bugs isn't also in the CC list you won't get bugmail on that bug any more.
14:52:47 <fell> I was thinking of users agnostic or lazy asigning General, but it is import, needs a change in engine and finally some documentation, resulting in a very long maiing list
14:53:02 <jralls> Now that's a bit contrived: We don't have a QA function and it's unlikely that anyone would take it. I'd actually like to disable the field at https://bugs.gnucash.org/editparams.cgi?section=bugfields, but I don't know whether that has an affect on bugmail.
14:54:50 <jralls> Yes, I understand. One can always remove the old pseudo from the CC list when reassigning the bug, but that's a PITA to remember.
14:59:42 <fell> It might be less work to CC the pseudo, If one really wants to take over QA (I do not remember any case)
15:04:11 <jralls> That's a thought. We could even emphasize that it's not to be changed. I wonder if we can make it so that only admins can change it...
15:08:30 <jralls> Unfortunately I don't see a way. Oh well, it's probably still better. I'll remove the CC from the component settings.
15:13:39 <jralls> fell: BTW you know that you're explicitly default CC on some products, right?
15:14:47 <fell> Yes, because once I created currency
15:15:20 <fell> and wanted to improve tax
15:21:41 <jralls> OK, the default assignee/qa pseudos aren't automatically added to the CC list anymore.
15:24:49 <fell> Shouldn't all-bugs@gnucash.bugs go to https://bugs.gnucash.org/editparams.cgi?section=mta: globalwatchers?
15:26:48 <jralls> warlord: How about DELETE FROM bugs_activity WHERE added LIKE 'all-bugs@gnucash.bugs'; That should fix the "last changed" value without actually changing the CC List.
15:28:36 <jralls> s/all-bugs@gnucsh.bugs/%all-bugs@gnucash.bugs%/ to cover any instances where I changed more than one CC.
15:31:00 <jralls> warlord: Hmm, though, I wonder if it writes multiple records to bugs_activity for multiple changes. What does SELECT * FROM bugs_activity WHERE bug_id = '458181' AND when = '2018-06-29 19:18:19 EDT'; produce?
15:38:03 *** guilherme has quit IRC
15:49:34 *** guilherme has joined #gnucash
15:53:51 *** Agfarmer18 has joined #gnucash
15:55:56 *** Agfarmer18 has quit IRC
16:01:54 <warlord> jralls:
16:01:58 <warlord> MariaDB [bugs]> SELECT * FROM bugs_activity WHERE bug_id = '458181' AND bug_when = '2018-06-29 19:18:19 EDT';
16:01:58 <warlord> +--------+--------+-----------+------+---------------------+---------+-----------------------+-------------------+------------+
16:01:58 <warlord> | id | bug_id | attach_id | who | bug_when | fieldid | added | removed | comment_id |
16:01:58 <warlord> +--------+--------+-----------+------+---------------------+---------+-----------------------+-------------------+------------+
16:02:00 <warlord> | 124215 | 458181 | NULL | 2670 | 2018-06-29 19:18:19 | 22 | all-bugs@gnucash.bugs | | NULL |
16:02:03 <warlord> | 124216 | 458181 | NULL | 2670 | 2018-06-29 19:18:19 | 16 | core@gnucash.bugs | chris@wilddev.net | NULL |
16:02:06 <warlord> | 124217 | 458181 | NULL | 2670 | 2018-06-29 19:18:19 | 18 | core@gnucash.bugs | chris@wilddev.net | NULL |
16:02:09 <warlord> +--------+--------+-----------+------+---------------------+---------+-----------------------+-------------------+------------+
16:02:12 <warlord> 3 rows in set, 1 warning (0.00 sec)
16:02:57 <jralls> warlord: OK, thanks. Thought that might be the case.
16:06:46 <jralls> So there will be three records to remove: DELETE from bugs_activity WHERE who = '2670' AND bug_when LIKE '2018-06-29 19:%'; should do it.
16:07:28 <warlord> That will remove from the history but not adjust the bug last_modified date.
16:08:47 <jralls> I don't see a last_modified in bugs. There's a lastdiffed.
16:10:02 <jralls> I'm operating on the theory that last modified is retrieved from the last bug_when in bugs_activity.
16:10:31 <jralls> There's supposed to be a way for admins to see the actual SQL emitted by a query, let me try...
16:10:33 <warlord> jralls: delta_ts
16:14:12 <warlord> At this point I think I just don't care enough to try to revert back those messages and time stamps.
16:14:29 <jralls> OK.
16:14:32 <warlord> A lot of these changes I could have done during the import had we known we needed to do it.
16:14:51 <warlord> I'm a bit sad I spent so much time to get the timestamps stable just to have them all changed immediately upon import.
16:15:52 <warlord> If I arbitrarily delete the history and then try to reset the delta_ts, I might accidentally remove something else you did.
16:16:39 <jralls> I'm not a bit worried about the history. Reseting delta_ts is a bit more troublesome.
16:17:30 <warlord> The delta_ts should match the last history entry, I think.
16:17:55 *** fabior has quit IRC
16:18:30 <warlord> I could write a perl script against the Bugzilla code to do it. Get all bugs, iterate, find the last history for that bug, then reset delta_ts
16:18:54 <warlord> It would still be a bit of a pain, but doable.
16:18:57 <jralls> Right. So I suppose after deleting the offending history items one could retrieve the last bugs_activity.bug_when and set delta_ts to that.
16:19:20 <jralls> Much easier and faster in SQL.
16:20:45 <jralls> Hmm, maybe not easier. I don't know how to combine a DELETE and a SELECT in one query.
16:21:06 <jralls> Not a DELETE, an UPDATE.
16:21:36 <warlord> jralls: This is why I'd do it in perl.. I'd write the code using the Bugzilla->dbh and write the SQL code directly.
16:24:33 <warlord> SELECT bug_when FROM bugs_activity WHERE bug_id = '458181' ORDER BY bug_when DESC LIMIT 1;
16:25:15 <warlord> Did you make no other changes to any bugs in the 19-hour yesterday?
16:25:41 <jralls> No.
16:27:56 <warlord> Okay. Let me work on a script..
16:28:11 <jralls> https://stackoverflow.com/questions/224732/sql-update-from-one-table-to-another-based-on-a-id-match
16:30:06 <jralls> So after the DELETE, UPDATE bugs, bug_activity SET bugs.delta_ts = max(bugs_activity.bug_when) WHERE bugs.bug_id = bugs_activity.bug_id;
16:32:44 <warlord> Hmmm....
16:34:22 <warlord> Okay, let me back up the DB and run those two queries..
16:34:36 *** guilherme has quit IRC
16:37:13 <warlord> UPDATE bugs, bugs_activity SET bugs.delta_ts = max(bugs_activity.bug_when) WHERE bugs.bug_id = bugs_activity.bug_id;
16:37:13 <warlord> ERROR 1111 (HY000): Invalid use of group function
16:37:18 <warlord> That update didn't work.
16:37:29 *** CDB-Man has quit IRC
16:37:30 <warlord> The delete worked:
16:37:32 <warlord> Query OK, 4602 rows affected (0.71 sec)
16:37:53 <jralls> Is that on the live DB or the backup?
16:37:59 <warlord> The live DB
16:38:17 <warlord> (I just made a backup to restore)
16:39:05 <warlord> There's been no activity for an hour.
16:39:22 <jralls> I checked and it shows the history correctly munged. So it probably doesn't like max(). Hmm.
16:41:36 <jralls> https://stackoverflow.com/questions/9408908/update-date-field-from-max-date-in-another-table
16:43:12 <jralls> UPDATE bugs b SET delta_ts = (SELECT MAX(bug_when) FROM bugs_activity a WHERE b.bug_id = a.bug_id);
16:43:45 <warlord> This seems to work: SELECT MAX(bug_when) bug_when from bugs_activity where bug_id = '458181';
16:45:06 <warlord> That seems to have (mostly) worked:
16:45:06 <warlord> Query OK, 2849 rows affected, 259 warnings (0.25 sec)
16:45:07 <warlord> Rows matched: 8679 Changed: 2849 Warnings: 259
16:45:46 <jralls> And a search shows the "Changed" column restored. Success!
16:46:29 <warlord> Yay!
16:47:08 <warlord> Okay, I'm going to play dad some more. glad we got that fixed.
16:47:09 *** RASSRQ1 has quit IRC
16:59:59 *** harshitaneja has quit IRC
17:09:45 *** harshitaneja has joined #gnucash
17:20:52 *** bertbob has quit IRC
17:28:01 <frakturfreak> jralls: I would’ve liked to send you a link to both the English and German version of a standard german DATEV CoA via the list, for better understanding of my mails. However the English version is missing much of the descriptive subheadings for different groups of accounts used in the German version of it.
17:35:22 *** bertbob has joined #gnucash
17:35:34 *** RASSRQ has joined #gnucash
17:38:36 *** bertbob has quit IRC
17:38:54 *** gour has quit IRC
17:41:33 <fell> frakturfreak, which SKRs?
17:43:05 <fell> Perhaps you should add them in https://wiki.gnucash.org/wiki/De/Projekte#Kontenrahmen
17:43:10 <frakturfreak> 04 because it’s more clearly split in balance-sheet and p/l accounts, but the same problem also exists for the for me more familiar 03
17:44:29 <fell> Yeah, Once I wrote https://wiki.gnucash.org/wiki/De/Referenz#DE_-_Deutschland
17:48:05 <fell> Mails on which list?
17:49:00 <frakturfreak> Maybe I should add number 45, I’ve come across this at work, man is accounting for social care cumbersome.
17:49:07 <frakturfreak> gnucash-user
17:50:50 <frakturfreak> in regards of the description of the required sections of a balance sheet according to § 266 HGB in some of the threads of “The two modules“
17:51:39 <fell> 45 or 49? Chf1 updated 49. it is waiting in bugzilla
17:54:41 <frakturfreak> 45 PBV (but I’ve seen it got mentioned somewhere else) Why have those businesses be accounting on a accrual basis … Also in adding I meant adding it to the list you’ve linked.
17:54:54 *** bertbob has joined #gnucash
18:01:54 *** fell has quit IRC
18:09:54 *** harshitaneja has quit IRC
18:12:36 *** fell has joined #gnucash
18:12:36 *** gncbot sets mode: +o fell
18:14:51 *** harshitaneja has joined #gnucash
18:25:47 *** oozer has joined #gnucash
18:31:17 * fell is reading that thread
18:45:55 *** CDB-Man has joined #gnucash
18:59:50 *** jotrago has quit IRC
19:04:35 *** chf1 is now known as chf
19:07:21 <chf> frakturfreak: I've specifically added those descriptive headings from the main part as well as from the "blocks" at the page side as hierarchy tree elements for the SKR49.
19:07:22 <jralls> warlord: I think that https://github.com/GNOME/bugzilla-gnome-org-customizations/tree/master/extensions/Browse is the browse extension fell wants.
19:08:23 <chf> This alone is MUCH work, so actually adding SKR45 would be far from a trivial task.
19:08:59 <frakturfreak> chf: Cool thing.
19:12:52 <chf> Additionally I've grouped tax relevant accounts, even if that breaks the number scheme a bit, because "side block" grouping does that anyway – as well as making the "most generic" account of each group its top level "directory".
19:14:14 <chf> This should be done to enable people to exclude VAT-stuff easily rather than hiding/deleting every single irrelevant account.
19:17:45 <chf> If you need SKR45 in Gnucash, frakturfreak, expect at least 40 hours of work to include the most recent version in that way from the most recent Datev PDF ONLY (without reflecting changes from recent years to ease uppdates…)
19:19:55 <frakturfreak> Sorry I wasn’t clear enough. I now that implementing the very detailed SKR45 is time consuming project
19:20:21 <chf> The update from the half-automated included original 2009 issue of SKR49 to the current "tree type" state and tracking the decelopment 2012/2017/2018 took me 60 hours.
19:20:24 <frakturfreak> what I meant with adding was adding it to the list of (to be implemented) accounts
19:20:55 <frakturfreak> s/accounts/CoAs
19:21:11 <frakturfreak> only to see later that it’s mentioned elsewhere
19:21:15 <chf> Feel free to do so, but that won't achieve much rather than documenting that somebody should do the work some day.
19:26:29 <chf> Because you obviously understand the problems involved in the first place, frakturfreak, I'd be glad if you'd take a look at my efforts with the SKR49 just to verify if it's OK or should be changed somehow.
19:30:31 <frakturfreak> Sorry but not really my area of expertise because a) I’ve never did accounting for an e.V. secondly the group I worked for used a totally distinct self-created CoA and just recently changed to 99 % copy of the SKR49 (as it’s the case with the other ones), so I can’t tell what changed.
19:32:06 <frakturfreak> s/worked for/work for/
19:32:11 <chf> It's not about "what changed"; that's rather trivial. Main question: is the tree structure OK for actual work?
19:34:40 <chf> And I probably failed sometimes in abbreviating the same things in the same way in multiple parts of the hierarchy.
19:37:15 <frakturfreak> No problem also happened to the account names in our now finally out-phased old accounting software (but that mainly was due to some stupid character limit restrictions and not in the printed CoA).
19:40:14 <frakturfreak> Yeah it looks usuable
19:40:21 <chf> The SKR49 is specifically redundant: almost everything fuplicated for sports/non-sports, and commercial/non-commercial,…
19:40:41 <chf> fup…->dup…
19:40:48 <frakturfreak> however I’ve some points to add
19:40:56 <frakturfreak> why the CAPS?
19:42:10 <chf> Because they were copy-pasted from the PDF or previously there (for the same reason in the 2009 PDF).
19:44:29 <frakturfreak> ok, the rip-off my company use becauso of nih doesn’t use them
19:48:06 <frakturfreak> secondly, but this mainly the fault of standard gnucash reports and a bit of my personal preference. I’d like account number and name clearly to be distinct and not having the account number with-in the name.
19:52:37 <chf> Has also been so before, if P remember correctly.
19:52:47 <chf> name = number + text
19:53:01 <frakturfreak> also did „9 Statistik-Konten“ really have the heading „Erträge“?
19:53:02 <chf> description = text
19:53:08 <chf> number = number
19:55:28 *** boldstripe has quit IRC
19:56:29 *** harshitaneja has quit IRC
19:56:39 <chf> No, but Gnucash has no "generic passive" account, doesn't allow anything other than "equity" as sub-account of the type "equity", and it is lacking something like a "statistical" or simply "overall generic" zype as well.
19:57:44 <frakturfreak> Also I don’t know if the whole class 9 is really needed especially the subsection 4 Personenkonten because it’s mainly just the description of the ones that should be created as subaccounts of #0650 and #1340 also in reality only 9000, 9008, 9009 and occasionally 9090 are really used. Maybe the other accounts should be made invisible?
19:57:46 <chf> This is because it was a US project in the first place, and those americans simply can't imagine that people elsewhere do it different.
19:58:57 <chf> I made nothing invisible, because that woul affect primaryly those who need it: they'd think it's missing.
19:59:00 <frakturfreak> chf: Yes, to bad there only is one type of ROOT account
19:59:51 *** harshitaneja has joined #gnucash
20:01:15 <frakturfreak> chf: Difference in philosophy, my software only makes an account in the tree visible once there is a transaction, however I can still see it the CoA section.
20:01:40 <chf> That's not the problem, the problem is that only ROOT allows any sub-type, while the others are more restricted, and there's nom way to adapt that to european customs.
20:03:08 <frakturfreak> That’s what I meant, also you can’t create an account with type ROOT from the GUI.
20:03:08 <chf> Gnucash makes everything visible, except marked as "invisible", but that CAN be influenced by configuring the standard filter.
20:10:45 * frakturfreak would like to rant about the bilrug and especially the changes to the definition of turnover but doesn’t feel confident enough to do it in english. (When speaking of American ideas).
20:12:08 <chf> What's the "bilrug", and what is the "definition of turnover"? Is that relevant in any way?
20:12:29 <frakturfreak> Bilanzrichtline-Umsetzung-Gesetz
20:13:30 <chf> Ach, das ist gar nicht englisch, ja das kenne ich, aber nicht, wenn Du es KLEIN schreibst.
20:13:51 <frakturfreak> Entschuldige bitte
20:14:20 <chf> Let's rant at a more general level: look at their current president; they just CAN'T do any better!
20:17:39 <frakturfreak> and with definition of turnover I mean Umsatzerlöse, which now include also rents and leases for a e.g. a normal merchant. Needly blowing up this number and making it more vague. Also another example of it is the removal of the „außerordentliche“ parts, just because THEY can’t understand the world
20:18:39 <frakturfreak> chf: If it weren’t so bad for the country, at least he sometimes gives something to laugh about.
20:19:43 <chf> I see, might be due to accountants generally not being able to transgress their horizon.
20:20:21 <chf> They even don't complain about prejudice, seeing me writing this here!
20:22:29 <frakturfreak> Also for the turnover definition change I’ve just read, that it lead to more difference to US GAAP and IRFS.
20:23:44 <frakturfreak> https://www.roedl.de/themen/bilrug/aenderungen-guv-durch-bilrug
20:24:13 <chf> OK, let's convince the developers to make a reform of account types NOW.
20:26:06 <frakturfreak> creditor protection ftw!
20:29:37 <frakturfreak> Also their philosophy leads to a much higher equity. Wait a minute I think I remember something.
20:30:42 <frakturfreak> also Vorsichtsprinzip > Fair view
20:31:10 <frakturfreak> https://www.elitenetzwerk.bayern.de/elitenetzwerk-home/forschungsarbeiten/geistes-und-sozialwissenschaften/2009/vogler-rechnungslegungsstandards/
20:34:40 <frakturfreak> I could punch the author for the last section. Since when is US-GAAP synonymous to modern? These are also around for quite a long time.
20:35:39 <chf> Oh, yes, american style: bragging with high equity; european style: avoid taxes by negative equity… business dumbness in action!
20:37:03 <frakturfreak> chf: Maybe we’ll get account types required by the hgb as result of the recent threads.
20:37:41 <frakturfreak> chf: I work for a tax advisory company, so I like the Europan approach ;-).
20:38:29 <chf> The author seems to be a BAVARIAN, frakturfreak. This sounding almost like "barbarian" in english is obviously no coincidence.
20:40:40 <chf> BTW, you are distracting me from watching "The Aliens" in the background, famous british TV science fiction series featuring racism as its main theme. Obviously NOZ made by the "brexit" majority… <sigh>…
20:40:58 <chf> NOT
20:41:10 <chf> typing disability
20:42:17 <frakturfreak> It would help to advertise my alternative keyboard layout then … Have fun watching
20:44:33 <chf> This here seems more important in the long run.
20:47:36 <chf> There is obviously a problem: european style is documented mainly NOT in english, while the brits have spread their style to english dominated countries, where no tradition of learning foreign languages exists due to "everyone" speaking english.
20:58:01 <frakturfreak> In another fundamental part of accounting language the british and americans have developed differently: Journal entries, once the also used by/to as aquivalent to the German (per)/an or italian per/a in journal entries. However some time over the 19th and 20th century the changed to explicitly stating debit and credit instead. Not very speech economic using 4 syllables instead of just 1 or 2.
21:00:55 <chf> jralls: we NEED to overwork the account types to adapt Gnucash to european (and possibly other) style accounting. That is no negligible minor difference, it prevents our accountants from considering to use Gnucash in eben small business environments, because circumventing the occuring problems is only possible for IT, not accounting experts.
21:01:14 <chf> WVEN
21:01:17 <chf> EVEN
21:01:43 <chf> typing disability continued…
21:01:57 <frakturfreak> https://archive.org/stream/studiesinhistory00litt#page/222/mode/2up At least 1956 Brits look like they still used by and to.
21:05:35 <jralls> chf: Vast amounts of work on GnuCash over the years by Europeans like fell, cstim, and gjanssens and you're yelling at me because they haven't created the requisite account type?
21:07:08 <jralls> I didn't see anything from the document that frakturfreak shared yesterday that couldn't be done in GnuCash now except providing a Passiv total.
21:07:57 <jralls> Which you could do by copying and pasting a balance sheet report into a spreadsheet and adding the row and a single cell.
21:08:05 <chf> We're not yelling at you; it simply has never been discussed appropriately, so there's no progress in this regard.
21:08:33 <frakturfreak> The current the two modules thread is very long.
21:08:54 <chf> Of course, you CAN do everything with Gnucash + spreadsheet, but that's not the point.
21:10:06 <chf> As of now, it's difficult enough for the average EU accountant to not consider Gnucash as fit for the job.
21:11:05 <frakturfreak> Well at some point or another you’ll run into having to use a spreadsheet due a missing fixed assets/deprecation module.
21:11:44 <chf> Gnucassh in the EU plays in the league of "MS Money" despite of being BY SEVERAL ORDERS OF MAGNITUDE MORE POWERFUL.
21:11:58 <jralls> frakturfreak: It's not hard to do by hand. I did that for a rental property I managed a few years ago.
21:12:44 <frakturfreak> Also before I go to bed I just wanted to remember about my pet peeve bug of not being able to add files to transactions generated by the business module due them bing write-protected.
21:14:33 <frakturfreak> jralls: I know it’s not really that heard. But the point is why do it externally if it could be done with-in gnucash with the ability to use similar features like the invoice module.
21:14:40 <frakturfreak> * hard
21:14:45 <frakturfreak> Good night!
21:14:56 <chf> Good night!
21:15:06 <jralls> Good night, frakturfreak.
21:15:47 *** fell_laptop has joined #gnucash
21:17:43 *** fell has quit IRC
21:18:01 *** oozer has quit IRC
21:20:17 <frakturfreak> also as mentioned numerous the handling of cash-based VAT is a bit cumbersome and the usage of input VAT outside the business module even more. In Germany the standard approach for this is the usage of automatic accounts and special account-number prefixes to select the appropriate vat acounts.
21:21:42 <frakturfreak> That’s a real reason why small EU enterprises might not use gnucash.
21:22:58 <warlord> jralls: there are 259 bugs with delta_ts = null.
21:23:25 <warlord> Those are the 259 warnings we got earlier!
21:24:02 <frakturfreak> Can’t the tax tables be used for that or are they to much ingrained in the business transactions. Just a thought
21:24:51 <jralls> warlord: Hah! Fortunately, easy to select and fix.
21:24:51 <warlord> jralls: updated (but needed "IS NULL", not "= NULL")
21:24:57 <warlord> jralls: indeed.
21:25:09 <jralls> Right. I mess that up about every third time.
21:25:20 <jralls> Anyway, I'm summoned for dinner.
21:26:16 <warlord> jralls: FYI, that Browse extension is *part* of what fell is asking for.
21:26:34 <warlord> But it will need to be ported to BZ5, and need to be extracted from the other Gnome Extensions that we are NOT running...
21:26:42 <warlord> And... I still need to find browse.cgi
21:27:28 <warlord> (I found one for 3.x -- need to find a 4.x and then port it to 5.x)
21:39:21 *** RASSRQ has quit IRC
22:10:45 *** badger92 has quit IRC
22:40:48 *** g5pw has quit IRC
22:42:49 *** g5pw has joined #gnucash
23:09:18 *** kael has joined #gnucash
23:45:55 *** kael has quit IRC
23:58:14 <chris> dumped all loaded reports reportguid/section/name - 1025 rows to process