kolibri
kolibri copied to clipboard
learningequality
The exported CSV file is not named correctly when the username and full name of the Super Admin contain characters in Unicode
Observed behavior
The exported CSV file is not named correctly when the username and full name of the Super Admin contain characters like 姚明 - when I select the option 'Generate a new log file' and then hit the Download button all I get is a file named 'download' which is without the .csv file extension. The users' export file is also without the .csv extension but is labeled with a random string of characters.
Expected behavior
The expected result is to have the exported files named correctly and containing the .csv file extension like: Home Facility test user_1542_content_session_logs.csv
User-facing consequences
Users are unable to open the exported CSV files unless they manually add the .csv file extension.
Steps to reproduce
- Install Kolibri on Windows or Ubuntu
- Create an admin user with Unicode username and full name such as 姚明
- Login with the admin user and interact with some content
- Go to Facility/Data and attempt to export Session Logs, Summary Logs or Users
Context
- Kolibri version: v0.14.7-rc2
- Operating system: Windows 10, Ubuntu
- Browser: Chrome, Firefox
Does this file name issue still happen if there are no data using Unicode characters? Or does it happen regardless of what data is in the logs?
It happens regardless of what data is in the logs yet the columns for Facility name and Username do contain the said Chinese characters.
It happens regardless of what data is in the logs yet the columns for Facility name and Username do contain the said Chinese characters.
Ah, okay, so it's not the case if you have username values like Yao Ming, the file names are correct. But if it's 姚明 the file names are incorrect?
So this is possibly just a problem with Windows and Ubuntu. If so, we should update the issue title and description to something like "The exported CSV is not named correctly on Ubuntu and Windows".
In Ubuntu at least, this doesn't seem to be an issue with saving the file - the file on disk has the correct file name, unicode included.
Seems like this is an issue with using unicode characters in the Content-Disposition header - lots more detail here: https://stackoverflow.com/questions/93551/how-to-encode-the-filename-parameter-of-content-disposition-header-in-http. Resolving this properly would probably involve us setting the file download name client side to avoid these sort of interoperability issues detailed in the stack overflow post, so I'm afraid we can't resolve this in the scope of this.
The simplest fix if we wanted to address this in the scope of 0.14.x would be to remove the facility name from the file name.
@radinamatic and @marcellamaki I'm not able to replicate this issue in both 0.15.10 and latest 0.16 so I guess it was fixed a long time ago. Tested in both Windows and Ubuntu.
