special character problem

I emailed the user and he said: He changed his username using BOINC Account Manager (BAM), and that corrected updated his username at Milkyway@Home and SETI@Home. Obviously E@H had a problem.

A second user has caused the same problem. I have taken a screenshots. The first shows the user profile without name, it should be above the profile picture. The second shows the admin interface when I searched for the users address, you can see there is a special character that can't seem to be rendered.

Last week I tried to reproduce the problem on my dev-site and on Albert@Home. But whenever I put in a special character such as a umlaut or a Chinese character, there seems to be no problem. I also tried changing the character using my browser and am_set_info.php, but again I could not reproduce it

I think step for me is to download BAM! or another account manager and see if that will reproduce this bug.

There is a user currently (July 12) in the moderation queue with no name, and again is causing problems. You may view the account profile. Could someone with access to the E@H project database look at the user table and see what exactly the special characters he is using are?

The BOINC ID of the user is 1000459. So the SQL below should work.

SELECT id,name FROM EinsteinAtHome.user WHERE id=1000459; 

I propose that after about a week, we as admins manually change his username to something else. I have already emailed him a week ago but received no response.

Problem: It turns out we as admins cannot change a user's BOINC username, only their internal Drupal username. (Other than manually updating the database.) Thus I have added a form element to the 'user edit' form which allows admins to change a user's name.

Only admins should see this element. Users still change their username in the Community Preferences form: this way the username change is not duplicated in two separate forms.

GitHub PR 2612 created to fix this.

The new code allows us admins to change the BOINC username of a user. I could change the user's name to be something other than blanks. But this doesn't solve the special character problem, whose cause is unknown.

Maybe one of the output content filters is a bit overzealous? It might also be a matter of character encoding (UTF-8) support.

A new user has appeared in the moderation queue that has no username: https://einsteinathome.org/account/42430

What's interesting here is that the user is from Scotland; there is a low-probability, but non-zero, that he is using any special UTF-8 characters in his name.

I have emailed him and asked him to change his username and give me any information he as about his username, i.e., was he using an account manager, or did he even change his username recently.

I'll quote myself (email):

It's not the same user and these cases are different than before as
these two have an empty string in boinc.user.name (checked DB) instead
of something non-printable.

https://einsteinathome.org/user/265717/edit
https://einsteinathome.org/user/42430/edit

How could that happen? That's supposed to be a mandatory field...

Re user: https://einsteinathome.org/account/42430,

He reports the following

I was changing my email address across all my BOINC accounts, going to the
individual web pages via the BOINC manager panel, clicking on individual
projects and then the 'account' button to open the web page in question. I
wasn't using an account manager...

The Einstein@home site is a little different from the norm, so I didn't visit
the community preferences page at all (mainly because I didn't notice that tab);
I merely updated my email and clicked 'save'.

I'm going to see if I can't reproduce this while also looking through the code.

Update: It's my belief this is a regression caused by me, perhaps as a result of DBOINCP-435. I'm going to open a new issue ticket for it.

Update: DBOINCP-460 created for the issue. To be clear: the two users affected Oliver identified in the moderation queue have empty usernames due to this regression, and not because of the issue from this ticket.