Gallery Server Pro 2.4.7 Released

Today I released version 2.4.7 of Gallery Server Pro. All versions have been updated, but the Web Application Gallery version takes a few days to get approved by Microsoft, so be patient for that one. There are no new features in this release; only bug fixes and one web.config change:

• Various functions do not work when viewStateEncryptionMode="Always"
• Case difference in username during logon causes duplicate user album
• Username not HTML encoded
• Exception data of inner exception not logged
• Possible NullReferenceException when gallery contains images with GPS metadata
• HTML embed code contains incorrect URL when the website is installed in a virtual directory
• Role name that contains HTML cannot be assigned to user
• Cannot add/remove roles for user when membership is read-only
• embed.aspx moved from web root to \gs\ directory
• web.config change: ViewStateEncryptionMode now set to “Always”

More details can be found in the Fixed Defect Report.

To upgrade from 2.4.6, download the 2.4.7 files to your hard drive. Then replace the GalleryServerPro.*.dll files in the bin directory with those from the download. Finally, replace the following files in your gallery with their matching file in the download:

• App_GlobalResources/GalleryServerPro.resx
• gs/embed.aspx (this is a new location; you may want to keep the original embed.aspx in the root directory if you have existing bits of embed code that point to this file)
• gs/controls/myaccount.ascx
• gs/controls/albumedittemplate.ascx
• gs/controls/thumbnailview.ascx
• gs/pages/admin/manageroles.ascx
• gs/pages/admin/manageusers.ascx
• gs/pages/myaccount.ascx
• gs/script/mediaobjectview.js

If you are upgrading from a version earlier than 2.4.6, follow the instructions in the Admin Guide.

I’ll discuss a couple of the more interesting bugs.

Various functions do not work when viewStateEncryptionMode="Always"

I first learned about this issue from a user about a month ago. First, some background: One can specify that the view-state always be encrypted by setting a property in web.config:

<pages … viewStateEncryptionMode="Always">

When not specified, this setting is “Auto”, which means view-state is encrypted only when a control requests it. GSP works fine in “Auto” mode, but one of the third party controls it uses cannot handle the setting “Always”. This is the Callback control from ComponentArt, which is a nifty control I use for Ajax callbacks that is a nice balance between raw Ajax requests and the heavyweight UpdatePanel. When view-state is encrypted and the Callback control’s PostState property is set to “true”, this control fails with one of these messages:

“An error occurred while communicating with the server. Try again. Error: Invalid response from server.”

“The data could not be loaded.”

This issue affected the following functions in GSP:

• Album thumbnail paging
• Adding/editing a user on the Manage Users page
• Adding/editing a role on the Manage Roles page

While this problem has always existed, it hasn’t appeared on my radar until a few weeks ago. This is because version 5.6.1 of DotNetNuke, released January 19, 2011, started using “Always” as its default setting. DotNetNuke didn’t announce the change ahead of time because they didn’t think it would be a breaking change for anyone. But this was a big problem for GSP.

I contacted ComponentArt and they were responsive in evaluating the issue, but in the end they couldn’t provide a fix, acceptable workaround, or estimated date for a fix. So I replaced the album thumbnail paging with a traditional hyperlink architecture, where navigating to the next and previous pages is done with hyperlinks. And I re-architected the user and role management pages to use Microsoft’s UpdatePanel. In the end the changes should be largely invisible to end users.

To keep the settings consistent between the various flavors of GSP, the web.config of all versions now set this setting to “Always”. There is a small performance impact of this change (about 1-2%), so if you don’t need this extra security and want the fastest possible gallery, feel free to change this back to “Auto”.

Cannot add/remove roles for user when membership is read-only

One of the great features of Gallery Server Pro is its ability to use Active Directory integration for membership. This can be easily achieved through a few simple edits to web.config (see the Admin Guide for step by step directions). However, there has always been a limitation where one can’t add or remove roles for a user when the web application doesn’t have permission to modify Active Directory data. The Admin Guide describes a few workarounds, but I finally got around to eliminating the limitation altogether.

