Re: [GNC-dev] GnuCash 4.13 Released

[Fross, Michael]

Well said Adrien.  I've yet to use OSS with a better or more helpful team
behind it.  Kudos to all of the devs.

Michael

On Mon, Dec 19, 2022 at 12:38 PM Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> A big Thanks! to the dev team, and congrats on the release.
>
> Of the many pieces of OSS I use, I'm the most impressed with the speed
> and professional attitude of the devs addressing any and all issues, not
> to mention their seemingly infinite patience with new users (and a few
> of us old hats) when we don't understand or misunderstand how the app
> works.
>
> Regards,
> Adrien
>
> On 12/18/22 5:07 PM, John Ralls wrote:
> > The GnuCash development team announces GnuCash 4.13, the fourteenth
> release in the stable 4.x series
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] GnuCash Windows Bundle 4.11-1 Released

[Fross, Michael]

Looks good on this end John.  Thank you very much!

Michael

On Sat, Jul 2, 2022 at 4:40 PM Gyle McCollam  wrote:

> John, Thanks to you and all involved with keeping this programing going.
>
>
> Thank You,
>
> Gyle McCollam
>
> Gyle McCollam
>
> gmccol...@live.com   email
>
> 
> From: gnucash-user  on
> behalf of John Ralls 
> Sent: Saturday, July 2, 2022 4:33 PM
> To: gnucash-annou...@lists.gnucash.org  >
> Cc: gnucash-devel ; Gnucash Users <
> gnucash-u...@gnucash.org>
> Subject: [GNC] GnuCash Windows Bundle 4.11-1 Released
>
> This fixes https://bugs.gnucash.org/show_bug.cgi?id=798559, Online
> Actions missing from menus.
>
> It restores File>Import>MT940 and other SWIFT formats, Actions>Online
> Actions, and Tools>Online Banking Setup.
>
> 63d98c5873e58191cbac5c6ba4f269528c67911d0d63e2dd114e2f1c12c328a7
> gnucash-4.11-1.setup.exe
>
> Downloads:
> https://code.gnucash.org/builds/win32/releases/gnucash-4.11-1.setup.exe
>
> https://downloads.sourceforge.net/gnucash/gnucash%20%28stable%29/4.11/gnucash-4.11-1.setup.exe
>
> https://github.com/Gnucash/gnucash/releases/download/4.11/gnucash-4.11-1.setup.exe
>
> Regards,
> John Ralls
>
> ___
> gnucash-user mailing list
> gnucash-u...@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
> ___
> gnucash-user mailing list
> gnucash-u...@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Multi-account actions

[Fross, Michael]

Hi John. If I can go to 10 transactions and change them 1 by 1, what’s the
difference if can be iterated through, making the same change in each? I
must be missing something.

I’m not a gnucash dev, but thought I would ask as I like Jean’s idea.

Michael

On Sun, Aug 30, 2020 at 10:40 PM John Ralls  wrote:

>
>
>
>
> > On Aug 30, 2020, at 10:32 AM, jean laroche  wrote:
>
> >
>
> > Devs,
>
> >
>
> > I have 2 PRs that I submitted for multi-account actions.
>
> > With these PRs, the user can select multiple accounts in the main
> account view, then:
>
> > - Delete multiple accounts in one shot,
>
> > - Edit multiple accounts in one shot (change the notes, the flags, the
> color, the currency, or move them to a different parent).
>
> >
>
> > I also want to add a "duplicate" action where the user can duplicate the
> selected account(s).
>
> >
>
> > All this of course isn't very useful if you already have your account
> tree and you never change it. But it's very useful, in my view if you need
> to setup your account tree or if you regularly need to add accounts.
>
> > Also, it's part of an effort to make GC more user friendly, offering
> features that are common in nearly all software (select multiple, then do
> something).
>
> >
>
> > I'm afraid that these PR will just be ignored, because some of the devs
> just don't look favorably upon them (John for example).
>
> >
>
> > I'd like to ask devs to chime in on that. My argument is that
>
> > - It makes the user's life easier.
>
> > - It adds a feature to GC that is expected in most software (of any
> kind), select multiple then do something.
>
> >
>
>
>
> I don't have a problem with cosmetic changes like colors, notes, or names.
> Anything like currency or parents that can affect the accounting logic
> shouldn't be permitted unless all of the accounts have no splits. IOW the
> use case you proposed on the PR, shuffling things around when setting up a
> book, is fine. Doing any of that after creating splits can change the
> meaning of the splits and can't be permitted.
>
>
>
> GnuCash is not like "all other software". Just because spreadsheets let
> you jump off the bridge doesn't mean that GnuCash should. ;-)
>
>
>
> Regards,
>
> John Ralls
>
>
>
> ___
>
> gnucash-devel mailing list
>
> gnucash-devel@gnucash.org
>
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Patelco stopped supporting OFX... other options

[Fross, Michael]

Thanks Jean for this...might be a great resource for all of us.  It would
be nice to not have to leverage a webserver on the client side and just
call the API.  Is that possible?  Might be a lot simpler.  Then the only
real task is converting to OFX or CSV.

