PDF doesn't rename

edited yesterday at 4:59pm
Hi,

I just noticed that one particular pdf is resistant to being renamed.
This pdf should have the [call-number] variable output at the beginning of the filename, but somehow it's not doing it.
(I'm aware that the "Application Number" field matches this variable, but that also doesn't work).
This is in troubleshooting mode. Other pdfs rename just fine.
https://s3.amazonaws.com/zotero.org/images/forums/u452233/034o902off9swa7jm4kv.png


What can I provide to help with the debugging or is this issue known already?

Thanks.
  • dstillman Zotero Team
    edited yesterday at 5:06pm
    We just don't parse values out of Extra for file renaming. That's not something we do in general. We're transferring those to real fields when they become available, but it's primarily just a citeproc-js hack. (I think one of the few exceptions is retracted-item detection, where we do look for a DOI or PMID in Extra.)
  • Thanks.
    As mentioned though, it also doesn't work if it's in "Application Number" (which matches the call-number CSL variable.
    https://s3.amazonaws.com/zotero.org/images/forums/u452233/eb6x9qe3gcpei0zu3879.png
  • Application Number is mapped to CSL call-number. It's not a base-mapped field in Zotero itself. So, for example, switching to another item type won't offer to transfer it to the Call Number field. I don't know if it should, but it's been this way since the beginning. The distinction is basically "is another name for the same semantic field" vs. "is cited the same way".
  • (Which is to say, {{ applicationNumber }} will work.)
  • Ok. Thanks for explaining. Appreciate it.
    This call-number export is part of a larger workflow, so will need to think how I'll do that then.
  • Just use both?

    {{ callNumber }}{{ applicationNumber }}

    Only the field that exists will show up.
Sign In or Register to comment.