I just did. Eight to be exact.
I think that only the patch for the book merge contains some
workarounds. Also the params that I have added might not be what you had
in mind.
The gncAddress one is a very good candidate to make it into 2.0.
Derek Atkins wrote:
Please definitely send in the bug fixes.
As for the new functionality, I think that attaching the patch(es)
to a bug report (or set of reports) is the right approach.
Personally, I'd rather see something get done "right", because
at this point it's NOT going into 2.0 so you certainly have a few
months to get the work done. ;)
And yes, the code DEFINITELY has a lot of issues... :(
-derek
Georgi Mirchev <[EMAIL PROTECTED]> writes:
I do understand your point of view, but my idea is to get results out of
the door. Doing everything right will be a lot of work, and I'm not
prepared to do it all. At least not now.
The current code has a lot of things implemented, and with several bug
fixes and with 50-100 additional lines of code I achieved the following:
1. import of gncCustomer, gncAddress, gncInvoice, gncEntry and Account
2. referencing between the the imported objects so that all of them are
connected - i.e. the addresses belong to customers, the entries belong
to invoices, the owner of the invoice is a customer and each entry
references an account
The referencing between imported and target book is not complete, so all
of these have to be imported in one file. But it WORKS.
I'm preparing patches now, in case someone finds the code useful. If you
choose not to import all patches, you can import only the bug fixes and
the correct code, and leave the code that is some kind of hack out. Thus
it could be at least partially integrated into gnucash.
The code really has a lot of issues, and is far from ready, so this
really is a distraction for 2.0. Thus I'll submit some entries in the
bugzilla with the patches attached, so that they can be handled after
2.0 is out of the door.
Derek Atkins wrote:
Georgi Mirchev <[EMAIL PROTECTED]> writes:
It turned out that I just can't use the same parameter for the
invoices. The "owner" param returns gncOwner object, and is used by
the rest of GnuCash, so nothing can be changed here.
Instead I added "owner-qof" that is of type QOF_TYPE_CHOICE, and
works with entities. It works fine with customers, and will work
fine with the other 3 objects that can be owners of an invoice. The
import of customers/addresses works fine now.
I still don't think that's the right answer... I have no objection to
changing the definition of a GncOwner (although you DEFINITELY need to
be careful about how it's done, because if done "incorrectly" it will
take a LOT of effort to change the code everywhere where it assumes it
knows how a GncOwner is implemented).
I'm working on the collections now, so that I can import the
invoice entries. In order to get any entries in, I had to add a
kludge. The QOF iterates over all parameters of the imported
object, calling their getters and trying to determine the
time. Guess what happens when the getter doesn't actually return an
entity, like in the case of parameter that is of type gncOwner. So
the QOF book merger code now checks specifically for
"gncOwner". Kludge, but works. Unless we add additional param flag
"has QofInstance", so that it is compatible with QOF, or we add
dummy QofInstance to gncOwner, I can't see how to resolve that.
... and this is DEFINITELY not the right answer. We shouldn't
special-case anything inside QOF.
There is an issue that seems to be a little more complex. During
the merge of two books the entries from the first are "copied" into
the second, then the first book and it's entries are destroyed. The
problem is that the "copy" often is just pointer copy. The reason
is that although we have clone functions in the gnc objects, the
QofObject doesn't specify a 'clone' callback, so QOF cannot clone
any objects. I think this needs to be added, so that QOF can safely
clone an object whenever needed.
What do you think?
I think, as Chris said, that these APIs are only half baked and really
require a lot of thought and effort to make work correctly. I would
recommend you sit back and come up with a reasonable design before you
jump head-first into coding it up. come up with a page or two
describing how you think it should work. Be detailed, but not
loquatious.
Once you have a design we can talk about the merits, work that out,
and then you're welcome to go full-bore into it.
Keep in mind that we're really trying to get 2.0 out the door, so
don't expect many cycles on something like this which really is a 2.0
distraction.
-derek
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
begin:vcard
fn:Georgi Mirchev
n:Mirchev;Georgi
org:Mirchev Ideas Ltd.
adr:;;Golash 18;Sofia;;1111;Bulgaria
email;internet:[EMAIL PROTECTED]
title:Manager
tel;work:+359-2-8705566
tel;cell:+359-888-518932
note;quoted-printable:Services:=0D=0A=
=0D=0A=
Software development=0D=0A=
Web development=0D=0A=
Web design=0D=0A=
Intranet solutions=0D=0A=
Consulting services=0D=0A=
Application security=0D=0A=
Hosting solutions=0D=0A=
Software outsourcing=0D=0A=
url:http://www.mirchevideas.com/
version:2.1
end:vcard
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
