Hope there is no other instance of such a change needed.

https://wiki.php.net/rfc/deprecate_dynamic_properties
Declare property before usage in PHP 8.2 and above.

// PHP <= 8.1: Silently creates dynamic undeclared property
// PHP    8.2: Raises deprecation warning, still creates dynamic property if undeclared.
// PHP    9.0: Throws Error exception.

Hence if you are using PHP >= 8.2 then at Line 211 of reporting/includes/tcpdf.php insert the following:

        /**
        * @var cell binary padding
        * @access protected
        */
        var $padding;

@joe: is this necessary to be in the core for all such instances of undeclared properties?

Choosing an Arabic font and printing it all in Arabic with the English Text too within the UTF-8 Arabic font will be the standard solution.

The HTML2PDF function is used for printing Reports. Hence if some html code for the specific Arabic Text with a RTL tag for it alone id ised, it may mitigate it. It may need to be embedded into the database text itself otherwise.

Using iFrame for integration is generally not recommended as it may be used in a separate browser unless some session variables and parent frame's js/data are linked.
Exporting, EMailing and Voiding are separate activities that need on the fly generation and parameter checking before completion.
The URL for such actions will also be linked to session variables and logged in credentials as well besides the normal record ID info.
Command Line / bash utilities in batch mode too can be explored with dovetailed sequenced operation on specific URL usage.
Viewing the invoice in your iFrame is presently possible as alos the menu links. That should be enough to export and email the invoice when viewing it through the use of some external get variable to trigger such scripts.
New menu options in FA using some extensions too can be used to do the above.

5

(3 replies, posted in Setup)

Wiki-ed.

6

(1 replies, posted in Wish List)

@joe: Nice addition to the FA core as the terms data.

Assuming you have a local MySQL/PHP or equivalent application for your Transport Management Solution (TMS) that has it's own database.
Create a read only view that takes the data from some SQL query in the FA database. Now tailor your application in your TMS to partake of the necessary FA data from within itself (RO views).

Stop nginx.
Export DB into SQL format as backup.
Rename the database.
Create a new database with the backup on the original db name.
Start nginx.
Check if the problem exists.

I checked on Apache 2.2.
Check the cache folder permissions if using caching. Looks like it is not allowing to store cache of php pages.
Also check the tmp/errors.log
Investigate with go_debug settings in config.php
See if the includes/session.inc file setting for secure constants need changing.
Your data on Debian 6 based FA system seems working fine after first callup.

10

(2 replies, posted in Report Bugs here)

Looks like you have an ajax timeout problem.
Checkout:
https://frontaccounting.com/punbb/viewtopic.php?pid=43737#p43737

Just tested it out. Yes the first Direct Invoice page is slow or even times out. Logged out, cleared cache and closed browser. On next login everything is fine. Looks like some server startup / mysql index recreation / updation issue. Not to worry.

Solved. Increases the Ajax timeout to 20 seconds.
Ref: https://frontaccounting.com/punbb/viewtopic.php?pid=5318#p5318
The default is 10 seconds (10000 milliseconds) in js/utils.js lines 36 to 42:

JsHttpRequest.request= function(trigger, form, tout) {
//    if (trigger.type=='submit' && !validate(trigger)) return false;
    tout = tout || 10000;    // default timeout value
    document.getElementById('msgbox').innerHTML='';
    set_mark(tout>10000 ? 'progressbar.gif' : 'ajax-loader.gif');
    JsHttpRequest._request(trigger, form, tout, 0);
};

Replacing 10000 to say 20000 or more in the two places above will do the job.
Logout of FA. Close the browser. Clear the cache and then login to get longer ajax queries of inquiry and reports.

This has been Wiki-ed.

@joe / @itronics: can we make this a setting in the config.php?

Check PM to verify GL data
What steps do you want to verify for size?

Checked out 01-01-2024 to 31-08-2024 in GL Inquiry for 1060 account and it works fine in 10 to 12 seconds.
When we go upto 30-09-2024 (ie., one more month) it times out in 12 seconds.
This did not change with memory_limit from 128M to 4G.
Looks like some script timeout or keepalive or session issue.