Michael

On Thu, Jun 18, 2020 at 10:46 AM jean laroche  wrote:

> Well, I tested plaid last night. https://plaid.com/pricing
> It worked without a hitch with my bank (Patelco). It works like this:
> - You create an account with plaid and get API keys.
> - Do this once:
> Using python (in my case, but there are other options) you run a local
> web server on your machine (code provided by plaid) which you can then
> go to using a browser. Using this server you log into your bank and get
> an *access token *for that bank. In my case that required two factor
> authentication (password then an email or text to my phone). I believe
> getting the access_token is a one-time thing, but I'm not sure how long
> that access_token remains valid.
> - Back into python, you can make a one line call to the plaid api
> *client.Transactions.get() *passing the access token, start and end
> date, and you get a python dictionary that includes all your accounts at
> that bank, and all the transactions for all accounts between these two
> dates.
>
> In my case, the response was lightning fast and the data seemed right.
> The output returned is a dictionary, so in order to send that to GC,
> you'd need to save that as an OFX or some other format that can be
> imported, which will require a tiny bit of python code.
>
> Apparently, according to plaid's web site, the free API keys allow you
> to have 100 "items", where an item is a "set of credentials at a
> financial institution". The way I read this is you can have up to 100
> simultaneous banks associated with your API keys. That should be more
> than enough!
>
> The way it works, if I'm not mistaken, plaid downloads the data from the
> bank on a regular basis (even if you don't do anything) and when you
> call the API, you don't connect to your bank, but rather you get the
> data that plaid holds. The data includes account numbers, etc, so this
> means that this data is now on plaid's servers, and some of you guys may
> not like that one bit.
> Also, one thing I don't know is how long the access_token is valid for.
> I reused the one I got last night this morning, and it worked. I have to
> guess that the access token remains valid for a while.
>
> So it seems to me that this would be a viable solution for me.
> Jean
>
>
> On 6/16/2020 8:08 PM, John Ralls wrote:
> >
> >> On Jun 16, 2020, at 2:23 PM, Jean Laroche  wrote:
> >>
> >> People,
> >> In the past week, my credit union (Patelco) retired their OFX server
> which means it's no longer possible to download transactions using OFX. You
> can still do it manually by logging into your account etc, but it's no
> longer possible to use tools like ofxclient, ofxget and probably aqbank as
> they all rely on the same data.
> >> I've contacted them and asked them to reconsider but I'm not holding my
> breath.
> >> So my question is: What alternative is there?
> >> Are there 3rd party tools, aggregation services that can gather the
> transactions, from which it's possible to download into GC?
> >>
> >> At the moment, I'm using selenium (a tool to automate your browser) to
> do the various clicks required to download my transactions, but that's very
> fragile...
> >> Of course, I can also switch bank.
> > Jean,
> >
> >  From
> https://www.patelco.org/-/media/patelco/pdfs/member-support/digital-banking-services/express-web-connect_windows.pdf
> it looks like they switched to OFX Web Connect. Unfortunately that's been
> the trend for the last 10 years, and I imagine that it's an easy sell to
> the banks considering the weak security offered by OFX Direct Connect. That
> also means that switching banks is at best a short-term solution because of
> that trend: The new bank is likely to do the same thing sooner or later.
> >
> > I think the only really feasible workaround is to reverse-engineer the
> Web Connect authentication. That would mean installing Quicken and setting
> up and using OFX Web Connect while monitoring the traffic with wireshark.
> https://redflagsecurity.net/2019/03/10/decrypting-tls-wireshark/ might be
> helpful for decrypting the authentication traffic with the browser. No
> doubt the quicken connection will also be encrypted so you'll need to find
> the keys for that too to be able to interpret the traffic--and working out
> the key exchange between Quicken and the bank will also be necessary.
> Frankly I would expect a low probability of success without help from a
> crypto expert.
> >
> > Regards,
> > John Ralls
> >
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list

Re: [GNC-dev] Feedback on GnuCash 3.903

[Fross, Michael]

Hello David T.,

I understand the point.  But I also struggle with having a lot of security
accounts and I'm always having to go tweak them.  If I could set it once
and it would apply to them all, I applaud the decision.  I think it boils
down to how the account types are defined.

Michael

On Fri, Jun 5, 2020 at 9:05 AM D via gnucash-devel <
gnucash-devel@gnucash.org> wrote:

> Bob,
>
> I still don't understand fully. Are you saying that if I set my column
> widths differently for Stock A and Stock B, and then close both and reopen
> them both, that they will open with a set of arbitrarily-defined default
> widths for that account type, rather than the account-specific settings I'd
> chosen previously?
>
> If that is so, I'd say that the decision that "was made" was a bad one.
>
> To take one example, my mortgage and my credit card are both liability
> accounts. The balances in the two accounts are going to be significantly
> different, however, and I'd prefer to have different widths for the balance
> column. It sounds like I'd be out of luck in this new regime, yes?
>
> I'm not clear what benefit this provides on the back end. Could you
> explain these reasons more clearly?
>
> Thanks,
> David T.
>
> On Jun 5, 2020, 06:41, at 06:41, Robert Fewell <14ubo...@gmail.com> wrote:
> >David,
> >
> >It was decided that instead of every time you open a register and then
> >change that layout to your liking we could just save the widths to be
> >used
> >as defaults for the 6 register layouts. As most registers of type will
> >have
> >similar widths set, the first one loaded will be used to set the
> >default
> >widths for that type which you can obviously change and save for future
> >opening of that type of register. To accommodate situations like you
> >have
> >described, register widths of all open registers when Gnucash is closed
> >will also be saved and used when restoring. Should any of them be
> >closed
> >and reopened then they will base the widths on the saved default for
> >that
> >register type.
> >Hope that answers your question.
> >
> >On Fri, 5 Jun 2020 at 11:12, David H  wrote:
> >
> >> Rob,
> >>
> >> Please clarify this.  I have 2 savings accounts and 4 credit card
> >accounts
> >> that I have open all the time and over the years I've gone to the
> >trouble
> >> of setting these up just the way I like them.  Of course flicking
> >through
> >> the register tabs the columns aren't all in the same places as I'm
> >using
> >> accounts with different nesting levels in each so the Transfer column
> >> widths vary even within each account type.  Are you saying that these
> >would
> >> be treated as 2 register types and you are going to blow away all my
> >good
> >> work and just randomly choose one of the open settings as the default
> >when
> >> you remove old configurations?
> >>
> >> Thanks David H.
> >>
> >>
> >> On Fri, 5 Jun 2020 at 19:05, Robert Fewell <14ubo...@gmail.com>
> >wrote:
> >>
> >>> Mark,
> >>> Yes the saving of column widths has changed, in version 4.0 they are
> >saved
> >>> per register type so you only have to set the defaults once per type
> >>> instead of every single register opened, there are menu options
> >under
> >>> 'Windows' that allow you to save new register widths or clear them.
> >Open
> >>> registers also save their widths and therefore can have temporarily
> >>> changed
> >>> widths.
> >>>
> >>> What should happen is when a register is opened with a saved
> >configuration
> >>> and no default has been saved for that type, that configuration will
> >be
> >>> used as the default. Once there is a default for the register type,
> >all
> >>> old
> >>> configurations will be removed. Did this not happen?
> >>>
> >>> On Fri, 5 Jun 2020 at 04:58, Christopher Lam
> >
> >>> wrote:
> >>>
> >>> > The balance sheet date option does not transfer because old
> >balance
> >>> sheet
> >>> > uses "Balance Sheet Date" whereas upgraded one uses "End Date". I
> >am not
> >>> > sure it is practical to set up a compatibility pathway -- new
> >balance
> >>> sheet
> >>> > can report multiple dates.
> >>> >
> >>> > On Fri, 5 Jun 2020, 7:27 am mark sattolo, 
> >wrote:
> >>> >
> >>> > > Yes, that makes sense. I did some more digging around, and not
> >all my
> >>> > > custom column widths were changed, just those for any of the
> >accounts
> >>> > that
> >>> > > I actually opened while using version 3.903. Which happened to
> >be
> >>> quite a
> >>> > > few as I was testing various transactions, etc.
> >>> > >
> >>> > >
> >>> > > *Mark Sattolo*
> >>> > > *mh.sa...@gmail.com *
> >>> > >
> >>> > >
> >>> > >
> >>> > > On Thu, Jun 4, 2020 at 7:15 PM D.  wrote:
> >>> > >
> >>> > > > Mark,
> >>> > > >
> >>> > > > If that's true, I imagine it's a mistake. At least I hope so!
> >I
> >>> trust
> >>> > the
> >>> > > > devs will fix it, since I'd be pretty upset to have to reset
> >column
> >>> > > widths
> >>> > > > on all my accounts...
> >>> > > >
> >>> > > > David
> >>> > > >
> >>> > > >
> >>> > > > 

Re: [GNC-dev] AppImage

[Fross, Michael]

Hello Derek,

Is the goal to have a Flatpak image be part of the standard release
process?  By this I mean to say, will there be a Flatpak build released
with the windows and mac builds upon a new release?

I think that would be a great addition and help ease a lot of the build
challenges Linux users go through with each release.

Michael

On Fri, Jan 11, 2019 at 11:34 AM Derek Atkins  wrote:

> For the record, we are working on getting a Flatpak build done locally.
> It's on my to-do to set up a "nightly" build.
> -derek
>
> cicko  writes:
>
> > Someone actually created an AppImage repo for GnuCash at
> > https://github.com/ecmu/gnucash.AppImage
> >
> > It seems pretty fresh. The release available there is 3.4. The title says
> > "Continuous Build", and it builds to the latest (.tar.gz) released
> sources.
> > It looks a bit funny, probably minor GTK issues. It crashed once on
> opening
> > the sqlite database so beware. But, in any case, it's there! :)
> >
> >
> >
> >
> > --
> > 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
> >
> >
>
> --
>Derek Atkins 617-623-3745
>de...@ihtfp.com www.ihtfp.com
>Computer and Internet Security Consultant
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel