Skip to content

Attribute welcome invite to the admin who actually sent it - #2022

Merged
maebeale merged 2 commits into
mainfrom
maebeale/fix-confirmation-email-attribution
Jul 29, 2026
Merged

Attribute welcome invite to the admin who actually sent it#2022
maebeale merged 2 commits into
mainfrom
maebeale/fix-confirmation-email-attribution

Conversation

@maebeale

@maebeale maebeale commented Jul 29, 2026

Copy link
Copy Markdown
Collaborator

🤖 suggested review level: 3 Read 📖 small logic change plus a nullable-column migration; blast radius limited to the invite attribution

What is the goal of this PR and why is this important?

  • When an admin sent a portal invite, the account showed the action as done by the wrong person: both the "Confirmation instructions sent … by X" tooltip and the "Last updated … by X" line credited whoever previously created/edited the account (e.g. the person who registered the trainee), not whoever actually pressed Invite. Reported in Slack.

How did you approach the change?

  • Added a dedicated welcome_instructions_sent_by_id column on users and set it to the acting user at each interactive send path (UsersController#send_welcome_instructions, ProcessConfirmation#send_welcome_instructions). The tooltip now shows the sender, and drops the "by …" suffix when unknown (legacy records) rather than the stale updated_by.
  • Sending an invite writes the token + timestamps, so it bumps updated_at. Also stamp updated_by with the sender at those paths so "Last updated" agrees with the sent-by attribution instead of crediting the previous editor.
  • BulkInviteService runs without a current_user, so it leaves both fields untouched.
  • Eager-loaded the new association in the users index to avoid an N+1.

Anything else to add?

  • Legacy invited-but-unconfirmed rows have no recorded sender, so they show the timestamp without attribution instead of the previous (incorrect) name.

The "Confirmation instructions sent … by X" tooltip credited the user
record's updated_by (whoever last edited the account — typically the
person who registered the trainee), not whoever pressed Invite. Record
the sender in a dedicated welcome_instructions_sent_by column at each
send path and show that instead, dropping the attribution when unknown.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings July 29, 2026 02:07

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@maebeale
maebeale marked this pull request as ready for review July 29, 2026 02:14
Sending an invite writes to the user record (token + timestamps), so it
bumps updated_at. Leaving updated_by untouched made "Last updated … by X"
credit whoever last edited the account rather than who sent the invite —
the same wrong-attribution Rachel reported. Set updated_by to the sender
in both send paths so the update line and the sent-by tooltip agree.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings July 29, 2026 02:22

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@maebeale
maebeale merged commit cafe973 into main Jul 29, 2026
3 checks passed
@maebeale
maebeale deleted the maebeale/fix-confirmation-email-attribution branch July 29, 2026 02:30
maebeale added a commit that referenced this pull request Jul 29, 2026
)

* Credit the acting admin on updated_by across user account actions

Several admin actions write the user record (bumping updated_at) but left
updated_by pointing at whoever last edited the account — the same wrong
attribution fixed for the welcome invite in #2022. Lock/unlock, manual email
confirmation, and sending reset-password instructions all go through the
controller; email-change and manual-confirm services already accepted
current_user but never applied it. Set updated_by to the actor in each path.

The Devise confirmation flows only save when they regenerate a token, so the
services persist the attribution themselves when it's left dirty.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Clear updated_by when an invited user sets their own password

The welcome/setup flow bumps the user's updated_at but no admin is acting, so
leaving updated_by credited whoever created or invited the account. Null it out
since the actor is the account owner, not a staff member. Trim the attribution
comments added in the prior commit.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Credit signed-in admin, else the user, on welcome password set

The welcome page is public — the invited user may set their own password, or an
admin may do it on their behalf. Setting updated_by to nil (prior commit) lost
the admin attribution Justin flagged. Use current_user when present, otherwise
the account owner, so we never fall back to whoever last edited the account.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Clarify welcome updated_by comment

current_user isn't necessarily an admin — reword to reflect it's whoever is
signed in.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants