For this, the album/photo contextmenus and multiselect is now
enabled for guests, but limited to the download items.
Additionally, Photo::getPublic has been extended to support
multiple photos and also optimized to use just one DB query.
This commit adds a download item to the album and albumMulti
contextMenu functions. Since the Archive class is already general
enough, we can easily support to download multiple albums. This
is especially nice, because we can now select individual albums.
Since we don't show the user invalid merge requests to send to the
server, the user would have to handcraft such requests. Only admins can
merge albums, which we trust anyway. So, let's remove this check.
Previously, we allowed that and reported an error in this case. Now,
the user can no longer select a parent album for merging it into a
subalbum. It is still checked on the server, though.
That means, when making an album public or private, all subalbums
are made public/private as well. This can be changed afterwards
by performing the opposite operation for a subalbum.
I think this is the better default, since most people probably
won't have public albums with private subalbums.
That is, albums can now contain other albums, which are shown at
the top of the album view. This required some changes to album.js
and the contextMenu.js, because this view contains now both
photos and albums.
The contextMenu on this view has been kept simple by requiring
the user to select either only albums or only photos, but not
a mixture of both.
This feature required a database change, so that the version
has been updated to 3.1.3.
At the moment, album and photo operations (make public, download,
delete, merge) are still "flat", i.e. don't respect the album
hierarchy.
