Feature request: Dynamic vault path per user

[Zepmann]

To support users having control over their own data, support dynamic construction of the path to their vaults. Currently the path is based on consecutive user ID's generated by Many Notes, starting at 1. What if more options were possible to improve interaction with other selfhosted applications?

Example:

- VAULT_DIR=/var/www/html/storage/app/private/%e/notevaults

%e is replaced with the user's email address.
%u is replaced with the first part of the user's email address, before the @.
%d is replaced with the domain name of the user's email address, after the @.

You can do some neat stuff with this. For example:

- VAULT_DIR=/mnt/data/userprofiles/%d/%u/notevaults

Which could become:
VAULT_DIR=/mnt/data/userprofiles/example.com/alice/notevaults

Alice would find all her vaults at this path.

A more predictable path allows user onboarding systems to better prepare interaction between different applications, without knowing Many Notes user ID numbers. An example would be configuring Nextcloud so users can access their own vaults through its web interface, WebDAV, etc.

This would greatly enhance data portability for those merely using systems hosted by others.

[brufdev]

I'm not a fan of those folder names either.

This is not something a normal user should worry about and it fits better in an admin panel than in the compose.yaml file. I will think about it but a slug managed by an admin seems like a good approach.

[Zepmann]

This is not something a normal user should worry about and it fits better in an admin panel than in the compose.yaml file.

I disagree. A "data dir" is exactly something I would want to control from a compose file. It makes moving the data dir so much easier. It is something you see with other software.

One does not have to exclude the other. It could be a configuration option in the admin control panel and set (overriden) by Docker.

Then again, you could also keep the data dir as it is and change how the subpath is generated and let the user decide where the data is actually stored with Docker volumes. That also works and might be simpler.

[brufdev]

I believe we are on the same page here. You already control the data directory through volume mapping in the compose.yaml file. For example:

volumes:
  - /mnt/data/userprofiles:/var/www/html/storage/app/private

The only thing you would manage from a potential admin panel is the slug for each user. It would initially be the ID, but you could change it to john for example.

[Zepmann]

Yeah. That sounds like a proper way forward with minimal changes to Many Notes. It might need to have a warning for the admin that changing this after deployment requires manual renaming of user directories. (1 -> john, etc.).

Thanks for taking this into consideration. 😃

[edit]
Please offer the following options to increase flexibility.

ID - The Many Notes user ID (as it is used now).
Username - The unique username as maintained by Many Notes or the preferred_username as provided by OIDC.
Email - The user's full email address as provided by OIDC's email scope and claim, not as the user configures. There are backend systems in which this value is unique, such as in LLDAP.