6,076

(5 replies, posted in Wish List)

FA v2.4 alpha (current Mercurial last changeset 3072) has a few small sql bugs that need to be corrected before install and testing. There is a new 0_wo_costing table that finds no mention in the default COAs and the upgrade sql patch at sql/alter2.4.sql cannot be for executed even on a new install due to these discrepencies.

The unstable corrected files and patches are available here since BugFixes 1809-1812 in Mantis have access denied issues that prevent us from following it up.

Hope the community can now accelerate bugfixing the development branch v2.4 alpha using these snapshots.

php.ini needs to be edited to enable openssl and Apache restarted.
Connection to internet is essential so that COAs and other goodies can be downloaded from the frontaccounting.eu repos.

Wikied it at:

ReportPaths

and placed a link in

TechInfo Resources

Alternatively, it should suffice to delete the said js files from each /company/X/js_cache folder.

Well done Joe!

Unrelated aside:

Bugfixes 1809-12 pertaining to unstable became marked as access denied in Mantis. Bugfix 1785 is still awaiting inclusion. (Role Elevation from reporter to developer in Mantis has not alleviated the Access denied status for following up on the said Bugs)

6,080

(66 replies, posted in Modules Add-on's)

Is Farhaj's demo an extension of the payroll module? Will try to contribute for this module...

Wow! That's great. You're the fastest in updating the repo!

6,082

(17 replies, posted in Reporting)

thorbjornw - have you got FA working nicely with PHP-Residence/HotelDruid ?

Thanks Joe, - Changeset 3069.

6,084

(5 replies, posted in Setup)

Hope BugFix on ChangeSet 3069 solves your issue.

6,085

(66 replies, posted in Modules Add-on's)

In the Google code page for the payroll module, no code commits are there after May 7th 2012. Also no download of any source file is provided. Hence has the development page gone elsewhere?

The 2 clones are also of same vintage.

The same would apply to different databases (assuming db names too are sequential / guessable) if permitted for the same db user. That is why the db user too must be different for each company's different database.

A config variable can be introduced to decide if the session variables (db user, db name, db pwd) should be allowed to pre-populate the create company form with initial values. Each company should have their own db user with privileges for their company's prefix only.

Thankyou for pointing out the vulnerability with fine clarity. In the meanwhile, we should not give restore functionality to the company admins and keep it with the Super Admin only.

Another possible solution (may not apply to limited hosting accounts) would be to auto generate the db name, db username, and db password for the company using a non displayed privileged db user.

One more solution would be to parse the sqls for create / insert (no select or update) statements only and pertaining to the current user's company prefix alone during a restore. Beware of compound insert cum select statements.

After the release of FA v2.3.12 (Mercurial Changeset 3061), important changes have been made (in Mercurial Changeset 3068) to the all default themes' renderer.php files that need to be backported to the existing non default themes to make them compatible for use in future releases.

In Mercurial Changeset 3068 certain rendering functions viz.,

    check_application_access
    check_module_access
    hide_inaccessible_menu_items

have been shifted from

    themes/*/renderer.php files

to

    includes/current_user.inc

Hence in the  hitherto non-default themes, the renderer.php files must get rid of the said functions and replace the following calls:

$this->check_application_access($app)
$this->check_application_access($selected_app)
$this->check_module_access($module)
$this->hide_inaccessible_menu_items()

with

$_SESSION["wa_current_user"]->check_application_access($app)
$_SESSION["wa_current_user"]->check_application_access($selected_app)
$_SESSION["wa_current_user"]->check_module_access($module)
$_SESSION["wa_current_user"]->hide_inaccessible_menu_items()

respectively.

Consequently, the function menu_header in the themes/*/renderer.php file will no longer need access to the variable $show_inaccessible_menu_items from the global context as it now has access to it's SESSION variable instead.

ie.,

global $path_to_root, $help_base_url, $db_connections, $show_inaccessible_menu_items;

will now be:

global $path_to_root, $help_base_url, $db_connections;

Disable rights for the dbuser for the said default db in question!

Anyway, only the default admin company (0) gets to use the Create/Add New Company Meny Item - so where's the security vulnerability?

6,089

(22 replies, posted in Accounts Receivable)

Web ERP's lead developer Phil Daintree's company LogicWorks provides a compiled POS connector and desktop application (Win, Lin, Mac - Counter-Logic Point of Sale System) for an annual fee of USD 75/-. There is no such equivalent in FA - AFAIK. It is based on Python and compiled and uses the Zadig USB Driver Installer from the libwdi project on Sourceforge and Python esc/pos project at Googlecode.

With rich HTML5 capabilities, it shouldn't be long before a completely free POS becomes available for FA. Chris Muench's PHP Point of Sale was free till they went closed source (USD 99/- per install with 1yr free upgrades), the last free version with all features are available as a WebApp for the BlueQuartz/BlueOnyx project (BQBO-webapp-phpos-11.3.pkg) and is privately available with a few developers.

The current open source version fork of the PHPPOS is available as Open Source POS. Their latest v2.01 released a few days ago is here.

Even without this, one can still change the database name before submitting the form to add a new company. Infact, the new different database may already have been created outside of FA and that is what v2.3.12 actually solves.

Check out the Bug Fix 1792 and control the default exchange rate provider in config.php file.....

Download Xchg_Rate_Fix.zip.

Works wonderfully on v2.3.12.

Hope this and the earlier BugFix 1785 make it to the core code base of v2.3.12 soon.....

Is the development work to be exclusively shifted to the v2.4 branch for now?

check permissions of the /var/php_sessions/ folder and ask godaddy to fix it.

6,093

(6 replies, posted in FA Modifications)

In what way is your login screen different from the standard one? Check the diffs of the login.php and see what has changed....

6,094

(66 replies, posted in Modules Add-on's)

Awaiting module for testing.
Looks great.

Will it be availabe for v2.4 only?

Tried out the project (not working) on google code - looks like the install functions do not match the current v2.3.12 module install specs.

Have created a tarball of the latest google repo at:

To get it, had to install Git on Lenny and update it thus:

apt-get update
apt-get install git git-core
cd /usr/src
wget http://ftp.us.debian.org/debian/pool/main/g/git/git_1.7.2.5-3_amd64.deb
dpkg -i git_1.7.2.5-3_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/g/git/git-core_1.7.2.5-3_all.deb
dpkg -i git-core_1.7.2.5-3_all.deb

Google code repo accepts only Git v1.6.6+ and Lenny had v1.5.6+ only.

Then did a clone:

git clone https://code.google.com/p/fa-payroll-module/
tar -czf FA_Payroll_Module_Git_`date +%Y-%m-%d`.tar.gz fa-payroll-module

6,095

(34 replies, posted in Modules Add-on's)

Attempting a git clone of the fa payroll module from google results in an error:

# git clone https://code.google.com/p/fa-payroll-module/
Initialized empty Git repository in /var/lib/vz/Repos/Git/fa-payroll-module/.git/
warning: remote HEAD refers to nonexistent ref, unable to checkout.

6,096

(3 replies, posted in Installation)

Windows or Linux - generally permissions affect all linux boxes and the newer windows server boxes.
In linux, chmod / chown are your friends.

Thanks Janusz, no hurry. Meanwhile, have posted updated LoginDelay Fix for BugPost 1785

6,098

(7 replies, posted in Announcements)

FrontAccounting v2.3.12 has been released over the weekend and since the primary site is not fully updated, the links are as follows:

Mercurial Dev

Bug Reporting

Download Page

FA Mercurial Usage on Wiki

Please note that the forum post on CAPTCHA integration needs to be modified to suit the new login failed attempts delay feature in this version.

Please see this forum post on same database usage vulnerability and fixes.

Snapshots as on 14th Nov 2012 (Mercurial Build 3099) are available: v2.3.12+ and v2.4a. Please test them extensively to obtain a bug free next release. Those who want to install only the 46 files that have changed in Mercurial Build 3099 since the release of v2.3.12 can take them from the attachment herein. The changes in config.default.php need to be made in the existing config.php file.

If it doesn't make it to the code base, can it find a place in the Wiki? (Placed in Wiki)

Now that the failed login delay feature has been introduced in v2.3.12, the above code needs to modified carefully in the light of changes to login.php and other files listed above.

Configurable Delay after specified login attempts is quite nice. May need to store login attempts somewhere or stale failed logins would false trigger.

Since the captcha is only on initial login (not for timeouts) and is configurable in the config.php would it's integration into the base code prove troublesome? The download size would become huge due tot he audio scripts - maybe another config variable for controlling audio enablement on captcha would be desirable. Yes the CAPTCHA proved very tiresome during repetitive testing....

Can it be encapsulated as an optional plugin (bundled with securimage code) ?