Previously, we calculated whether there are at least two albums so that
we can actually perform the operation. Due to subalbums this simple
check is not sufficient anymore. Since the rules are more complicated
and we don't have all albums loaded at that point to calculate it
properly, this commit removes the check entirely and always displays
the operations.
The only disadvantage is that if an installation really has just one
album (should rarely happen), the user still sees the merge operation
(not merge all), which results in an album-list with one disabled album.
I think this is okay.
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.
Nils Asmussen