Bug description
The two invitation paths of the same instance send different welcome emails, and the one an
operator reaches for after a failed send is the one that cannot be acted on.
core/Command/User/Add.php:187 calls generateTemplate($user, true) — the reset-password
link is always included.core/Command/User/Welcome.php:72 calls
generateTemplate($user, $input->getOption('reset-password')) — the link is included only if
-r / --reset-password is passed.
Without that option, occ user:welcome sends a well-formed welcome email whose button points at
the instance root, which immediately redirects to the login page. The recipient has no password
yet and no way to set one, so the invitation is a dead end. Their only route is "forgot
password", which is precisely what the invitation was supposed to spare them.
Why this matters more than a default
This composes with #64151. There, occ user:add reports Welcome email sent even when the mail
never left, because the transport failure is swallowed. The operator sees success, the user
receives nothing, and the natural recovery is to re-send with occ user:welcome <uid>.
That re-send is the one without the link. So the sequence an operator most plausibly follows —
create, believe it worked, discover it did not, re-send — produces an email that cannot be used.
Both commands read as the obvious thing to run, and neither warns.
Steps to reproduce
occ user:add --display-name "Test" --email test@example.org testuserocc user:welcome testuser- Open the email and click the button.
Expected behaviour
Either the two paths agree, or occ user:welcome says what it is about to send. Concretely, one
of:
- default
user:welcome to including the reset link, matching user:add, with an opt-out for
the case where the account already has a password; or
- keep the current default and print a one-line notice when the link is omitted, e.g.
Sending without a password reset link (use --reset-password to include one).
Actual behaviour
The email is sent, the command exits 0, and nothing indicates that the button leads to a login
page the recipient cannot pass.
Nextcloud version
34.0.3 (34.0.3.2), official Docker image. Both call sites were read in the running container.
Bug description
The two invitation paths of the same instance send different welcome emails, and the one an
operator reaches for after a failed send is the one that cannot be acted on.
core/Command/User/Add.php:187callsgenerateTemplate($user, true)— the reset-passwordlink is always included.
core/Command/User/Welcome.php:72callsgenerateTemplate($user, $input->getOption('reset-password'))— the link is included only if-r/--reset-passwordis passed.Without that option,
occ user:welcomesends a well-formed welcome email whose button points atthe instance root, which immediately redirects to the login page. The recipient has no password
yet and no way to set one, so the invitation is a dead end. Their only route is "forgot
password", which is precisely what the invitation was supposed to spare them.
Why this matters more than a default
This composes with #64151. There,
occ user:addreportsWelcome email senteven when the mailnever left, because the transport failure is swallowed. The operator sees success, the user
receives nothing, and the natural recovery is to re-send with
occ user:welcome <uid>.That re-send is the one without the link. So the sequence an operator most plausibly follows —
create, believe it worked, discover it did not, re-send — produces an email that cannot be used.
Both commands read as the obvious thing to run, and neither warns.
Steps to reproduce
occ user:add --display-name "Test" --email test@example.org testuserocc user:welcome testuserExpected behaviour
Either the two paths agree, or
occ user:welcomesays what it is about to send. Concretely, oneof:
user:welcometo including the reset link, matchinguser:add, with an opt-out forthe case where the account already has a password; or
Sending without a password reset link (use --reset-password to include one).Actual behaviour
The email is sent, the command exits 0, and nothing indicates that the button leads to a login
page the recipient cannot pass.
Nextcloud version
34.0.3 (34.0.3.2), official Docker image. Both call sites were read in the running container.