Upgrade Storage[Bug] Attachment title "Full Text" confusion when info is publishedVersion or acceptedVersion
I noticed that Zotero PDF auto-download used methods ['doi', 'url', 'oa', 'custom'] in this order. I use a small piece of code to inspect what open-access PDF files would be returned in case the first two methods fail:
```
var doi = "10.1103/PhysRevLett.115.171602";
var req = await Zotero.HTTP.request('POST', 'https://services.zotero.org/oa/search', {headers: {'Content-Type': 'application/json'}, body: JSON.stringify({"doi": doi, timeout: 5000}), responseType: 'json'});
return req.response;
```
My question is that I cannot understand why in so many cases the downloaded attachment title is set to be "Full Text" no matter what info given.
For example, https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.115.171602 this is a paywalled journalArticle. The 'doi' and 'url' methods fail. The open-access returns a publishedVersion (in a university repository). But the attachment title is still set to be "Full Text".
https://iopscience.iop.org/article/10.1088/0264-9381/28/11/114007 this is also a paywalled journalArticle. The open-access returns some acceptedVersion (in a university repository) and some submittedVersion (arxiv). But the attachment title is still set to be "Full Text".
https://iopscience.iop.org/article/10.1088/1126-6708/2008/02/045 this is free article. The 'doi' method should work. I expect the attachment title to be "Published version" but it's still "Full Text". WTF?? Even the open-access would return a publishedVersion info for it.
Same for other journals, e.g. 10.1007/JHEP11(2019)069 , 10.1103/PhysRevD.101.105015 , 10.22323/1.305.0002
As a result, "Full Text" can represent publishedVersion, acceptedVersion or maybe even submittedVersion (arxiv), what is the logic here?? Why use the wording "Full Text" if it's designed/intended for publishedVersion (say, when 'doi' method succeeded or when open-access returned info 'publishedVersion', use the wording "Published version", leaving the wording "Full Text" or "Unspecified" for PDFs downloaded from other untrustworthy 'url' or 'custom' methods)??
Due to this kind of confusion, I had to manually filter out publishedVersions from the others while this essentially is the info given during auto-download.
```
var doi = "10.1103/PhysRevLett.115.171602";
var req = await Zotero.HTTP.request('POST', 'https://services.zotero.org/oa/search', {headers: {'Content-Type': 'application/json'}, body: JSON.stringify({"doi": doi, timeout: 5000}), responseType: 'json'});
return req.response;
```
My question is that I cannot understand why in so many cases the downloaded attachment title is set to be "Full Text" no matter what info given.
For example, https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.115.171602 this is a paywalled journalArticle. The 'doi' and 'url' methods fail. The open-access returns a publishedVersion (in a university repository). But the attachment title is still set to be "Full Text".
https://iopscience.iop.org/article/10.1088/0264-9381/28/11/114007 this is also a paywalled journalArticle. The open-access returns some acceptedVersion (in a university repository) and some submittedVersion (arxiv). But the attachment title is still set to be "Full Text".
https://iopscience.iop.org/article/10.1088/1126-6708/2008/02/045 this is free article. The 'doi' method should work. I expect the attachment title to be "Published version" but it's still "Full Text". WTF?? Even the open-access would return a publishedVersion info for it.
Same for other journals, e.g. 10.1007/JHEP11(2019)069 , 10.1103/PhysRevD.101.105015 , 10.22323/1.305.0002
As a result, "Full Text" can represent publishedVersion, acceptedVersion or maybe even submittedVersion (arxiv), what is the logic here?? Why use the wording "Full Text" if it's designed/intended for publishedVersion (say, when 'doi' method succeeded or when open-access returned info 'publishedVersion', use the wording "Published version", leaving the wording "Full Text" or "Unspecified" for PDFs downloaded from other untrustworthy 'url' or 'custom' methods)??
Due to this kind of confusion, I had to manually filter out publishedVersions from the others while this essentially is the info given during auto-download.
That should be the reason why even when open-access returned acceptedVersion or submittedVersion, the attachment title is still incorrectly set as "Full Text". Oh nope, that's not yet the reason.
That being said, I can accept Zotero (and Web Translators) using "Full Text" to signify "Published Version", but while adopting this convention, it would be better to use something else in the function `_getTitleFromVersion` when the version really really is unspecified.
For example, I hope that when the function `Zotero.Attachments.getFileResolvers` is parsing customResolver prefs into resolvers, the resolver functions would return an object including an extra "version" or "articleVersion" field (whose values are specified in the `extensions.zotero.findPDFs.resolvers` pref). That would leave the only scenarios where the attachment title would be set as (for example) "Unspecified" / "PDF" are when the customResolvers and the open-access resolvers don't include a regular "version" field/value.
For example, for DOI: 10.1088/0264-9381/28/11/114007 , the open-access resolver returns { "url": "https://dro.dur.ac.uk/12327/1/12327.pdf?DDC63+DDD21+dul4eg", "pageURL": "https://dro.dur.ac.uk/12327/", "version": "acceptedVersion" }
File downloading by "url" failed, whereas the "pageURL" webpage invoked a "Embedded Metadata.js" translator, which incorrectly set the attachment title as "Full Text PDF", disregarding the fact that OA already told us it's not the published version and that the webpage itself does mention it's the arXiv preprint version.
I'd say the attachment title should prioritize the version info (if exists) rather than the title string returned by all kinds of Translators (which are usually unable to cover all cases and choose to return an oversimplified template string, e.g. "Full Text PDF", disregarding the version info on the webpage).
---
Edit:
Especially when the open-access resolvers have already returned the version info "acceptedVersion", please fix the current behaviour by setting the attachment title according to the version info instead of the title string returned by the translators (they mixed up different versions in an irresponsible way).