Encoded the folder names, and breadcrumbs across all sections and search API's.

Pull Request: https://bitbucket.org/nfreese/django-cyversedev/pull-requests/149/igbf-2292/diff

Nowlan Freese Can you please test this ticket. Moving to Needs Testing

Merged: https://bitbucket.org/nfreese/django-cyversedev/pull-requests/149/igbf-2292/diff

I can navigate through folders with special characters, and the bread crumbs are working, but I'm seeing lots of odd behavior.

1) Search bar seems to be broken everywhere ( ? )

2) The files here - will not load in IGB. The normalName file does not cause an error, but it does not load the file. The file with special characters throws an error in IGB. I'm wondering if the public link being generated is not being encoded correctly? The public link shown in the Manage Link right panel is not encoded either.

3) The right-panels seem to be working correctly (have not run an analyses), but there's a weird behavior in the metadata. Once a species is selected the dropdown for version shows all of the options and no longer functions as a dropdown. This may not be related to your changes, though, I recently merged in some other changes from Karthik.

Fixed the Search bar issue.
Fixed the View in IGB issue, encoding the public file path in the manage link, fixed the dropdown issue in the metadata genome version.

Commit Link:
https://bitbucket.org/ckintali/latest-ck-django-cyversedev/commits/735c2ecf6d38ea8ea17a759cf037fafc83e32839

View in IGB is working.
Public file path in manage link is working.
Dropdown for genome version is working.

Search bar is working with one interesting edge case:

If you do a search for a file with special characters (stuff_Unable to render embedded object: File (&_ space _stuff.bedGraph) we get an error. If I encode the file name, no results are returned (stuff_) not found.%40%23%24%25%5E%26_%20space%20_stuff.bedGraph). However, if I try the same thing in the discovery environment, it leads to an error. If I try to hit the API directly, it also causes an error. I don't think the Terrain API can handle special characters, so I don't think there is anything we can do about it.

Closing issue.

Chaitanya Kintali

I have been testing running analyses on files/folders with special characters and have come across some edge cases.

In the Discovery Environment:
Running an analyses on a bam file with NO special characters from a directory with special characters and the output being saved to a directory with NO special characters works.
Running an analyses on a bam file with special characters from a directory with special characters and the output being saved to a directory with NO special characters does not work.
Running an analyses on a bam file with NO characters from a directory with special characters and the output being saved to a directory with special characters is not allowed.

In BioViz Connect because we always save the output to the same directory as the input (assuming in Home), if the folder has special characters, then the analysis will fail. Because the only scenario that works through the DE is when the file has no special characters and the output is saved to a folder with no special characters, there isn't anything we can do to get this to work in BioViz Connect. Effectively it seems like special characters in folders/files will trip up analyses.

Something to keep in mind if this creates issues in the future.

Nowlan Freese,

Thank you so much for testing and finding out these issues. So considering this above scenario, how would it impact https://jira.transvar.org/browse/IGBF-2304.
Even though the analyses might fail, the output folder will still be the folder from where the analyses was run ( if the file is in home section). When the user clicks on the failed analyses name he will be redirected to the output folder but he won't be able to see the output file since the analyses was failed. Should we go with this same behavior? or do something like do not redirect the user to the output folder if the analyses fails ?

I think we should be consistent and have the analyses link back the folder from where the analyses was run even if the analyses failed. That way if the analysis fails (for any reason), they will see that it fails in the Analyses log, and can then quickly link back to the folder where the file was run from. It's possible the analyses could fail for other reasons (something wrong with cluster running jobs) and that the user would want to re submit the analyses.