Fix radio buttons with e.g. o001

[bhilbert4]

Resolves #990

This PR fixes the bug that was causing entries such as o001 to show up in the list of filename suffixes in the radio buttons for an individual file.

Previously, the suffix of the file was being found by assuming that it was the 4th section of the filename (separated by '_'). This doesn't work for crf files because they have an extra section that lists the association value, immediately before the 'crf' suffix. By using the filename parser, this should now work correctly for all file types.

[pep8speaks]

Hello @bhilbert4, Thank you for updating !

• In the file jwql/website/apps/jwql/data_containers.py:

Line 53:34: E126 continuation line over-indented for hanging indent
Line 217:64: E226 missing whitespace around arithmetic operator
Line 1116:17: W503 line break before binary operator
Line 1117:17: W503 line break before binary operator
Line 1118:17: W503 line break before binary operator
Line 1119:17: W503 line break before binary operator
Line 1539:9: E722 do not use bare 'except'

Comment last updated at 2022-08-17 16:32:18 UTC

[bhilbert4]

• Still needs to be tested on the test server.

[bhilbert4]

Tested on the test server and it seems to be working. The radio button for crf files now includes the name of the association (e.g. 'o001_crf'). This is because crf filenames have an extra string when you break up a filename between underscores.

I also found and fixed the bug that was causing the slider bar under the image to always list the image as '1/NaN' integrations. There was a typo in the directory being searched for jpgs. I also tweaked the code a bit so that the value now used in place of the NaN is the the total number of integrations in the file, rather than the number of integrations for which we have created preview images. These numbers are only different for exposures that have more than 100 integrations, which means only TSO observations I think. But using the true number of integrations is much less confusing than the number of jpg files, since for observations with more than 100 integrations we start making preview image for every 100th integration, in order to save disk space. I also tested this on the test server and it looks good.

• Check a crfints example
  Actually, I'm not sure where to find crfints data. That will only be made if someone runs the stage 3 pipeline and feeds it calints files. I'm not sure under what situation that would happen. Maybe only for moving target (i.e. solar system) data?

[bhilbert4]

I just checked the Jupiter observations from commissioning and there are no crfints files in the filesystem. So maybe we assume this fix is ok for those too and fix it if we find a problem in the future?

If you agree @mfixstsci then this is ready for review.

[mfixstsci]

LGTM.

[mfixstsci]

@bhilbert4 I went reviewed and fixed conflicts. Anything else before merging?

[bhilbert4]

@mfixstsci I think it's ready to go!