When clicking the Save button for a user on the Manage Users page, the gallery does two things: (1) update the user properties in the membership provider (such as e-mail address, comment, or approval status), and (2) update the list of roles the member belongs to. Starting with 2.4.7, if there aren’t any changes to the user properties, then only the role membership is updated. That is, the gallery skips a call to the membership UpdateUser() method, thereby sidestepping the possibility of the membership provider throwing a permission error. Voila – you can now manage role membership for users even when using Active Directory in read-only mode.

Better looking galleries in IE9

Gallery Server Pro makes extensive use of rounded corners and drop shadows to make a great looking gallery. While other browsers have supported these features for a while, IE has lagged behind. Now I am pleased to report that IE has finally caught up! After you upgrade to IE9 your galleries will suddenly look a little more awesome.

For example, here is a typical album as seen in IE8:

Now the same album in IE9:

The thumbnail images, the frame, and the paging controls all have nice rounded corners, and the images have a nice drop shadow effect.

When you click an image, this is what IE8 will show:

The same image in IE9:

Astute observers will notice that the IE8 screen shots *do* have a drop shadow similar to the IE9 shots. That is because years ago I decided I couldn’t wait for IE to add drop shadow support, so I implemented a complicated hack to simulate the effect with nested div tags and images. I describe the technique in this blog post. Gallery Server Pro still uses the older technique for IE 8 and earlier, but all other browsers – including IE9 – get the new CSS drop shadow. The end result is that using CSS instead of a hack results in much simpler HTML, allowing for such basic improvements as centering images. Here is an image in IE8 – notice how it is left-aligned:

 

The same image in IE9:

These are just a few of the places where better CSS support results in a better looking gallery. To get these improvements, all you need is IE9 and any version of Gallery Server Pro 2.4.0 or higher. Enjoy!

Add the Facebook comment widget to your gallery

One of the frequent requests I get is the ability for users to comment on photos and other media objects. I am considering adding this feature – in fact, it is one of the items you can vote for in the poll I am running. But today I discovered a technique for incorporating the Facebook comment widget right into your gallery. I enabled this feature on an album in the demo site so you can see for yourself. Feel free to leave a comment on one or more photos – I’ll purge them periodically.

This is not for everyone. Users need a Facebook account, and it is a little tricky to set up and maintain. For these reasons, I am reluctant to add this as a built-in feature. But for some of you this will be an excellent addition to the gallery.

Here is what it looks like:

There are a few steps getting this to work.

1. Add a script tag to the web page hosting the gallery control.

Open default.aspx in a text editor and add this line somewhere in the <head> section:

<script src="http://connect.facebook.net/en_US/all.js#xfbml=1"></script>

2. Update mediaobjectview.js

Two javascript functions in \gs\script\mediaobjectview.js must be updated to call the Facebook API. In showNextMediaObject() and showPrevMediaObject(), find this line of code:

document.body.style.cursor = "default";

Then add this line just *before* it:

if (typeof (FB) != 'undefined') FB.XFBML.parse();

Because the file is minified, it is difficult to edit, so for your convenience just grab the one used on the demo site. If you are running a different version than the one on the demo site you’ll have to manually edit the file. To make this easier, you could edit the un-minified version that is in the source code download (Website\gs\script\mediaobjectview.debug.gs) and then run it through any minifier (like this one).

3. Enable HTML editing and add the ‘fb:comments’ tag.

Log in to your gallery as an administrator and turn on HTML editing on the User Settings page. Then add ‘fb:comments’ as a valid HTML tag.

4. Update each media object caption with the Facebook HTML snippet.

For each media object where you want to enable comments, edit the caption and add this HTML after the regular caption:

               <div id="fb-root"></div>
<fb:comments href="http://www.site.com/default.aspx?moid=8274"></fb:comments>

Replace the URL with the actual URL to your media object. Notice there are several spaces before the first <div>. That is intentional, as it provides a buffer to prevent Gallery Server Pro from accidentally rendering the comment widget on the thumbnail image. Save your changes and then refresh the page. The Facebook comment widget should appear just below the caption.

