Renaming attachments directly or based on parent items doesn't change betterbibtex json attachment filename

[zanodor]

Debug log ID

U7VV7QP3-euc/7.0.5

What happened?

I tried to look for this problem among the Issues and Discussions and and hesitated before writing this up as it should be so basic that I thought it is me that must be doing something wrong.

Case is simple enough:
You realize there is a typo or some other need to rename the attachment and possibly even the parent item.
This can be done two ways:

1. Rename the parent item first and have the attachment based on the parent item (Zotero template might interfere with how long the filename can get).
2. Rename the attachement, the title and the parent item. Quite a big job.

Wait a few seconds and check the json (if you have set automatic export on changes)... -- No changes in the pdf.
Export the json manually as if doing the export for the very first time for the whole library. -- No changes in the pdf. Rename not reflected.

Current workaround to get the rename updated: manually change BibTex key: this will change the citeKey and adds a property to the Extra YAML key with this change.
Then check the json: the rename update is reflected now.

Is there some way to spare all this, or am I dumb enough to keep doing something wrong?

I tried to create for you some debug lines but not sure what you can make of this. I tried to go up and didn't see the relevant parts.
Then in the meantime I sent the log but not sure if that caught anything, so I kept this for you:

(3)(+0000000): UPLOAD BATCH:

(3)(+0000000): [ "0": { "key": "VVSH4KV9" "version": 19407 "extra": "Citation Key: WeszpremiKalmanMagyarzsido" "tags": [ "0": { "tag": "📘" } "1": { "tag": "#magyarságkutatás/zsidó-héber-szemita-talmud/zsidó-leleplezés" } "2": { "tag": "#zsidó-héber-szemita-talmud/zsidó-leleplezés" } "3": { "tag": "#zsidó-leleplezés" } ] "dateModified": "2025-01-16T22:03:23Z" } ]

(3)(+0000000): Uploading 1 item

(3)(+0000000): Sending If-Unmodified-Since-Version: 19409

(3)(+0000000): [ConcurrentCaller] Running function (0/4 running, 0 queued)

(3)(+0000001): HTTP POST "[{"key":"VVSH4KV9","version":19407,"extra":"Citation Key: WeszpremiKalmanMagyarzsido","tags":[{"tag":"📘"},{"tag":"#magyarságkutatás/zsidó-héber-szemita-talmud/zsidó-leleplezés"},{"tag":"#zsidó-héber-szemita-talmud/zsidó-leleplezés"},{"tag":"#zsidó-leleplezés"}],"dateModified":"2025-01-16T22:03:23Z"}]" to https://api.zotero.org/users/9697111/items

(3)(+0000043): {better-bibtex: <7.0.5 65JF53YN>} sync started

(4)(+0000035): SELECT A.itemID FROM items A WHERE 1 AND A.itemID NOT IN (SELECT itemID FROM deletedItems) AND libraryID=? [1]

(3)(+0000001): Creating string pref 'extensions.zotero.translators.better-bibtex.autoExport.C%3A%5CUsers%5CODOR%5CDocuments%5CObsidian%5CCORPUS%5CSYSTEM%5CZOTERO%5Cbibliography%2ejson'

(3)(+0000281): HTTP POST https://api.zotero.org/users/9697111/items succeeded with 200

(3)(+0000000): [ConcurrentCaller] Done with function (0/4 running, 0 queued)

(4)(+0000001): Tags haven't changed

(4)(+0000000): Relations have not changed for item 1/VVSH4KV9

(4)(+0000000): Field 'dateAdded' has not changed

(4)(+0000000): Field 'dateModified' has not changed

(3)(+0000000): Collections have not changed for item 19771

(3)(+0000000): Saving to sync cache:

