Search options (Page 236 of 247)

Currently the following are observed:
1. Create new block works.
2. Create new function works and the code gets stored anew as the htmlentities version that is acceptable as long as no single quotes are used.
3. Test button in create new function does not work when any quote - single or double - are used. It works for any function with nothing after the function name - assuming that the function exists as part of some include(d) file.
4. Create new report results in only the report info, select and group entries being stored and the items and graphics are not stored nor are they editable - possible glitch due to db_query["BEGIN"] being used with no db_query["END"] but just a db_query["COMMIT"] assuming even that stored procedure / trigger rights are available for the MySQL user.
5. On the reports listing page, if we run any report, then subsequently all other buttons - Edit, Delete, Copy - also just run the reports.

Preliminary code reading / divining suggests that
1. some cache / globals parsing issue is involved in 5 above.
2. globals missing out on report id when passing to the strings and graphics page in 4 above. A mixture of POST and GET besides conflicting cleaning of GET and POST duplication efforts may be involved.
3. multiple escaping of quotes and / or php.ini settings different from the recommended ones being in use in some parts of the code in item 3 above for eval issues.

All Edit is done by deleting the existing record and inserting a new one in it's place - this can be more efficiently done using an update statement. "Update on insert fail" type of construct will fail as there is no primary key and the "where" can be ambiguous.

Wikied the above.

Attached here is the v2.3.13-1 version of the repgen Report Generator Extension incorporating corrections done so far.

Includes 2 fixes for the tab succeeding an "=" sign and preceeding a gettext translation "_("xxx").

Includes extra page sizes (but stays commented out) in the repgen.inc file

Fixed the manual.html for wrong link and removed the form tags in it.

reports.sql - cleaned up and organised by typ and id with standard delimiters with fields of double quote.

There are many statements like:

$query="INSERT INTO xx_reports VALUES ('".$id."','info','".$info."')";

in the repgen extension that need to be wary of single quotes getting into the strings like $info....

Hi Joe, that is what I would like to have.

In the hg 3127, it appears that the hooks.php of the modules are loaded before the translation strings get added and hence the non display. This is so since the section string is available only when install_access() is invoked.
Incidentally, the module/includes/acc_levels.php file does not seem to get used anywhere at all.

As a temporary workaround, I have commented out the define for the SS_REPORT_GENERATOR in the module's hooks.php and altered the install_access() function to be:

        function install_access()
        {

                $security_sections['SS_SPEC'] = _("Special maintenance");

                $security_areas['SA_REPORT_GENERATOR'] = array(SS_SPEC|130, _("Report Generator"));

                return array($security_areas, $security_sections);
        }

and it now shows up under Special maintenance section group.

The key here is that the label Report generator for the group is not displayed in the roles and after uncommenting the debug code in admin/includes/security_roles.php (lines 217, 218) and turning $go_debug = 1 in the config.php, we get the following error:

Bad section 38200:
Undefined offset: 229888 in file: /var/www/frontac/admin/security_roles.php at line 219

The security role Report generator is displayed corrrectly but the group name (line preceeding it) "Report Generator:" is not displayed but only ":".

Compare the module's files with those from Sep 2010 (v2.3.0) taking into account the various extension parameters that have changed.

The error may be due to themodules/repgen/includes/acc_levels.php(must the file extension be.inc?) using the old style $security_areas. This file is not used now.

$security_areas['SA_REPORT_GENERATOR'] = array(SS_SPEC|155, _("Report Generator"));

Must the SS_SPEC|155 above be SS_REPORT_GENERATOR|130 ?

Optionally the missing single quote for thedefinein line 23 of modules/repgen/hooks.php:

I can see the Report Generator Menu link greyed out in Setup -> Maintenance on the right side. It gets corrected when we tick the Setup -> Access Setup last ":" role for System Administrator, then the Report Generator checkbox pops up and on ticking and saving, logging out and logging back in, the Report Generator works.

