Zotero has always distinguished between the attachment title (Full text PDF or the like), displayed in the middle panel, and the attachment file name (visible e.g. in the right panel.
That's by design and not new in Zotero 7. If this worked different from you before, that was likely due to using Zotfile for renaming

It's not ideal that it's inconsistent, but the automatic rename gets the title from the translator (e.g. it's different for open access PDFs added from other sources). The manual rename doesn't have that information so falls back to the filename for the title

The attachment title (i.e. what's displayed in the middle panel and the bold title on the right) is typically something along the lines of Full Text PDF. You can always verify the filename under "Filename" on the right.

The attachment title is a description of what the PDF is. E.g., when you add 10.1029/2004GL020892 you get "Submitted Version" -- i.e. not the full text from the publisher, but the submitted version as deposited by the author. The attachment title provides additional search functions (e.g., if you don't want any snapshots you can search for "snapshot", select all items and delete) and is quicker to read than the filename (which, in the context of the middle-panel, presumably consists of information available in other columns for the parent item anyway).

Again, this is expected behavior and has been that way for at least a decade, probably since the beginning of Zotero.

I don't know (not something I'm involved in the decision-making on), but from past statements, I doubt they'll pref this (though they do take note of threads like this).

Got it. Thanks both of you for taking the time to explain. I see the point now with having the title carrying different information and will probably start using it that way. So yes, I have now flipped to desiring the update suggested! i.e. not changing the attachment title on a manual rename if the title is already different from the filename.

Goes to show that you can use Zotero every day, for the better part of 2 decades, and still not fully appreciate how subtle and useful it is.

thanks for explanation (I am coming from other thread)
Still, could this new behaviour of not manually renaming be opt-out, for example under flag in advanced settings? Not crucial thing, but small quality of life improvements

If the Item has "Full PDF" type pdf file, it indicated for me that I didnt processed it, and I should check this pdf as newly downloaded from internet (this is error-prone, I know), but it is useful heuristics for me, when I read/skim pdf I was changing the displayed name (without further tagging or moving to folders)

With Zotero 6, there is Zotfile, with Zotero 7 users doesnt have this plugin for renaming, I am renaming for asesthethical reason, "Full PDF" name as information is most oftern nor meaningful or helpful, a way of adding suffixes, custom names or similar thing on top of renamed pdf would be indeed beneficial (Both preprint and the published version can have name full pdf), but it can be really complicated to implement

@cjb if you are used to the way that Zotfile handles renaming in this case (as I am too), the new zotero-file addon should replicate that behaviour in Zotero 7.
https://forums.zotero.org/discussion/comment/439774/#Comment_439774

@danielborek, it's worth being clear that you were using the attachment-title behavior as a hack for your own personal workflow. You weren't even actually renaming files, since Zotero has always automatically renamed downloaded files. So even making this about file renaming isn't particularly appropriate. If your goal is just to flag something as processed, there are plenty of other ways to do that — plugins that automatically add a tag to new items that can be cleared, clicking the attachment title in the right-hand pane and adding some indicator, whatever. Again, the actual files were already being renamed, so there's no reason you had to use Rename File from Parent Metadata.

For the reasons explained above, I'd strongly recommend that, if a plugin was going to customize something related to this, it just customize whether the items list shows the filename or attachment title instead of permanently overwriting attachment titles created by Zotero. That won't make it work for your specific workflow, but your workflow isn't about filenames anyway.

Re "instead of permanently overwriting attachment titles created by Zotero" ...

Zotfile has *always* (over)written the attachment title with the same (renamed) name it has applied to the actual PDF filename. At least for the auto-renaming that Zotfile invokes during PDF download. For right-click Rename/Move, Zotfile can do some stuff that can result in the title being slightly different to the actual filename (ie the latter may have a '2' suffix added, while the title does not).

In any case it would seem reasonable that a Zotfile-coded addon for Zotero 7 would do the same as Zotfile does in Zotero v6.

@danielboek I am not able to test the operation in Zotero 7 beta. But just to be sure , do you have 'Use Zotero to Rename' set to OFF in zotero-file preferences ?

And if you do have it set to OFF, how exactly does the zotero-file behaviour differ from Zotfile's ? And does it do so for both auto-renames when downloading a PDF and also for right-click Rename/Move ?

I think we'll have to agree to disagree on this. I cannot recall a single instance where the often-arbitrary download file name applied by a journal publisher was worth preserving. Applying Zotfile renaming rules to both the title field and the actual filename has always seemed the most sensible option to me (albeit making double fields redundant; which is another way of saying separate title/filename fields are probably rarely useful).

If I look at my most recent download titles they are mostly meaningless things like ...
paper_221219.pdf
000118.pdf
10.1515_hf.2011.148.pdf
main file.pdf

I am sure there are instances where the download title from some organizations (eg government departments, legal documents) is very meaningful and important to preserve (and in those cases you would probably preserve the actual filename too ... so again, redundancy ?). So there must be a way of preserving those if needed. I just haven't come across it in my work, mainly with journal papers.

If nothing else, the 1000s of Zotfile users who are used to this behaviour will expect it to be preserved in a Zotero-7 compatible version of a Zotfile-emulating addon (ie @polygon 's zotero-file).

I understand that others have other preferences - for example the way that Zotero now handles this issue. Different preferences is why we have addons. If an addon didn't do something different to Zotero itself - like overwriting attachment titles - it wouldn't be an addon. ;)

OK, apologies if I've misinterpreted what I've been seeing/what Zotero does (not for the first time !). My use case with Zotfile is ... my use case. Thanks for clarifying the Zotero operations that I've not seen as often - because I have rarely used them.

As to my opinion that Zotfile's making the title and the filename the same is the most sensible option for me (and possibly other Zotfile users who are used to it) ... that remains the same. But I will try turning Zotfile's renaming off and see if the alternative makes sense.

As to what the "whole" thread was about, it has obviously meandered. The OP's issue was basically why Zotero v7 no longer appeared to reflect what was actually a Zotfile operation (which does not run in v7). That is the issue that has been returned to several times in the thread (amongst others) and what I was referring to - that is, what Zotfile puts in the attachment *title* field, as it appears in the main pane under the item and at the top of the right pane when the PDF is selected.

I have just checked what Zotero itself actually does (in v6, without Zotfile), to refresh my memory. Zotero downloaded the PDF, put 'Full Text PDF' in the middle pane (so my memory was just wrong - I thought Zotero put the *actual* download filename as the title there), and it put the same title above the PDF URL in the right pane (along with the actual stored filename). I also tried an in-press pre-proof. Zotero put "ScienceDirect Full Text PDF" in the main/right panes for that.

So an argument that those titles used by Zotero are clearly more meaningful than having the title match the actual renamed filename (Zotfile-style) I feel is somewhat tenuous (esp given that the ScienceDirect one says nothing about the paper being a pre-proof). That was the accurate part of my memory of what Zotero does.

I have sometimes manually added my own suffix to the same-as-filename title from Zotfile, eg where the PDF file is a google translation from another language, or where I have attached several PDFs to an item and only one is annotated, or where I want to distinguish between different versions (presumably more accurately than Zotero can).

So all in all I think it still comes down to personal preference. And I still prefer how Zotfile does it. Part of that is familiarity/consistency (I have 4000 PDFs stored in the database that way). But it's also that "PDF Full text" and "ScienceDirect Full Text PDF" (for a pre-proof) don't seem very meaningful to me. But I will try to approach any advances in Zotero's new renaming scheme in the eventual v7 release with an open mind (compared to what the Zotfile-emulating addon zotero-file does, hopefully exactly what Zotfile does). ;)

Think about it this way: if you added a meaningful suffix to the attachment title, and then you corrected an author name in the metadata and wanted to rename the file again to match, you wouldn't want to lose your manual edits! That's why the attachment title is separate from the filename, and why overwriting it doesn't make sense. Even for automatic file renaming, it'd be better to populate some other field that could be used automatically to rename the file with that info preserved. In Zotero 7, you'll be able to put, say, {{ extra }} or {{ rights }} into the filename template to add some information to the filename automatically. To support renaming multiple child attachments, we could even add support for {{ attachmentTitle }}, and then the attachment title itself (or the attachment title with a particular prefix, etc.) could be the string that was added to the filename, even if you chose to display the filename in the items list.

To support renaming multiple child attachments, we could even add support for {{ attachmentTitle }}, and then the attachment title itself (or the attachment title with a particular prefix, etc.) could be the string that was added to the filename

@dstillman, I am looking forward to the addition of the {{ attachmentTitle }} variable for renaming files. Some sites (ie. Project MUSE) offer PDF downloads for each individual chapter of a book, and the Zotero browser extension makes it easy to download them all at once, and very helpfully adds each PDF as a child nested under the same book entry. Currently, the translator automatically assigns each of those PDF files a title (not file name!) corresponding to the name of each chapter. After the addition of the {{ attachmentTitle }} variable, it would finally be possible to automatically transfer the chapter names (which Zotero displays in the attachment's Title field) to the PDF file names!

1. would be covered by _showing_ the filename instead of the attachment title as mentioned by dstillman above. I understand that's planned as an option.
3. isn't a use case but a claim that there isn't a use case for the attachment title -- which there very much is: we have the different names for different green OA articles, for PDFs linked to from google scholar, we have helped people here on the forums remove unwanted snapshots by taking advantage of attachment titles of those. All of this happens automatically on import, so not comparable to manually added tags. It's fine if you find none of that relevant to your work, but it's just not true that there is 'no need.'

Which leaves 2. as a use case, but when are you actually doing that? I find it hard to think of a scenario that doesn't have an easier solution (like, searching by the actual item title). If anything I'd find the search hits for title searches here rather confusing.