adityachandelgit
Idea: Email Providers should be implemented similarly to Auth Settings
I have no idea why we might need multiple email providers. The app configuration should be allowed to define via ENV variables
@astappiev Honestly, I’m not entirely sure why I initially added support for multiple email providers :)
Maybe the idea was to support both a self-hosted mail server and something like Gmail simultaneously. Technically, this could be managed via environment variables, but I personally prefer keeping .env and YAML files lean and handling most of the configuration through the UI for better clarity and flexibility.
That said, I’d love to hear your thoughts on why configuring via env vars might be the better route in your view, maybe there’s a use case or operational benefit I’m overlooking.
Additionally it would be nice, if the admin don't has to configure mail-recipients manually. Instead it should, when hitting quick send, grab the users mail-address and send the book to the user via its mail-address.
If you think about kindle for example this a a address of Amazon to send the books to, so it has to be a different address than the one for the login so a Passwort reset reaches the user. But I think it would be good if the users can add device emails (if this is not possible yet)
Maybe an possible solution could be to move the "recepient Emails" into the users context instead of a global context.
That said, I’d love to hear your thoughts on why configuring via env vars might be the better route in your view, maybe there’s a use case or operational benefit I’m overlooking.
Having configuration separate from app data is always a good pattern. If I ever have an issue with my current instance, I have two options:
- Restore from a back-up, hoping that they work as intended and that the issue isn't beyond the backup retention window
- Start from scratch, entirely.
If configuration was done through env variables, the second scenario would be much simpler - I would e.g. not have to define my email provider, OIDC provider, libraries location... all over again.
It also allows to have configuration centralised across different services. For example, I'm using NixOS (but that's equally valid for something like Ansible etc). I could define my OIDC client both in my provider and in Booklore through the same configuration, in the same location.
It also allows patterns like automated secret rotation. Using something like OpenBao/HashiCorp Vault and their respective agents, one can easily provide a new credential every X hours/days/months, and reload the service when the credential changes. Doing something like that when the configuration is, as far as I can tell, entirely stored in the database is... well, not trivial.
I'm absolutely not saying that this should be a priority for Booklore, but just sharing some perspective as of why people tend to like being able to provide configuration through environment variables.
Maybe an possible solution could be to move the "recepient Emails" into the users context instead of a global context.
This is why I was reading this issue - the current situation of recipients being defined server-wide is definitely not ideal.