(3)(+0000000): [ "0": { "key": "VVSH4KV9" "version": 19410 "library": { "type": "user" "id": 9697111 "name": "zanodor" "links": { "alternate": { "href": "https://www.zotero.org/zanodor" "type": "text/html" } } } "links": { "self": { "href": "https://api.zotero.org/users/9697111/items/VVSH4KV9" "type": "application/json" } "alternate": { "href": "https://www.zotero.org/zanodor/items/VVSH4KV9" "type": "text/html" } } "meta": { "numChildren": 1 } "data": { "key": "VVSH4KV9" "version": 19410 "itemType": "document" "title": "Weszprémi Kálmán – A magyarországi zsidóságról – a magyarországi zsidók statisztikája" "creators": [] "abstractNote": "" "publisher": "" "date": "" "language": "" "shortTitle": "" "url": "" "accessDate": "" "archive": "" "archiveLocation": "" "libraryCatalog": "" "callNumber": "" "rights": "" "extra": "Citation Key: WeszpremiKalmanMagyarzsido" "tags": [ "0": { "tag": "#magyarságkutatás/zsidó-héber-szemita-talmud/zsidó-leleplezés" } "1": { "tag": "#zsidó-héber-szemita-talmud/zsidó-leleplezés" } "2": { "tag": "#zsidó-leleplezés" } "3": { "tag": "📘" } ] "collections": [ "0": "KYLKQNSP" ] "relations": {} "dateAdded": "2024-02-19T02:14:59Z" "dateModified": "2025-01-16T22:03:23Z" } } ]

(4)(+0000000): INSERT OR REPLACE INTO syncCache (libraryID, key, syncObjectTypeID, version, data) VALUES (?, ?, ?, ?, ?) [1, 'VVSH4KV9', 3, 19410, '{"key":"VVSH4KV9","version":19410,"library":{"type":"user","id":9697111,"name":"zanodor","links":{"alternate":{"href":"https://www.zotero.org/zanodor","type":"text/html"}}},"links":{"self":{"href":"https://api.zotero.org/users/9697111/items/VVSH4KV9","type":"application/json"},"alternate":{"href":"https://www.zotero.org/zanodor/items/VVSH4KV9","type":"text/html"}},"meta":{"numChildren":1},"data":{"key":"VVSH4KV9","version":19410,"itemType":"document","title":"Weszprémi Kálmán – A magyarországi zsidóságról – a magyarországi zsidók statisztikája","creators":[],"abstractNote":"","publisher":"","date":"","language":"","shortTitle":"","url":"","accessDate":"","archive":"","archiveLocation":"","libraryCatalog":"","callNumber":"","rights":"","extra":"Citation Key: WeszpremiKalmanMagyarzsido","tags":[{"tag":"#magyarságkutatás/zsidó-héber-szemita-talmud/zsidó-leleplezés"},{"tag":"#zsidó-héber-szemita-talmud/zsidó-leleplezés"},{"tag":"#zsidó-leleplezés"},{"tag":"📘"}],"collections":["KYLKQNSP"],"relations":{},"dateAdded":"2024-02-19T02:14:59Z","dateModified":"2025-01-16T22:03:23Z"}}']

(3)(+0000000): [ConcurrentCaller] All tasks are done

(4)(+0000003): Beginning DB transaction 6QbdQKDj

(4)(+0000011): Item 19771 has not changed

(4)(+0000000): Updating database with new library data

(4)(+0000000): UPDATE libraries SET version=? WHERE libraryID=? [19410, 1]

(4)(+0000001): UPDATE items SET version=19410 WHERE itemID IN (?) [19771]

(4)(+0000000): UPDATE items SET synced=1 WHERE itemID IN (?) [19771]

(4)(+0000002): Committed DB transaction 6QbdQKDj

All the best
Z.

[github-actions]

🤖 this is your friendly neighborhood build bot announcing test build 7.0.5.7584 ("log cache by name")

This update may name other issues, but the build just dropped here is for you; it just means problems already fixed in other issues have been folded into the work we are doing here. Install in Zotero by downloading test build 7.0.5.7584, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".

[retorquere]

Then in the meantime I sent the log but not sure if that caught anything, so I kept this for you:

The log did capture an error. New log from build 7584 please.

[zanodor]

Installed:

D682467095
I can't get any other debug id from it no matter how much I click.

I checked the json, the renames didn't happen.
I didn't go toward the workaround (yet), especially because the rename changed the citationKey form as well, but as I said, no difference.
Only the parent item title is changed while on my hard drive the new filename is there, Zotero also sports the new names.

[zanodor]

I did some more testing:

1. When file (and parent item) rename involved changing of first string and consequently contributed to the changing of the citationKey, manual export of bibliography json resulted in the proper new filenames in the json. But automatic saving didn't achieve that.
2. When file (and parent item) rename involved trimming off last string (or more) and didn't contribute to the changing of the citationKey, even manual export of json didn't result in updating the pdf filename to the new one.

