Upgrade StorageForbid duplicate: Warning/Error if BibTex key already exists
I'm using Better BibTex to export items, and I chose a key format that gives me results like NC10_QuantumComputationQuantum. As a result, it's very unlikely that two items get the same citation key. But if I re-import twice a document (easy to do if I forgot that the document was already part of the database), Zotero creates another entry whose name is like NC10_QuantumComputationQuantuma (note the trailing a). Most of the time I do not notice it directly, and I end up using different bib entries for the same reference... which is pretty bad.
I'd much prefer a warning/error to notify me that I already have this document in my Zotero bibliography. Is it possible?
I'm aware of the "duplicate" search to remove duplicates, but I'd much prefer a warning directly when I add the file since I won't check my duplicate tab every time I add a new item. Is it possible?
I'd much prefer a warning/error to notify me that I already have this document in my Zotero bibliography. Is it possible?
I'm aware of the "duplicate" search to remove duplicates, but I'd much prefer a warning directly when I add the file since I won't check my duplicate tab every time I add a new item. Is it possible?
Not just unlikely. If you let BBT generate all your keys, you are guaranteed you get no duplicates.
But why do you re-import these files? You're not going to end up with just duplicate keys, but full duplicate entries
It shouldn't do this, unless you have disabled importCitationKey. By default, BBT will import keys as-is, and then you will indeed end up with duplicate keys.
Define "possible". There's no law of nature or logic that forbids creating something like this, but you'd be fighting the Zotero infrastructure. During import, the importer cannot see existing entries in your database, it's fully isolated, so by the time you can compare them, you're too late, they're already in your database.
Not as-is, no. But what do you aim to achieve with this workflow? If you have a BBT-generated bib file from (part of) your databases, any entry you import from it will be a duplicate, by necessity.
At heart, this has nothing to do with BibTeX, that's just what they happen to be using.
I remain curious though why @tobiasBora is reimporting zotero exports. I can't really think of a use case that this would be a solution to m
Concerning reimporting zotero entries, maybe we are not using the same terminology: by reimporting, I mean add an article which turns out to be already in the Zotero database using the browser extension. In that case, I do endup with different BBT keys, with "a", "b", "c"... added at the end depending on the number of duplicates. Therefore, there is no "use case" for reimporting, it's just that sometimes I think that an article is not yet in Zotero, so I add it... and then I realize it was already there.
Also, I would be suprised if it's a fundamental problem: since BBT can detect duplicate keys (it can since it adds the "a", "b"... suffix) , I guess in this part of the code we could say "do not add the suffix 'a', 'b' but remove the entry". After of course I've no idea how Zotero is coded internally so I may be wrong.
What you describe is in principle possible, but i don't see how it could be desirable. Whether duplicate keys will occur between two items is highly dependent on your key pattern; if you have an author-year style key, you will easily get key duplicates, which must be postfixed to make them unique, but the articles could be wholly distinct. Whether or not two items refer to the same article should certainly not be decided on the citekey.
If Zotero solves duplicate detection with auto-rejection of the duplicate, this problem goes away, but this detection is definitely not a problem BBT should solve.
Anyway, thanks a lot for your help.