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.
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
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:
Hi,
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 ), I may chose to invest it in writing a plug-in…
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
[TEASING MODE ON]
A bit like not accepting to allow user signatures because it’s for our own good.
[TEASING MODE OFF]
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)
This is what I have for now.
I’m unsure if I should feel bad; maybe a little hacky here.
js
<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 (this.model.name) {
// Hide only the input field (name is displayed)
this.model.can_edit_name = false;
} else {
// Hide the whole section
return false;
}
}
return enables_name;
},
});
</script>
Thanks @Arkshine, this looks very much like what I need. I’ll just have to dig on how to include this into my environment , 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/Discourse.org, 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.
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?
), I may chose to invest it in writing a plug-in…
, but I’ll probably have it included by this week-end.