[retorquere]

D682467095

These go to Zotero. I have no access to these.

I can't get any other debug id from it no matter how much I click.

There isn't anything in the Help menu? No Better BibTeX or File.io?

I checked the json, the renames didn't happen.

The test build only adds logging, it's not a fix, I don't know what the problem is yet. The errors in U7VV7QP3-euc say you're accessing a non-existent cache, I need to know what is happening there.

I did some more testing:

I need to address the existing problem in U7VV7QP3-euc first, and I really need logs to work. Scenario explanations only really help when accompanied by a log.

[zanodor]

If I click BBT Help or right-click menu to send debug, I have no confirmation that it was sent. I am on blind mode here.

Some logs:

(3)(+0000000): HTTP POST "[{"key":"EHHIZZ24","version":19472,"title":"Heribert Illig – The Invented Middle Ages (Toronto conference 2005).pdf","dateModified":"2025-01-17T14:59:31Z","md5":"","mtime":""}]" to https://api.zotero.org/users/9697111/items

(3)(+0000168): {better-bibtex: <7.0.5.7584 9WRB9VUT>} sync started

(3)(+0000036): HTTP POST https://api.zotero.org/users/9697111/items succeeded with 200

(3)(+0000001): [ConcurrentCaller] Done with function (0/4 running, 0 queued)

(4)(+0000001): Tags haven't changed

(4)(+0000000): Relations have not changed for item 1/EHHIZZ24

(4)(+0000000): Field 'dateAdded' has not changed

(4)(+0000000): Field 'dateModified' has not changed

(4)(+0000000): Note hasn't changed

(3)(+0000000): Saving to sync cache:

(3)(+0000000): [ "0": { "key": "EHHIZZ24" "version": 19473 "library": { "type": "user" "id": 9697111 "name": "zanodor" "links": { "alternate": { "href": "https://www.zotero.org/zanodor" "type": "text/html" } } } "links": { "self": { "href": "https://api.zotero.org/users/9697111/items/EHHIZZ24" "type": "application/json" } "alternate": { "href": "https://www.zotero.org/zanodor/items/EHHIZZ24" "type": "text/html" } "up": { "href": "https://api.zotero.org/users/9697111/items/2Z9NNY3A" "type": "application/json" } } "meta": { "numChildren": 0 } "data": { "key": "EHHIZZ24" "version": 19473 "parentItem": "2Z9NNY3A" "itemType": "attachment" "linkMode": "imported_file" "title": "Heribert Illig – The Invented Middle Ages (Toronto conference 2005).pdf" "accessDate": "" "url": "" "note": "" "contentType": "application/pdf" "charset": "" "filename": "Heribert Illig – The Invented Middle Ages (Toronto conference 2005).pdf" "md5": null "mtime": null "tags": [] "relations": { "dc:replaces": "http://zotero.org/users/9697111/items/TAP7LNQF" } "dateAdded": "2023-06-10T21:16:40Z" "dateModified": "2025-01-17T14:59:31Z" } } ]

(4)(+0000001): INSERT OR REPLACE INTO syncCache (libraryID, key, syncObjectTypeID, version, data) VALUES (?, ?, ?, ?, ?) [1, 'EHHIZZ24', 3, 19473, '{"key":"EHHIZZ24","version":19473,"library":{"type":"user","id":9697111,"name":"zanodor","links":{"alternate":{"href":"https://www.zotero.org/zanodor","type":"text/html"}}},"links":{"self":{"href":"https://api.zotero.org/users/9697111/items/EHHIZZ24","type":"application/json"},"alternate":{"href":"https://www.zotero.org/zanodor/items/EHHIZZ24","type":"text/html"},"up":{"href":"https://api.zotero.org/users/9697111/items/2Z9NNY3A","type":"application/json"}},"meta":{"numChildren":0},"data":{"key":"EHHIZZ24","version":19473,"parentItem":"2Z9NNY3A","itemType":"attachment","linkMode":"imported_file","title":"Heribert Illig – The Invented Middle Ages (Toronto conference 2005).pdf","accessDate":"","url":"","note":"","contentType":"application/pdf","charset":"","filename":"Heribert Illig – The Invented Middle Ages (Toronto conference 2005).pdf","md5":null,"mtime":null,"tags":[],"relations":{"dc:replaces":"http://zotero.org/users/9697111/items/TAP7LNQF"},"dateAdded":"2023-06-10T21:16:40Z","dateModified":"2025-01-17T14:59:31Z"}}']

