[GNC] Bulk Operations on

[Jim DeLaHunt]

Ulrich:

Thank you for your reply.

On 2025-01-28 01:29, Ulrich Schwardmann via gnucash-user wrote:
> Dear Jim, all
>
> sorry for my inaccurateness here. Of course not the accounting
> application gnucash itself was meant....

Good! I am glad that is cleared up.


> I was instead refering to the gnucash python module that also is called
> just gnucash and which was the basis of gnucash-fiximports.py. As far as
> I can see this gnucash python module is not supported anymore and its
> features are newly implemented in a more pythonic, but python-gnucash
> compatible way in piecash. ...

This python module called "gnucash" might be the official Python 
bindings built into the GnuCash source code:

  * Chapter 17. "Python Bindings", in the GnuCash Tutorial and Guide
    <https://gnucash.org/docs/v5/C/gnucash-guide/ch_python_bindings.html>
  * "Python bindings" developer documentation,
    <https://code.gnucash.org/docs/STABLE/python_bindings_page.html>
  * "Python Bindings" in the GnuCash wiki,
    <https://wiki.gnucash.org/wiki/Python_Bindings>

This module is indeed supported, in the sense that the GnuCash source 
code continues to include it, and when built properly it continues to 
function with the current version of the GnuCash application. It is not 
included in most pre-built GnuCash installers distributed by the GnuCash 
project. It is included with some GnuCash distributions, including for 
example the MacPorts distribution of GnuCash 
<https://ports.macports.org/port/gnucash/details/>. I use that the 
`gnucash` Python module from that distribution.

This module is not supported, in the sense that the GnuCash project does 
not have a way of supporting people trying to use these bindings beyond 
response to questions in the GnuCash email lists -- but you are getting 
support that way, and I have got support in the past, so it does 
happen.  This module is also not actively developed, in the sense that 
(as far as I can see) the current GnuCash developers are choosing to 
devote their energies to other parts of the project.  I might at some 
point contribute some improvements, based on what the Python bindings 
currently make difficult for me.


> ...Regarding your invitation 'to write a bulk edit feature for the 
> GnuCash
> app': I just entered this list a day before and only occasionally saw
> some discussion about this topic. Perhaps you allow a viewpoint from a
> user of the software, as I am. ...

Welcome to GnuCash. Your viewpoint as a user is very welcome.

However, when I read,

>> ... the importance of this
>> feature so we might have a formal solution that we can put into the
>> document section. Gnucash cuts into the prosumer market where users do
>> need such "advanced" features. ...
I interpret, "the GnuCash project should have a formal solution but it 
doesn't, and the contributors to the project are making a mistake by not 
delivering this formal solution for the prosumer market instead of 
whatever else it is they are doing".

It is one thing to point out a shortcoming in a project which makes your 
use of it more difficult. It is quite another thing to have an 
expectation that you are entitled to someone else contributing work to 
fix that shortcoming.


>
> Any bulk edit feature needs some kind of rules on which decisions can be
> made - either as static dependencies or via some kind of bayesian
> filter. I prefer self defined rules, but in any case from my point of
> view it makes sense to keep this part out of the business of the kernel
> application.
>
> I actually find it somehow reassuring to have a well defined import
> interface like QIF import into some imbalance account. Then, always
> based on this well defined status before, an additional rule based
> structure and process can organizes the transactions in a way that is
> appropriate to the needs of the specific accounts. For me it is not so
> much a problem but more a feature to have two separate steps for this.
> My two cents.

Yes, this is a good example of feedback about "this is what works for me 
and what is missing for me", without including any sense of expectation 
that the project should change direction to fix that.

Best regards,
       —Jim DeLaHunt