Pretty cool, huh?

Updating the caption for every media object is pretty tedious, so below I describe a shortcut.

Disclaimers and caveats

BROKEN CAPTION EDITING – This technique breaks the ability to edit a caption on the single media object view. Once you comment-enable a media object, the only way to edit its caption is through the Edit Captions task available in the Actions menu. And when you do, you have to be careful not to edit the Facebook HTML that is part of the caption.

Remember, Gallery Server Pro was not designed for this comment widget, so it is kind of a hack to add it to the comment field. If you don’t like this limitation, then don’t use this technique.

NO SUPPORT – Gallery Server Pro does not provide support for the Facebook comment widget, so you are on your own. I did minimal testing and don’t know how robust it is or even whether it is a good idea. It may kill your hamster. That said, I am curious to hear your feedback and experiences.

Comment-enable your whole gallery (or just an album) in one step

Rather than update each media object one at a time, you can execute a SQL statement against the database to comment-enable all your media objects at once. Here is some example SQL – it adds the necessary Facebook HTML to any existing text in the Title column of the gs_MediaObject table.

SQLite:

UPDATE gs_MediaObject
SET Title=Title || "                <div id='fb-root'></div><fb:comments href='http://www.site.com/default.aspx?moid=" || MediaObjectId || "'></fb:comments>"

SQL Server:

UPDATE gs_MediaObject
SET Title=Title + "                <div id='fb-root'></div><fb:comments href='http://www.site.com/default.aspx?moid=" + MediaObjectId + "'></fb:comments>"
WHERE FKAlbumId=XXXX

Add a WHERE clause – like in the second SQL – to update the items in just one album. It is beyond the scope of this post to tell you how to execute SQL, so if you don’t know, you’ll have to learn or just forget the idea.

As you add objects to your gallery, you will need to manually update each caption or re-apply the SQL. But don’t run the SQL more than once against the same set of media objects, or you’ll start to get multiple copies of the Facebook HTML.

More information

To learn more about the Facebook Comments Box, read the documentation. It includes information about moderation tools to help you manage the comments.

I think some of you will really like this trick. Let me know how it goes!

Vote for the features you want to see

Now that Gallery Server Pro 2.4 is good and solid I am thinking about the next major features for 2.5. What should they be? I have a hunch, but I want to be a bit more scientific about this, so I created an online poll. Vote for the features you want to see here:

http://forum.galleryserverpro.com/yaf_postst1517_Vote-for-the-features-you-want-to-see-in-GSP.aspx

There is a very good chance that the top two or three vote-getters will make into into 2.5, so make yourself heard! And if you want a feature that isn’t listed, want to add detail, or you want to remind me of a previous feature request that is important, add your comment to that thread.

2.4.6 patched with minor bug fixes

Since releasing 2.4.6 on February 21, a few bugs have surfaced. I wanted to quickly fix them instead of making you wait for the next release, so I updated the existing 2.4.6 versions to include the fixes. These were updated today, so if you downloaded them earlier, you may want to upgrade.

These bugs were fixed:

• BUG: ArgumentOutOfRangeException on account creation page when anonymous browsing is disabled
• BUG: Auto-synch fails when images contain GPS data
• BUG: (DotNetNuke only) Auto-sync function causes error emails to not be sent
• BUG: “String was not recognized as a valid DateTime” error after enabling auto-sync in non-United States cultures
• BUG: Cannot play audio or video when option 'Allow anonymous browsing of high resolution images' is disabled

There were also a few changes in behavior for the HTTP handler that serves media files to the browser:

• A request for a resource that no longer exists now returns an HTTP 404 status code. Previously it returned 200 (OK) with an empty body. This change helps search bots know when to remove an item from its database.
• File-not-found errors are no longer logged as an error. This is because search bots re-indexing a site can generate hundreds of file-not found errors by requesting items that had been moved or deleted since the last time. This shouldn’t be treated as an error.
• A request that fails the security test now returns an HTTP 403 (forbidden) status code. Previously it return 200 (OK) but didn’t include the media file. This is basically a “best practice” change that shouldn’t have much impact.

