976

(5 replies, posted in Reporting)

Since FA 2.4 is getting trivial fixes, this can go into it and then get pulled in to FA 2.5.

Please note that this was done when escaping was really long winded in the old days 10 years or more ago with having to carryover large number of users from PHP 4 and MySQL 3.x.

Also a multitude of languages cause quite some heartache across linux/windows platforms that all this was cobbled together with least pain. The forum is replete with such legacy issues.

Possibly in FA v2.5, better HTML escaping and accommodation of HTML encoding / decoding will be implemented.

Nice to have such experienced users like yourself pitch in. Please study the code as it evolves and make suggestions that hopefully will not break existing users installs.

978

(3 replies, posted in Announcements)

As of 2019-08-19, the FA 2.5 repo has been started as the current unstable branch.

The FA 2.5 is now complemented with it's own unofficial repo.

CHANGELOG.

We do not want code to be executable like "Bennet Cole &$var Co" where $var can be a malicious bit of code change.

980

(4 replies, posted in Setup)

User variables can be used to some extent in MySQL but it does not work for table names.

981

(5 replies, posted in Reporting)

@joe: If such allocations are not accounted for, we need to update the wiki accordingly - or is a fix slated for it in 2.5?

Check the code flow on value of $all in the get_invoices() function in the report.

@joe: any fix needed here or for 2.5?

As SA_MULTIFISCALYEARS has been enabled (logged out and logged in again after clearing browser cache), verify the setting is saved in Setup => Access Setup => Role: System Administrator (Role of logged in user).

The function that allows Suppliers, Customers and Items to be entered in older fiscal years is defined in admin/db/fiscalyears_db.inc is is_date_in_fiscalyears() and is used in the function is_date_in_fiscalyear() defined in  includes/date_functions.inc where the first said file is "include"d.

Inspect the variables at that point in Line 204 of the last file stated above. The function user_check_access() is defined in includes/current_user.inc file.

Scope, availability and visibility of the variables and their values will be of use in investigating it. If all is well, then scour the scripts that use these values before "post"ing the updated values to the db.

@itronics: must this now be added into the core?

@itronics: must this now be added into the core?

986

(4 replies, posted in Setup)

Restoring from a wrong company's backup will limit / avoid data loss if separate prefixes are used.
Also, you can use multiple databases - one for each company - if there is no limitation on your hosting plan.
If the same mysql server hosts both databases, then getting consolidated reports from both database tables is possible and the table prefixes can help avoid using database name prefixes in the field names.

Switch active fiscal to previous fiscal in Setup => Company Setup temporarily for the change to be done.

The affected report reporting/rep602.php was last changed in 2016-09-06 and that too for only a column width change. However, it's include files may have changed since then.

Upgrading to FA v2.4.7+ is trivial as there are no real DB changes.

@poncho1234: This may not be tenable this way as the checkbox for Editable Description can be changed independant of the specific transaction at any time. However, if it is implemented by checking f a change in standard description from the one used in the PO, then any inadvertent change there may get reflected in the Supplier Invoice without notice - hence a prudent way was sought in the current implementation where a human re-check is envisaged before finalisation.

Forecasting from how many years it took to come in from FA 2.3 to FA 2.4 and the fact that the devs are much older now, take it to be atleast 5 years from when the initial 2.5 branch began. If it is any sooner, thank the advances in coding technologies and that we are now older and wiser wink

@kvvaradha: Whatever changes you have in mind to make a start, do let us know here so that it can atleast get into the codebase for those who wish to benefit from it in the meanwhile and form part of FA 2.5 if and when it appears.

Aug 17th 2019 - probably last commit to the 2.4(.7) branch.
Aug 19th 2019 - first commit to merge stable into unstable for 2.5 branch

@joe: If this was the original intended functionality, then it must be changed.

When a PO is raised and the Description is edited, then it must persist through to the Supplier Invoice.

To rule out PHP/MySQL versions being the cause, check it out on say PHP 5.3.x with MySQL 5.1 and see what gives.

You will have to logout and clear browser cache and then login again.

State which version (and date) of FA you are using and what is the server platform and PHP/MySQL versions and browser type and version used.

The sys_prefs table by default has ref_no_auto_increase disabled but it still works in AutoInc mode.

The error is in the absence of an "else" for line 294 in sales/includes/cart_class.inc and it's positioning after a blank check. The lines 287 to 301 are reproduced here:

    function write($policy=0) {
        
        global $SysPrefs, $Refs;
        
        begin_transaction(); // prevents partial database changes in case of direct delivery/invoice
        if ($this->reference != 'auto' && $this->trans_no == 0 && !is_new_reference($this->reference, $this->trans_type))
        {
            if (!empty($SysPrefs->prefs['ref_no_auto_increase']))
                $this->reference = $Refs->get_next($this->trans_type, null, array('date' => Today()));
            if (!is_new_reference($this->reference, $this->trans_type))    
            {
                commit_transaction();
                return -1;
            }    
        }
...
...

Keep changing the next invoice number manually in Setup => Transaction References and then let it auto-populate this manually provided value in the invoice you enter. The responsibility of maintaining non duplicate Invoice Number will then vest with you as the system will simply reject duplicates only after entering the invoice.

Direct Database intervention in the following tables among others:

debtors_master
cust_branch
crm_persons

Possibly the audit_trail, sys_prefs, journal and voided tables may have some telltale leftovers.

Since this does not affect the DB schema, can we not make a start here?

1. Search the forums and the wiki.
2. Study the DB changes for each transaction / form entry and see if it makes sense.
3. Keep track of the FA version and the DB version in version.php
4. Study the commits in the Repos - Core and Extensions (official and others you follow).
5. Make sure the config.php and sys_prefs table entries match the changes committed in each version.
6. Plug and Pray that nothing breaks.
7. Wish @joe & @itronics a long life to fix anything that goes wrong and gets found wink

999

(2 replies, posted in Reporting)

@joe committed it.

1,000

(15 replies, posted in Reporting)

Fixed by @joe in repo