Thanks for the reminder. I'm sorry nobody came around to give more feedback.
I'll look into this the next days.
However, AFAIK your patch introduces new strings. Unfortunately we are
currently in string freeze for another few weeks until 2.4.0 is out. After
that, you patch can go into SVN right
Hi all, I'd appreciate it if someone would take the time to review and
respond to my previous message. I've reattached the patches for your
convenience.
On Sat, Aug 21, 2010 at 11:21 PM, Simon Ruggier wrote:
> Hey all, I finally finished implementing everything I mentioned back
> in early 2009, e
Hey all, I finally finished implementing everything I mentioned back
in early 2009, except the KvpFrame stuff. It's been hard to find time
to work on this, and the KvpFrame issue isn't really any more of a
problem as a result of my changes, so I think I will draw the line
here. I ended up making au
On Wed, Feb 11, 2009 at 1:20 AM, David Reiser wrote:
> Sorry for my screw-up. And thank you very much for taking the time to track
> down these bugs.
No problem, and I appreciate that you took the time to test my patch.
As mentioned before, I do intend to make the following changes when I
get th
[snip]
Are you sure that the first deposit gets reassigned in the case
where
it is a manual deposit? The matching code clearly attempts to avoid
matching transactions that were manually set (in import-backend.c
at
gnc_import_TransInfo_refresh_destacc).
>>>
>>> Yes,
On Feb 8, 2009, at 10:13 PM, Simon Ruggier wrote:
> On Sun, Feb 8, 2009 at 7:40 PM, David Reiser
> wrote:
>>
>> On Feb 8, 2009, at 6:07 PM, Simon Ruggier wrote:
>>
>>> On Sun, Feb 8, 2009 at 3:51 PM, David Reiser
>>>
>>> wrote:
This patch has some nasty side effects. It tries to c
On Sun, Feb 8, 2009 at 7:40 PM, David Reiser wrote:
>
> On Feb 8, 2009, at 6:07 PM, Simon Ruggier wrote:
>
>> On Sun, Feb 8, 2009 at 3:51 PM, David Reiser
>> wrote:
>>>
>>> This patch has some nasty side effects. It tries to change assigned
>>> target
>>> accounts on the fly within a single impor
On Feb 8, 2009, at 6:07 PM, Simon Ruggier wrote:
> On Sun, Feb 8, 2009 at 3:51 PM, David Reiser
> wrote:
>> This patch has some nasty side effects. It tries to change assigned
>> target
>> accounts on the fly within a single import. If I have several ATM
>> deposits
>> in one import, most
On Sun, Feb 8, 2009 at 3:51 PM, David Reiser wrote:
> This patch has some nasty side effects. It tries to change assigned target
> accounts on the fly within a single import. If I have several ATM deposits
> in one import, most of them will come up assigned to the last assignment
> from a prior im
On Feb 8, 2009, at 3:20 AM, Simon Ruggier wrote:
> Hi, see the attached patch. This repairs the ability for the
> transaction import dialog to retry automatches for each transaction
> being imported.
>
> Simon
> <0002-Repair-
> automatch_store_transactions
> .patch>_
] Repair automatch_store_transactions
The automatch_store_transactions function seems to have been broken in the
process of being ported from GtkCList to GtkTreeModel APIs. This change
restores it to the intended behaviour of retrying an automatch for every row
in the GtkTreeModel.
---
src/import
11 matches
Mail list logo