The final change is that e-mails are no longer sent each time an auto-sync begins and ends. They are, however, logged to the error log – even though they are not errors. (Note to self: In a future version rework the error log to be an EVENT log.)

Upgrading

If your current version is earlier than 2.4.6, follow the standard upgrade instructions in the Admin Guide. If you are already on 2.4.6, just replace the following files in your bin directory with the ones from the 32-bit or 64-bit download (doesn’t matter, since these three are the same in both):

• GalleryServerPro.Business.dll
• GalleryServerPro.ErrorHandler.dll
• GalleryServerPro.Web.dll

DotNetNuke Users – Download the latest ZIP module and install just as you would a new module. The installer will ask if you want to repair the current installation. Choose yes.

Gallery Server Pro 2.4.6 Released

Less than two months after 2.4.5 was released, I am pleased to announce 2.4.6. There are a bunch of new features along with the normal collection of bug fixes.

The Admin Guide has instructions for upgrading to this version. The short story is that you use the Upgrade Wizard for upgrading from 2.3.*. To upgrade from 2.4.*, simply replace the web files with the latest version.

The philosophy behind this release was to implement the “low-hanging fruit” features that have been frequently requested but didn’t require significant resources. In the coming weeks I will post a roadmap about what is coming down the pipe.

New features

• Automatic synchronizations
• Synchronizations can be remotely triggered
• Synchronization performance increases, especially for large galleries
• Improved UI feedback during synchronizations
• Faster search performance
• ‘Embed code’ allows media objects to be added to other web sites
• New admin setting: Allow users to download media files but not entire albums
• Albums always sorted at the beginning of any thumbnail list
• Allow keeping underlying file or directory when deleting objects
• More flexibility when choosing a thumbnail image for an album
• More flexibility for generating captions for new media objects
• More metadata extracted from files, including IPTC and GPS properties
• GPS coordinates now link to Bing or Google Maps
• Admin can specify order and visibility of metadata
• jQuery path setting exposed in admin area
• Additional application details shown in admin area
• Improved thread safety
• Added support for router port forwarding scenarios
• Upgraded to jQuery 1.5
• Upgrade to latest version of SharpZipLib

Bug fixes

• Synchronization estimated time left never changes from “Calculating…”
• Album thumbnails not always correctly updated after moving media objects
• Null reference exception when HttpContext.Current.Request.Browser.Browsers is null
• E-mail notification sometimes stops working
• Anonymous user can view media object when anonymous browsing is disabled
• Titles of new objects are empty strings when metadata value contains whitespace
• Metadata window shows only the first 20 metadata items
• DivideByZeroException caused by invalid metadata
• Rating metadata imported when it has never been assigned
• User loses breadcrumb location when saving change on Gallery Settings page
• Gallery setting 'Discard the original image when it is added to the gallery' is always unchecked and cannot be enabled
• Now able to extract ZIP archives created by Hotmail

Synchronization improvements

Several changes to the synchronization area improves user feedback, performance, and gives administrators additional management options.

Performance improvements: GSP has always been able to handle hundreds of thousands of files, but around the 100,000 object mark or so the synchronization process would get noticeably slower. Database profiling revealed that significant gains could be made by adjusting one of the stored procedures and adding an index and a few statistics. There were also some changes to the API that reduced unnecessary overhead. For example, there was no need to load the metadata associated with existing media objects at the beginning of a synchronization. By modifying the code to allow for a “lightweight” version of each media object, they load much faster and put reduced pressure on the memory of the server.

The database tuning applies only to SQL Server. If you are using SQLite and are experiencing performance issues, then you should migrate to SQL Server. The Admin Guide has instructions.

Improved UI feedback during synchronization: The first step in any synchronization is to load the existing media objects into memory. When the gallery contains hundreds of thousands of items, this can take a while. Prior versions of GSP did not update the progress window during this phase, leading users to wonder what was happening or thinking the application locked up. Worse, a bug compounded the problem by sometimes incorrectly showing “Calculating…” for the entire duration of the synchronization instead of giving meaningful updates.

