but that just seems like one more way in which attachment titles are/can be helpful? Since filenames are constructed from item metadata, they couldn't include that information.
To be clear, what dstillman mentions (and IIRC has since confirmed as planned) would be an _option_ to display filenames instead of attachment titles (thus mimicking ZotFile behavior in Zotero =<6), and I'd assume not the default option (which would be to display attachment titles as previously).
@adamsmith absolutely attachment titles are useful! But they're only useful within the Zotero app interface. When working with attachment files from Zotero in other applications, the fact that (afaik) there's no {{ attachmentTitle }} variable (as proposed by dstillman) means that it's difficult to distinguish one chapter from another within the same book when working with files in other applications—and @erazlogo's use case 1. was about working in other applications.
Right, but what people here are suggesting (and the current ZotFile behavior they're using and have not complained about as far as I know) is to set the attachment title to the (ZotFile-generated) filename which would make this worse, not better.
@adamsmith All I am asking for is an OPTION to set Attachment file title according to the citation information, not to do that automatically on import. Currently the only way to change Attachment Title is by typing it manually, one attachment at a time. There is already a script to change file name according to citation information. It could be adapted to attachment title. It doesn't seem too much work to accommodate me and a considerable number of other users here and on a few other threads who are asking for this feature.
@erazlogo: You didn't actually respond to adamsmith's points. As we've said repeatedly, we're going to add the option to display the filename in the items list instead of the attachment title. If you don't find the attachment titles useful, you can then ignore them. (And compared to Zotero 6, you'll no longer need to run some tedious manual step just to get the attachment title to match the filename.) If that option somehow wouldn't fulfill your needs, you'd have to explain why. Duplicating citation info in another field makes no sense to us, so it's not something we're planning to implement.
You are telling me that the way I use Zotero is "confusing" (adamsmith) and "makes no sense" (dstillman). I am not responding to these comments. These are not logical points. They are just dismissive insults.
If a user drags a PDF from the file system the attachment title does get changed according to the filename in the latest Zotero 7 version. But a user cannot do the same with files imported from online databases. That is indeed "confusing" and "makes no sense." Then the attachment title should be "PDF added by user" to be consistent.
After upcoming changes, you'll have a variable (filename) that users will be able to display in the list view but will not be able to find via search. That will also be "confusing" and will not "make sense." If data is useful enough to be displayed, it should be available via search.
@erazlogo: I'm not sure why you're interacting with us this way? Someone disagreeing with you, explaining their viewpoint, or asking for clarification isn't being rude or dismissive, and they're certainly not insulting you. You've been around long enough to know that we don't just make changes to Zotero because people demand them — we make changes when people engage with us and convince us with well-reasoned arguments.
@adamsmith and I are both genuinely trying to understand why the option we've repeatedly said we'll be adding would be insufficient for your usage.
If a user drags a PDF from the file system the Attachment Title does get changed according to the file name in the latest Zotero 7 version. […] Then the attachment title should be "PDF added by user" or something.
It's doesn't "get changed" — when it's a standalone file, there's nothing else to call it. But yes, we're likely going to start changing the attachment title to just "PDF" once metadata retrieval is run and a parent item is created if the title still matches the filename, because we don't think there's any point in duplicating either the filename or the parent row.
Again, though, you will be able to set it to show filenames in the items list and never think about attachment titles again if you don't want to. I'd also just like to reiterate that the only way you would've been getting an attachment title that matched the filename in Zotero 6 was by running a manual operation on every single file you saved from the web (or by using a plugin, which is out of scope for this discussion). And while I assume you understood this, I think many people genuinely did not understand that files saved from the web have always been automatically renamed and only got into the habit of running it manually because they thought they were renaming the file. This is the kind of tedium we try to help people save themselves from, and our proposed setting will do that while producing the same result in the items list.
But if that's not sufficient for you for some reason, you'd have to explain why.
After upcoming changes, you'll have a variable (filename) that users will be able to display in the list view but will not be able to find via search.
I mean, we can obviously change All Fields & Tags to match the filename as well and add a search condition for that in Advanced Search. But @adamsmith asked what the actual use case is for matching a child attachment by filename when it's almost certainly named using the parent item metadata, and you refused to answer.
It's doesn't "get changed" — when it's a standalone file, there's nothing else to call it. But yes, we're likely going to start changing the attachment title to just "PDF" once metadata retrieval is run and a parent item is created if the title still matches the filename, because we don't think there's any point in duplicating either the filename or the parent row.
I am not talking about a standalone file, but when an item exists already and I drag the PDF over it to create an attachment. The attachment title is then renamed according to item metadata, which makes it seem that this renaming is an expected behavior, but actually it is not.
@adamsmith asked what the actual use case is for matching a child attachment by filename when it's almost certainly named using the parent item metadata, and you refused to answer.
Users will still be able to change the attachment titles and filenames manually, no? In that case, it may be necessary to search for the filename.
With the old usage, I could match the two variables, and then display (in the list view) and search for the attachment title, knowing that I would see and find the filename. Now that the two fields are distinct by design and I cannot match them nor search for the filename, I no longer have this functionality and I will miss it.
I will adapt of course, and being able to display the filename in the list view will be great, thanks! But you are in fact taking away user agency and functionality in this (admittedly, minor) case.
I am not talking about a standalone file, but when an item exists already and I drag the PDF over it to create an attachment. The attachment then is renamed according to item metadata, which makes it seem that this renaming is an expected behavior, but actually it is not.
Oh, OK. The behavior is actually a little more complicated there. If it's the first PDF, we rename the file (on the assumption that it's the primary file), and if it's not, we don't (on the assumption that it might be supplementary materials). So the first case would be equivalent to a standalone file being recognized and we should similarly set the title to "PDF", and the second case should use the filename because that's all there is.
It's true, I never had to deal with the fact that the two variables are different.
But you did, though. Again, files saved from the web have always been renamed, and have always had a translator-set title. As we've explained, the fact that Rename File from Parent Metadata — which had zero effect on the filename of a file saved from the web — changed the title as well was essentially a bug. That's what we've fixed in Z7.
Now that the two fields are distinct by design and I cannot match them nor search for the filename, I no longer have this functionality and I will miss it.
But the fields have always been distinct by design! You were performing an extra manual step that didn't actually do what it said it was doing but had the incorrect side effect of making them the same. The fact that All Fields & Tags didn't match the filename as well has always been a bit of an oversight, specifically because in the default case the filename was different from the title. We'll fix that along with adding the setting to show filenames in the list. In practice, though, this just almost never matters, because when the filename is named after the metadata it's easier to just search for the parent. That's what @adamsmith was getting at above.
Thank you for adding filename to the search in the future--that would get me back to the functionality I need. And yes, you are right, that is definitely a better solution than the manual renaming of attachment titles.
In practice, though, this just almost never matters, because when the filename is named after the metadata it's easier to just search for the parent. That's what @adamsmith was getting at above.
I understood what @adamsmith was getting at, but I prefer to be able to search for the filename in those rare cases.
@dstillman here's an actual use case for using search to match an item by filename. Using the browser extension to import many chapters in the same book from direct.mit.edu/ is a tedious process (at least the way I do it, which I believe is the least tedious way) where I open the chapter PDF for each chapter in the browser then import the PDF. Zotero (usually) fails to recognize the book/chapter metadata or automatically rename, so each chapter ends up with a filename like "9780262305358_fb.pdf". It's tedious enough to go through and manually give each PDF a sensible title that reflects the chapter's proper name, and doubly tedious to do it twice to give it a proper filename too. So usually I just fix the title and leave the nonsensical filename intact. A few months later, let's say I run a search for PDF files on my computer using ie. macOS Finder or Spotlight or another app, and I start reading 9780262305358_fb.pdf, and then I want to find that file in Zotero, but I don't know what book it came from. That can be challenging.
Upgrade Storage
To be clear, what dstillman mentions (and IIRC has since confirmed as planned) would be an _option_ to display filenames instead of attachment titles (thus mimicking ZotFile behavior in Zotero =<6), and I'd assume not the default option (which would be to display attachment titles as previously).
{{ attachmentTitle }}variable (as proposed by dstillman) means that it's difficult to distinguish one chapter from another within the same book when working with files in other applications—and @erazlogo's use case 1. was about working in other applications.If a user drags a PDF from the file system the attachment title does get changed according to the filename in the latest Zotero 7 version. But a user cannot do the same with files imported from online databases. That is indeed "confusing" and "makes no sense." Then the attachment title should be "PDF added by user" to be consistent.
After upcoming changes, you'll have a variable (filename) that users will be able to display in the list view but will not be able to find via search. That will also be "confusing" and will not "make sense." If data is useful enough to be displayed, it should be available via search.
@adamsmith and I are both genuinely trying to understand why the option we've repeatedly said we'll be adding would be insufficient for your usage. It's doesn't "get changed" — when it's a standalone file, there's nothing else to call it. But yes, we're likely going to start changing the attachment title to just "PDF" once metadata retrieval is run and a parent item is created if the title still matches the filename, because we don't think there's any point in duplicating either the filename or the parent row.
Again, though, you will be able to set it to show filenames in the items list and never think about attachment titles again if you don't want to. I'd also just like to reiterate that the only way you would've been getting an attachment title that matched the filename in Zotero 6 was by running a manual operation on every single file you saved from the web (or by using a plugin, which is out of scope for this discussion). And while I assume you understood this, I think many people genuinely did not understand that files saved from the web have always been automatically renamed and only got into the habit of running it manually because they thought they were renaming the file. This is the kind of tedium we try to help people save themselves from, and our proposed setting will do that while producing the same result in the items list.
But if that's not sufficient for you for some reason, you'd have to explain why.
With the old usage, I could match the two variables, and then display (in the list view) and search for the attachment title, knowing that I would see and find the filename. Now that the two fields are distinct by design and I cannot match them nor search for the filename, I no longer have this functionality and I will miss it.
I will adapt of course, and being able to display the filename in the list view will be great, thanks! But you are in fact taking away user agency and functionality in this (admittedly, minor) case.