Additional users cannot see photos (single photo path)

[kpine]

I probably have a misunderstanding about how multiple users are supposed to work. Can multiple users share the same photo path?

I have a single directory of photos mapped to /photos in the Docker container. For the admin user I set /photos as the photo path. All the photos appear for that user. I then added a second user (another family member) and also configured that user's photo path to /photos, but no photos are visible. Are the photo paths exclusive to each user?

[viktorstrate]

Currently each users root path should be not be overlapping with other users, ie. each photo is only owned by one user.

The solution would either be to have each users directory inside of the /photos directory, like /photos/user1 and /photos/user2, otherwise multiple mounts could be set up from the docker-compose.yml config file.

The problem is that if a photo is shared between two users, it would be a waste to generate the thumbnails twice, once for each user, so it would require some changes to implement this.
Specifically albums/directories should not be bound to a specific user, and photo favourites and public shares should be bound to both a user and a photo instead of only the photo.

[numen31337]

I would like to suggest a feature that allows users to have multiple folders. In this way, it would be possible to have a shared folder across multiple accounts and individual folder for those photos that should be bound to the user. This would be very useful when setting up a family library.

[viktorstrate]

@numen31337 I think this sounds like a really good approach.
This does require some significant internal restructuring though, but I think it would be worth it for the flexibility it would give.

Proposed solution

If the database is changed such that the root_path of the users and the owner_id of albums are removed.
And instead a new many-to-many relation between users and albums is made, then multiple users can share the same album.

As all albums already have the path attribute, which describes where on the filesystem the album is located, the root_path is not neccessary, as it would be infered from the album it self.

Also public shares could still be infered, as the share_token table already has the owner_id attribute.

CREATE TABLE user (
-  root_path varchar(512),
)

CREATE TABLE album (
-  owner_id int NOT NULL,
)

+CREATE TABLE user_album_relation (
+  user_id int NOT NULL,
+  album_id int NOT NULL,
+
+  PRIMARY KEY (user_id, album_id)
+)

But this would mean that favorites would be shared across users, which is probably unwanted.
To fix this, the favorites attribute could be moved to a new table like so.

+CREATE TABLE user_media_data (
+  user_id int NOT NULL,
+  media_id int NOT NULL,
+  favorite boolean DEFAULT FALSE,
+
+  PRIMARY KEY (user_id, media_id)
+)

CREATE TABLE user (
-  favorite boolean DEFAULT FALSE,
)

Migration conserns

As this would require lots of changes to the database, I don't know if it would be possible or feasible to add automatic migrations.

If not, we would have to implement this as a major update (version 2.0.0), and current users would have to set up photoview manually again, and all user data (favorites) would be lost.

[bochachaner]

If you want to have access control, you can use the root_path to grant access.

UserA: /*
UserB: /folder1/*
UserC: /folder3/*

[viktorstrate]

This has been solved in #157 and will be released in v2.0 when it is ready.