Move items from one album to another

[crspybits]

Server API Design

1. Only allow album admin's to do this. This is a lot of power.

2. The owners of all of the media items to be moved must also have membership in the target/destination album.

By owners here I mean the person that triggered the initial addition of each media item.
Without this, it is possible for the media items to be moved so that the person that had uploaded the item to no longer have access to the media item.

3. We'll need to respond from this call with some detailed error results:

a) Success
b) Failed because user (mover) was not an admin
c) Failed because not all media item owners were in the target album.

iOSBasics SDK design

This is going to be a non-queued operation. It shouldn't take too much time to carry out on the server.

UI Design

1. I plan to add two menu items under "Mark all read".
   

I'm putting these towards the bottom because these items are powerful.

I'll either disable these two options or not show them for non-admin users in the album.

a) "Move items": This will operate in a manner initially like the "Share items". The user can select items, and then can move them to a different album.

b) "Move all items"

In both of these options, the user will finally select a destination album. This is analogous to the way the deletion UI operates:

[crspybits]

Hmmm. I've run into a bit of difficulty. We are not currently tracking the original uploading user of a file group.

The FileIndex table on the server has a userId field, but that is the effective owning user. If the user that originally uploaded the files in the file group was a sharing user (i.e., without cloud storage), then the userId field in the FileIndex would not be that of the sharing user.

However, this a theoretical problem, not a real problem currently. There are currently no users without cloud storage on the system aside from the few test users I added, and one used by Apple for review. And the Apple review user is in just one album, and there are no files in that album.

But, going forward I do need the capability to know, for a file group, the original uploading user. I'm going to add a new table to the system-- which I probably should have had before-- for FileGroups.

[crspybits]

Given this new FileGroup table, which has fields: userId, objectType, sharingGroupUUID, the same fields in the FileIndex are now redundant. So, I need to shift this usage.

(But, userId in the FileIndex table is the owning user; this corresponds to the owningUserId in the FileGroup table).

I need to keep the fileGroupUUID reference in the FileIndex to reference into the FileGroup table.

[crspybits]

Other Neebla tasks

I need to make sure to deal with the results of the move on:

a) The app instance that initiates the move

b) Other app instances that receive updated indexes.

An inefficient way to handle this would be to (i) delete the items from the source album, and (ii) re-download them in the destination album.

Some users who have access to the source album may not have access to the destination album, so the above strategy would work for that case as well.

Other server tasks

I need to:

[DONE] a) Check the production db and make sure there are no nil fileGroupUUID's in the FileIndex table. My change to the use of the FileGroup table assumes this.

[DONE] b) Get rid of any tests in the automated tests that work with a nil fileGroupUUID.

c) In the iOSBasics tests, get rid of any automated tests that work with a nil fileGroupUUID.

[DONE] d) In the server, don't allow deletion of just a single file without a file group. That was designed for the cases of a file that doesn't have a file group.

[DONE] e) Remove the fileUUID option from UploadDeletionRequest.

[DONE] f) Do we have a unique index in the FileIndex on fileUUID? We should.