feat: provisioning sender name templates#12256
feat: provisioning sender name templates#12256olvidalo wants to merge 1 commit intonextcloud:mainfrom
Conversation
|
Thanks for opening your first pull request in this repository! ✌️ |
27e1b4b to
2625867
Compare
Signed-off-by: Marcel Schaeben <m.schaeben@uni-koeln.de>
2625867 to
c3cab02
Compare
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
|
Thanks a lot for your pr 🙏 I see the use case, but I am not sure if this is something we want to integrate. Do you know if other mail clients or platforms offer a similar feature? |
Summary
This adds configurable sender name templates to mail provisioning, allowing admins to define how the "From" sender name (e.g.,
Jane Doe <jane.doe@example.org>) is set for provisioned accounts.Currently, provisioned mail accounts use the Nextcloud display name as the sender name. This addition allows to configure different formats like "Jane Doe | Organization Name" or "Support Team" in the provisioning config. In a new multi-line text field, admins can specify one sender name template per line using the
%DISPLAYNAME%and%USERID%placeholders, for example:This creates three aliases per email address, each with a different sender name that users can choose from when composing emails. The first line is the default sender name.
Points that might be worth discussing
%DISPLAYNAME%as a default value mirroring the current version's behaviour. An empty value also falls back to just%DISPLAYNAME%. This way, updating shouldn't change anything for existing installations (but I might have missed a detail somewhere).Note
While the code is working and ready to test, this is a draft PR to gather feedback and see if this could be a candidate for merging. If so, I'll need to update the tests accordingly (which currently don't pass due to constructor changes).