Twice now, I’ve tried to login to my Gibbon account and been told I have wrong password (though I didn’t change it).
After thinking about what might have triggered the problem, I realized that I had run the extension Data Admin Module’s “Full User Data” import, but in doing so I had left the password column empty (blank). This seems to be what caused the problem. I had exported this table earlier (using the Data Admin module), and had incorrectly assumed it would retain the original password information. Apparently it does not, and so I locked myself out of the system. Luckily I was able to retrieve the old password from my backup database and get back into the system, but just in case someone else runs into a similar problem I figured I’d post the problem and solution.
The User Data export/import also seems to cause a secondary issue with the “All Roles” column, wherein the numeric field becomes a single numeric string, instead of a list of numbers (“2001” instead of “002, 001”). At least this is what happens to me when I open the exported file in LibreOffice. This can cause a second login problem, related to “insufficient privileges”, if a user has more than one role.
So note to anyone using this module (which is great BTW!), be careful to make sure that all the data is correctly entered and in the correct format before importing.
I agree with your conclusion. Importing a blank password for all your users (including yourself) would certainly lock you out of the system. A couple ways to avoid this might be to exclude yourself from the import, re-import the passwords each time, or select “Skip this column” for the password import so it doesn’t overwrite them. Passwords aren’t stored as plain text, so they can only be exported as hashes from the database: if they exist in plain text, it’ll only be pre-import in your own files.
The problem with All Roles might be a spreadsheet formatting issue, lots of spreadsheet tools will attempt to convert numbers and dates when opening a CSV. So, it’s seeing 3 digit numbers separated by a comma, (002,001) and converting them to a whole number (2001). Depending on the software, there should be an option to turn off this kind of formatting on import. I know Excel loves to randomly turn student homerooms into dates, so it’s definitely something to keep an eye on when working with CSV files, and try to use Plain Text for all the column formats.
There’s no “Skip this column” option in the Password column
Hi Deanna,
I agree with your conclusion. Importing a blank password for all your users (including yourself) would certainly lock you out of the system. A couple ways to avoid this might be to exclude yourself from the import, re-import the passwords each time, or select “Skip this column” for the password import so it doesn’t overwrite them. Passwords aren’t stored as plain text, so they can only be exported as hashes from the database: if they exist in plain text, it’ll only be pre-import in your own files.
The problem with All Roles might be a spreadsheet formatting issue, lots of spreadsheet tools will attempt to convert numbers and dates when opening a CSV. So, it’s seeing 3 digit numbers separated by a comma, (002,001) and converting them to a whole number (2001). Depending on the software, there should be an option to turn off this kind of formatting on import. I know Excel loves to randomly turn student homerooms into dates, so it’s definitely something to keep an eye on when working with CSV files, and try to use Plain Text for all the column formats.
The password field is mandatory because importing a user with a blank password could be a very bad idea :# The import definitions are in yml and editable if needed, they can be found in resources/imports. I’ve attached an example of a full user import with no password, however this import is set to only be usable for updates and not inserting new users. Unzip it and place it in your resources/imports folder, then visit Import from File.
Thank you for your reply @ross I don’t want to have blank passwords. I only want them to retain the old ones.
I will check out the file you have given. Thanks again !
Oops looks like I was moving too quickly this morning and forgot to save the file changes before I compressed and attached the file, here’s the correct file
You’re a life saver @ross !!! I was split between entering each students details individually or informing each parent a new password ! This did the trick !
Hi flygye12, this is probably to do with the date format you are using in your Excel file. See the instructions on the import page, and it should give you some hints. Ross.
@admin Thanks Ross ! I found out, it was not a date format issue (my date was in dd/mm/yyyy format), but I had shown the first day of school as closed (special day) due to COVID-19. So the new kids were all having 01/01/1970 while the rest were having the correct date. Thanks for the help.
Hi flygye12, sounds like you got it sorted. Be sure to keep an eye on date formats, dd/mm/yyyy with slashes may still cause issues. It seems like a perfectly logical date format for many of us, but there must have been an american on the PHP dev team, because PHP treats dates with slashes as mm/dd/yyyy :# The best format to use is YYYY-MM-DD, otherwise be sure to read the snippet in the docs about how dates are disambiguated https://www.php.net/manual/en/function.strtotime.php (note #3)