One correction may be needed in the modules/repgen/sql/reports.sql file at line 59, the id should be '6' instead of 'B1' which is for blocks.

Some extra report definitions have been culled out of www.fvr.ro and attached herewith. Since the table xx_reports has no primary key, it seems to be accumulating duplicate records.

The installed_extensions.php file in the webroot uses true/false for the 'active' attribute of the array whereas it is 0/1 in the company/#/installed_extensions.php files. Renumbering the array elements in both files in the same manner maintains status quo.

Can the FA Admins correct it and upload a new PKG?

The current translation strings (FA v2.3.13 Mercurial Build 3127) empty.po files generated in accordance with the sequence at the Wiki Page is attached herewith.

Many obsolete entries have been removed, existing ones updated and new ones added.

Since there are too many changes and order differences, no patch file has been generated.

Use the profit and loss account or any suspense account - it will all zero out since the Balance Sheet is balanced. Even a dummy Balance Sheet Type account possibly named "Opening Balances Transfer Account" would suffice.

Thanks Januz.

I have standardised the method of generation of [both main and install empty.po files with:

#!/bin/bash

mkdir -p /tmp/fagettext
cd /tmp/fagettext

FAVERSION="2.3.14"
FRONTACFILE=frontaccounting-$FAVERSION.tar.gz

wget https:/sourceforge.net/projects/frontaccounting/files/FrontAccounting-2.3/$FAVERSION/$FRONTACFILE
tar -xzf $FRONTACFILE
rm -f $FRONTACFILE

MAINDIR=`pwd`/frontaccounting

cd $MAINDIR

# Generate the main empty.po file

TPL=lang/new_language_template/LC_MESSAGES/empty
GTEXEC="xgettext  -d empty --language=PHP  --from-code=ISO-8859-1 \
                  -p $MAINDIR/lang/new_language_template/LC_MESSAGES "

# Backup the old main empty.po
mv $MAINDIR/$TPL.po $MAINDIR/$TPL.po.org

# Generate main header as well
$GTEXEC -k_ -n *.php

# set the charset
sed -i 's/charset=CHARSET/charset=ISO-8859-1/g' $MAINDIR/$TPL.po


mv install ..

$GTEXEC -k_ -n -j */*.php
$GTEXEC -k_ -n -j */*/*.php
$GTEXEC -k_ -n -j */*/*/*.php
$GTEXEC -k_ -n -j */*.inc
$GTEXEC -k_ -n -j */*/*.inc
$GTEXEC -k_ -n -j */*/*/*.inc

mv ../install .

# Generate the install empty.po file

ITPL=install/lang/new_language_template/LC_MESSAGES/empty
GTEXEC="xgettext  -d empty --language=PHP  --from-code=ISO-8859-1 \
                  -p $MAINDIR/install/lang/new_language_template/LC_MESSAGES "

# Backup the old install empty.po
mv $MAINDIR/$ITPL.po $MAINDIR/$ITPL.po.org

# Generate install header as well
$GTEXEC -k_ -n install/*.php

# set the charset
sed -i 's/charset=CHARSET/charset=ISO-8859-1/g' $MAINDIR/$ITPL.po

$GTEXEC -k_ -n -j install/*.inc
$GTEXEC -k_ -n -j includes/system_tests.inc
$GTEXEC -k_ -n -j includes/packages.inc

cd $MAINDIR
tar -czf ../../fac_empty_po.tar.gz $TPL.po $ITPL.po
cd ../..
rm -rf fagettext

echo "fac_empty_po.tar.gz created"

Have Wikied it as well.

Attached are the empty.po files taken from the gettext of the FA v2.3.14 code.

What is the script you use to get the gettext to do the job?

Oh yes, thanks. Lines 238-240 in system_tests.inc do it:

    $fname =  $path_to_root.'/lang';
    $test['test'] = $fname;
    if (!(is_dir($fname) && is_writable($fname))) {