(3)(+0000000): [ConcurrentCaller] All tasks are done

(4)(+0000002): Beginning DB transaction SVcolKIq

(4)(+0000000): Item 9475 has not changed

(4)(+0000000): Updating database with new library data

(4)(+0000001): UPDATE libraries SET version=? WHERE libraryID=? [19473, 1]

(4)(+0000000): UPDATE items SET version=19473 WHERE itemID IN (?) [9475]

(4)(+0000000): UPDATE items SET synced=1 WHERE itemID IN (?) [9475]

(4)(+0000001): Committed DB transaction SVcolKIq

(4)(+0000000): DELETE FROM syncCache WHERE ROWID IN (SELECT SC.ROWID FROM syncCache SC LEFT JOIN items O USING (libraryID, key, version) WHERE syncObjectTypeID=? AND SC.libraryID=? AND (O.libraryID IS NULL OR SC.version < O.version)) [3, 1]

(2)(+0000006): Failed: 0

(4)(+0000000): Unregistering notifier observer in notifier with id 'itemsUpload_AO'

(3)(+0000000): Done uploading items in library 1

(3)(+0000000): {}

(4)(+0000000): Upload result is 1

(4)(+0000000): Updating database with new library data

(4)(+0000000): Beginning DB transaction LdQXBzMx

(4)(+0000001): UPDATE libraries SET lastSync=? WHERE libraryID=? [1737125976, 1]

(4)(+0000001): Committed DB transaction LdQXBzMx

(3)(+0000000): Done syncing My Library

(4)(+0000000): REPLACE INTO version (schema, version) VALUES ('lastsync', ?) [1737125976]

(3)(+0000001): Starting file syncing

(3)(+0000001): File sync is not enabled for My Library

(3)(+0000000): Done with file syncing

(3)(+0000000): Done syncing

(3)(+0000000): Notifier.trigger('finish', 'sync', []) called [observers: 3]

(4)(+0000000): SELECT libraryID AS id FROM feeds WHERE refreshInterval IS NOT NULL AND ( lastCheck IS NULL OR (julianday(lastCheck, 'utc') + (refreshInterval/1440.0) - julianday('now', 'utc')) <= 0 )

(3)(+0000000): Running update for feeds:

(3)(+0000000): All feed updates done

(3)(+0000000): Scheduling next feed update

(4)(+0000000): SELECT ( CASE WHEN lastCheck IS NULL THEN 0 ELSE strftime('%s', lastCheck) + refreshInterval * 60 - strftime('%s', 'now') END ) AS nextCheck FROM feeds WHERE refreshInterval IS NOT NULL ORDER BY nextCheck ASC LIMIT 1

(3)(+0000001): Next feed check in 2660 seconds

(3)(+0000960): {better-bibtex: <7.0.5.7584 9WRB9VUT>} sync stopped

(4)(+0003229): SELECT synced FROM fulltextItems WHERE itemID=? [9475]

(4)(+0000001): SELECT indexedPages, totalPages AS total FROM fulltextItems WHERE itemID=? [9475]

(4)(+0012293): SELECT synced FROM fulltextItems WHERE itemID=? [9475]

(4)(+0000001): SELECT indexedPages, totalPages AS total FROM fulltextItems WHERE itemID=? [9475]

(3)(+0024556): BlockingObserver: Removed observer

I have these settings:

Please instruct how to proceed.

Cheers

[zanodor]

It's funny, it has renamed the actual attachment (I mean the rename is reflected in the json with automatic save even), but the change in the Title is not picked up. But even Zotero itself is slow to pick up on these changes. I had to open a different app window and come back to see the rename based on parent metadata happen in Zotero itself.

Could be in issue with a large sql databases with too much index. I cannot investigate...

I tried a second one, this time even the pdf rename was not reflected, but I didn't initiate the rename from metadata, but used manual rename.
Then following a manual export, no changes in filename or title in attachment.

So it's all haphazard, is all I can say.
Only the parent item's title in the json is what's always correct, the rest, can be updated on a whim or not.

The one workaround I can do is change citationKey and then either the automatic save will update the renames of filename and title or a manual export.

