Reviewing Internal Note Badge MR and Mailer Preview Testing

TL;DR

• Reviewed an MR that adds an internal note badge (HTML and plain text) to emails triggered when a note is added on a confidential issue or Epic
• Tested via GDK’s /rails/letter_opener by creating a note, marking it internal, and manually calling the notify method
• Explored the permission system for viewing internal notes, noting reporters may lack access that developers have
• Found that the mailer preview uses a hard-coded ‘user.last’ (a bot without permissions), so it doesn’t show the badge, unlike the GDK admin view
• Confirmed via Claude that the system blocks emails to users without permission, but the mailer preview bypasses this check since it generates the email directly through the notify create service

Testing the Internal Note Badge

I’ve been reviewing an MR that adds an internal note badge in HTML and plain text for emails triggered from someone adding a note on a confidential issue. If you add a note or comment on a comment thread, and it’s a confidential issue or Epic, the email notification sent to anyone subscribed will have an internal note badge. To test this, I went to GDK and navigated to /rails/letter_opener. In the rails console, I grabbed a project, user, and an issue from the database, created a new note marking it as internal, then manually called the notify class using the notify method for the note issue email, providing the user ID and note ID, and delivering it. This showed up in the letter opener UI.

Permissions and the Mailer Preview Discrepancy

There’s a permission that controls whether someone can create or view internal notes—for example, a reporter may not be able to see them, but a developer might. Creating a confidential issue should automatically send an email, but I questioned why subscribing to an issue would let someone receive confidential notes without the necessary permission. In GDK, as an admin, I saw the badge correctly. But in the mailer preview, a hard-coded preview picks a user via ‘user.last’—the last ID in the database, which turned out to be a bot without permissions—so the preview didn’t show the badge. I confirmed through Claude that the system normally blocks emails from going to users without permission, but the mailer preview bypasses this because it generates the email directly using the notify create service, circumventing the permission check I still need to verify.