The bug has been fixed. And now the progress window informs the user during the initial phase where items are loaded into memory, as seen here:

Auto-sync and remotely triggered syncs: You can now schedule a synchronization to automatically occur at periodic intervals. This allows the gallery to automatically stay up to date with files and directories in the media objects directory on the server. This feature can be managed on the Albums page in the site admin area:

The scheduling logic depends on the application being kept alive by periodic HTTP requests. If no one browses the gallery, the code that checks if a sync is required never runs. As you might expect, the sync interval is only approximate, but should be reasonably accurate in any gallery that has at least a few hits per hour.

One can also remotely trigger a sync through two new web services. These web services require a password – you choose that password in the admin page shown above.

How you invoke the web service depends on how it is configured in web.config. By default, it is set to accept HTTP POST.

Faster search performance

Search performance was improved by the addition of an index on the gs_MediaObject table. If you have hundreds of thousands of objects and are still experiencing slow searches, you can further improve performance by modifying the search stored procedure to ignore metadata in searches. It is named gs_SearchGallery. Use SQL Management Studio or a similar tool to delete or comment out the section that queries the gs_MediaObjectMetadata table.

This affected SQL Server only. Again, if you are experiencing performance issues with SQLite, it is time to migrate to SQL Server.

‘Embed code’ allows media objects to be added to other web sites

You can now get embed code for any media object by clicking one of the buttons above the media object:

This embed code lets you add media objects to other sites while keeping the original files on your own server.

New admin setting: Allow users to download media files but not entire albums

One of the cool features in GSP is that users can quickly download a bunch of media objects in a ZIP archive. However, there was a potential for a user to overwhelm a server by requesting that a top level album be packaged into a ZIP file. For example, downloading the root album in a gallery with 100,000 objects causes the server to try to add 100,000 files to a ZIP archive and then transmit it to the user. Not cool.

Starting in 2.4.6, an administrator can specify that only media objects in the current album can be added to a ZIP archive:

Albums always sorted at the beginning of any thumbnail list

Previous versions of GSP added new items at the end of each album, whether they were albums or media objects. This sometimes caused albums and media objects to be mixed together in a seemingly random fashion, making it hard to quickly find an item. In 2.4.6, albums are always shown at the beginning, and media objects are always shown at the end. This cannot be overridden, even with the rearrange function.

This is similar to how Windows sorts directories and files in Windows Explorer.

Allow keeping underlying file or directory when deleting objects

Starting in 2.4.6, one can delete an album or media object from the gallery without deleting the underlying directory or file. A new option appears on the Delete objects page:

Since the directory and media files aren’t deleted, they will re-appear if you synchronize the parent album. If you want to permanently prevent items from appearing in the gallery, but you don’t want to delete them from the server’s hard drive, use one of these tricks:

• Mark the file or directory as hidden with a file utility such as Windows Explorer
• Edit the NTFS permissions on the IIS application pool identity so that it does not have access to the file or directory.

More flexibility when choosing a thumbnail image for an album

You can now select from albums in addition to media objects when choosing a thumbnail image for an album. This lets you “bubble up” an image from a nested album:

More flexibility for generating captions for new media objects

Before 2.4.6, if GSP discovered a title embedded in the metadata of an image, it used that for the media object’s caption. If not found, it defaulted to the file name. That is still the default behavior in 2.4.6, but you can now change it if you want. A setting on the Metadata page (which is also new in 2.4.6) defines the template to use when assigning captions for newly added media objects:

As you can see, the default value is {Title}, but dozens of replacement tokens are supported. A complete list is found further down on the Metadata page. Here is a partial list:

For example, say you want the title and file size assigned as the default caption. Specify a template like this:

Then, when you add a media file, the caption is automatically assigned:

You can mix hard coded text as well as HTML in the template. Note: You must have the HTML editing option enabled if you want to use HTML in the template. (Do this on the User settings page.)

More metadata extracted from files, including IPTC and GPS properties

