Reviewing MR: Internal Note Badge in Mailers

TL;DR

• Reviewed an MR that adds an internal note badge (HTML + plain text) to emails triggered by notes on confidential issues/epics
• Tested via GDK’s /rails/letter_opener by creating a note in rails console and manually invoking the notify method
• Explored the permission controlling who can view internal notes (e.g., reporter vs developer)
• Found that the mailer preview uses user.last, which picks a bot without permissions, so the badge doesn’t show there
• Confirmed via Claude that the system blocks emails to users without permission, but the mailer preview bypasses that check since it uses the create notify service directly

Learning about mailers via MR review

I’ve been reviewing an MR and learning quite a bit about mailers in the process. This particular MR adds an internal note badge, in both HTML and plain text, to emails triggered when someone adds a note on a confidential issue. If you add a note or reply on a comment thread and it belongs to a confidential issue or epic, the email notification sent to anyone subscribed will include an internal note badge.

Testing process

To test this, I opened GDK and navigated to /rails/letter_opener. In the rails console, I grabbed a project, user, and issue from the database, then created a new note on the issue and marked it as internal by toggling the relevant boolean. From there, I manually called the notify class’s notify method for the note issue email, passing in the user ID and note ID, and delivered it. The result showed up in the letter opener UI.

Permissions question

There’s also a permission that governs who can create internal notes. As someone on a project, I need to know whether I’m allowed to view internal notes in the first place. For example, a reporter may not have that permission, while a developer might. If I can see internal notes as a developer, that confirms I have the permission. Creating a confidential issue should automatically trigger an email.

Confusion and mailer preview discrepancy

What didn’t initially make sense to me is that if I can subscribe to an issue, I shouldn’t be able to receive confidential-related notes without the necessary permission. Yet in GDK, as an admin, I could see the internal note badge and text in both plain text and HTML. However, there’s a separate place called the mailer preview, which uses hard-coded previews that may not rely on the same project, user, or associated permissions. In the mailer preview, the user is selected via user.last, which grabs whichever user has the last ID in the database. That’s not the admin user, but a bot without permissions - which is why the badge doesn’t show up there. I still technically receive an email, though, because the mailer preview bypasses the system that would otherwise block delivery to a user without the right permission.

Confirmation

Through Claude, I confirmed that this is indeed how it works, which makes sense, so I won’t question it further. If the system normally blocks emails from going out to a user who isn’t allowed to see the internal note, then in the mailer preview we still see the note because it’s generated directly through the create notify service. Under the hood, though, there’s still a check for whether the recipient can see and create internal notes, and that’s what I need to look into next.