Again pressed log to be sent. No confirmation it was sent.

[zanodor]

Tried again.
Full log:
https://pastebin.com/Baeb4U4W

[github-actions]

🤖 this is your friendly neighborhood build bot announcing test build 7.0.5.7600 ("cache count failed")

This update may name other issues, but the build just dropped here is for you; it just means problems already fixed in other issues have been folded into the work we are doing here. Install in Zotero by downloading test build 7.0.5.7600, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".

[retorquere]

this also fixes the debug log submitter

[zanodor]

Sorry, didn't see notifications for this earlier.

I had to remove earlier version because the install was not overwriting the old one.

Made the drill of renaming parent item, then the PDF and the title property.
Only the parent item's title appeared as correct.

Debug log:
VMTIVQCI-euc/7.0.5.7600

[retorquere]

You mean you initially had two BBTs installed side by side?

[zanodor]

I think the first tester file was installed to take over the existing one. I don't remember having to remove it...?
Then the second one provided didn't install to overwrite the first tester, so I removed it, restarted Zotero 7 (maybe only Zot 6 has to be restarted but I did it anyway), then installed the second tester file, which I used to create the debug.

In the meantime, with the second tester, it didn't want to fit into the Zotero. I think it was me disabling and enabling it that caused the following output:

Error: Error(s) encountered during statement execution: no such table: betterbibtex.sqlite_master [QUERY: SELECT COUNT(*) FROM betterbibtex.sqlite_master WHERE type='table' AND tbl_name=?] [PARAMS: autoexport] [ERROR: no such table: betterbibtex.sqlite_master]
Zotero.DBConnection.prototype.valueQueryAsync@chrome://zotero/content/xpcom/db.js:737:13

And:

TransactionInactiveError: A request was placed against a transaction which is currently not active, or which is finished.
put@jar:file:///C:/Users/ODOR/AppData/Roaming/Zotero/Zotero/Profiles/default/extensions/[email protected]!/content/better-bibtex.js:57387:48
open@jar:file:///C:/Users/ODOR/AppData/Roaming/Zotero/Zotero/Profiles/default/extensions/[email protected]!/content/better-bibtex.js:58180:25
openWindowPrompt@resource://gre/modules/Prompter.sys.mjs:1231:17
openPrompt@resource://gre/modules/Prompter.sys.mjs:1052:12
openPromptSync@resource://gre/modules/Prompter.sys.mjs:1031:10
alert@resource://gre/modules/Prompter.sys.mjs:1334:17
alert@resource://gre/modules/Prompter.sys.mjs:72:7
alert@jar:file:///C:/Users/ODOR/AppData/Roaming/Zotero/Zotero/Profiles/default/extensions/[email protected]!/bootstrap.js:43:21
startup@jar:file:///C:/Users/ODOR/AppData/Roaming/Zotero/Zotero/Profiles/default/extensions/[email protected]!/bootstrap.js:125:12

Then I restarted Zotero 7 again and then the enable of the plugin was successful.

Then I didn't bothered with it.

If the first tester was installed ALONGSIDE the existing one, I certainly don't remember seeing visual feedback of any such anomaly. If that's what you're asking.

[retorquere]

Then the second one provided didn't install to overwrite the first tester

I don't know what you mean by this. Were two BBTs installed? In what sense didn't it overwrite the installed build? What did you see/experience to make you say "it didn't overwrite"?

Error: Error(s) encountered during statement execution: no such table: betterbibtex.sqlite_master [QUERY: SELECT COUNT(*) FROM betterbibtex.sqlite_master WHERE type='table' AND tbl_name=?] [PARAMS: autoexport] [ERROR: no such table: betterbibtex.sqlite_master]
Zotero.DBConnection.prototype.valueQueryAsync@chrome://zotero/content/xpcom/db.js:737:13

This is not good. A new build is incoming, it should report

3135: dbpath

before the error. I need that line.

[retorquere]

Oh and you need to have debug logging on (in the help menu) before installing the test build, it was off at time of installation in VMTIVQCI-euc/7.0.5.7600 so it didn't capture the startup error.

[github-actions]

🤖 this is your friendly neighborhood build bot announcing test build 7.0.5.7605 ("database is not attaching?")

