It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Posts by joe
Ok, I am also using php 8, $go_debug=2 and not getting this error. I am an old C and C++ programmer and these languages always take care of old versions (backward compatible), so I am getting really weird of this php language.
We will simply change the function in pdf_report.inc.
We still have some other issues in php 8. Working on it. One of them is crediting in Customer Transactions.. Not reading the original invoice.
So please do NOT use php 8 seriously yet.
Joe
@kvvaradha
I see no problem here. Do you?
/Joe
i have amended the text in current_user.inc, line 369.
We will let it be for a while, for backwards compatibility in modules.
/Joe
Will have a look.
Joe
I am not so sure about this. It is very common to let the username be case insensitive.
It is more important that the password is strong. And, really, this is not a Fort Knox issue.
Joe
Yes, I guess you are right.
I am out of office this week. This will be fixed when in office again.
Joe
This mission is now fixed and committed to stable repo. I hope all of them are taken, but please report any remains.
/Joe
After talking to Janusz, we can
change the line:
return $row[0];
to
return is_array($row) ? $row[0] : false;This fixes the problem. But we don't have to do it all over the places. Only where there are NO aggregates as SUM, COUNT etc. These aggregates will always deliver at least one row with empty values.
I will start fixing the needed places tomorrow.
/Joe
ok Thanks @kvvaradha.
I will just have a short discussion with Janusz (itronics) about this mysqli issue, before trying to fix it.
I will fix the qty_cell error.
/Joe
Did you also try:
if ($result == false)
return false;Joe
@apmuthu
Good observation with SET commands. I will look for how to do it.
Of course if you have it at hand, please advise.
Joe
@kvvaradha
Couldn't we just put these two lines after the query result:
if (!$result)
return false;Because if there is a $result then db_fetch will always return at least one array.
/Joe
This has been committed to stable repo.
A downloaded file can be downloaded here and replaced in /includes/ui/
Joe
Ok I will have a look at this.
Joe
hello again @rafat.
I think I will commit the changes already done. It is almost perfect now, and we can always improve it during the release.
Thank you for cooperation and see you 
/Joe
I meant, try to set the currently defined value of 27 to 23 on line 63 in class.graphic.inc.
Joe
@rafat
The graphics for balance-sheet, pie, donut and half donut shold now be ok.
The graphics for sales customers top 10 is not changed, but you could try to reduce the MAXLEN in the define on line 63.
It is currently 27.
I see a big fontsize on the graphics, so try with 23 or so.
This is difficult to do when you mix Arabic and English language in the same graph.
But try to experiment a little.
/joe
Thanks @kvvaradha
Nice job you have done.
As I am very overloaded with several tasks, RTL, Graphics etc. I would like you to help me and eventually make a list over places that we should fix.
I guess this is a PHP 8 problem, right? I have already taken some basic ones, but again it is good that we are helping each other detecting and fixing these problems.
/Joe
Hi again, @rafat
I have now gone through all the graphics on both SVG and traditional Graphics (JPG, PNG etc.).
The Graphic engine will truncate all labels longer than 27 chars in all the graphics. This make it much more flexibel to work with.
All the Graphics are now unified and will work as you want it to do.
Download the attached and replace it in /reporting/includes/class.graphic.inc and /includes/dashboard.inc folders.
You might try the reports Customer Aged.. and Supplier Aged (try the various graphic types). Also Balance Sheet and PL Sheet.
There was a reported bug under 'Report Bugs here'. Have a look here, there are 2 new files that should fix the issues here.
See ya Monday
/Joe
Yes, these parameters were missing. It is fixed and committed to stable repo.
You can download the 2 files here, rename the extension from php1 to php and replace in /reporting folder.
/Joe
@rafat,
I only had to clear my browser cache, then it worked with removing the table class in default.css.
So now we should just fix the default.css and it should be ok. Cool . Good work, @poncho1234!!
Anyhow it is good to also test that the LTR still works everywhere.
Ok, you still have some problem with your test. I will have to look at this. Any thing to reproduce this? Long text or so?
We are celebrating the Mid Summer today, so don't expect to much work here
/Joe
Hello @rafat and @poncho1234
I am glad that you, @poncho1234, is contributing in this important matter.
You wrote that eliminating the table class in default.css would do it automatically. I couldn't reporduce this, will you upload your default.css, so I can test this.
Regarding the Graphics Legends in class.graphic.in . It should now work both in LTR and RTL. Please replace the attached file in /reporting/includes folder and let me know.
@rafat
It surely looks better now 
/joe
Ok, I will continue tomorrow with the right justified text legends.
/Joe
@rafat
To sum up. In most places in FA tables, transaction lists, the text columns are left justified also for RTF.
In some other places, f.i. reports, the text columns are right justified.
So I think we should leave the html table columns be as is.
But we could fix the graphics legends to be right justfied in all graphic types. What do you say?
Joe
@rafat
The text justification in the table is browser html treated. So this is a tricky one.
The right justificationfor for text in the SVG graphics legends could be fixed, however.
What should we do?
Joe
FrontAccounting forum → Posts by joe
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.