Several third party programs allow users to embed metadata in image files. This version has improved support for extracting IPTC metadata as well as GPS data.

Note that this functionality requires .NET 3.0 or higher and that the application be running in full trust.

GPS coordinates now link to Bing or Google Maps

When an image has GPS data, a link to Bing Maps is automatically created:

If you prefer to use Google Maps, no problem. Just update the template on the Metadata page. The popup help icon contains a pre-tested template that works with Google Maps.

Admin can specify order and visibility of metadata

Control which metadata items are visible and in what order in a new admin setting on the Metadata page:

Upgrade to jQuery 1.5 /jQuery path setting exposed in admin area

Now that jQuery 1.5 is out, GSP was updated to point to the latest version. And the setting was exposed in the Site Settings – General page to make it easier to change:

There are two things to note about the jQuery URL:

1. It starts with “//”, not “http://”. This is intentional and helps improve caching performance while still supporting SSL scenarios. A good discussion can be found here.
2. It doesn’t actually reference version 1.5. Instead, the “1” you see just before jquery.min.js indicates that any 1.* version is acceptable. By doing this, GSP will automatically stay up to date with the current version of jQuery – at least until version 2 is released. If you don’t like the uncertainty this brings to your gallery (because an update could break things), then update the path to specify a particular version.

Note also the admin exposes a setting for jQuery UI. jQuery UI was added for 2.4.6 and is currently used on the Metadata page to provide the cool drag and drop functionality. I anticipate expanding its usage in the future.

Additional application details shown in admin area

A few additional pieces of information are now shown on the Site Settings – General page:

Improved thread safety

Some refactoring was done to ensure that objects are updated and iterated in a thread-safe manner.

Added support for router port forwarding scenarios

Support was added for users who configure their router to forward requests on a particular port to an internal location that may be on a different port. For example, you might expose your gallery to the world at http://www.site.com:8080, but in your router configuration you send this traffic to port 80 of a local web server.

GSP now detects this situation and behaves appropriately. This required two changes:

1. The external-facing address was explicitly assigned to all instances of the ComponentArt Callback control.
2. URLs generated by the gallery (such as a welcome email) now reflect the external address, not the internal one.

Upgrade to latest version of SharpZipLib

A user reported that GSP could not unzip files created by Hotmail. This is actually handled by a third party library called SharpZipLib. I upgraded to the latest version with the hope that it would fix the problem, but it did not. However, with a little extra work, I coded a bug fix that seems to do the trick. This tweaked version of SharpZipLib is included in 2.4.6. I reported the potential bug to SharpZipLib and hopefully they’ll incorporate the bug fix in the core product.

 

Gallery Server Pro 2.4.5 Released

Version 2.4.5 of Gallery Server Pro was released today. The WPI version should be available within a week or so soon after the release of 2.4.6. A number of bugs were fixed, including a couple of important security issues. Also, a few minor features were added to enhance usability.

To upgrade, follow the instructions in the Admin Guide.

Security fixes

Two security issues were identified and fixed:

1. Gallery admin can elevate his or her own access and that of other users.

This issue is serious because it allows a user to elevate his or her permission to that of site administrator. The vulnerability exists in two locations:

• On the Manage Users page, a gallery administrator is able to create a new user with site administration privileges.
• The User Settings page allows an administrator to specify a role that all new users are automatically added to, including a role that provides site administration access.

The gallery admin cannot directly elevate her access, but she can create a site administrator, then log in as that user, which *does* have permission to elevate the gallery admin to a site admin.

Although this vulnerability is serious, it affects few users. It is not exploitable by anonymous users or any logged on user unless they are in a role with ‘Allow administer gallery’ permission. Gallery admins are users that an administrator has already given a certain amount of trust, so they are not your average malicious user. Also, the concept of a gallery administrator is new in 2.4, so it is likely there are few accounts that are vulnerable.

2. User can delete album on 'delete objects' page without 'delete child album' permission as long as user has 'delete media object' permission.

I would be surprised if anyone is actually affected by this issue because it requires that a user be given permission to delete media objects in an album but not permission to delete albums. In this scenario, the user is still able to delete albums.

