ck-ledger-users Mailing List for CK-Ledger (Page 5)
Status: Beta
Brought to you by:
ckwu
Menu
▾
▴
ck-ledger-users — Mailing list and discussion group for CK-Ledger Users
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
(18) |
Mar
(3) |
Apr
(6) |
May
(19) |
Jun
(8) |
Jul
(10) |
Aug
(10) |
Sep
(17) |
Oct
(10) |
Nov
(8) |
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(15) |
Feb
(9) |
Mar
(16) |
Apr
(7) |
May
(5) |
Jun
(1) |
Jul
(6) |
Aug
(8) |
Sep
(42) |
Oct
(8) |
Nov
(22) |
Dec
(3) |
| 2004 |
Jan
(14) |
Feb
(8) |
Mar
(8) |
Apr
(1) |
May
(2) |
Jun
|
Jul
(13) |
Aug
(4) |
Sep
(6) |
Oct
(5) |
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: C K Wu <ck...@ho...> - 2003-09-28 00:30:18
|
Derrick Lo ??: >Hi CK, > >Thanks for your quick response. I have already done Pt2 before encountering >the error: >Admin/Setup -> 1 - Setup Data Tables >Admin/Setup -> 2 - Build Chart -> Default Chart >Admin/Setup -> 3 - Create Test Data >Play around with the various features. If stuck, >Admin/Setup -> 4 - Delete all Data and repeat the process >*Default data and COA were setup properly. > >I discovered that this Database error not only occurs in CK-Ledger, but >also in ALL modules. > Yes. It would. Since it's a change in the internal API. All modules that are not in sync with such change, will encounter the same problem. > >This urlencode/decode problem that you mentioned in Pt 1, is it easily >solved (or by-passed), or do you recommend re-install with phpgroupware >0.9.14.006? > > No. it's not easily by-passed. The best bet is to re-install phpgw 0.9.14.006 if you are eager to test out phpgw along with its various add-on modules. Since phpgw 0.9.16 is a major upgrade, there may yet be other teething problems waiting to be discovered. >I believe CK-Ledger have huge potential, and because it is built on top of >a groupware, is able to extend functions easily. Also look at new JiNN >function that came with the eGroupWare installation, though don't know how >to use it yet. > > I like to add a word of caution here. Since eGroupWare is a fork resulting from internal argument amongst phpgroupware project team members, it is expected that pretty soon phpgroupware and eGroupWare will divert in their development path, you may like to choose carefully which platform to invest your time and effort. I have yet to decide for myself whether to ensure CK-Ledger is compatible to future release of eGroupWare. Cheers, CK >Thanks, >Derrick > >--- C K Wu <ck...@ho...> wrote: > > >>Hi Derrick, >> >>Thank you for checking out CK-Ledger. >> >>There are probably two things that you have to watch out for, >> >>a) The '+WHERE+1%3D1+' that you saw in the error message is >>most likely caused by a recent change in phpgroupware's api. >>AFAIK, eGroupWare is a fork of the most recent version of phpgroupware, >>so eGroupWare/CK-Ledger will probably suffer from the same problem >>exhibited by phpgw/CK-Ledger. If you look through the postings to >>ck-...@li... during this month, you'll see a lot >>of discussion on the urlencode/decode problem, which is the source of the >>error that you encounter. Bottom line is CK-Ledger v.0.7.1 will only >>work properly with phpgroupware 0.9.14.006. However, the next >>release of CK-Ledger should work nicely with phpgw 0.9.16RC1 and >>by corollary, eGroupWare. But, I am afraid the next release of CK-Ledger >>is not quite there yet. >> >>b) After successful installation of CK-Ledger and before doing >>any testing, you have to build the default data tables. At the >>index page of any CK-Ledger module and some way down the >>User/Administrator column, it reads, "The best way to study >>LedgerAdmin is to follow the steps: ......." >> >>Follow the steps listed and the default data tables will be created. >> >>Cheers, >>CK >> >>Derrick Lo ??: >> >> >> >>>Hi, >>> >>>I have just installed eGroupWare-0.9.99.004-0.tar.gz and >>>ck-ledger-0.7.1.tar.gz. Things look fine, was able to create default >>> >>> >>users >> >> >>>and login to CK. >>> >>>However, when I tried CK-Ledger -> Ledger A/Cs, and click "Start Search" >>> >>> >>to >> >> >>>view all accounts, I got this error: >>> >>>"Database error: Invalid SQL: SELECT * from gl +WHERE+1%3D1+ order by >>>transdate ASC >>>MySQL Error: 1064 (You have an error in your SQL syntax. Check the >>> >>> >>manual >> >> >>>that corresponds to your MySQL server version for the right syntax to >>> >>> >>use >> >> >>>near '+WHERE+1%3D1+ order by transdate ASC' at line 1) >>> >>>Session halted. " >>> >>>Did anyone encounter this? How do you solve this? Is there any >>> >>> >>Bugs/Tracker >> >> >>>page for CK? >>> >>>Many Thanks and have a good week-end! >>>Derrick >>> >>> >>>__________________________________ >>>Do you Yahoo!? >>>The New Yahoo! Shopping - with improved product search >>>http://shopping.yahoo.com >>> >>> >>>------------------------------------------------------- >>>This sf.net email is sponsored by:ThinkGeek >>>Welcome to geek heaven. >>>http://thinkgeek.com/sf >>>_______________________________________________ >>>CK-Ledger-users mailing list >>>CK-...@li... >>>https://lists.sourceforge.net/lists/listinfo/ck-ledger-users >>> >>> > > >__________________________________ >Do you Yahoo!? >The New Yahoo! Shopping - with improved product search >http://shopping.yahoo.com > > > > |
|
From: C K Wu <ck...@ho...> - 2003-09-27 18:41:12
|
Hi Derrick, Thank you for checking out CK-Ledger. There are probably two things that you have to watch out for, a) The '+WHERE+1%3D1+' that you saw in the error message is most likely caused by a recent change in phpgroupware's api. AFAIK, eGroupWare is a fork of the most recent version of phpgroupware, so eGroupWare/CK-Ledger will probably suffer from the same problem exhibited by phpgw/CK-Ledger. If you look through the postings to ck-...@li... during this month, you'll see a lot of discussion on the urlencode/decode problem, which is the source of the error that you encounter. Bottom line is CK-Ledger v.0.7.1 will only work properly with phpgroupware 0.9.14.006. However, the next release of CK-Ledger should work nicely with phpgw 0.9.16RC1 and by corollary, eGroupWare. But, I am afraid the next release of CK-Ledger is not quite there yet. b) After successful installation of CK-Ledger and before doing any testing, you have to build the default data tables. At the index page of any CK-Ledger module and some way down the User/Administrator column, it reads, "The best way to study LedgerAdmin is to follow the steps: ......." Follow the steps listed and the default data tables will be created. Cheers, CK Derrick Lo ??: >Hi, > >I have just installed eGroupWare-0.9.99.004-0.tar.gz and >ck-ledger-0.7.1.tar.gz. Things look fine, was able to create default users >and login to CK. > >However, when I tried CK-Ledger -> Ledger A/Cs, and click "Start Search" to >view all accounts, I got this error: > >"Database error: Invalid SQL: SELECT * from gl +WHERE+1%3D1+ order by >transdate ASC >MySQL Error: 1064 (You have an error in your SQL syntax. Check the manual >that corresponds to your MySQL server version for the right syntax to use >near '+WHERE+1%3D1+ order by transdate ASC' at line 1) > >Session halted. " > >Did anyone encounter this? How do you solve this? Is there any Bugs/Tracker >page for CK? > >Many Thanks and have a good week-end! >Derrick > > >__________________________________ >Do you Yahoo!? >The New Yahoo! Shopping - with improved product search >http://shopping.yahoo.com > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >CK-Ledger-users mailing list >CK-...@li... >https://lists.sourceforge.net/lists/listinfo/ck-ledger-users > > > > |
|
From: Derrick Lo <hy...@ya...> - 2003-09-27 14:46:37
|
Hi CK, Thanks for your quick response. I have already done Pt2 before encountering the error: Admin/Setup -> 1 - Setup Data Tables Admin/Setup -> 2 - Build Chart -> Default Chart Admin/Setup -> 3 - Create Test Data Play around with the various features. If stuck, Admin/Setup -> 4 - Delete all Data and repeat the process *Default data and COA were setup properly. I discovered that this Database error not only occurs in CK-Ledger, but also in ALL modules. This urlencode/decode problem that you mentioned in Pt 1, is it easily solved (or by-passed), or do you recommend re-install with phpgroupware 0.9.14.006? I believe CK-Ledger have huge potential, and because it is built on top of a groupware, is able to extend functions easily. Also look at new JiNN function that came with the eGroupWare installation, though don't know how to use it yet. Thanks, Derrick --- C K Wu <ck...@ho...> wrote: > Hi Derrick, > > Thank you for checking out CK-Ledger. > > There are probably two things that you have to watch out for, > > a) The '+WHERE+1%3D1+' that you saw in the error message is > most likely caused by a recent change in phpgroupware's api. > AFAIK, eGroupWare is a fork of the most recent version of phpgroupware, > so eGroupWare/CK-Ledger will probably suffer from the same problem > exhibited by phpgw/CK-Ledger. If you look through the postings to > ck-...@li... during this month, you'll see a lot > of discussion on the urlencode/decode problem, which is the source of the > error that you encounter. Bottom line is CK-Ledger v.0.7.1 will only > work properly with phpgroupware 0.9.14.006. However, the next > release of CK-Ledger should work nicely with phpgw 0.9.16RC1 and > by corollary, eGroupWare. But, I am afraid the next release of CK-Ledger > is not quite there yet. > > b) After successful installation of CK-Ledger and before doing > any testing, you have to build the default data tables. At the > index page of any CK-Ledger module and some way down the > User/Administrator column, it reads, "The best way to study > LedgerAdmin is to follow the steps: ......." > > Follow the steps listed and the default data tables will be created. > > Cheers, > CK > > Derrick Lo ??: > > >Hi, > > > >I have just installed eGroupWare-0.9.99.004-0.tar.gz and > >ck-ledger-0.7.1.tar.gz. Things look fine, was able to create default > users > >and login to CK. > > > >However, when I tried CK-Ledger -> Ledger A/Cs, and click "Start Search" > to > >view all accounts, I got this error: > > > >"Database error: Invalid SQL: SELECT * from gl +WHERE+1%3D1+ order by > >transdate ASC > >MySQL Error: 1064 (You have an error in your SQL syntax. Check the > manual > >that corresponds to your MySQL server version for the right syntax to > use > >near '+WHERE+1%3D1+ order by transdate ASC' at line 1) > > > >Session halted. " > > > >Did anyone encounter this? How do you solve this? Is there any > Bugs/Tracker > >page for CK? > > > >Many Thanks and have a good week-end! > >Derrick > > > > > >__________________________________ > >Do you Yahoo!? > >The New Yahoo! Shopping - with improved product search > >http://shopping.yahoo.com > > > > > >------------------------------------------------------- > >This sf.net email is sponsored by:ThinkGeek > >Welcome to geek heaven. > >http://thinkgeek.com/sf > >_______________________________________________ > >CK-Ledger-users mailing list > >CK-...@li... > >https://lists.sourceforge.net/lists/listinfo/ck-ledger-users __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |
|
From: Derrick Lo <hy...@ya...> - 2003-09-27 11:12:29
|
Hi, I have just installed eGroupWare-0.9.99.004-0.tar.gz and ck-ledger-0.7.1.tar.gz. Things look fine, was able to create default users and login to CK. However, when I tried CK-Ledger -> Ledger A/Cs, and click "Start Search" to view all accounts, I got this error: "Database error: Invalid SQL: SELECT * from gl +WHERE+1%3D1+ order by transdate ASC MySQL Error: 1064 (You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '+WHERE+1%3D1+ order by transdate ASC' at line 1) Session halted. " Did anyone encounter this? How do you solve this? Is there any Bugs/Tracker page for CK? Many Thanks and have a good week-end! Derrick __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |
|
From: C K Wu <ck...@ho...> - 2003-09-25 14:10:57
|
Hello, folks, I have finally tested all 15 modules of CK-Ledger and the preliminary test result is that other than the urlencode/decode problem, all functions work as usual. I have also updated CK-Ledger's distribution codebase to get around the urlencode/decode problem. So, be rest assured the next release of CK-Ledger will work nicely with phpgw 0.9.16RC1. My immediate next challenge is to implement the multi-currency features that Marc, Robert and I had discussed a while back and to slot in the various features that were requested during the past few months. As to the other major questions, a) whether to integrate with phpgw's new contact backend b) whether to maintain interoperability with eGroupWare These are major strategic design questions that need very detail and careful study. I'll try to provide further information at a later stage. However, in the mean time, your input is most welcome. Cheers, CK |
|
From: C K Wu <ck...@ho...> - 2003-09-25 13:44:21
|
Hello, Folks, My ISP finally pulls itself out of the blackhole, and I am back to the old email address, ck...@ho... . Cheers, CK |
|
From: Dave H. <dav...@mb...> - 2003-09-22 05:42:39
|
C=3D20K=3D20Wu =3Cchiukay2000=40yahoo=2Ecom=2Ehk=3E wrote=3A =3E Hi Dave=2C =3E = =3E I hate to be a pest=2E No you are not a pest=2E I think this thread will provide some good adivce for other developers=2E =3E = =3E However=2C I think phpgwapi=27s nextmatchs class is =3E actually passing get values as =3E =22arg1=3Dval1=26arg2=3Dval2=26=2E=2E=22 =2E =3E = Yeah=2C not everything is done as it should be in phpGroupWare=2E The li= nk method is designed so =24extravars can be an array or a string=2C but for= it to function properly is =24extravars should be an array=2E = =3E In =2E=2E=2E/phpgwapi/inc/class=2Enextmatchs=2Einc=2Ephp=2C =3E = =3E From line 744=2C within function show=5Fsort=5Forder=2C it =3E reads=2C =3E = =3E if (is=5Farray(=24extra)) =3E =7B =3E =24extra =3D =24this-=3Eextras=5Fto=5Fstring(=24extra)=3B =3E =7D =3E = =3E =24extravar =3D =3E =27order=3D=27=2E=24var=2E=27=26sort=3D=27=2E=24sort=2E=27=26filter=3D=27= =2E=24filter=2E=27=26qfield=3D=27=2E=24qfield=2E=27=26start=3D=27=2E=24st= art=2E=27=26query=3D=27=2Eurlencode(stripslashes(=24GLOBALS=5B=27query=27= =5D))=2E=24extra=3B =3E = =3E =24link =3D =3E (=24this-=3Eaction=3F=24this-=3Epage(=24extravar)=3A=24GLOBALS=5B=27p= hpgw=27=5D- =3E =3Elink(=24program=2C=24extravar))=3B =3E = =3E If I read it correctly=2C it actually turns =24extra into =3E a string if it is an array=2E Again=2C =24filter and =24query =3E are probably most exposed to the =27=3D=27 and =27=26=27 problems =3E that we=27ve discussed=2E Ok that looks like it is creating a lot of work=2C which doesn=27t need t= o be done=2E =3E = =3E To clarify further=2C I have done a =22grep -R =27link(=27 *=22 =3E on the phpgwapi folder=2E It shows that a lot of calls =3E to =24GLOBALS=5B=27phpgw=27=5D-=3Elink() are actually passing =3E extra get values as =22arg=3Dval=22 strings=2E They don=27t =3E show up as problem only because no non-alphanumeric =3E data is involved=2E However=2C there may yet be other =3E nextmatchs-=3Eshow=5Fsort=5Forder=27s lurking behind the =3E scene=2E =3E = =3E Because show=5Fsort=5Forder is the primary function to =3E allow retrieved info to be re-sorted=2C I am going back =3E to double urlencode/decode=2E =3E = =3E I would suggest that a detail review of phpgwapi is =3E needed to ensure the change in session =24extravar =3E handling is not creating hidden bugs waiting to be =3E discovered=2E Yeah=2C we will check it=2C and alter the behavoir of the offending calls= =2E =3E = =3E Cheers=2C =3E CK =3E = =3E = =3E --- Dave Hall =3Cdave=2Ehall=40mbox=2Ecom=2Eau=3E =3A =3E = =3E C K Wu =3Cchiukay2000=40yahoo=2Ecom=2Ehk=3E wrote=3A =3E =3E = =3E =3E =3E Hi=2C Dave=2C =3E =3E =3E = =3E =3E =3E Thank you for spotting the security flaw=2E I=27ll =3E =3E =3E certainly tighten up security further=2E = =3E =3E = =3E =3E No problem=2E Good to hear =3A) =3E =3E = =3E =3E =3E At the same =3E =3E =3E time=2C =27=3D=27 within the GET value string is a general =3E =3E =3E problem=2E Any unstructured GET value string has =3E =3E the =3E =3E =3E potential of including a =27=3D=27 char=2C thus causing =3E =3E =3E problem to the callee script=2E Actually=2C this =27=3D=27 =3E =3E =3E problem could easily be rectified=2E Instead of a =3E =3E =3E general =27split=27=2C class=2Esessions=2Einc=2Ephp could =3E =3E simply =3E =3E =3E pick on the 1st =27=3D=27 char and assign the pre-=27=3D=27 =3E =3E string =3E =3E =3E to GET arg and the post-=27=3D=27 string to GET value=2E = =3E =3E =3E However=2C the =27=26=27 char could be much more =3E =3E difficult=2E A =3E =3E =3E double urlencode/decode seems to be the easiest =3E =3E =3E solution=2E =3E =3E =3E = =3E =3E =3E Any thoughts =3F =3E =3E = =3E =3E Pass the =24extravars arg of the link() method an =3E =3E array=2C not a string=2E = =3E =3E That is how it is designed to be used=2E So then =3D =3E =3E and =26 are properly =3E =3E encoded=2C along with all other values=2E I this is a =3E =3E little bit of work=2C =3E =3E but it will make it run faster=2C as no explode()ing =3E =3E is done on the =3E =3E =24extravars variable within the link() method=2C it =3E =3E just url=5Fencode()s it=2E =3E =3E = =3E =3E Hope this helps =3E =3E = =3E =3E Cheers =3E =3E = =3E =3E Dave =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F =3E =B3=CC=B7s=B9a=C1n=B1=C0=A4=B6=3A=B9J=A8=A3=A1A=B6=C3=A5=40=A8=CE=A4H= =A1A=B0=B2=A6p=B7R=A6=B3=A4=D1=B7N=2E=2E=2E =3E http=3A//ringtone=2Eyahoo=2Ecom=2Ehk =3E = =3E |
|
From: <chi...@ya...> - 2003-09-22 04:44:44
|
Hi Dave,
I hate to be a pest.
However, I think phpgwapi's nextmatchs class is
actually passing get values as
"arg1=val1&arg2=val2&.." .
In .../phpgwapi/inc/class.nextmatchs.inc.php,
From line 744, within function show_sort_order, it
reads,
if (is_array($extra))
{
$extra = $this->extras_to_string($extra);
}
$extravar =
'order='.$var.'&sort='.$sort.'&filter='.$filter.'&qfield='.$qfield.'&start='.$start.'&query='.urlencode(stripslashes($GLOBALS['query'])).$extra;
$link =
($this->action?$this->page($extravar):$GLOBALS['phpgw']->link($program,$extravar));
If I read it correctly, it actually turns $extra into
a string if it is an array. Again, $filter and $query
are probably most exposed to the '=' and '&' problems
that we've discussed.
To clarify further, I have done a "grep -R 'link(' *"
on the phpgwapi folder. It shows that a lot of calls
to $GLOBALS['phpgw']->link() are actually passing
extra get values as "arg=val" strings. They don't
show up as problem only because no non-alphanumeric
data is involved. However, there may yet be other
nextmatchs->show_sort_order's lurking behind the
scene.
Because show_sort_order is the primary function to
allow retrieved info to be re-sorted, I am going back
to double urlencode/decode.
I would suggest that a detail review of phpgwapi is
needed to ensure the change in session $extravar
handling is not creating hidden bugs waiting to be
discovered.
Cheers,
CK
--- Dave Hall <dav...@mb...> :
C K Wu <chi...@ya...> wrote:
>
> > Hi, Dave,
> >
> > Thank you for spotting the security flaw. I'll
> > certainly tighten up security further.
>
> No problem. Good to hear :)
>
> > At the same
> > time, '=' within the GET value string is a general
> > problem. Any unstructured GET value string has
> the
> > potential of including a '=' char, thus causing
> > problem to the callee script. Actually, this '='
> > problem could easily be rectified. Instead of a
> > general 'split', class.sessions.inc.php could
> simply
> > pick on the 1st '=' char and assign the pre-'='
> string
> > to GET arg and the post-'=' string to GET value.
> > However, the '&' char could be much more
> difficult. A
> > double urlencode/decode seems to be the easiest
> > solution.
> >
> > Any thoughts ?
>
> Pass the $extravars arg of the link() method an
> array, not a string.
> That is how it is designed to be used. So then =
> and & are properly
> encoded, along with all other values. I this is a
> little bit of work,
> but it will make it run faster, as no explode()ing
> is done on the
> $extravars variable within the link() method, it
> just url_encode()s it.
>
> Hope this helps
>
> Cheers
>
> Dave
_________________________________________________________
最新鈴聲推介:遇見，亂世佳人，假如愛有天意...
http://ringtone.yahoo.com.hk
|
|
From: Dave H. <dav...@mb...> - 2003-09-19 19:57:12
|
C=3D20K=3D20Wu =3Cchiukay2000=40yahoo=2Ecom=2Ehk=3E wrote=3A =3E Hi=2C Dave=2C =3E = =3E Thank you for spotting the security flaw=2E I=27ll =3E certainly tighten up security further=2E = No problem=2E Good to hear =3A) =3E At the same =3E time=2C =27=3D=27 within the GET value string is a general =3E problem=2E Any unstructured GET value string has the =3E potential of including a =27=3D=27 char=2C thus causing =3E problem to the callee script=2E Actually=2C this =27=3D=27 =3E problem could easily be rectified=2E Instead of a =3E general =27split=27=2C class=2Esessions=2Einc=2Ephp could simply =3E pick on the 1st =27=3D=27 char and assign the pre-=27=3D=27 string =3E to GET arg and the post-=27=3D=27 string to GET value=2E = =3E However=2C the =27=26=27 char could be much more difficult=2E A =3E double urlencode/decode seems to be the easiest =3E solution=2E =3E = =3E Any thoughts =3F Pass the =24extravars arg of the link() method an array=2C not a string=2E= = That is how it is designed to be used=2E So then =3D and =26 are properl= y encoded=2C along with all other values=2E I this is a little bit of work= =2C but it will make it run faster=2C as no explode()ing is done on the =24extravars variable within the link() method=2C it just url=5Fencode()s= it=2E Hope this helps Cheers Dave =3E = =3E Cheers=2C =3E CK =3E = =3E = =3E Dave Hall =3A =3E = =3E =3EC K Wu =3Cchiukay2000=40yahoo=2Ecom=2Ehk=3E wrote=3A =3E =3E =3E =3E=3EHello=2C folks=2C =3E =3E=3E =3E =3E=3EMe again=2E There is some further complication with =3E the =3E =3E=3Eurlencode/decode thing=2E =3E =3E=3E =3E =3E=3EIn =2E=2E=2E/phpgwapi/inc/class=2Esessions=2Einc=2Ephp=2C aroun= d =3E =3E=3Eline 1145=2C the code reads=2C =3E =3E=3E =3E =3E=3E/* Now we process the extravars into a proper url =3E =3E=3Eformat */ =3E =3E=3E/* if its not an array=2C then we turn it into one */ =3E =3E=3E/* We do this to help prevent any duplicates from =3E =3E=3Ebeing sent=2E */ =3E =3E=3Eif (!is=5Farray(=24extravars) =26=26 =24extravars !=3D =27=27) =3E =3E=3E=7B =3E =3E=3E =24a =3D explode(=27=26=27=2C =24extravars)=3B =3E =3E=3E =24i =3D 0=3B =3E =3E=3E while (=24i =3C count(=24a)) =3E =3E=3E =7B =3E =3E=3E =24b =3D split(=27=3D=27=2C =24a=5B=24i=5D)=3B =3E =3E=3E =24new=5Fextravars=5B=24b=5B0=5D=5D =3D =24b=5B1=5D=3B =3E =3E=3E =24i++=3B =3E =3E=3E =7D =3E =3E=3E =24extravars =3D =24new=5Fextravars=3B =3E =3E=3E unset(=24new=5Fextravars)=3B =3E =3E=3E=7D =3E =3E=3E =3E =3E=3EApparently=2C =27=3D=27 is used as the GET argument/value =3E =3E=3Eseparator=2E However=2C if there is a second =27=3D=27 in =3E =3E=3E=24a=5B=24i=5D=2C the value part will be truncated=2E This is =3E the =3E =3E=3Ecase when an SQL is passed from script to script as =3E =3E=3EGET value=2E In my case=2C the raw GET string looks =3E like =3E =3E=3Ethis=2C =3E =3E=3E =3E =3E=3E=22filter=3D WHERE substring(source=2C1=2C2)=3D=27GD=27=22 =3E =3E=3E =3E =3E=3Eso the callee script only recovers =24filter as =22WHERE =3E =3E=3Esubstring(source=2C1=2C2)=22 =3E =3E =3E =3E =3E =3EHmmmm=2E I would argue that passing SQL via GET or =3E even POST is very poor =3E =3Esecurity=2C and so it is good that this breaks=2E Also =3E the =24extravars=2C as =3E =3Eshown in the code should be an array as it is faster =3E for process=2C no =3E =3Eexplode() needed =3A) =3E =3E =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F =3E =B3=CC=B7s=B9a=C1n=B1=C0=A4=B6=3A=B9J=A8=A3=A1A=B6=C3=A5=40=A8=CE=A4H= =A1A=B0=B2=A6p=B7R=A6=B3=A4=D1=B7N=2E=2E=2E =3E http=3A//ringtone=2Eyahoo=2Ecom=2Ehk =3E = =3E |
|
From: <chi...@ya...> - 2003-09-19 19:42:38
|
Hi, Dave, --- Dave Hall <dav...@mb...> ： > > Pass the $extravars arg of the link() method an > array, not a string. > That is how it is designed to be used. So then = > and & are properly > encoded, along with all other values. I this is a > little bit of work, > but it will make it run faster, as no explode()ing > is done on the > $extravars variable within the link() method, it > just url_encode()s it. > That's certainly a better way of doing it. Thanks. Well, got quite a bit of program modification work now, :-( . Cheers, CK _________________________________________________________ 最新鈴聲推介:遇見，亂世佳人，假如愛有天意... http://ringtone.yahoo.com.hk |
|
From: <chi...@ya...> - 2003-09-18 11:28:52
|
Hi, Dave,
Thank you for spotting the security flaw. I'll
certainly tighten up security further. At the same
time, '=' within the GET value string is a general
problem. Any unstructured GET value string has the
potential of including a '=' char, thus causing
problem to the callee script. Actually, this '='
problem could easily be rectified. Instead of a
general 'split', class.sessions.inc.php could simply
pick on the 1st '=' char and assign the pre-'=' string
to GET arg and the post-'=' string to GET value.
However, the '&' char could be much more difficult. A
double urlencode/decode seems to be the easiest
solution.
Any thoughts ?
Cheers,
CK
Dave Hall :
>C K Wu <chi...@ya...> wrote:
>
>>Hello, folks,
>>
>>Me again. There is some further complication with
the
>>urlencode/decode thing.
>>
>>In .../phpgwapi/inc/class.sessions.inc.php, around
>>line 1145, the code reads,
>>
>>/* Now we process the extravars into a proper url
>>format */
>>/* if its not an array, then we turn it into one */
>>/* We do this to help prevent any duplicates from
>>being sent. */
>>if (!is_array($extravars) && $extravars != '')
>>{
>> $a = explode('&', $extravars);
>> $i = 0;
>> while ($i < count($a))
>> {
>> $b = split('=', $a[$i]);
>> $new_extravars[$b[0]] = $b[1];
>> $i++;
>> }
>> $extravars = $new_extravars;
>> unset($new_extravars);
>>}
>>
>>Apparently, '=' is used as the GET argument/value
>>separator. However, if there is a second '=' in
>>$a[$i], the value part will be truncated. This is
the
>>case when an SQL is passed from script to script as
>>GET value. In my case, the raw GET string looks
like
>>this,
>>
>>"filter= WHERE substring(source,1,2)='GD'"
>>
>>so the callee script only recovers $filter as "WHERE
>>substring(source,1,2)"
>
>
>Hmmmm. I would argue that passing SQL via GET or
even POST is very poor
>security, and so it is good that this breaks. Also
the $extravars, as
>shown in the code should be an array as it is faster
for process, no
>explode() needed :)
>
_________________________________________________________
最新鈴聲推介:遇見，亂世佳人，假如愛有天意...
http://ringtone.yahoo.com.hk
|
|
From: Dave H. <dav...@mb...> - 2003-09-18 07:57:46
|
C=20K=20Wu <chi...@ya...> wrote:
> Hello, folks,
>
> Me again. There is some further complication with the
> urlencode/decode thing.
>
> In .../phpgwapi/inc/class.sessions.inc.php, around
> line 1145, the code reads,
>
> /* Now we process the extravars into a proper url
> format */
> /* if its not an array, then we turn it into one */
> /* We do this to help prevent any duplicates from
> being sent. */
> if (!is_array($extravars) && $extravars != '')
> {
> $a = explode('&', $extravars);
> $i = 0;
> while ($i < count($a))
> {
> $b = split('=', $a[$i]);
> $new_extravars[$b[0]] = $b[1];
> $i++;
> }
> $extravars = $new_extravars;
> unset($new_extravars);
> }
>
> Apparently, '=' is used as the GET argument/value
> separator. However, if there is a second '=' in
> $a[$i], the value part will be truncated. This is the
> case when an SQL is passed from script to script as
> GET value. In my case, the raw GET string looks like
> this,
>
> "filter= WHERE substring(source,1,2)='GD'"
>
> so the callee script only recovers $filter as "WHERE
> substring(source,1,2)"
Hmmmm. I would argue that passing SQL via GET or even POST is very poor
security, and so it is good that this breaks. Also the $extravars, as
shown in the code should be an array as it is faster for process, no
explode() needed :)
Without studying the CK Ledger code, anyone with access to the app,
could easily use mailicious SQL, for example by changing the URL from:
filter= WHERE substring(source,1,2)='GD'
to
?filter=WHERE+substring(source,1,2)='GD';+DROP+DATABASE+phpgroupware#
Note some (but not all) url_encode()ing is done
You should never send anything to the database without making sure it is
safe. All it takes is one line of compromised code in one compromised
app, and you whole phpgw install could be lost. As part of the 16
release we are removing a lot of these problems.
A safer way of handling the example above would be:
//Code Snippet for app/caller.php
$get_args = array( 'sub_start' => 1,
'sub_end' => 2,
'sub_field' => 'source',
'filter_val' => 'GD'
);
$url = $GLOBALS['phpgw']->link('/app/script.php', $get_args);
//Code Snippet for app/script.php
....
//some get_var var assignments here
....
$sql = 'SELECT * FROM phpgw_app_tbl ';
$sql .= 'WHERE substring(' . $this->db->db_addslashes($sub_field) .','
intval($sub_start) . ',' . intval($sub_end) . ")="' .
$this->db->db_addslashes($filter_val) . "'";
I know this is a little messy, it is designed to be an example. The
easiest way to do this casting/escaping is when assigning the values
using get_var(), just wrap the call in the appropriate function. This
may look like it is adding a lot of extra work to creating a query, but
really it must be done for every variable. Best place to do it is in
the so layer.
I hope this makes sense, if not ask questions and I will try to explain
it a little more.
Cheers
Dave
<snip />
> I am not sure if '&' may similarly be a problem. I'll
> leave it to the sessions maintainer to check it out
> and perhaps rectify the situation. Again, this
> problem will affect other addon scripts.
>
> Cheers,
> CK
>
> --- Dave Hall <dav...@mb...>:
> Hey CK,
> >
> > C=20K=20Wu <chi...@ya...> wrote:
> >
> > > Hello, Dave,
> > >
> > > I think I've found what's going on.
> > >
> > > With 0.9.14.006,
> > >
> > > ../phpgwapi/inc/class.sessions_php4.inc.php (line
> > 951)
> > > and ../phpgwapi/inc/class.sessions_db.inc.php
> > (line
> > > 977) read,
> > >
> > > $new_extravars .= "$key=$value" ;
> > >
> > > With 0.9.16RC1,
> > >
> > > ../phpgwapi/inc/class.sessions.inc.php (line 1194)
> > > reads,
> > >
> > > $new_extravars .= $key.'='.urlencode($value) ;
> > >
> > > So, apparently, with earlier versions, it is the
> > > application script's responsibility to url_encode
> > GET
> > > variables before sending it on. However, with
> > > 0.9.16RC1, the sessions facility handles the
> > > url_encode-ing when it receives the GET variables
> > from
> > > the application script.
> > >
> > > With CK-Ledger v.0.7.1 running against phpgw
> > > 0.9.16RC1, it means double url_encoding and
> > therefore
> > > the callee scripts need to url_decode the GET
> > variable
> > > one more time to recover the correct value.
> > >
> > > I think this will break a lot of the addon module
> > > codes. However, if the GET variable passed
> > contains
> > > pure alphanumeric chars, no error will be
> > detected,
> > > since urlencode/urldecode in these cases do not
> > alter
> > > the GET variables. So, there may be quite a fair
> > bit
> > > of spurious 0.9.16RC1 errors being the result of
> > the
> > > above.
> >
> > Ok, now I follow what is going on. I didn't make
> > this change, but I can
> > understand (and agree with) the logic behind it.
> > This is my logic with
> > it, others may disaagree, it is easier to url_encode
> > the variables, once
> > in the api, than each app maintainer having to
> > remember to encode them.
> > It also means that if we ever have to do anything
> > else to the GET args
> > it can be changed once in the API and all apps
> > automatically get the
> > benefit.
> >
> > I understand this will cause some problems with CK
> > Ledger, this is
> > unfortunate, but I doubt the change will be backed
> > out. As will all new
> > versions of the API there are changes. The 16 API
> > has quite a few
> > changes, some of which I think you app could benefit
> > from.
> >
> > I would suggest that you continue testing with the
> > 16RCs with regular
> > CVS updates, and keep in touch with us. I am
> > willing to assist you get
> > your app to run properly on 16. Please be aware
> > that I do not use CK
> > Ledger, but am happy to answer any questions you may
> > have.
> >
> > Cheers
> >
> > Dave
> >
> > >
> > > Cheers,
> > > CK
> > >
> > >
> > >
> > > Dave Hall:
> > >
> > > >CK Wu <chi...@ya...> wrote:
> > > >
> > > >>Hello, folks,
> > > >>
> > > >>While testing CK-Ledger v.0.7.1 against
> > > >>phpgroupware-0.9.16.RC1,
> > > >>I came across the following,
> > > >>
> > > >>When calling,
> > > >>
> > > >>
> > >
> >
>
>http://localhost/.../loglist.php?filter=%2BWHERE%2B1%253D1%2B&sessionid=...&kp3=...&domain=default&click_history=...
> > > >
> > > >Is this
> > >
> >
>
>http://localhost/phpgroupware/loglist.php?filter=%2BWHERE%2B1%253D1%2B&...
> > > >
> > > >or
> > > >
> > > >http://localhost/ck-
> > >
> > ledger/loglist.php?filter=%2BWHERE%2B1%253D1%2B&...>
> > > >Looking at that code ... there are several
> > problems
> > > ....
> > > >
> > > >firstly the $_POST/$_GET hack won't work with
> > > register_globals = off
> > > >
> > > >Also phpgroupware has never processed the
> > external
> > > variables, I think it
> > > >is a PHP problem. IIRC php will url_decode all
> > $_GET
> > > vars for you.
> > > >
> > > >Bit more info about where this code is will
> > probably
> > > help us track this
> > > >down.
> > > >
> > > >Cheers
> > > >
> > > >Dave
> > > >
|
|
From: <chi...@ya...> - 2003-09-18 06:35:37
|
Hello, folks,
Me again. There is some further complication with the
urlencode/decode thing.
In .../phpgwapi/inc/class.sessions.inc.php, around
line 1145, the code reads,
/* Now we process the extravars into a proper url
format */
/* if its not an array, then we turn it into one */
/* We do this to help prevent any duplicates from
being sent. */
if (!is_array($extravars) && $extravars != '')
{
$a = explode('&', $extravars);
$i = 0;
while ($i < count($a))
{
$b = split('=', $a[$i]);
$new_extravars[$b[0]] = $b[1];
$i++;
}
$extravars = $new_extravars;
unset($new_extravars);
}
Apparently, '=' is used as the GET argument/value
separator. However, if there is a second '=' in
$a[$i], the value part will be truncated. This is the
case when an SQL is passed from script to script as
GET value. In my case, the raw GET string looks like
this,
"filter= WHERE substring(source,1,2)='GD'"
so the callee script only recovers $filter as "WHERE
substring(source,1,2)"
At the moment, I get around the problem by doing
double encoding/decode, ie the calling script
urlencodes $filter (thus hiding the '='), hands the
GET string to sessions, and the callee script
urldecodes to recover the original $filter.
I am not sure if '&' may similarly be a problem. I'll
leave it to the sessions maintainer to check it out
and perhaps rectify the situation. Again, this
problem will affect other addon scripts.
Cheers,
CK
--- Dave Hall <dav...@mb...>:
Hey CK,
>
> C=20K=20Wu <chi...@ya...> wrote:
>
> > Hello, Dave,
> >
> > I think I've found what's going on.
> >
> > With 0.9.14.006,
> >
> > ../phpgwapi/inc/class.sessions_php4.inc.php (line
> 951)
> > and ../phpgwapi/inc/class.sessions_db.inc.php
> (line
> > 977) read,
> >
> > $new_extravars .= "$key=$value" ;
> >
> > With 0.9.16RC1,
> >
> > ../phpgwapi/inc/class.sessions.inc.php (line 1194)
> > reads,
> >
> > $new_extravars .= $key.'='.urlencode($value) ;
> >
> > So, apparently, with earlier versions, it is the
> > application script's responsibility to url_encode
> GET
> > variables before sending it on. However, with
> > 0.9.16RC1, the sessions facility handles the
> > url_encode-ing when it receives the GET variables
> from
> > the application script.
> >
> > With CK-Ledger v.0.7.1 running against phpgw
> > 0.9.16RC1, it means double url_encoding and
> therefore
> > the callee scripts need to url_decode the GET
> variable
> > one more time to recover the correct value.
> >
> > I think this will break a lot of the addon module
> > codes. However, if the GET variable passed
> contains
> > pure alphanumeric chars, no error will be
> detected,
> > since urlencode/urldecode in these cases do not
> alter
> > the GET variables. So, there may be quite a fair
> bit
> > of spurious 0.9.16RC1 errors being the result of
> the
> > above.
>
> Ok, now I follow what is going on. I didn't make
> this change, but I can
> understand (and agree with) the logic behind it.
> This is my logic with
> it, others may disaagree, it is easier to url_encode
> the variables, once
> in the api, than each app maintainer having to
> remember to encode them.
> It also means that if we ever have to do anything
> else to the GET args
> it can be changed once in the API and all apps
> automatically get the
> benefit.
>
> I understand this will cause some problems with CK
> Ledger, this is
> unfortunate, but I doubt the change will be backed
> out. As will all new
> versions of the API there are changes. The 16 API
> has quite a few
> changes, some of which I think you app could benefit
> from.
>
> I would suggest that you continue testing with the
> 16RCs with regular
> CVS updates, and keep in touch with us. I am
> willing to assist you get
> your app to run properly on 16. Please be aware
> that I do not use CK
> Ledger, but am happy to answer any questions you may
> have.
>
> Cheers
>
> Dave
>
> >
> > Cheers,
> > CK
> >
> >
> >
> > Dave Hall:
> >
> > >CK Wu <chi...@ya...> wrote:
> > >
> > >>Hello, folks,
> > >>
> > >>While testing CK-Ledger v.0.7.1 against
> > >>phpgroupware-0.9.16.RC1,
> > >>I came across the following,
> > >>
> > >>When calling,
> > >>
> > >>
> >
>
>http://localhost/.../loglist.php?filter=%2BWHERE%2B1%253D1%2B&sessionid=...&kp3=...&domain=default&click_history=...
> > >
> > >Is this
> >
>
>http://localhost/phpgroupware/loglist.php?filter=%2BWHERE%2B1%253D1%2B&...
> > >
> > >or
> > >
> > >http://localhost/ck-
> >
> ledger/loglist.php?filter=%2BWHERE%2B1%253D1%2B&...>
> > >Looking at that code ... there are several
> problems
> > ....
> > >
> > >firstly the $_POST/$_GET hack won't work with
> > register_globals = off
> > >
> > >Also phpgroupware has never processed the
> external
> > variables, I think it
> > >is a PHP problem. IIRC php will url_decode all
> $_GET
> > vars for you.
> > >
> > >Bit more info about where this code is will
> probably
> > help us track this
> > >down.
> > >
> > >Cheers
> > >
> > >Dave
> > >
> >
> >
> >
>
_________________________________________________________
> > 最新鈴聲推介:遇見，亂世佳人，假如愛有天意...
> > http://ringtone.yahoo.com.hk
> >
> >
> > begin:vcard
> n:Hall;Dave
> fn:Dave Hall
> tel;fax:+61 3 8610 0029
> tel;work:+61 3 96 871 871
> org:Dave Hall Consulting;
> adr:;;;;;;AUSTRALIA
> version:2.1
> email;internet:dav...@mb...
> end:vcard
>
>
_________________________________________________________
最新鈴聲推介:遇見，亂世佳人，假如愛有天意...
http://ringtone.yahoo.com.hk
|
|
From: <chi...@ya...> - 2003-09-18 05:58:50
|
Hi, Konstantinos, I haven't had time to examine the new phpgw addressbook setup, but will look at it pretty soon. I am still working on the urlencode/decode problem, there is some further complication. I'll be posting a new message to the phpgw-developer list on this shortly. Phpgw's translation tool is definitely ideal for producing translation for CK-Ledger. I use it myself to produce Chinese translation for CK-Ledger, so go for it. Btw, what language translation will you be working on ? If you don't mind, I could list your name as part of the translation team at CK-Ledger's demo site and incorporate your output (phpgw_??.lang files) into CK-Ledger's distribution codebase. Cheers, CK --- MarinBlu <cma...@ya...>: Hi CK, > > Are you using the addressbook from phpGW ? If not, > are > you consider to merge the new 16 backend ? > > Could I use the translation tool for CK-Ledger ? > > Thanks, > Konstantinos > _________________________________________________________ 最新鈴聲推介:遇見，亂世佳人，假如愛有天意... http://ringtone.yahoo.com.hk |
|
From: Dave H. <dav...@mb...> - 2003-09-17 21:19:42
|
C=3D20K=3D20Wu =3Cchiukay2000=40yahoo=2Ecom=2Ehk=3E wrote=3A =3E Hi=2C Dave=2C =3E = =3E Nah=2C I don=27t mean to nag the core team or the phpgw =3E leadership into backing out of the =2E16 API changes=2E = =3E My last email is actually to highlight to other addon =3E maintainers that there is this potential problem that =3E they have to deal with when they are preparing to =3E upgrade to 0=2E9=2E16RC1 =2E No problem=2E Sorry I misunderstood=2E I think other developers will appreciate the heads up=2E My offer of assisting you to get CK Ledger ready for 16 still stands =3A) Cheers Dave =3E = =3E Cheers=2C =3E CK =3E = =3E --- Dave Hall =A1G=3E =3E Hey CK=2C =3E =3E = =3E =3E C=3D20K=3D20Wu =3Cchiukay2000=40yahoo=2Ecom=2Ehk=3E wrote=3A =3E =3E = =3E =3E =3E Hello=2C Dave=2C =3E =3E =3E = =3E =3E =3E I think I=27ve found what=27s going on=2E =3E =3E =3E = =3E =3E =3E With 0=2E9=2E14=2E006=2C =3E =3E =3E = =3E =3E =3E =2E=2E/phpgwapi/inc/class=2Esessions=5Fphp4=2Einc=2Ephp (line= =3E =3E 951) =3E =3E =3E and =2E=2E/phpgwapi/inc/class=2Esessions=5Fdb=2Einc=2Ephp =3E =3E (line =3E =3E =3E 977) read=2C =3E =3E =3E = =3E =3E =3E =24new=5Fextravars =2E=3D =22=24key=3D=24value=22 =3B =3E =3E =3E = =3E =3E =3E With 0=2E9=2E16RC1=2C =3E =3E =3E = =3E =3E =3E =2E=2E/phpgwapi/inc/class=2Esessions=2Einc=2Ephp (line 1194) =3E =3E =3E reads=2C =3E =3E =3E = =3E =3E =3E =24new=5Fextravars =2E=3D =24key=2E=27=3D=27=2Eurlencode(=24v= alue) =3B =3E =3E =3E = =3E =3E =3E So=2C apparently=2C with earlier versions=2C it is the =3E =3E =3E application script=27s responsibility to url=5Fencode =3E =3E GET =3E =3E =3E variables before sending it on=2E However=2C with =3E =3E =3E 0=2E9=2E16RC1=2C the sessions facility handles the =3E =3E =3E url=5Fencode-ing when it receives the GET variables =3E =3E from =3E =3E =3E the application script=2E =3E =3E =3E = =3E =3E =3E With CK-Ledger v=2E0=2E7=2E1 running against phpgw =3E =3E =3E 0=2E9=2E16RC1=2C it means double url=5Fencoding and =3E =3E therefore =3E =3E =3E the callee scripts need to url=5Fdecode the GET =3E =3E variable =3E =3E =3E one more time to recover the correct value=2E =3E =3E =3E = =3E =3E =3E I think this will break a lot of the addon module =3E =3E =3E codes=2E However=2C if the GET variable passed =3E =3E contains =3E =3E =3E pure alphanumeric chars=2C no error will be =3E =3E detected=2C =3E =3E =3E since urlencode/urldecode in these cases do not =3E =3E alter =3E =3E =3E the GET variables=2E So=2C there may be quite a fair =3E =3E bit =3E =3E =3E of spurious 0=2E9=2E16RC1 errors being the result of =3E =3E the =3E =3E =3E above=2E =3E =3E = =3E =3E Ok=2C now I follow what is going on=2E I didn=27t make =3E =3E this change=2C but I can =3E =3E understand (and agree with) the logic behind it=2E = =3E =3E This is my logic with =3E =3E it=2C others may disaagree=2C it is easier to url=5Fencode =3E =3E the variables=2C once =3E =3E in the api=2C than each app maintainer having to =3E =3E remember to encode them=2E =3E =3E It also means that if we ever have to do anything =3E =3E else to the GET args =3E =3E it can be changed once in the API and all apps =3E =3E automatically get the =3E =3E benefit=2E =3E =3E = =3E =3E I understand this will cause some problems with CK =3E =3E Ledger=2C this is =3E =3E unfortunate=2C but I doubt the change will be backed =3E =3E out=2E As will all new =3E =3E versions of the API there are changes=2E The 16 API =3E =3E has quite a few =3E =3E changes=2C some of which I think you app could benefit =3E =3E from=2E = =3E =3E = =3E =3E I would suggest that you continue testing with the =3E =3E 16RCs with regular =3E =3E CVS updates=2C and keep in touch with us=2E I am =3E =3E willing to assist you get =3E =3E your app to run properly on 16=2E Please be aware =3E =3E that I do not use CK =3E =3E Ledger=2C but am happy to answer any questions you may =3E =3E have=2E =3E =3E = =3E =3E Cheers =3E =3E = =3E =3E Dave =3E =3E = =3E =3E =3E = =3E =3E =3E Cheers=2C =3E =3E =3E CK =3E =3E =3E = =3E =3E =3E = =3E =3E =3E = =3E =3E =3E Dave Hall=3A =3E =3E =3E = =3E =3E =3E =3ECK Wu =3Cchiukay2000=40yahoo=2Ecom=2Ehk=3E wrote=3A =3E =3E =3E =3E =3E =3E =3E =3E=3EHello=2C folks=2C =3E =3E =3E =3E=3E =3E =3E =3E =3E=3EWhile testing CK-Ledger v=2E0=2E7=2E1 against =3E =3E =3E =3E=3Ephpgroupware-0=2E9=2E16=2ERC1=2C =3E =3E =3E =3E=3EI came across the following=2C =3E =3E =3E =3E=3E =3E =3E =3E =3E=3EWhen calling=2C =3E =3E =3E =3E=3E =3E =3E =3E =3E=3E =3E =3E =3E =3E =3E =3E =3Ehttp=3A//localhost/=2E=2E=2E/loglist=2Ephp=3Ffilter=3D=252BWHERE=252B1= =25253D1=252B=26sessionid=3D=2E=2E=2E=26kp3=3D=2E=2E=2E=26domain=3Ddefaul= t=26click=5Fhistory=3D=2E=2E=2E =3E =3E =3E =3E =3E =3E =3E =3EIs this =3E =3E =3E =3E =3E =3E =3Ehttp=3A//localhost/phpgroupware/loglist=2Ephp=3Ffilter=3D=252BWHERE=25= 2B1=25253D1=252B=26=2E=2E=2E =3E =3E =3E =3E =3E =3E =3E =3Eor =3E =3E =3E =3E =3E =3E =3E =3Ehttp=3A//localhost/ck- =3E =3E =3E =3E =3E ledger/loglist=2Ephp=3Ffilter=3D=252BWHERE=252B1=25253D1=252B=26=2E= =2E=2E=3E =3E =3E =3E =3ELooking at that code =2E=2E=2E there are several =3E =3E problems =3E =3E =3E =2E=2E=2E=2E =3E =3E =3E =3E =3E =3E =3E =3Efirstly the =24=5FPOST/=24=5FGET hack won=27t work with =3E =3E =3E register=5Fglobals =3D off =3E =3E =3E =3E =3E =3E =3E =3EAlso phpgroupware has never processed the =3E =3E external =3E =3E =3E variables=2C I think it =3E =3E =3E =3Eis a PHP problem=2E IIRC php will url=5Fdecode all =3E =3E =24=5FGET =3E =3E =3E vars for you=2E =3E =3E =3E =3E =3E =3E =3E =3EBit more info about where this code is will =3E =3E probably =3E =3E =3E help us track this =3E =3E =3E =3Edown=2E =3E =3E =3E =3E =3E =3E =3E =3ECheers =3E =3E =3E =3E =3E =3E =3E =3EDave =3E =3E =3E =3E =3E =3E =3E = =3E =3E =3E = =3E =3E =3E =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F =3E =3E =3E =B3=CC=B7s=B9a=C1n=B1=C0=A4=B6=3A=B9J=A8=A3=A1A=B6=C3=A5=40=A8= =CE=A4H=A1A=B0=B2=A6p=B7R=A6=B3=A4=D1=B7N=2E=2E=2E =3E =3E =3E http=3A//ringtone=2Eyahoo=2Ecom=2Ehk =3E =3E =3E = =3E =3E =3E =3E =3E =3E begin=3Avcard =3E =3E n=3AHall=3BDave =3E =3E fn=3ADave Hall =3E =3E tel=3Bfax=3A+61 3 8610 0029 =3E =3E tel=3Bwork=3A+61 3 96 871 871 =3E =3E org=3ADave Hall Consulting=3B =3E =3E adr=3A=3B=3B=3B=3B=3B=3BAUSTRALIA =3E =3E version=3A2=2E1 =3E =3E email=3Binternet=3Adave=2Ehall=40mbox=2Ecom=2Eau =3E =3E end=3Avcard =3E =3E = =3E =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F =3E =B3=CC=B7s=B9a=C1n=B1=C0=A4=B6=3A=B9J=A8=A3=A1A=B6=C3=A5=40=A8=CE=A4H= =A1A=B0=B2=A6p=B7R=A6=B3=A4=D1=B7N=2E=2E=2E =3E http=3A//ringtone=2Eyahoo=2Ecom=2Ehk =3E = =3E |
|
From: <chi...@ya...> - 2003-09-17 07:55:14
|
Hi, Dave, Nah, I don't mean to nag the core team or the phpgw leadership into backing out of the .16 API changes. My last email is actually to highlight to other addon maintainers that there is this potential problem that they have to deal with when they are preparing to upgrade to 0.9.16RC1 . Cheers, CK --- Dave Hall ：> Hey CK, > > C=20K=20Wu <chi...@ya...> wrote: > > > Hello, Dave, > > > > I think I've found what's going on. > > > > With 0.9.14.006, > > > > ../phpgwapi/inc/class.sessions_php4.inc.php (line > 951) > > and ../phpgwapi/inc/class.sessions_db.inc.php > (line > > 977) read, > > > > $new_extravars .= "$key=$value" ; > > > > With 0.9.16RC1, > > > > ../phpgwapi/inc/class.sessions.inc.php (line 1194) > > reads, > > > > $new_extravars .= $key.'='.urlencode($value) ; > > > > So, apparently, with earlier versions, it is the > > application script's responsibility to url_encode > GET > > variables before sending it on. However, with > > 0.9.16RC1, the sessions facility handles the > > url_encode-ing when it receives the GET variables > from > > the application script. > > > > With CK-Ledger v.0.7.1 running against phpgw > > 0.9.16RC1, it means double url_encoding and > therefore > > the callee scripts need to url_decode the GET > variable > > one more time to recover the correct value. > > > > I think this will break a lot of the addon module > > codes. However, if the GET variable passed > contains > > pure alphanumeric chars, no error will be > detected, > > since urlencode/urldecode in these cases do not > alter > > the GET variables. So, there may be quite a fair > bit > > of spurious 0.9.16RC1 errors being the result of > the > > above. > > Ok, now I follow what is going on. I didn't make > this change, but I can > understand (and agree with) the logic behind it. > This is my logic with > it, others may disaagree, it is easier to url_encode > the variables, once > in the api, than each app maintainer having to > remember to encode them. > It also means that if we ever have to do anything > else to the GET args > it can be changed once in the API and all apps > automatically get the > benefit. > > I understand this will cause some problems with CK > Ledger, this is > unfortunate, but I doubt the change will be backed > out. As will all new > versions of the API there are changes. The 16 API > has quite a few > changes, some of which I think you app could benefit > from. > > I would suggest that you continue testing with the > 16RCs with regular > CVS updates, and keep in touch with us. I am > willing to assist you get > your app to run properly on 16. Please be aware > that I do not use CK > Ledger, but am happy to answer any questions you may > have. > > Cheers > > Dave > > > > > Cheers, > > CK > > > > > > > > Dave Hall: > > > > >CK Wu <chi...@ya...> wrote: > > > > > >>Hello, folks, > > >> > > >>While testing CK-Ledger v.0.7.1 against > > >>phpgroupware-0.9.16.RC1, > > >>I came across the following, > > >> > > >>When calling, > > >> > > >> > > > >http://localhost/.../loglist.php?filter=%2BWHERE%2B1%253D1%2B&sessionid=...&kp3=...&domain=default&click_history=... > > > > > >Is this > > > >http://localhost/phpgroupware/loglist.php?filter=%2BWHERE%2B1%253D1%2B&... > > > > > >or > > > > > >http://localhost/ck- > > > ledger/loglist.php?filter=%2BWHERE%2B1%253D1%2B&...> > > >Looking at that code ... there are several > problems > > .... > > > > > >firstly the $_POST/$_GET hack won't work with > > register_globals = off > > > > > >Also phpgroupware has never processed the > external > > variables, I think it > > >is a PHP problem. IIRC php will url_decode all > $_GET > > vars for you. > > > > > >Bit more info about where this code is will > probably > > help us track this > > >down. > > > > > >Cheers > > > > > >Dave > > > > > > > > > > _________________________________________________________ > > 最新鈴聲推介:遇見，亂世佳人，假如愛有天意... > > http://ringtone.yahoo.com.hk > > > > > > begin:vcard > n:Hall;Dave > fn:Dave Hall > tel;fax:+61 3 8610 0029 > tel;work:+61 3 96 871 871 > org:Dave Hall Consulting; > adr:;;;;;;AUSTRALIA > version:2.1 > email;internet:dav...@mb... > end:vcard > > _________________________________________________________ 最新鈴聲推介:遇見，亂世佳人，假如愛有天意... http://ringtone.yahoo.com.hk |
|
From: Dave H. <dav...@mb...> - 2003-09-17 05:19:26
|
Hey CK=2C C=3D20K=3D20Wu =3Cchiukay2000=40yahoo=2Ecom=2Ehk=3E wrote=3A =3E Hello=2C Dave=2C =3E = =3E I think I=27ve found what=27s going on=2E =3E = =3E With 0=2E9=2E14=2E006=2C =3E = =3E =2E=2E/phpgwapi/inc/class=2Esessions=5Fphp4=2Einc=2Ephp (line 951) =3E and =2E=2E/phpgwapi/inc/class=2Esessions=5Fdb=2Einc=2Ephp (line =3E 977) read=2C =3E = =3E =24new=5Fextravars =2E=3D =22=24key=3D=24value=22 =3B =3E = =3E With 0=2E9=2E16RC1=2C =3E = =3E =2E=2E/phpgwapi/inc/class=2Esessions=2Einc=2Ephp (line 1194) =3E reads=2C =3E = =3E =24new=5Fextravars =2E=3D =24key=2E=27=3D=27=2Eurlencode(=24value) =3B= =3E = =3E So=2C apparently=2C with earlier versions=2C it is the =3E application script=27s responsibility to url=5Fencode GET =3E variables before sending it on=2E However=2C with =3E 0=2E9=2E16RC1=2C the sessions facility handles the =3E url=5Fencode-ing when it receives the GET variables from =3E the application script=2E =3E = =3E With CK-Ledger v=2E0=2E7=2E1 running against phpgw =3E 0=2E9=2E16RC1=2C it means double url=5Fencoding and therefore =3E the callee scripts need to url=5Fdecode the GET variable =3E one more time to recover the correct value=2E =3E = =3E I think this will break a lot of the addon module =3E codes=2E However=2C if the GET variable passed contains =3E pure alphanumeric chars=2C no error will be detected=2C =3E since urlencode/urldecode in these cases do not alter =3E the GET variables=2E So=2C there may be quite a fair bit =3E of spurious 0=2E9=2E16RC1 errors being the result of the =3E above=2E Ok=2C now I follow what is going on=2E I didn=27t make this change=2C bu= t I can understand (and agree with) the logic behind it=2E This is my logic with= it=2C others may disaagree=2C it is easier to url=5Fencode the variables=2C= once in the api=2C than each app maintainer having to remember to encode them=2E= It also means that if we ever have to do anything else to the GET args it can be changed once in the API and all apps automatically get the benefit=2E I understand this will cause some problems with CK Ledger=2C this is unfortunate=2C but I doubt the change will be backed out=2E As will all = new versions of the API there are changes=2E The 16 API has quite a few changes=2C some of which I think you app could benefit from=2E = I would suggest that you continue testing with the 16RCs with regular CVS updates=2C and keep in touch with us=2E I am willing to assist you g= et your app to run properly on 16=2E Please be aware that I do not use CK Ledger=2C but am happy to answer any questions you may have=2E Cheers Dave =3E = =3E Cheers=2C =3E CK =3E = =3E = =3E = =3E Dave Hall=3A =3E = =3E =3ECK Wu =3Cchiukay2000=40yahoo=2Ecom=2Ehk=3E wrote=3A =3E =3E =3E =3E=3EHello=2C folks=2C =3E =3E=3E =3E =3E=3EWhile testing CK-Ledger v=2E0=2E7=2E1 against =3E =3E=3Ephpgroupware-0=2E9=2E16=2ERC1=2C =3E =3E=3EI came across the following=2C =3E =3E=3E =3E =3E=3EWhen calling=2C =3E =3E=3E =3E =3E=3E =3E =3Ehttp=3A//localhost/=2E=2E=2E/loglist=2Ephp=3Ffilter=3D=252BWHERE=252B1= =25253D1=252B=26sessionid=3D=2E=2E=2E=26kp3=3D=2E=2E=2E=26domain=3Ddefaul= t=26click=5Fhistory=3D=2E=2E=2E =3E =3E =3E =3EIs this =3E =3Ehttp=3A//localhost/phpgroupware/loglist=2Ephp=3Ffilter=3D=252BWHERE=25= 2B1=25253D1=252B=26=2E=2E=2E =3E =3E =3E =3Eor =3E =3E =3E =3Ehttp=3A//localhost/ck- =3E ledger/loglist=2Ephp=3Ffilter=3D=252BWHERE=252B1=25253D1=252B=26=2E=2E= =2E=3E =3E =3ELooking at that code =2E=2E=2E there are several problems =3E =2E=2E=2E=2E =3E =3E =3E =3Efirstly the =24=5FPOST/=24=5FGET hack won=27t work with =3E register=5Fglobals =3D off =3E =3E =3E =3EAlso phpgroupware has never processed the external =3E variables=2C I think it =3E =3Eis a PHP problem=2E IIRC php will url=5Fdecode all =24=5FGET =3E vars for you=2E =3E =3E =3E =3EBit more info about where this code is will probably =3E help us track this =3E =3Edown=2E =3E =3E =3E =3ECheers =3E =3E =3E =3EDave =3E =3E =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F =3E =B3=CC=B7s=B9a=C1n=B1=C0=A4=B6=3A=B9J=A8=A3=A1A=B6=C3=A5=40=A8=CE=A4H= =A1A=B0=B2=A6p=B7R=A6=B3=A4=D1=B7N=2E=2E=2E =3E http=3A//ringtone=2Eyahoo=2Ecom=2Ehk =3E = =3E |
|
From: <chi...@ya...> - 2003-09-17 04:39:07
|
Hello, Dave, I think I've found what's going on. With 0.9.14.006, ../phpgwapi/inc/class.sessions_php4.inc.php (line 951) and ../phpgwapi/inc/class.sessions_db.inc.php (line 977) read, $new_extravars .= "$key=$value" ; With 0.9.16RC1, ../phpgwapi/inc/class.sessions.inc.php (line 1194) reads, $new_extravars .= $key.'='.urlencode($value) ; So, apparently, with earlier versions, it is the application script's responsibility to url_encode GET variables before sending it on. However, with 0.9.16RC1, the sessions facility handles the url_encode-ing when it receives the GET variables from the application script. With CK-Ledger v.0.7.1 running against phpgw 0.9.16RC1, it means double url_encoding and therefore the callee scripts need to url_decode the GET variable one more time to recover the correct value. I think this will break a lot of the addon module codes. However, if the GET variable passed contains pure alphanumeric chars, no error will be detected, since urlencode/urldecode in these cases do not alter the GET variables. So, there may be quite a fair bit of spurious 0.9.16RC1 errors being the result of the above. Cheers, CK Dave Hall: >CK Wu <chi...@ya...> wrote: > >>Hello, folks, >> >>While testing CK-Ledger v.0.7.1 against >>phpgroupware-0.9.16.RC1, >>I came across the following, >> >>When calling, >> >> >http://localhost/.../loglist.php?filter=%2BWHERE%2B1%253D1%2B&sessionid=...&kp3=...&domain=default&click_history=... > >Is this >http://localhost/phpgroupware/loglist.php?filter=%2BWHERE%2B1%253D1%2B&... > >or > >http://localhost/ck-ledger/loglist.php?filter=%2BWHERE%2B1%253D1%2B&... > >Looking at that code ... there are several problems .... > >firstly the $_POST/$_GET hack won't work with register_globals = off > >Also phpgroupware has never processed the external variables, I think it >is a PHP problem. IIRC php will url_decode all $_GET vars for you. > >Bit more info about where this code is will probably help us track this >down. > >Cheers > >Dave > _________________________________________________________ 最新鈴聲推介:遇見，亂世佳人，假如愛有天意... http://ringtone.yahoo.com.hk |
|
From: <chi...@ya...> - 2003-09-17 02:34:34
|
Hi, David, Nice to know that CK-Ledger has grown to a stage to be benefitial to other apps too. Good luck to your porting effort. I am forwarding this email to ck-...@li... so the others are aware of current development. Cheers, CK --- "David L." : > 收件人：: "'C K Wu'" <chi...@ya...> > 標題: RE: Could you tell me ... > 日期: Tue, 16 Sep 2003 10:58:12 -0500 > > Hi CK > > Thanks for your reply, much appreciated. > > Just to set the record straight, I was not planning, > and will not resell > free products for a profit. > > My idea is to port some of my past applications to > PHP, integrate them with > the framework of phpGroupWare as you have done for > CK Ledger, and make them > ride on top of data from CK Ledger, so that I'll not > have to write an > accounting package as well. > > What will be sold will be our applications and > system integration. > > Thanks again for taking time to enlighten a newbie. > > David L. > -------- > da...@ra... www.rabboar.com 479-621-8003 > > _________________________________________________________ 最新鈴聲推介:遇見，亂世佳人，假如愛有天意... http://ringtone.yahoo.com.hk |
|
From: <chi...@ya...> - 2003-09-16 15:45:44
|
Hi David, First and foremost, a standard rider, both phpGroupWare and CK-Ledger are still in beta, so bugs are inevitable, ie use them, play with them, sell them, ... , at your own risk. Secondly, CK-Ledger is GPL and phpGroupWare is partly GPL and partly LGPL, so I think you should read in totality and in detail both the GPL and LGPL licenses. At the same time, AFAIK, you should be able to sell GPL and LGPL software as commercial product. However, I like to ask you to retain the index page of each CK-Ledger module in any commercial product that you sell because it contains all the warnings, highlights and disclaimers. The retention is actually stated as a pre-condition for re-distribution of CK-Ledger. Cheers, CK David L. : >Hi CK > >I have looked at phpGroupWare as a possible platform for deploying >inexpensive commercial applications. I have downloaded and tested your port >of SQL Ledger, and I am very impressed. > >It's the first time that I look to non-commercial SW as foundation, and >being a novice I'm weary of making big mistakes. > >If you'd be so kind, could you tell me if it's even legal to develop & sell >commercial apps on top of phpGroupWare ? > >David L. >-------- >da...@ra... www.rabboar.com 479-621-8003 > > > _________________________________________________________ 最新鈴聲推介:遇見，亂世佳人，假如愛有天意... http://ringtone.yahoo.com.hk |
|
From: <chi...@ya...> - 2003-09-16 15:25:51
|
Hi, Konstantinos, I have tested CK-Ledger 0.7.1 against phpgw 0.9.16RC1. Everything went OK except for one major problem relating to url_decoding of GET variables. I have posted the problem to both phpgw's developer list and CK-Ledger's user list. Dave Hall's subsequent reply does not provide too much insight into the problem. However, the solution to the problem is already there, ie simply url_decode all GET variables before utilizing them. But this solution is pretty stupid. Php manual states that all GET variables are url_decoded before being delivered to the callee script. So, there must be something fishy going on. I'll probably dig a little bit further. To conclude, CK-Ledger will support phpgw 0.9.16, albeit, with a little tweaking. The eGroupWare question is a bit tricky. I haven't done any work on eGroupWare. However, from discussions at phpgw's developor list, it seems that in future, the major difference between phpGroupWare and eGroupWare will involve the templating engine, phpGroupWare goes for XML/XSLT and eGroupWare goes for etemplate (but Ralf Becker had indicated eGroupWare will continue to support XML/XSLT). I don't know enough about the two technologies to determine if they are mutually exclusive or if one is better than the other. In general, my current inclination is to go for phpGroupWare, ie XML/XSLT, while at the same time, check if eGroupWare(etemplate) can be supported with the same codebase and with minimal modification. However, I think Sigurd (Nes) has better understanding over this issue. Hi, Sigurd, I think your Property app is the first module to implement XML/XSLT. What is your opinion on XML/XSLT versus eTemplates ? Cheers, CK MarinBlu : >Hi CK, > > Are you supporting and eGroupware too ? > > What is your status to support the new 16 ? > >Thanks, >Konstantinos > _________________________________________________________ 最新鈴聲推介:遇見，亂世佳人，假如愛有天意... http://ringtone.yahoo.com.hk |
|
From: <chi...@ya...> - 2003-09-12 14:07:22
|
Hello, folks,
While testing CK-Ledger v.0.7.1 against
phpgroupware-0.9.16.RC1,
I came across the following,
When calling,
http://localhost/.../loglist.php?filter=%2BWHERE%2B1%253D1%2B&sessionid=...&kp3=...&domain=default&click_history=...
[ and the initial few lines of loglist.php reads,
$phpgw_info["flags"] =
array('currentapp'=>'ck-ledadmin',
'enable_nextmatchs_class'=>True);
include('../header.inc.php');
$_POST = $HTTP_POST_VARS ; $_GET = $HTTP_GET_VARS
;
$filter = ($_GET["filter"]) ? $_GET["filter"] :
$_POST["filter"] ;
$order = ($_GET["order"]) ? $_GET["order"] :
$_POST["order"] ;
$sort = ($_GET["sort"]) ? $_GET["sort"] :
$_POST["sort"] ;
$where = stripslashes($filter) ;
$filter = urlencode($where) ;
...
]
The script failed because of invalid string embedded
in $where .
This script had been working with previous releases of
phpgroupware.
However, after changing the 2nd last line shown above
to,
$where = stripslashes(urldecode($filter)) ;
every thing went back to normal. Other CK-Ledger
scripts behaved similarly.
Apparently, before 0.9.16RC1, get arguments were
urldecoded prior to being
despatched to application script. However, post
0.9.16RC1, application scripts
need to do their own urldecoding. Is this a design
change for 0.9.16RC1,
or is it something that I need to dig deeper ?
Thank you for any suggestions or comments in advance.
Cheers,
CK
_________________________________________________________
最新鈴聲推介:十面埋伏，多謝失戀，心淡...
http://ringtone.yahoo.com.hk
|
|
From: <chi...@ya...> - 2003-09-10 13:36:52
|
Marc Lutolf 提到: >>Hi CK, >> >>Here are some notes to your message. >> >>Cheers, >> >>Marc >> >> >>FOREX vendor invoice >>FOREX payment >>FOREX customer invoice >>FOREX receipt >>FOREX adjustment journals >>FOREX period end journal to record unrealised FOREX gain/loss >> >>The last two are perhaps infrequent occurrence that can be dealt with >>manually. >> >> >> > >>>>>>agree >>>>>> >>>>>> > >> >> >>For FOREX invoices, I think it is sufficient to introduce something like, >> >>Currency: [drop-down currency list] Exchange rate: _______ >> >> >> > >>>>>>agree >>>>>> >>>>>> > >> >>ie, a single foreign currency for the entire invoice. It would probably >>require too much effort if each invoice line item is allowed to choose >>a different currency. The initial default exchange rate is taken from >>a FOREX table updatable via Ledger Admin, but could be override at >>invoice creation time. The actual booked invoice amount will be >>calculated as, FOREX AMOUNT x Exchange Rate . >> >>For monetary FOREX payment/receipt, a similar arrangement can be >>implemented. >> >> >> > >>>>>>Yes. Overrides bring a whole new set of problems. For my purposes it is >>>>>> >>>>>> > >>enough to work with a standard exchange rate. >> >>The hard part is perhaps invoice matching against payment/receipt. There are >>three possible scenarios, >> >>a) X currency invoice can only be settled against X currency >>payment/receipt. >>b) X currency invoice can be settled against X currency and/or home >>currency payment/receipt. >>c) X currency invoice can be settled against any currency payment/receipt. >> >>At this stage, I would incline to go for alternative a), since it is the >>easiest to implement and probably handles majority of cases faced by an SME. >> >> >> > >>>>>>absolutely agree that a is the way to go >>>>>> >>>>>> > >> >>Here is what I am using at the moment: >> >>CREATE TABLE xar_ledger_currency ( >> xar_id int(11) NOT NULL default '0', >> xar_isocode varchar(5) NOT NULL default '', >> xar_currname varchar(100) NOT NULL default '', >> xar_rounding float NOT NULL default '0', >> xar_notes longtext NOT NULL, >> PRIMARY KEY (xar_id), >> UNIQUE KEY xar_isocode (xar_isocode) >>) TYPE=MyISAM; >> >>The iso code is not really used, except as a possible key for importing new >>data. Internally the system needs to work with the unique id. >> >>Note the rounding field. This is for currencies that get rounded in >>transactions. In Switzerland for instance, you almost always have rounding >>up to the nearest 0.05 CHF. Notable exceptions are bank accounts, so you >>have to define the rounding per account. >> >>I work with a 3 tier system: there is a system default given by the currency >>table, which can be taken over or overridden manually by the customer. On >>creation of an invoice you can take the customer's exchange rate or override >>it manually on the invoice. >> >>I don't like the name FOREX too much, because it's not just foreign >>exchange; the home currency is in the currency table, too! But that's me. >> >> >> >> Great. I'll try to have these implemented by the next release. Cheers, CK _________________________________________________________ 最新鈴聲推介:十面埋伏，多謝失戀，心淡... http://ringtone.yahoo.com.hk |
|
From: <chi...@ya...> - 2003-09-10 13:35:03
|
Hi, Marc, Robert, In terms of SME requirements, I think the following foreign-currency (FOREX) situations will be encountered, FOREX vendor invoice FOREX payment FOREX customer invoice FOREX receipt FOREX adjustment journals FOREX period end journal to record unrealised FOREX gain/loss The last two are perhaps infrequent occurrence that can be dealt with manually. For FOREX invoices, I think it is sufficient to introduce something like, Currency: [drop-down currency list] Exchange rate: _______ ie, a single foreign currency for the entire invoice. It would probably require too much effort if each invoice line item is allowed to choose a different currency. The initial default exchange rate is taken from a FOREX table updatable via Ledger Admin, but could be override at invoice creation time. The actual booked invoice amount will be calculated as, FOREX AMOUNT x Exchange Rate . For monetary FOREX payment/receipt, a similar arrangement can be implemented. The hard part is perhaps invoice matching against payment/receipt. There are three possible scenarios, a) X currency invoice can only be settled against X currency payment/receipt. b) X currency invoice can be settled against X currency and/or home currency payment/receipt. c) X currency invoice can be settled against any currency payment/receipt. At this stage, I would incline to go for alternative a), since it is the easiest to implement and probably handles majority of cases faced by an SME. What's your opinion on these ? Cheers, CK C K Wu : >>Hi, Marc, >> >>Yes. Multicurrency is indeed the next major target. >>Just about every company >>here in Hong Kong have to due with two currencies, the >>Hong Kong dollar >>and mainland China's Remibi (RMB). >> >>Currently, if any company wishes to maintain separate >>books for individual >>currencies, then the multi-ledger/attribute features >>suffice. However, if the >>effect of different currency transactions is to appear >>within one ledger, then >>major redesign and addition to CK-Ledger have to be >>carried out. Let's think about >>it over this week-end and compare notes early next >>week and see if we can >>come up with a design that would fit both the European >>and the Asian scene. >> >>PS - Sorry. I should have mentioned that the floor is >>open and all comments >from whatever part of the world are welcome. >> >>Cheers, >>CK >> >> _________________________________________________________ 最新鈴聲推介:十面埋伏，多謝失戀，心淡... http://ringtone.yahoo.com.hk |
|
From: <chi...@ya...> - 2003-09-10 13:31:34
|
robert : >>I haven't had a need for multicurrency support even though I live along the >>US/Mexican border. All our transactions appear in US dollars and with US >>vendors. So, forgive me for asking a dumb question... why couldn't the >>business simply record the transaction in their home currency using that >>day's exchange rates? >> >> >> For transactions that are completed instantaneously, eg cross counter trade, this may be possible. However, for transactions with an extended life (eg a Mexican vendor sending a US dollar invoice to a US customer and the invoice got settled three months later), this foreign currency denominated transaction (A/R asset) will have to be reflected, during the interim period, in the accounting book, with due regard to the fluctuating exchange rate. The same thing happens if the Mexican cross counter vendor receives US dollar proceeds and decides to hold on to the US currency, pending favourable exchange rate before converting the US dollar back to Mexican peso. Cheers, CK _________________________________________________________ 最新鈴聲推介:十面埋伏，多謝失戀，心淡... http://ringtone.yahoo.com.hk |
3 messages has been excluded from this view by a project administrator.
