Oh no! Where's the JavaScript?
Your Web browser does not have JavaScript enabled or does not support JavaScript. Please enable JavaScript on your Web browser to properly view this Web site, or upgrade to a Web browser that does support JavaScript.
Sign In
Not a member yet? Click here to register.

User level changed from 103 to -103

Please find my latest commit.

Pre-existing installs please manually change your user_level in DB_USERS table to:

Type: CHAR
Length: 4
Default "-101"
Remove Unsigned and switch to blank.

Group 100 - 103 should be able to pass groupaccess without compromising user_level access checks now.
$result = dbquery("ALTER TABLE ".DB_PREFIX."users CHANGE user_level user_level CHAR(4) NOT NULL DEFAULT ''");

   if (empty($data)) {
      $data = dbquery_tree_full(DB_SITE_LINKS, "link_id", "link_cat", "WHERE link_position >= 2".(multilang_table("SL") ? " AND link_language='".LANGUAGE."'" : "")." AND link_visibility <= '$acclevel' ORDER BY link_cat, link_order");

There are no links because my access level is -103 and the public level is 0.
(site links still contain the old values in the installer)
To be, or not to be, that is the question—


$data = dbquery_tree_full(DB_SITE_LINKS, "link_id", "link_cat", "WHERE link_position <= 2".(multilang_table("SL") ? " AND link_language='".LANGUAGE."'" : "")." AND ".groupaccess('link_visibility')." ORDER BY link_cat, link_order");

I knew it would be a fix to unfix everything else because it began with the wrong footing.

The end to checkgroup bug roadmap. Perfect implementation of functions reached. :)

Upgrade Gits:


I might have missed out.

Run this in custom page preview

   // Modify All Users Level > 0
+   $result = dbquery("SELECT user_id, user_level FROM ".DB_USERS."");
+   if (dbrows($result)>0) {
+   while ($data = dbarray($result)) {
+   if ($data['user_level']) { // will omit 0
+   dbquery("UPDATE ".DB_USERS." SET user_level ='-".$data['user_level']."' WHERE user_id='".$data['user_id']."' ");
+   }
+   }
+   }
+   // change link_visibility
+   $result = dbquery("ALTER TABLE ".DB_SITE_LINKS." CHANGE link_visibility link_visibility CHAR(4) NOT NULL DEFAULT ''");

More for existing v9 installers


// change link_visibility
      $result = dbquery("ALTER TABLE ".DB_SITE_LINKS." CHANGE link_visibility link_visibility CHAR(4) NOT NULL DEFAULT ''");
      $link_result = dbquery("SELECT link_id, link_visibility FROM ".DB_SITE_LINKS."");
      if (dbrows($result)>0) {
         while ($data = dbarray($result)) {
            if ($data['link_visibility']) { // will omit 0
               dbquery("UPDATE ".DB_SITE_LINKS." SET user_visibility ='-".$data['link_visibility']."' WHERE link_id='".$data['link_id']."' ");

I started to find more bug in connection with new user level, but there are so many forgotton code and hard to find them. You can see how many files I changed: https://github.com/php-fusion/PHP-Fus...5d3371dc0c
and I have not finished yet.

Maybe changing it before RC was not the best idea.
Nvm. we can extend to beta 5 even if necessary. I believe this is all we need to do once and for all.. Not to the most beautiful way of doing things, but acceptable if group_id = 103 can coexist with iSUPERADMIN/aka. USER_LEVEL_SUPER_ADMIN. (btw, i like the new constant name.. very editor friendly).

Anyway, -ve values have repercussion in isnum() function...

Only with this I manage to fix 'infinity loop' redirection... float or not, just update to php latest. (I mean the "php is_numeric() is better than fusion's native Isnum() in this context) Is that acceptable? I already git in just to get my maintenance debug going. It's not even saving -103 with isnum() check, not to mention defender has all the isnum() check as well and will reject negative values.


function isnum($value, $decimal = FALSE) {
   return is_numeric($value);
   //$float = $decimal ? '(\.{0,1})[0-9]*' : '';
   //return !is_array($value) and preg_match("/^[0-9]+".$float."$/", $value);

is_numeric() is perfect usually. I wrote about it if I remember well. But I think, isnum() was intended for positive numbers in decimal system. We could replace isnum() with is_numeric() where it is possible, but is_numeric() check if the input is a number in any number system.

is_numeric("0x123") is TRUE

Maybe sometimes isnum() used to make sure the number is an integer as a string:

It cannot be float, but is_numeric() let it to be a float.
filter_input(INPUT_GET, 'rowstart', FILTER_VALIDATE_INT) 

could also solve the problem in this case

So the two functions work different way. We should not change the original function! The better way is replacing isnum() with is_numeric() when it is necessary.

Or rethinking the negative numbers and finding a better solution before we go too far.
Ok. https://github.com/php-fusion/PHP-Fusion/blob/9.00/administration/settings_security.php#L43 - i'll change.
Thread Information
9 posts
559 times
Last Post
Last updated on 5 years ago
You can view all discussion threads in this forum.
You can start a new discussion thread in this forum.
You cannot reply in this discussion thread.
You cannot start on a poll in this forum.
You cannot upload attachments in this forum.
You cannot download attachments in this forum.