[Feature:System] Don't set given names to empty string #37
Conversation
lavalleeale
changed the title
lavalleeale
changed the title
|
Thank you very much, I placed the |
|
Sorry, now it really should be in the right place. Also, is there an example csv that can be used for local testing? |
There was a problem hiding this comment.
This change is showing OK in pgAdmin.
This line is intended to "write protect" user_preferred_givenname after a value has been inserted. That is, the CSV can change user_preferred_givenname only when it is blank. Please update this line to reflect that a blank value is now null.
I will do a more thorough test when this requested change is done.
I built my own testing tools, and they are not for public use. pgAdmin is very useful for testing queries and transactions, and it is free and open source. |
|
I can make that change if needed, but that means that if there is lag between this PR being deployed and the migration being run on main there will be a period where preferred names will not automatically be fetched for existing students. I can make a second PR once the migration is run, but for now main expects both null and empty strings to mean no preferred name. If you would still like the changes to be made here first I can also do that however, just let me know how you would like to proceed. |
|
I am the guy who manages the student auto feed in production. The auto feed system is entirely separate from Submitty. No migration is needed for the auto feed. As for the requested changes... once they are finished, I can upload the changes to production ASAP or delay or schedule for any changes being planned for Submitty itself. The code patch process for (auto feed) production takes almost no time at all. Updating the write-protect line should be my last change request, assuming that things work well when I do more thorough testing. |
|
Should this change be uploaded to production ASAP, or is there a wait period for work on Submitty? |
### Please check if the PR fulfills these requirements: * [ ] Tests for the changes have been added/updated (if possible) * [ ] Documentation has been updated/added if relevant * [ ] Screenshots are attached to Github PR if visual/UI changes were made ### What is the current behavior? <!-- List issue if it fixes/closes/implements one using the "Fixes #<number>" or "Closes #<number>" syntax --> Preferred names can both be empty strings or null to indicate the user does not have a desired preferred name ### What is the new behavior? All existing empty preferred names will be set to null and constraints are added to the database to ensure that empty preferred names cannot be added to the database in the future. ### Other information? <!-- Is this a breaking change? --> <!-- How did you test --> This is part of a series of changes starting with Submitty/SysadminTools#37 and will be followed up by more PRs to remove the handling of empty strings in the database to be able to further simplify the code to not have to handle 2 cases that both mean the user does not have a preferred name.
### Please check if the PR fulfills these requirements: * [ ] Tests for the changes have been added/updated (if possible) * [ ] Documentation has been updated/added if relevant * [ ] Screenshots are attached to Github PR if visual/UI changes were made ### What is the current behavior? <!-- List issue if it fixes/closes/implements one using the "Fixes #<number>" or "Closes #<number>" syntax --> Preferred names can both be empty strings or null to indicate the user does not have a desired preferred name ### What is the new behavior? All existing empty preferred names will be set to null and constraints are added to the database to ensure that empty preferred names cannot be added to the database in the future. ### Other information? <!-- Is this a breaking change? --> <!-- How did you test --> This is part of a series of changes starting with Submitty/SysadminTools#37 and will be followed up by more PRs to remove the handling of empty strings in the database to be able to further simplify the code to not have to handle 2 cases that both mean the user does not have a preferred name.
Currently this script is setting all users preferred names to an empty string upon running, which causes many database queries to become substantially longer to account for both values indicating no desired preferred name.