This update may name other issues, but the build just dropped here is for you; it just means problems already fixed in other issues have been folded into the work we are doing here. Install in Zotero by downloading test build 7.0.5.7605, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".

[zanodor]

I don't know what you mean by this. Were two BBTs installed? In what sense didn't it overwrite the installed build? What did you see/experience to make you say "it didn't overwrite"?

As I said I don't think two BBTs were installed, as I have only three more extensions, Add-on Market, ZotMoov and Actions&Tags installed and if I had visual notification of two BBTs next to each other among the extensions, I would have easily seen it but of course I don't remember anything now.

Although it must be said, we average users don't know if we install a second instance of the same extension, how Zotero will handle it.
I mean on Windows and Linux, if you install the same program, the OS either asks to uninstall the old version or does its thing without the user needing to know what is going on behind the scenes.
I'm sorry if I didn't read some How-To Guide or dismissed the the Issues template too quickly before I offered to take part in this debugging process.

I have removed the 2nd tester or whatever with 7600 suffix and installed this new one with 7605 AFTER enabling logging.
I have also renamed a parent item and the corresponding PDF and its title.

I have this before sending:

• Strange I see no cache size now as I had before..? Well, I don't know what to expect here anyway...

Debug log ID:
EJKD9YM2-euc/7.0.5.7605

[github-actions]

🤖 this is your friendly neighborhood build bot announcing test build 7.0.5.7606 ("more logging")

This update may name other issues, but the build just dropped here is for you; it just means problems already fixed in other issues have been folded into the work we are doing here. Install in Zotero by downloading test build 7.0.5.7606, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".

[zanodor]

By overwrite I meant what I wrote above: you have something that is essentially the same thing (app, plugin, etc.) as you have had before, in our case: the BBT plugin. If you install another of the same thing, would Zotero allow two of the same thing? I don't think so (I don't want to try now), so the new version would be expected (by me) to overwrite the previous version of the same thing, the plugin. That can be called an overwrite, no?

Screencast:
https://youtu.be/7yTNFvN_y08

Didn't bother to check the json as I know you are not sending a fix yet. But I still go ahead to apply my workaround.

Debug ID sent:
C9VMM5CJ-euc/7.0.5.7606

[retorquere]

By overwrite I meant what I wrote above: you have something that is essentially the same thing (app, plugin, etc.) as you have had before, in our case: the BBT plugin. If you install another of the same thing, would Zotero allow two of the same thing? I don't think so (I don't want to try now)

No, it doesn't, but it's the only way I could make sense of what you're saying. It's technically possible if I somehow gave it a different internal ID, which I didn't.

so the new version would be expected (by me) to overwrite the previous version of the same thing, the plugin. That can be called an overwrite, no?

Yes, which is what Zotero always does, so in what sense did it not do that? I still don't understand how you came to the conclusion that "it did not overwrite". This is supposed to be impossible, and could point to a deeper problem in Zotero, so I'm trying to understand what's going on.

[retorquere]

But I still go ahead to apply my workaround.

Please do this after sending the debug log. I don't want this in the log, because it could mask the problem of an event not being handled.

[retorquere]

Wait a few seconds and check the json (if you have set automatic export on changes)... -- No changes in the pdf.

When you say "no changes in the PDF", you mean "no changes in the path in the JSON that points to the PDF", right? Automatic exports don't do attachment export.

Wait a few seconds and check the json

For an auto-export? According to C9VMM5CJ-euc/7.0.5.7606 you don't have auto-exports. In U7VV7QP3-euc/7.0.5 you did.

[retorquere]

Yes, which is what Zotero always does, so in what sense did it not do that? I still don't understand how you came to the conclusion that "it did not overwrite". This is supposed to be impossible, and could point to a deeper problem in Zotero, so I'm trying to understand what's going on.

Or do you mean Zotero would not allow you to install the replacement xpi until you removed the existing install? If that's the case you'd need to take that up with Zotero. I'm not involved in the install process.

[zanodor]

But I still go ahead to apply my workaround.

Please do this after sending the debug log. I don't want this in the log, because it could mask the problem of an event not being handled.

Of course I did, after.

[zanodor]

Wait a few seconds and check the json (if you have set automatic export on changes)... -- No changes in the pdf.

When you say "no changes in the PDF", you mean "no changes in the path in the JSON that points to the PDF", right?

