allow users to manage their first/last name from Account Settings

[Alex-Jordan]

This is mostly so that a user can go to Account Settings and change their first and last name. That is, if they have the new permission allowing them to do that.

This also now prints the effective user ID in the page title, to be clear which user is being altered. The individual items already said the first and last name of the user being edited, but now that we could be editing first and last names, it seemed appropriate to put the effective user ID front and center.

A few cosmetic changes:

• remove "Change" from all the sections of the Course Config page. It seems unnecessary and would now be even more repetitive than it already is.
• change the button to use "Save" instead of "Change"
• make the read-only fields visually appear as plain text

Overall that page could probably look a little better with some layout design work. But that is for another time.

This may need changes, so I'm not opening a parallel hotfix for now.

[drgrice1]

I think that this sort of thing is starting to go beyond hotfix territory. This isn't a bug, but a new feature really.

[Alex-Jordan]

That sounds good. I was wondering when/where we would draw a line.

[somiaj]

I do see you mention the issue with this and the LTI updating the users name. Would it be worthwhile to just disable the ability to change a user's name if $LMSManageUserData is set vs making instructors configure things properly?

[Alex-Jordan]

$LMSManageUserData might be set, but the course could not be using LTI at all.

[somiaj]

If it isn't fully possible to determine if users are using an LMS, then it is fine to let instructors deal with issues that arise of a student changing their name only to be reset to the LMS.

[Alex-Jordan]

Personally I feel that $LMSManageUserData should be off by default (but it is on by default). If something changes with a user's metadata in the LMS, then immediately changing that in the WW course without notifying the instructor seems like it could cause confusion. So I have it turned off for PCC. Maybe that informs my opinion on this too much.

[dlglin]

I personally want student metadata to stay in sync with the LMS, so I would leave $LMSManageUserData on regardless of the default.

It might also be good to add a note in the LTI config reminding people that by default users can change their email address in WW, so they may want to review the permissions for changing email (and now name).

[Alex-Jordan]

This week there was a Runestone student whose last name in the LMS has a "wide character" (although in this case, I suspect it's either been corrupted or it was a data entry error). Having the LMS enforce that would lead to seeing errors about a wide character. We changed their name in WeBWorK to make the error clear up. (Of course, maybe WeBWorK should be ok with that kind of name though.)

…

On Wed, Aug 21, 2024, 9:07 AM Danny Glin ***@***.***> wrote: I personally want student metadata to stay in sync with the LMS, so I would leave $LMSManageUserData on regardless of the default. It might also be good to add a note in the LTI config reminding people that by default users can change their email address in WW, so they may want to review the permissions for changing email (and now name). — Reply to this email directly, view it on GitHub <https://protect2.fireeye.com/v1/url?k=31323334-501d2dca-3132feb7-454455534531-35a1b18db6d83e5d&q=1&e=097cc22e-0493-43d3-9a74-ac60bde76eb7&u=https%3A%2F%2Fgithub.com%2Fopenwebwork%2Fwebwork2%2Fpull%2F2526%23issuecomment-2302457194>, or unsubscribe <https://protect2.fireeye.com/v1/url?k=31323334-501d2dca-3132feb7-454455534531-9bbda98bf2c097ab&q=1&e=097cc22e-0493-43d3-9a74-ac60bde76eb7&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABEDOADU7D47UJPP4FKQESLZSS3NTAVCNFSM6AAAAABMV3FD4WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBSGQ2TOMJZGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Alex-Jordan]

I updated this so that the help test for $LMSManageUserData explains that you should review the permissions for changing one's name and email address.

[drgrice1]

I think this generally looks good other than changing how the custom options page_title is done.

[drgrice1]

You mentioned that a student had a "wide character" in their name from the LMS. Wide characters are allowed in names for webwork. For example, you can use Hebrew characters in a name. So there must be something else going on with the name that had the issue. Perhaps it is something with the particular character.

[Alex-Jordan]

OK, I made the changes described here.

The name where that happened had some sort of character modification character in it. IIRC, it was a character that places a small vertical line under the preceding character. So some kind of "accent" character. It was clearly wrong, as the student's name in other places had a regular ASCII letter in place of that special character.

I don't have the details written down though, this was over a Zoom session with a Runestone subscriber.

The original reason that we prefer $LMSManageUserData to be 0 at PCC, is that some faculty use the section and recitation fields in special ways. They manually put the students in groups using these fields. And we found that when $LMSManageUserData is 1, the instructor's section/recitation entries would get obliterated.

[dlglin]

The original reason that we prefer $LMSManageUserData to be 0 at PCC, is that some faculty use the section and recitation fields in special ways. They manually put the students in groups using these fields. And we found that when $LMSManageUserData is 1, the instructor's section/recitation entries would get obliterated.

Is it worth adding functionality to customize which user data fields are managed by the LMS? Perhaps have $LMSManageUserData accept an array of fields which should be updated from data in the LMS, and any fields not in the array are left alone?