There is the Slim PHP micro framework - v2.64 has been tested.
SimpleAPI extension available at https://github.com/andresamayadiaz/FrontAccountingSimpleAPI ?
https://www.frontaccounting.com/fawiki/index.php?n=Devel.SimpleAPIModule
Is this the one you are using?

A lack of indices on some fields of some tables - that only speeds up processing.
If the output is because of having a single output buffer for a very large amount of data that needs to be streamed, then a file capture of the output can be implemented. @joe: any ideas?

Are you using any extensions?
Just take a full compressed backup (delete the data from the users table in the backup) from within FA and upload it somewhere and send me a PM and indicate it here.
What versions of PHP / MySQL are you using?

16

(1 replies, posted in Setup)

Assume there are 96 "Quarter Hours" in a day and proceed.

17

(40 replies, posted in Reporting)

https://github.com/apmuthu/FA24extensions/tree/master/Extensions/mail

Take a look at the php.ini setting:

intl.default_locale.

https://server.hk/blog/15807/

If mass-answering is your issue, then many satisfied users would not have been benefited here. It is not very often that anyone answers posts in the forum lately after the start of the Ukraine war. I am doing my best to keep the project alive. Checking for code updates and code commits will reveal that clearly.

Thanks to this post, I have added this solution to the wiki at the end of:
https://frontaccounting.com/fawiki/index.php?n=Main.OpeningBalances

In case my suggestions have sent you on tangents please note that all this is part of checking the possibilities as I thought might expose issues with PHP versions. The Job offers section is there for professional assistance in case the general community does not elicit a solution.

Adding a new user post was meant for another post.

I do not know of what changes PHP 8.x will have on these extensions. Also, if there is no Banking Transactions in the said list and the Journal Transactions did not suffice, the error logs with debug on should provide some pointers. If you consider my suggestions as a tangent then please seek professional assistance in the Job Offers board. Using the audit trail is another method of viewing the various SQL queries that get traversed through during it's execution.

I maintain the unofficial extensions repo as it has some third party extensions also, not officially vetted as yet to serve as a self help resource. Also I make sure that the white space in the changed code is synched with those in the core and official code base to make for ease of troubleshooting and development.

My requests on the board and its archives have not elicited any response from the original developers of the extensions till date. Nor have any users listed the way they have solved the issues at hand in the forum and in the wiki as far as I know.

Count the number of data elements and the number of headers - they appear correct herein but if there are any tabs and / or other delimiters or blank values some issues may occur based on PHP version.
This extension last worked in FA v2.4.6.
Some corrections have been made in the unofficial extensions repo for this extension.

To download this extension visit:
https://download-directory.github.io/
and paste in the github folder:
https://github.com/apmuthu/FA24extensions/tree/master/Extensions/import_transactions
and press Enter and you will get the zip file of the extension.

Use a folder compare utility like ExamDiffPro or WinDiff or WinMerge to check on the files in your official extension at FAwebroot/modules folder with that in the zip file and upload the changes in the files as listed therein.

Just checked. This has been the default since the very beginning over 15 years ago.

Duplication of posts causes deletion to avoid having to look into multiple posts.
Please take assistance of php programmers to inspect variables in the code at the point of failure where the error comes out. There is one of the forums in this board where such professional programmers exist.
I used an existing test install on Debian 6 to check out if and when the closing GL greyed out issue occurred since several code changes have been effected over time. It is not my recommendation to use Debian 6 in public facing installs.
The project admins are in Poland (@itronics Janusz) and Sweden (@joe Hunt) who are closer to your time zone and possibly have access to several platform versions to assist.
I only have as much time to assist on various issues in FA as I participate in the project only as a hobby and for teaching accounting.
I am sorry I have been of little use to solve your issue. Good luck with others helping you.

Generally when ever any issues arise with later versions of PHP/MySQL we generally regress to a known state / platform and then probe our way to a solution.

Tested with Debian 6 and MySQL 5.1 and PHP 5.3.3 and all worked well.
If adding a user was a real problem practically all major users of FA would have complained by now.
Single stepping and watch points and debug_status are the way forward.

You will have to do an investigation into it in the code given earlier by putting it watch points and logging the variables.