Open phraenquex opened 2 years ago
What's needed here is for the SDF that is downloaded to contain a field with the fragment code (e.g. Mpro-x0072_0A). Probably this should be the title line (first line in the record) so that it can also happen for the molfiles (this is needed for the fragmenstein workflows).
It seems that the download dialog in Fragalysis allows to specify to create a single SDF with all fragments as well as individual files for each fragment. Both types would benefit from this field.
However note:
Thanks @tdudgeon The point of the ticket was meant to be, to fix the backend to ensure the downloaded file is always generated, and always correct.
From the comment above, it dawns on me that the original download spec (Epic 4) took the lazy route: the backend merely serves up what was generated from XChemReview. I didn't notice this, and it was definitely not what I had expected.
The proper spec is: the fragalysis backend should ensure the file is correct. If its missing the crystalIDs, it should stick them in. If the file hasn't been generated, it should do so from the individual sdfs.
It's not "ugly", it's the right place to do it; we can't rely on the upload to get it right, it's (a) far too fragile and (b) doesn't fix historic data.
Please scope out how much work is involved, so we can prioritise accordingly.
@alanbchristie I cannot check if this has been fixed because none of the mol files or sdf files are being downloaded. Only the bound pdbs. This is a major issue. You have an example here:
Apologies - the merge to master (which I was convinced had taken place) had not been done. I'm merging these changes in now to create a new latest backend.
Should be a very easy fix, for someone that knows where to look.
@alanbchristie will bug @duncanpeacock for pointers.
Here's one version of the user request:
Priority is high - this bug ticket dropped off the list back when downloads (Epic 4) were released.