[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fix for "Edit Account" -> Save action loosing GIFI
- Subject: Fix for "Edit Account" -> Save action loosing GIFI
- From: Erik Huelsmann <..hidden..>
- Date: Sun, 29 May 2011 13:16:41 +0200
While writing the mail below, I tried something different and found
that the problem isn't in the LSMB 'account save' code, but in the
parameter mapping between Perl and PostgreSQL code. Rather, the
'account_save' function has an incorrectly named argument, which
prevents it from being set correctly.
I left the original mail at the bottom, because it may help others to
find out what the call graph in LSMB "new code" is in general.
This patch fixes the issue at hand:
Index: sql/modules/Account.sql
===================================================================
--- sql/modules/Account.sql (revision 3186)
+++ sql/modules/Account.sql (working copy)
@@ -54,7 +54,7 @@
CREATE OR REPLACE FUNCTION account_save
(in_id int, in_accno text, in_description text, in_category char(1),
-in_gifi text, in_heading int, in_contra bool, in_link text[])
+in_gifi_accno text, in_heading int, in_contra bool, in_link text[])
RETURNS int AS $$
DECLARE
t_heading_id int;
@@ -89,7 +89,7 @@
SET accno = in_accno,
description = in_description,
category = in_category,
- gifi_accno = in_gifi,
+ gifi_accno = in_gifi_accno,
heading = t_heading_id,
contra = in_contra
WHERE id = in_id;
Bye,
Erik.
As a simple introduction into the code base, I'm trying to fix what I
think ought to be a simple issue: The "Edit Account" screen looses any
GIFI account number, even if it's already filled in when entering the
screen.
So, this is what I found out so far regarding the call-graph that's
being executed (oh, btw, from what I found, I concluded this is "new
code"):
The "Save" action triggers a form POST request
The post request is received by 'account.pl'
which forwards the request to 'scripts/account.pl' via
'lsmb-request.pl', calling its "save" method.
the 'save' method calls the 'account_save' stored procedure defined in
sql/modules/Account.sql
lsmb-request.pl creates an LedgerSMB object to represent the request.
later on (or so it seems), scripts/account.pl creates an
LedgerSMB::DBObject::Account object from the LedgerSMB request object
I checked to see that the gifi data is actually saved in the call to
'account_save'. Which seems logical, because if it wasn't saved, the
GIFI data probably wouldn't have been lost :-)
So, it seems the gifi data is lost somewhere in the process.