Prevent users from changing their Full Names

Hi all,

On the forum we manage, although we give a lot of leeway on the username, we required (in the terms of use) that the users provide their full names and do not change them except to reflect legal name changes. We dont’ have many users yet (less than 250), but already, some people start not respecting this rule. We therefore need a way to enforce it.

In short, we need that a full name can only be changed by a moderator or an admin after the account has been approved. Is there any way to achieve this in Discourse? I have browsed the documentation to no avail.

If not, could this feature be added to the code?



A simple but avoidable solution is to hide the edit button with CSS. Clever people could edit it anyway. To enforce keeping it you’d need a plugin or maybe sso.


Thanks for your answer. Do you know if such plugin exists already? If not, I’ll try and understand how to do this, but it’s been ages since I last coded anything :frowning:


It seems the plugin don’t exists but CSS workaround is just Inspect from Firefox or Chome clicking into the box you want to hide and edit the CSS on theme:


I think the strongest option here is to use an external authentication provider (OAuth whatever) with the “auth overrides username” option:

Overrides local full name with external site full name on every login, and prevent local changes. Applies to all authentication providers.

1 Like

That’s do the trick but including third party services, it’s not a good deal for many of us that are OK leaving users to choose their e-mail provider.

By “external”, I don’t mean “third party” but rather “external to discourse”. You could use a third-party solution, or you could run it yourself.

Trust in ourselves is different than trusting Discourse core team, they are top notch professionals that builded the whole thing.

My point is that your strongest solution is not the most elegant that should to be disabling the option from a switch.

1 Like

Thanks for the suggestion, but unfortunately, this is currently not an option. We don’t have a central SSO and its management is much more than I want to endeavor!

Currently, CSS tampering is probably the extent to which I may go. What I’m managing is a club forum, with all the members identified, and forcing this change despite it being simply disabled (and forbidden in the rules) would be cause for the user’s account to be either converted to read-only or fully disabled.

Thanks @matenauta for the links you provided, I’ll browse through this content and see if I can manage the change easily. For the long term, when I have time (I may need to wait 15+ years until retirement for this :sweat_smile:), I may chose to invest it in writing a plug-in…


Would a hybrid solution work @AriesFR ?

If you take Jay @pfaffman suggestion of hiding it with CSS then create a custom user field and have the settings as:



Uh, it could indeed work, but I still want it to appear next to the username as is currently specified for the full name.

For now, hiding the full name section from the user’s profile update section will be an OK temporary solution. I can still handle exceptions coming from users too nosey for their own good.

I still cannot understand why it seems to be such a problem to have this locking option in the base product like we have for the username… it seems very dogmatic

A bit like not accepting to allow user signatures because it’s for our own good.

I did take a look; hiding the field with the API can be done, but I can’t find any data I can rely on to know if that user is approved or not (in the preference page context) :thinking:

This is what I have for now.
I’m unsure if I should feel bad; maybe a little hacky here. :smile:

<script type="text/discourse-plugin" version="0.8">

const { setting } = require("discourse/lib/computed");

api.modifyClass("controller:preferences/account", {
  pluginId: "hide-name-in-preferences",

  get canEditName() {
    const enables_name = setting("enable_names");

    if (enables_name && this.isCurrentUser && !this.model.staff) {
      if ( {
        // Hide only the input field (name is displayed)
        this.model.can_edit_name = false;
      } else {
        // Hide the whole section
        return false;

    return enables_name;
1 Like

It’s not a problem or dogma, most of our features are prioritized based on demand, and there hasn’t been a lot of demand for this.


Thanks @Arkshine, this looks very much like what I need. I’ll just have to dig on how to include this into my environment :slight_smile:, but I’ll probably have it included by this week-end.

Thanks, I can understand prioritizing, although the global mechanism is already present and, as far as I could see, has been requested multiple times by users. If the patch really is as simple as what Arshkine just provided, it seems to me that it was a conscious choice NOT to grant the same “courtesy” to this field as it was for the others.

Don’t take me wrong, this is a wonderful piece of software that was developed here. As far as I can tell from the forum I help administer, it seems to work flawlessly, and I know how difficult this is. I just don’t agree with all the decisions that were made, and I consider some of the justifications that were given to sometimes be dogmatic or authoritative. This does not prevent it from being the best available today.


A theme component can be bypassed by using safe mode or otherwise modifying stuff in the browser.

Mostly, development is driven by people who are hosted with CDCK/, as that is where the money comes from. Sometimes features are added if lots of people want/need a feature, but if those people are not paying money to CDCK, it needs to be very many, or a feature that it seems like many paying customers will be happy to have. Note, I don’t work for them, so this is merely my observation from the past bunch of (almost 8) years.


Indeed! You may want to disable the enable safe mode setting so non-admins can’t use it.


OH! I’d missed that. It can still by bypassed by people who are clever with the brower developer console.

1 Like

Thanks, I did not see this parameter, it’s now disabled!

1 Like

Speculating: I wouldn’t be surprised if most of the people who want this and are paying customers are likely to already have an SSO of some sort. So it becomes even more of a niche feature for everyone else.


It does not sound like you are doing anything to authenticate the full name your users provide when they sign up. So if they change it from Bob Jones to Sam Smith, how do you know either name is theirs?