Hi,

In my site only a certain user role has the "access gallery" permission, other users can only see images that have been explicitly exposed via g2image blocks within the content.

Therefore I need to be able to remove the "Gallery" tab from the Drupal Search form to prevent unauthorised users searching the Gallery and seeing the other images.

There seems to be no option for this the "Gallery Settings" pages in Drupal so in desperation I tried disabling (and later even uninstalling) the Search plugin in Gallery Site Admin -> Plugins. The Drupal "Gallery Settings" pages now report that Gallery Search is not working, but the "Gallery" tab still appears on the Drupal Search form -- and it still works too!!

This means that any visitor to the site can search the gallery and get a list of results with thumbnails.

When a visitor then clicks on those thumbnails they get Access Denied pages (since they do not have permission to use the Gallery).

Since it seemed impossible to remove or disable the Gallery Search feature, I tried to stop the thumbnails in the results from attempting to link to the gallery pages, by putting "none" in the "image link" box of the "Gallery Settings" search tab. This didn't do anything either, the hyperlinks remain - so I seem to be stuck.

I wonder what is the point in being able to restrict the "access gallery" permission to certain user roles if any site visitor can still see the contents of the gallery anyway via the non-removable gallery search form?

This is unsatisfactory, I want to be able to remove the "Gallery" tab from the Drupal Search form. If that is not possible, neutralising the Gallery search so it yields no results would at least be a start as it would prevent unauthorised users seeing the Gallery contents. At the very least, being able to stop these results from attempting to link to the Gallery pages would prevent users from encountering access denied errors.

Thus far I have been quite impressed with the Gallery2/Drupal integration, but this appears to be a pretty major flaw.

Is anyone else aware of this? Are there any workarounds/fixes?

Thanks..

Comments

profix898’s picture

profix898 CreditAttribution: profix898 commented

Hi Jon! Thanks for reporting. I was NOT aware of this "major flaw" ... and I agree that it must be addressed. The desired behavior is that the "Gallery" tab on the search page vanishes when "access gallery" is denied or the "Search" plugin is disabled in G2. I think users with "access gallery" and "search content" permissions in Drupal should be able to search the Gallery content. Do you think we should have separate permissions for G2 search? I will need to try it myself, but you can expect this fixed within 48 hours.

jonbowyer’s picture

jonbowyer CreditAttribution: jonbowyer commented

Thanks for your prompt and helpful response :)

I suspect that some will find it convenient to have the granularity offered by a seperate "search gallery" permission, but if it's a lot more work to do then just having the Gallery Search tab disappear when the user does not have the "access gallery" permission then maybe it's mot worth the extra effort.

For my purposes I just want a way of hiding that "Gallery" tab from visitors who are not logged in, so I don't mind which way it's done.

Cheers again,

Jon

profix898’s picture

profix898 CreditAttribution: profix898 commented

I would love to commit a patch for this to cvs, but for some reason I'm unable to access the cvs repository at the moment (http://drupal.org/node/239319).

jonbowyer’s picture

jonbowyer CreditAttribution: jonbowyer commented

Whilst you are waiting on CVS issues being resolved, could you make the patch available in some other way, e.g. by putting it on a webserver or FTP server where I can download it?

I would like to fix this ASAP as the website I am working on is "going live" tomorrow and I want to fix this before then!

Thanks,

Jon

profix898’s picture

profix898 CreditAttribution: profix898 commented
Status: Active » Fixed

Fixed in 5.x-2.x-dev.

jonbowyer’s picture

jonbowyer CreditAttribution: jonbowyer commented

Thanks - seems to fix the problem :)

I have a quick question re module upgrades that follows from this; this is only the second time I have updated a module from one version to another, the first such update being upgrade of the menu_stp module from v 5.x-0.x-dev to 5.x-1.x-dev.

What I have done to replace gallery 5.x-2.0 with your new 5.x-2.x-dev version is the same as what I did to upgrade menu_stp. My procedure in both cases was:

1. Disable the existing version of the module in admin->site building->modules
2. Delete the module's whole directory from [drupal dir]/modules/
3. Extract the new version's tar file into [drupal dir]/modules
4. Re-load the admin->site building->modules page and enable the new version of the module.

In both cases this seemed to work, but I am a bit concerned about the statement on the modules page you should run update.php whenever you update a module.

I have just tried doing this but it said "No updates available" for all modules, so I didn't proceed further with it.

What I want to ask is whether I should be doing this "update" anyway despite it saying there are no updates available?

My instincts (especially when it comes to a live site) are to leave well alone - I don't want to mess with the database unnecessarily and risk breaking my site!

If someone could explain what this update.php actually does to the database, what the update selection dropdown boxes on it are selecting etc I might understand better what it is for and when I should run it in the future. I have searched around on this a bit and havent found a decent explanation anywhere!

Thanks again for fixing the Gallery module :)

Jon

profix898’s picture

profix898 CreditAttribution: profix898 commented

Updating a module is basically a 2-step procedure:
1. Replace the existing module with the new sources
2. Make sure your database is up-to-date by running update.php

In case you are not upgrading to a new major version of Drupal or a contributed module, for example 5.x-2.0 to 5.x-2.1, there is no reason to disable the module prior to replacing the sources. Simply put your site in maintenance mode, override the sources and run update.php.

A module implements hook_update_N() in its .install file whenever it is necessary to make changes to the database. If you run update.php and it tells you that there are no updates available, it simply means that there are no db changes required (and you can skip or execute the update, both resulting in no changes to the db at all). Drupal internally stores the database revision (equal to the highest N of hook_update_N() implemented) for each module. If you replace the sources of a module with a newer version and the module maintainer added a new hook_update_N() executing update.php runs that new update function(s) once and increments the revision.
That said, the above is not entirely true. Actually it is always a good idea to run update.php after replacing source files, because it wipes all cache tables (including js/css cache, node filter cache, etc.), rebuilds the theme registry, the menu tree, node types, etc. So even if no changes are announced (by implementing hook_update_N) its is still possible that you dont properly update your module because of obsolete data in the database (especially in the cache tables).

jonbowyer’s picture

jonbowyer CreditAttribution: jonbowyer commented

OK thanks for that info.

What are the risks to running update.php then? The warnings about backing up your DB beforehand etc make it sound like a major (and risky) operation and therefore make me not want to run it except when absolutely necessary.

Do things sometimes go wrong in an update, and if so, how badly?

Cheers again :)

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.