I was active on the project wiki yesterday as MaxEnt as I worked through the process of installing refbase on a ISP with an unusually restrictive mysql admin policy. My account there comes with ten distinct MySQL databases each with three predefined MySQL usernames: user, user_w, user_r. Th user allows creation of tables, etc. The user_w is the one normally embedded in a PHP applications configuration file with the normal set of table read/write perms. user_r is read only, so relatively safer for pasting into informational scripts. There is no access to the 'mysql' database from user accounts whatsoever. Databases are managed through an account control center with just a handful of features: create, delete, baackup, and reconfigure the optimization period.
I could have allocated a spare database entirely to refbase. However, I have nearly ten distinct domains hosted under that single account, and our policy has been that each hosted domain is allocated a single database, which is shared among apps by configuring each app with a distinct database table prefix.
Yesterday I discovered that refbase has a rudimentary facility for configuring table prefixes, which evidently is not much used, because on my first page load after configuration, I triggered the following bug:
$query = "SELECT allow_add, allow_edit, allow_delete, allow_download, allow_upload,
allow_details_view, allow_print_view, allow_browse_view, allow_sql_search,
allow_user_groups, allow_user_queries, allow_rss_feeds, allow_import, allow_export,
allow_cite, allow_batch_import, allow_batch_export, allow_modify_options FROM " . $pfx .
$permissionType . "_permissions WHERE " . $permissionType . "_id = " .
Note the required addition of $pfx which contains my database table prefix. The adjusted name of this table in my modified db.inc.php is $tableUserPermissions, which this query does not employ.
I was intending to post this bug into the bug tracker. I was able to find the following link, but there is nothing I can find on the page to submit a new bug report, nor any indication that I must first log in to do so. I'm presently waiting to recover my forgotten password on an account I haven't used in a long while.
Occassionally I bounce off a page such as this because my browser security profile is strung too tight, but I see no evidence of that in this case.
Until I get my sourceforge credentials back, follow-ups can be brought to my attention at:
thanks for the bug report! I've fixed your issue (along with a two similar cases) in the code and uploaded the modified scripts to the bleeding-edge branch of our SVN repository. You may want to download them here:
The current revisions (901-903) of above linked files should work fine with a standard refbase-0.9.0 installation.
The 'db.inc.php' file now also has a '$tablePrefix' variable, as you suggested in our wiki. In the future, we should probably use a table prefix (such as "rb_") by default which would ease installation of refbase on a shared host. However, I haven't changed this yet, since it may cause unexpected issues for current users upon update. We'll have to think about this a bit more...
Hope this helps, Matthias
Much thanks for the fast response. I was just on my way back to document that I had just tripped over user_permissions on line 3194 of includes.inc.php but you beat me to it with your fix (which I confirmed in the new SVN diff). I'll update my code with your new changes straight away.
Glad you like it! Let us know if you discover any other bugs or misbehaviour.
Thanks again for the report, Matthias