Can't remove Real Name if Admin disables themm

admin

(cpradio) #1

Okay, so Real Names are on by default, if the admin for whatever reason turns them off, users (nor staff) have the ability to remove them.

The worst part still, is the Real Name is still getting used in various locations (mostly emails – I’m not 100% sure where, as I turn off most notifications).

Here is my repro on my local instance:

  1. Ensure “enable names” is enabled.
  2. Your preferences will have an editable Name field
  3. Admin User Page does not show your Full Name (even with the option enabled)
  4. Disable the “enable names” setting
  5. Perform a hard refresh
  6. Visit your Preferences, the Name field is completely removed
  7. Admin User Page still has no Full Name field (although your full name is still being stored)
  8. Re-enable the “enable names” and perform step #2 again (after a hard refresh), you’ll see your name is still there.

During our import process, I believe the “Real Name” got set for a few of our accounts, and since we disabled the feature, we have no way of removing our “Real Names”. Sure we can have the admin re-enable the feature, but until the feature is disabled again, it would show full names everywhere.

Is there a reason we hide this field on the Preferences page when it isn’t being used? What is the harm of letting people constantly change it?

Would a PR that allows this field to be edited (even if the setting is disabled) be permitted?


(Mittineague) #2

Could it be that somehow the intent of “display name” and “edit name” got mingled?
user JSON shows
"can_edit_name":false,
though I thought that was about changing the membername.


(cpradio) #3

Here is the code (found in user_guardian.rb), it is definitely not right.

  def can_edit_name?(user)
    return false if not(SiteSetting.enable_names?)
    return false if (SiteSetting.sso_overrides_name? && SiteSetting.enable_sso?)
    return true if is_staff?
    can_edit?(user)
  end

So if SiteSetting.enable_names is false, prevent editing the name (regardless if you are staff or the user who owns that profile…

I think it should read:

  def can_edit_name?(user)
    return false if (SiteSetting.sso_overrides_name? && SiteSetting.enable_sso?)
    return true if is_staff?
    can_edit?(user)
  end

or maybe (if the sitesetting should take precedence for SSO implementations)

  def can_edit_name?(user)
    return false if (not(SiteSetting.enable_names?) && SiteSetting.sso_overrides_name? && SiteSetting.enable_sso?)
    return true if is_staff?
    can_edit?(user)
  end

That way the user can always edit their “real name” regardless of the site setting. Same with staff, and SSO will still be dependent on whether or not the implementation wants to permit such.


(cpradio) #4

I moved this to UX because the more we discussed it, the more it felt UX instead of Bug. From a UX position, I find it odd to hide a field based on a SiteSetting that is tied to the user. You are telling them, although you may have entered this data, you are no longer allowed to change/alter it. That just doesn’t seem right.


(TechnoBear) #6

As far as I’m aware, for all imported members, the “Real Name” was set (intentionally or otherwise - I don’t know) to the first part of the e-mail address. These members have no way of knowing that, and no control over it. Moreover, if any member does a search for e.g. “david”, the results will return not only those members whose user-name includes david, but also those whose real name (and for the bulk of our members, that means their e-mail address) includes david. This strikes me as something of a privacy concern.


(cpradio) #7

But that is somewhat unique to our instance (granted, I think it is in the vb importer that way…)


(TechnoBear) #8

… as far as we know. Other instances with imported members may well have a similar issue; it took us a while to discover what was happening.


(cpradio) #9

True. But the important part is, if you are going to let users enter information, that data should be editable regardless of whether the site is going to use it for anything. It shouldn’t be hidden when a feature is disabled (especially since we’ve got numerous cases where we still see the data that isn’t supposed to be used).


(TechnoBear) #10

[quote=“cpradio, post:9, topic:22934”]
the important part is, if you are going to let users enter information, that data should be editable regardless of whether the site is going to use it for anything.
[/quote]Agreed.

(And if you’re going to arbitrarily enter the information on behalf of users, it’s even more important that they know what’s been entered and have the ability to edit it. I’m just trying to say I think this is an important issue, rather than just a “wouldn’t it be nice if…” issue.)

[quote=“cpradio, post:1, topic:22934”]
Is there a reason we hide this field on the Preferences page when it isn’t being used?
[/quote]And likewise, is there a reason why we even require this information on sign-up when it (supposedly) isn’t being used?


(Kane York) #11

Because this was caused by the importer, I think a fix via the Ruby console is appropriate.

You’ll have to get the team to do this because you’re hosted, but still:

User.all.each do |u|
  u.name = u.username
  u.save
end

(Sam Saffron) #12

keep in mind this kind of stuff can blow up on big databases, entire result set is in memory at the point you are iterating.


#13

Yeah, tbh I’m not sure that it’s actually that big of a deal.
@cpradio is there an instance of it causing problems for us, or is it more a case of some staff being concerned that it will confuse people? If it’s the later, I’m not risking the database.


(Mittineague) #14

Though having a quirky UX could be confusing, IMHO the main concern is that the real names

  • are still be shown some places (eg. digests? molona or @TechnoBear know better than I)
  • when the names were from email addresses it might be a concern (even w/o the @ domain?)
  • they interfere with site Search results

#15

But I’m not sure that’s an issue, considering the digests only go to the person who’s name it is. My assumption is that they know their name already.

I guess it comes down to WHERE those names are displaying.


(Jeff Atwood) #16

Can we just run a raw SQL command to null that field where it is not currently null?


(Sam Saffron) #17

yeah that will work in this case

rails c
User.exec_sql('update users set name = null')

(Jeff Atwood) #18

Shouldn’t that be

update users set name = null where name is not null

Otherwise it will write null to all the rows, even rows where the value is already null. This has a tendency to cause massive locking problems for a bunch of unnecessary writes.


(Sam Saffron) #19

yeah, also, this is going to leave a slightly invalid full text index behind.


(cpradio) #20

No. It isn’t their own name that they are seeing. They are seeing the names of other members who were part of the posts/topics in the digests.

But we are straying away from the UX problem here. As a forum manager how does one explain to their users: we collected your full name at sign up but you can never ever update it, change it, or remove it?

Even admins can’t remove it.


#21

Ah right, yup, I understand now.
Agreed, not ideal.

I like @sam 's solution