Add table/value to map user id to storage id

[PVince81]

At the moment it is very hard to find the storage of a given user, one needs to find the correct storage id (local:: or home::, also from LDAP's getHome()).

If would be much more convenient to have either a mapping table that maps user ids to numeric storage ids (numeric_id).

Also it could help solving the problems with legacy storages by having a stronger/stabler link with the storage numeric id (which isn't supposed to change)

@icewind1991 @MorrisJobke @Xenopathic @schiesbn @DeepDiver1975

[mmattel]

👍

Maybe from singular to plural, which storage ID´s are available for a particular user ID or group ID.
If you add / delete / change a storage for a user / group, this is then just a DB change with minimum efforts and immediate effect.

uID, gID, stID (columns could be extended)

Example: a user can have a (or more) stID for himself AND some additional stID´s because he is part of a group and they can be differnt ID´s ect.

To consider: having eg SMB, you can declare that a user is directed based on an stID to a remote subfolder with his name. This is not declared seperately for each user, but in general for all users in one declaration (root = $user).

[PVince81]

Or add an additional column in the oc_storages table at least.

[PVince81]

A repair step will be needed to fill the table/column for existing users.

[PVince81]

The basic requirement is at least knowing what home storage belongs to which user.
As an extension, which external storage is mapped to which user.
This PR which moves the ext storage config to the database already provides an "applicable" table which could be used for external storages: #20370

[PVince81]

@icewind1991 let's use this ticket for the fstab-like mapping table.

Can you post the columns you suggested ?

[PVince81]

@DeepDiver1975 talked with @nickvergessen and @icewind1991 and we'll need this mapping table.
As discussed in Berlin #18771 we suggested having a fstab-like table that lists mount points for all users for easier lookup. That table would also help to be able to resolve the owner of storages.

[PVince81]

WIP PR here #20768

[PVince81]

PR was merged already (oc_mounts table), closing

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.