• I see. Thanks.

    Not sure about this, why not just show an icon then for the file type and file number? One more thing to edit...

    Also, how do I edit the name of the attachment rather than the file? Not in the right click where one would expect it and not in the panel.
  • I'd suggest reading the linked section again. It sounds like you're missing a bunch of things it explains, including what's actually new here, what was actually necessary before, and the reasons for the change.
  • I have read it. We shall have to presume that I am stupid as I cannot follow.
  • Had another go. You mean they are auto-generated at import and not editable? Hm...

    So, after I add the second and remove the first I have this and cannot change?

    https://s3.amazonaws.com/zotero.org/images/forums/u84240/6uyp2hyxq5kgn54ogyxs.png

    And all Z6 attachment will use file names and cannot be conformed to the new approach?

    With my deficiencies, I might still be missing things.
  • You mean they are auto-generated at import and not editable?
    From the page: "You can view and change the title and filename by clicking on the attachment and looking in the item pane."
    And all Z6 attachment will use file names and cannot be conformed to the new approach?
    From the page: "If you'd like to convert existing attachments to use “PDF” titles for consistency, you can select all items in the items list, go to Tools → Developer → Run JavaScript, and run this code:"

    More generally:
    • Zotero has always had separate attachment titles — it's not "One more thing to edit".
    • They've always been editable from the attachment's pane — but most of the time you shouldn't need to edit anything.
    • There's no reason to be manually running Rename File from Parent Metadata on every item — files have always been automatically renamed.
    • The fact that Rename File from Parent Metadata changed the title to match the filename before was a bug.
  • I have the same problem, there was no problem with Zotero6 before. The help file is too long, have you solved the problem?
    https://s3.amazonaws.com/zotero.org/images/forums/u11839746/31td6f12ly8cwzv27qfk.png
  • @longhhh: You'll need to read the linked section. This isn't a bug.
  • @dstillman OK, I got that, thank you.
  • I see that:

    "The parent item row already displays metadata such as the title and authors, and since files are generally renamed using that same metadata, Zotero doesn't show the filename directly in the items list. Instead, it uses simpler attachment titles such as “PDF” or “Ebook” for the first file of a given type or includes additional information about the source of the file (e.g., “ScienceDirect Full Text PDF” for a file saved from ScienceDirect, or “Accepted Version” or “Submitted Version” for open-access files). These separate titles avoid cluttering the items list with duplicate metadata and prevent parent items from being unnecessarily expanded when searching for titles or creators."

    So this is a new feature that is different from zotero6.
  • It's not really a new feature, no. I've updated this section to more clearly explain exactly what changed:

    https://www.zotero.org/support/file_renaming#attachment_title_handling_in_zotero_7
  • I'll give this a try, as suggested, but my first reaction is that it's counter-intuitive and not an improvement. I agree with with @sdflewrit783 that the icon indicates the file type, so a generic "PDF" as a title is pointless, as it tells the user nothing new.

    It's also a bit odd to me that additional files of a given type get their filenames as titles. If that's the case, why not do the same with the first one?

    Finally I like to see the filename as well, so that when I open it in an external viewer (my default behavior), I know what the filename is going to be.
  • @John_muccigrosso:
    the icon indicates the file type, so a generic "PDF" as a title is pointless, as it tells the user nothing new
    It's just a simple, distraction-free way of identifying the primary file, without some long title that pointlessly duplicates the parent row and messes with searches. There's a pretty specific context here — generally speaking, you have an item and you have its PDF. This is the PDF.
    It's also a bit odd to me that additional files of a given type get their filenames as titles. If that's the case, why not do the same with the first one?
    This is explained in the linked documentation. The primary attachment has a filename based on the parent item metadata, which is already shown in the row above. Additional files are likely supplementary files, so the filename is likely to be informative.
    Finally I like to see the filename as well, so that when I open it in an external viewer (my default behavior), I know what the filename is going to be.
    You can always see the filename in the right-hand pane after clicking on the attachment. But normally to open the primary attachment in Zotero you would just double-click on the parent item, so you wouldn't see the attachment title anyway.
  • Thanks for all that. I’ll try to live with this a while.

    I still find it a bit odd that the file now has three titles, as it were: the file name, the one in the pdf metadata (optional but usually there), and now this one in Zotero, which I didn’t even know about. I used to think it was just the file name. This might be the part of the model that many people won’t grok instantly.

    Since this title is purely generic, is there perhaps a way to just not show it at all? Indicate the file type of the main file with just an icon somewhere.

  • edited August 11, 2024
    I mean, you don't have to expand the parent item — as I say, you can just double-click on the parent item to open the default attachment — but if you do, there's has to be a title in the items list. There's just no reason to duplicate the parent metadata.
    I still find it a bit odd that the file now has three titles
    I think you understand this, but just to be clear, there's no "now" here. Zotero has always had attachment titles that were separate from the filename.

    Files saved from the web have always been given titles like "ScienceDirect Full Text PDF" or "Submitted Version" (while being automatically renamed based on the parent item metadata), so anyone who has used the Zotero Connector has seen similarly generic titles. They (or a plugin they used) might have done something to overwrite those with the filename, but our goal has always been to avoid unnecessarily cluttering the items list with redundant data. Z7 just goes further towards that goal.
    the one in the pdf metadata (optional but usually there)
    Zotero has never done anything with the PDF metadata, which is often absent or junk.
  • I see that there’s always been a title. I just had no idea that it existed, after years of using Zotero, which is why I say this may be confusing: I was confused. I’m not quite sure I see the benefit of attachment titles, but maybe that’s just how I work. A sensible file name is a good identifier for me.

    I was one of those people who had files automatically renamed with Zotfile (I think), so I never left those generic titles alone. I don’t know what other people do, of course, so maybe that’s unusual behavior. Again, I thought that was just the file name.

    > Zotero has never done anything with the PDF metadata, which is often absent or junk.

    I realize pdf metadata is often pretty useless, or worse.

    > I mean, you don't have to expand the parent item — as I say, you can just double-click on the parent item to open the default attachment — but if you do, there's has to be a title in the items list. There's just no reason to duplicate the parent metadata.

    My suggestion was not to include the default attachment in a list like additional ones. Not quite sure what that would look like, but it potentially lessens clutter, especially when most of the time, there’s just one attachment, at least in my setup. A duplicated file name doesn’t seem much different or worse from a generic “PDF”, though I understand the point about searching.

    So I think I get the idea. As I said, I’ll live with it for a while. It’s clear that we’ve got different expectations about what info should be where.
  • edited August 21, 2024
    Well, easy enough but some titles do not get renamed, e.g., 'Sage PDF' does not.

    var items = ZoteroPane.getSelectedItems();
    for (let item of items) {
    if (!item.isRegularItem()) continue;
    let attachment = await item.getBestAttachment();
    if (!attachment) continue;
    let title = attachment.getField('title');
    if (title.endsWith('.pdf')) {
    attachment.setField('title', 'PDF');
    await attachment.saveTx();
    }
    if (title.endsWith('.epub')) {
    attachment.setField('title', 'EPUB');
    await attachment.saveTx();
    }
    }


    Where can I find the JavaScript API documentation please?
  • The code is for renaming titles matching filenames. "Sage PDF" isn't supposed to get renamed, because it's already a simple title — just one with more information on the precise source of the file. Again, every attachment ever saved to Zotero from the web has gotten a title like that, and new attachments saved from the web will continue to get titles like that.

    You can write code to do whatever you want (and the JS API isn't relevant for that — this is basic JS string manipulation), but all we're doing here is providing an option to set titles that have already been changed to match the filename back to default simple titles. We'll be adding a menu option for that shortly so that running code manually isn't required. New titles going forward would be unchanged.
  • Thanks, I understand it by now.

    It is impossible to manipulate strings without knowing the objects and object interfaces specific to Zotero.

    Your script would not rename epubs, so I added a couple of lines. I mistyped EPUB and want to correct it not but not sure how.
  • edited August 21, 2024
    Everything you need to conditionally rename titles based on what's currently in them is in the above code, or is basic, non-Zotero-specific JS. There are no other "objects" or "object interfaces" that are relevant here.
  • I managed. Still interested in seeing the docs if they are published.
Sign In or Register to comment.