Search options (Page 170 of 247)

Does this occur in FA v2.3.24?

If you wish to track inventory of Services, then create a Service Item of Inventory Type (and not Service Type) and put in a huge value of stock so that it does not run out... A separate stock category if you want.....

When installing, choose the US New CoA in Company #0. This will be your "default" company for making settings changes and installing addons (like themse, CoAs, Languages and Extensions) across companies and should not be used for any transactions.

From within Company #0, create a new company #1 and in your case choose the preferred Australian CoA.
Now logout of the default company #0.
Then, login to the Company #1 which will be your "working" company and enjoy FA.

https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1315888

If gzopen64() function exists, use it else use gzopen() => needs to be implemented in FA.

The said function appears in 4 core files (and not in any extension file):

  admin/backups.php (1 hit)
    Line 102:     if (function_exists("gzopen"))
  admin/db/maintenance_db.inc (1 hit)
    Line 723:         if ($zp = @gzopen(BACKUP_PATH . $backupfile, "a9"))
  includes/archive.inc (2 hits)
    Line 441:             if ($fp = gzopen($this->options['name'], "wb{$this->options['level']}"))
    Line 462:         return @gzopen($this->options['name'], "rb");
  includes/packages.inc (2 hits)
    Line 165:     $list = gzopen($file, 'rb');
    Line 220:     $file = $zip ?  gzopen($fname, 'wb') : fopen($fname, 'wb');

Maybe a wrapper function is in order.... fa_gzopen()

@joe: any ideas?

To get PHP work done it is not necessary to get the programmer into Saudi Arabia from anywhere in the world and subject them to your local laws, security and social mores. Your "employees" can remain anywhere in the world as long as they are connected.

In this world, it is sustainable for people to work with each other and not for any other.

The ui_input.inc fix was committed after the release of FA v2.3.24.

Thanks for your diligence in ferreting out this bug and testing it through to it's logical end!

The problem you are getting is because all areas have been stored in the security_roles tables for all roles that got edited with the erroneous file. Start afresh for the security_roles table and see how it goes.

Check out the latest FA v2.3.24 and see if that solves your problems.

The Wiki is the place to look:

Generic Installation of Addons and their links.

Specific to Modules

Finally fixed it - it was failing since the value of the checked element was not being tested:

--- admin/security_roles.php    Sat Mar 14 20:35:36 2015
+++ admin/security_roles.php    Thu Apr 02 11:09:29 2015
@@ -85,8 +85,8 @@
         $sections = array();
         $areas = array();
         foreach($_POST as $p =>$val) {
-            if (substr($p,0,4) == 'Area') {
-                $a = substr($p, 4);
+            if (substr($p,0,4) == 'Area' && $val == 1) {
+                $a = (int)substr($p, 4);
                 if (($a&~0xffff) && (($a&0xff00)<(99<<8))) {
                     $sections[] = $a&~0xff;    // add extended section for plugins
                 }

The devs can now port it to FA 2.4 as well using the same patch file.

The fix needs to be corrected since the database storage symptoms are still there although the GUI shows it correctly:

Salesman Role:

sections: 768;3072;5632;8192;15872
areas: 773;774;3073;3075;3081;5633;8194;15873

Cloning Salesman as SalesWoman and adding in 2 areas to existing section and 1 area to new section results in:

sections: 768;3072;5632;5888;8192;15872
areas: 773;774;3073;3075;3081;5633;5889;8194;15873;15874;15875;513;514;515;516;517;518;519;520;521;522;523;524;525;526;2817;2818;2819;2820;2821;2822;2823;3329;3330;3331;3332;3333;3334;3335;5377;7937;7938;7939;7940;8449;8450;8451;10497;10753;10754;10755;10756;10757;11009;11010;11011;11012;13057;13313;13314;13315;15617;15618;15619;15620;15621;15622;15623;15624;15628;15625;15626;15627;15629;16129;16130;16131;16132

but it should be:

sections: 768;3072;5632;5888;8192;15872
areas: 773;774;3073;3075;3081;5633;5889;8194;15873;15874;15875

Eliminating all blank areas is better than choosing all selected areas if a mere presence is checked instead of the value!

This persists even in FA 2,4 where an extra permission 775 (Edit other users transactions) is given to Salesman role - is this intended? If so, would it not be better to keep the 775 along with 773 and 774 instead of at the end in the insert statement statements in the CoAs? This (775) seems to be so for practically every role!

Probably a footnote to state it so would appease the "authorities".

What a nice way to Ajax the whole page temporarily! Thanks for the real fix - that was fast - will test and revert.

When you release the FA v2.3.24, please make the now unused field 0_sys_types.type_no = 1 for all records in both CoAs in the insert statements.

Also "stay in old page when customer is updated fix" can also be committed.

To prevent uneditable item descriptions in "purchasing" files from being unnecessarily being updated with same content (and mangling special characters), my commits to the files:
FAMods/purchasing/includes/po_class.inc
FAMods/purchasing/includes/ui/po_ui.inc
FAMods/purchasing/po_entry_items.php
may be taken into the new release as well.