As seen in: app/assets/javascripts/discourse/templates/preferences/account.hbs 4eb54f08b {{combo-box value=newPrimaryGroupInput content=model.filteredGroups none="user.primary_group.none"}} {{/if}} {{#if canCheckEmails}} {{i18n 'user.auth_tokens.title'}} {{#each authTokens as |token|}} {{d-icon token.icon}} {{#unless token.is_active}} {{auth-token-dropdown token=token revokeAuthToken=(action "revokeAuthToken") The visibility of this section of Preferences > Account: [image] Seems to be guarded by the condition of whether the users can check their own emails. This is unexpected behavior to me as a plugin developer, because when I override the can_check_email value for that user, it also hides the Recently Used Devices, when this seemingly has nothing to do with email. The use case here is that we have SSO enabled on our site, and I’d rather not have the email label show up at all, since it is confusing for our users due to the way we integrate with our main site, and also causes inconsistencies across our sites in how we display PII, so I want to hide the email label entirely from Preferences > Account. I do not want to hide the Recently Used Devices however, since this is useful information for users / admins, but I can’t do this without overriding the template / css hacks, since both the email label and this recently used devices section use the same guard. It seems like it would make more sense if the guard was replaced with something like {{#if canCheckAuthTokens}}. (It can initially be aliased from canCheckEmails for a quick fix, just so plugin developers can differentiate between the two when overriding these values) If it is intended that this section is hidden by canCheckEmails, would anyone be able to give the semantics here as to why that makes sense? Thanks a lot!

I think canCheckEmails was used as a shortcut here because the permissions are the same. [image] Hooksmith: It seems like it would make more sense if the guard was replaced with something like {{#if canCheckAuthTokens}} . (It can initially be aliased from canCheckEmails for a quick fix, just so plugin developers can differentiate between the two when overriding these values) That sounds like a good approach to me - would be #pr-welcome if you have the time to implement it.

"Recently Used Devices" section is guarded by "canCheckEmails" which seems unexpected

Development

david (David Taylor) December 2, 2019, 3:54pm 2

I think canCheckEmails was used as a shortcut here because the permissions are the same.

That sounds like a good approach to me - would be pr-welcome if you have the time to implement it.

Topic		Replies	Views
Email preferences still show when emails are disabled Bug	6	1143	March 11, 2021
Email configuration Help Product Support email , site-settings	6	138	September 16, 2026
Hide 'email account exists' for invites Feature completed , invites	3	1255	May 25, 2022
Admins: Show a dialogue before entering email logs, log email log views Feature	0	105	October 20, 2025
How to disable Incoming Email modal Development	9	738	November 29, 2023

"Recently Used Devices" section is guarded by "canCheckEmails" which seems unexpected

Related topics