Both security issues are fixed in 2.4.5.

Complete list of bug fixes

• (Described above) Gallery admin can elevate his or her own access and that of other users.
• (Described above) User can delete album on 'delete objects' page without 'delete child album' permission as long as user has 'delete media object' permission
• User with 'delete album' permission but not 'delete media object' permission cannot access Delete objects page
• Cannot override 'Allow downloading ZIP archive' options on the Gallery Control Settings page
• Disabling 'Show Header' option on Gallery Settings page causes website title URL to be set to blank string
• Error when navigating media objects: "The server method 'GetMediaObjectHtml' failed"
• Album Owner Template role not hidden by default on Manage Users and Manage Roles pages
• (DotNetNuke only) NullReferenceException during call to PerformMaintenance() function
• (DotNetNuke only) NullReferenceException during call to AddMembershipDataToGallerySettings() function
• (DotNetNuke only) Album owner function does not work when a long username and/or long role name is involved
• Role not saved correctly when name exceeds maximum allowed length
• Thumbnail images appear below treeview
• (Stand-alone version only) Error "Connection string cannot be blank" during 2.3 to 2.4 upgrade
• User album not deleted when admin disables user album on Manage Users page

New features

• (Details below) Ability to restrict gallery admins from managing users and roles
• (Details below) Allow a gallery admin to give an existing user access to gallery
• (Details below) Album Owner Template role is unique to each gallery
• Include users who are gallery admins in the 'toggle admin' filter on Gallery Settings and User Settings pages

Ability to restrict gallery admins from managing users and roles
Allow a gallery admin to give an existing user access to gallery

Recall that each installation of Gallery Server Pro can contain multiple galleries, and each gallery can be assigned an administrator. Before 2.4.5, the following rules were enforced:

1. A gallery admin could create users and roles. (The DotNetNuke module had an additional requirement that the user must also be in the Administrators role.)
2. A gallery admin could see users and roles that have access to the gallery he or she administers, but other users and roles are hidden.

Both of these rules are appropriate in many cases, but additional flexibility was required. A site administrator might not want to allow a gallery admin to be able to create users or roles. And the second rule created an issue where a gallery admin could not give an existing user access to his or her gallery.

To solve these issues, two application-level settings were added:

By default both options are enabled. There isn’t a change in behavior for the first option, since previous versions also let gallery admins manage users and roles. But now gallery admins are able to view users and roles that do not have access to a gallery they manage. I felt that it would be fairly common for a gallery admin to want to give an existing user access to a gallery he or she manages, so that is why it is now enabled by default.

Album Owner Template role is unique to each gallery

Recall that users’ access to albums is managed by their role membership. Two features use roles behind the scenes – album ownership and user albums. If you are not sure what these are, the Admin Guide has a full discussion. The short story is that these features automatically create roles and apply them to users.

When a role is created, it is copied from a template role called the album owner template role. This role is automatically created when needed and by default is given all permissions except for admin gallery and admin site. You, as the administrator, can edit the permissions on this template role to control which permissions a user gets when they are assigned as the owner of an album or are given a new user album.

Prior to 2.4.5, this template role was named “_Album Owner Template”. There was only a single template role, regardless of how many galleries you had. This violated the concept of gallery isolation, since a single role could be edited by multiple gallery admins. For example, gallery admin Bob could edit the template role for gallery A, but so could gallery admin Vino in gallery B.

Starting in 2.4.5, each gallery gets its own template role, and it is given a name that is unique to each gallery, such as “_Album Owner Template (Gallery ID 2: 'Engineering')”

What does this mean for upgraders? Well, nothing if you never use the album ownership or user albums feature. It also doesn’t affect you if you never edited the role “_Album Owner Template”. However, if you changed the permission on this role, you will need to re-apply the same permissions to the new album owner template role. It will be created the first time it is needed – an easy way to trigger its creation is to temporarily make a user an owner of an album (do this in each gallery).

A final note: Since GSP no longer uses the original template role “_Album Owner Template”, you can safely delete it.