For various annoying reasons we keep our name change window open much much longer than default. This has led people to make use of it in an interesting manner. Changing your username seems to also clear the post history of a user when you look at their profile. We understood that changing the username would break being tagged in a post but this was unexpected.
I though it was worth mentioning.
Good point. Allowing a large name change window is … not recommended. Not just for that reason, but for many others as well.
I agree that is … not recommended. So our primary reason for a long delay is that when a student registers, generally in spring, with our school we generate an account in our discourse instance. They start receiving the daily digest email at that point as it lets them get to know what is happening on campus. They may no actually start interacting with site till fall or maybe even longer so we have a large window for people to chose their presentation. The other reason is that we have a pretty large Trans population for a college and names and control over one’s own name is of particular importance to them. Which is very reasonable.
Given that people are abusing this we will have to change I think. That said I think it is a little buggy that the post history gets wiped.
In which case they have no (or very little) post history.
I guess ideally the name change time window would be similar to the delete account time window.
That is, if they have n number of posts, it can’t be changed.
The issues is that people that have been interacting with the site for a while and then are changing their names repeatedly to escape a their post history when they are being a*****es.
As I said it is an abuse issue and it exposed an interesting and unexpected side effect of changing ones name. I do not expect any real fix to this as it is a human issue.
I still think
…/lib/guardian/user_guardian.rb has
def can_edit_username?(user)
return false if (SiteSetting.sso_overrides_username? && SiteSetting.enable_sso?)
return true if is_staff?
return false if SiteSetting.username_change_period <= 0
is_me?(user) && (user.post_count == 0 || user.created_at > SiteSetting.username_change_period.days.ago)
end
So the current logic is if they have no posts OR if they have been members for less than the username_change_period settings value. (default 3 days)
I have a feeling you didn’t realize that a member can change there username any time as long as they haven’t made any posts {I know I didn’t until just now) i.e.
no actually start interacting with site till fall or maybe even longer
There is no reason for you to tweak up that setting to account for a semester break.
Our generally observation, for our setup in particular, is that people want to change their display usernames after they have interacted with the site for a little while. Since we are generating accounts for them and the users are not making an affirmative action to create an account their experience is a bit different than many discourse populations. Sites where the user is making an affirmative action to create their account have a different experience and the users are making a statement about themselves with their display username. In our case that affirmative action is when the user decides that there is enough utility in the site to decide on a display username.
Like I said I was just documenting this somewhere for others.
Very good point. I added this:
If you change your username, all prior quotes of your posts and @name mentions will be broken, and your post history will be interrupted. Are you absolutely sure you want to?
I can’t repro this, so I believe you gave me bad information? Here’s try.discourse.org user page for a given user:
Now I will rename mcwumbly to sassafras and visit their user page…
So what are you referring to here? I made a bad, confusing copyedit based on this report. I should have verified it myself first 
It stopped for us a couple weeks ago. I am not sure what changed but I was happy for the change.