Yes, I need the PDF attachment's filename (not too concerned for the title) in the json in line with the physically saved filename I manage to do with Zotero. If the attachment filename is incorrect in the json, my Python script's extractor will have no legal file to point to in my Obsidian vault.

Automatic exports don't do attachment export.

Ah, that's a bummer, but still... if I manually export the whole json...it still will not sport my new changed filenames, unless I change the citationKey. So this all this runaround will always be needed?

Wait a few seconds and check the json

For an auto-export? According to C9VMM5CJ-euc/7.0.5.7606 you don't have auto-exports. In U7VV7QP3-euc/7.0.5 you did.

Well, I'd like for my settings stick... I didn't have problem my auto-export settings not stick in the past. Meh...

BTW, all looks okay in settings:

[zanodor]

Yes, which is what Zotero always does, so in what sense did it not do that? I still don't understand how you came to the conclusion that "it did not overwrite". This is supposed to be impossible, and could point to a deeper problem in Zotero, so I'm trying to understand what's going on.

Or do you mean Zotero would not allow you to install the replacement xpi until you removed the existing install? If that's the case you'd need to take that up with Zotero. I'm not involved in the install process.

We are through with that. Initially, for the first tester, I was wary of removing my own official add-on because as I looked around in the plugin settings, I couldn't find an export for the settings and didn't want to remove the extension. So I think I installed the 1st tester on top of the existing one. But as I said, I don't remember now what happened. I'm guessing the 1st tester installed over the official release without a hitch.

After this occasion, I always removed the existing extension, quit Zotero, came back to Zotero, installed the next tester and finally for the last time I started debugging before installing the tester, as I recorded in the video.

[retorquere]

Yes, I need the PDF attachment's filename (not too concerned for the title) in the json in line with the physically saved filename I manage to do with Zotero. If the attachment filename is incorrect in the json, my Python script's extractor will have no legal file to point to in my Obsidian vault.

OK, no problem. This should have just worked, so that means I'm likely not updating the cache correctly.

Automatic exports don't do attachment export.

Ah, that's a bummer, but still... if I manually export the whole json...it still will not sport my new changed filenames, unless I change the citationKey. So this all this runaround will always be needed?

No, that's a problem I need to address.

Well, I'd like for my settings stick... I didn't have problem my auto-export settings not stick in the past. Meh...

They do stick. Auto-exports are only deleted when removed from the preferences. Which is why I asked.

BTW, all looks okay in settings:

Then there's something wrong with that too. I'll investigate.

I was wary of removing my own official add-on because as I looked around in the plugin settings, I couldn't find an export for the settings and didn't want to remove the extension.

Removing of the extension never removes configuration or data. There is also a facility to export/import preferences, but that should only be needed to get your settings to another computer.

New build will drop momentarily

[github-actions]

🤖 this is your friendly neighborhood build bot announcing test build 7.0.5.7608 ("touch parents when child changes")

This update may name other issues, but the build just dropped here is for you; it just means problems already fixed in other issues have been folded into the work we are doing here. Install in Zotero by downloading test build 7.0.5.7608, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".

[zanodor]

Z3PJ3UWM-euc/7.0.5.7608

[zanodor]

I'd like for my settings to stick

The one change I've started seeing (don't know since when) is not remembering my preference for 'Keep Updated'.
I need to always check it on each manual export. It may be a default setting...? Probably. Anyway, one must make a mental note to check it.

Which reminds me, that when you check it, the Background Export goes unchecked. Maybe that is the source of all our problems?

[retorquere]

The one change I've started seeing (don't know since when) is not remembering my preference for 'Keep Updated'.
I need to always check it on each manual export. It may be a default setting...?

Yes. If it didn't always reset, that would be a bug. I don't want people setting up auto-exports by accident.

when you check it, the Background Export goes unchecked. Maybe that is the source of all our problems?

It should remain checked but disabled. I have no influence on the colorscheme, it is a bit hard to tell, but it remains checked for me. Auto-exports are always background exports.

I'll look at the log later when I'm home.

[zanodor]

I have no influence on the colorscheme, it is a bit hard to tell

In my screenshot, I showed the pre-state, before checking 'Keep Updated'. 'Background export' will grey out afterwards.

[retorquere]

Greyed out means the control is disabled (you can't edit it), not that the feature is off (that would show as unchecked, regardless of whether the control is enabled)