| Issue Number | 4802 |
|---|---|
| Summary | Modify audio import tool to check for correct file name |
| Created | 2020-03-25 16:03:39 |
| Issue Type | Improvement |
| Submitted By | Osei-Poku, William (NIH/NCI) [C] |
| Assigned To | Englisch, Volker (NIH/NCI) [C] |
| Status | Closed |
| Resolved | 2020-10-12 13:57:34 |
| Resolution | Fixed |
| Path | /home/bkline/backups/jira/ocecdr/issue.259090 |
Similarly to what you did in OCECDR-4592, please modify the audio import tool to report wrongly formatted audio pronunciation files.
The way this ticket is worded, it appears to be asking that the software confirm that each pronunciation file is really using the MP3 audio format. Is that what you wanted, or did you want the software to check the file names instead of the files themselves?
I'm certain that William is looking for a test of the file names rather than the content.
~oseipokuw, since the program is already reporting if a file listed on the spreadsheet doesn't exist I'm not sure what additional information you like to see? I'm not terribly familiar with the process but I think the spreadsheet is the driving force for the import and you would like to see what audio files are missing compared to the spreadsheet and what files are included in the *.zip file but are not not listed on the spreadsheet. Is that correct?
The problem we are trying to solve includes what I reported yesterday in OCECDR-4801. Vanessa sometimes does not follow the predetermined filename format for either the top-level zip file or the individual filename format of the mp3 files or the filenames in the spreadsheet, when she is naming them. When we try to download the files to review them, we get an error message. In order to resolve the problem, we have to get CBIIT involved to delete the file from the FTP server. This takes a long time and sometimes takes a lot of back and forth before the problem is resolved. So, in OCECDR-4592, we implemented a way to check for the filename format of the top-level file. If there is an error in the format, it is reported to us and we don't complete the download. Vanessa can then correct the filename and reload the file. However, even if she has the correct filename format for the top-level folder, there could be an error in the filename format of the individual mp3 files or the filenames in the spreadsheet. In both cases, we get an error message and are usually prevented from completing the review of the audio files until the problem is addressed. But in addressing the problem, we still must go through CBIIT. So, what we are asking for in this ticket is, for the program to not only check for the correct filename format of the top level zip file but also to check for the correct filename format of the individual mp3 files and the filenames in the spreadsheet to make sure they match and that they are in the correct format. If they are not in the correct format or they do not match what is in the spreadsheet, then it should be reported to us and it should prevent the download or import of the folder until it is corrected.
The following script has been modified to check the correct file name format of the audio zip file members.
If we detect an incorrectly formed member file name the zip file on the CDR server will be renamed to prevent it from being loaded.
This change is ready for review on DEV.
~volker With the changes in this ticket OCECDR-4893, do you think anything should be looked at again for this changes?
This ticket is checking that the members of the spreadsheet are following the agreed file name format for the *.mp3 files. I don't see that the linked ticket is changing the file name format, therefore I don't see a reason why we need to look at this ticket again.
Did the audio file name format change?
Okay. Thanks! I was just wondering.
Verified on DEV. Thanks!
Verified on QA. Thanks!
This one will be difficult to check on PROD so I will enter a new ticket if we encounter a problem.
Elapsed: 0:00:00.001625