[FEATURE] When sending a sign request send from the users email rather than the system email.

[Mojo7797]

Is your feature request related to a problem? Please describe.

The user who is requesting a document to be signed would be the best person to send the email to the person signing as they will have already received emails from that user and therefore less likely to end up in junk. Plus any response goes to the users email account.

Describe the solution you'd like

Libre sign to use the users default email address in the mail app on nextcloud to send the document

Describe alternatives you've considered

No response

Additional context

No response

[vitormattos]

Description

Implement a new policy to control how LibreSign sends notification emails:

• system (default): send via OCP\Mail\IMailer
• requester: try to send via the requester’s account using OCP\Mail\Provider\IManager

Apply this policy in MailService for:

• notifyUnsignedUser
• notifySignDataUpdated

If provider-based sending is unavailable or fails, fall back to IMailer.

Scope

• Add the backend policy provider for mail_sender_strategy
• Register the policy in the policy provider mapping
• Add the Policy Workbench setting definition using the existing UI structure, without creating a standalone page
• Read the effective policy in MailService and execute the selected strategy with fallback
• Keep the current email content and templating behavior

Out of scope

• New dedicated settings page
• user_choice strategy
• Template or content redesign
• Applying the strategy to other MailService methods in this first step

Workbench grouping

Add mail_sender_strategy to the system-behavior category in:

• src/views/Settings/PolicyWorkbench/settings/realDefinitions.ts

Acceptance criteria

• The policy supports system and requester
• The policy is available in the backend and Policy Workbench
• system preserves the current behavior
• requester attempts provider-based sending
• The system falls back to IMailer when no provider, account, or sending service is available, or when sending fails
• The strategy is applied to notifyUnsignedUser and notifySignDataUpdated
• Tests cover system, successful requester, and fallback
• No regression in the current notification flow

References

• https://docs.nextcloud.com/server/latest/developer_manual/digging_deeper/groupware/mail_provider.html

Additional context

Questions are welcome in this issue.

For higher-priority implementation, funding options can be discussed. Otherwise, this issue is open for a community contribution.

Give this repository a ⭐️ if you find LibreSign useful and would like to support the project.

[maia-andre]

I'd like to work on this one. Plan, following the scope above:

• Backend: MailSenderStrategyPolicy (mail_sender_strategy, values system | requester, default system) modeled on SignatureHashAlgorithmPolicy, registered in PolicyProviders; MailService resolves the policy for the requester (resolveForUserId on the file owner, so it also works for reminders sent from cron) and, under requester, sends through OCP\Mail\Provider\IManager (findServiceByAddress on the requester's account, IMessageSend), falling back to IMailer when there is no provider/account/sending service or when sending fails. Only notifyUnsignedUser and notifySignDataUpdated.
• Frontend: definition under src/views/Settings/PolicyWorkbench/settings/mail-sender-strategy/, added to the system-behavior category in realDefinitions.ts.
• Tests: policy provider, MailService (system, successful requester, fallback), workbench definitions spec.

Two assumptions I'll go with unless you prefer otherwise:

1. supportedScopes: ['system'] in this first step (like signing_mode), since per-user choice is out of scope.
2. Fallback logging: info when no provider/service is available, warning when provider sending throws.

One optional question: under requester, when we fall back to IMailer, would you like Reply-To set to the requester's address? Happy to leave it out if you prefer to keep the fallback identical to system.

[vitormattos]

This issue is a bit more complex than a usual good first issue and is considered Medium effort, but your proposed approach looks good. I'll assign it to you.

supportedScopes: ['system'] makes sense for this first step.

About the fallback, I think we should separate configuration from runtime behavior.

If no Mail Provider is available when the admin configures the policy, we should not allow the requester strategy to be configured, because we already know it cannot work.

The fallback makes sense when the environment changes later. For example, the Mail app is disabled, the user removes their email account, or the sending service becomes unavailable. In these cases, falling back to IMailer keeps the notification working.

I also like the Reply-To suggestion. When we fall back to the system mailer, setting Reply-To to the requester's email keeps replies going to the person who requested the signature.

I would prefer checking for an available Mail Provider instead of checking directly if the Mail app is enabled. This keeps LibreSign independent from a specific app.