BibTex Key after resolving duplicates

[VH87]

Hello,

I have just resolved all the duplicates in Zotero, keeping the oldest version, i.e. all entries should have the bibtex key [auth][year] as specified in BetterBibTex. However, some of them still have a letter, e.g. "Smith1999a". I would like to change these keys now by getting rid of the final letter and only keeping name + year. Is there an automatic way to do it? I tried unpinning and refreshing the keys but that doesn't help.

[bothide]

I have seen the same (unwanted) behaviour and would be happy if it would be possible to change it.

[blip-bloop]

:robot: this is your friendly neighborhood build bot announcing test build 5.0.116.6226.issue-944 ("always refresh postfix").

[retorquere]

Please try 6226.

[retorquere]

@bothide, @VH87, I'd really prefer to have confirmation this works as you want it.

[VH87]

Thanks for the information, I installed the version of the AddOn you linked (I had a version that was last updated yesterday beforehand), it worked for the first reference but for some reason does not work for the others, even if I try manually refreshing one-by-one. I am not sure what "always refresh postfix" means.

[bothide]

Hi Emiliano,

Sorry, but I have not had time to make a full test yet. Right now I am stuck with the >X pseudofunction that all of the sudden started to malfunction... Until I have investigated that problem and hopefully resolved it, I will have limited time to test for #944.

Bo

On 6 April 2018 at 13:17, Emiliano Heyns notifications@github.com wrote:

@bothide https://github.com/bothide, @VH87 https://github.com/VH87, I'd really prefer to have confirmation this works as you want it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/retorquere/zotero-better-bibtex/issues/944#issuecomment-379223933, or mute the thread https://github.com/notifications/unsubscribe-auth/AHlBJJuv7zy0pKexh7V7yPcjnf7zxG_wks5tl07mgaJpZM4TIY7L .

--

---

Emeritus Professor Dr Bo Thidé https://www.researchgate.net/profile/Bo_Thide Swedish Institute of Space Physics (IRF), P. O. Box 537, SE-751 21 Uppsala Phone: Office +46184715902 Mobile/Cell +46705613670 Home +46184951801 Visiting address: Ångström Laboratory, Rm# 84108, Lägerhyddsvägen 1, Uppsala

[retorquere]

@VH87 can you try to refresh one of the keys where it's not doing what you want and then sending a BBT debug report (with extended debugging on)?

"always refresh postfix" is gone in 6226, that behavior is now default.

[retorquere]

@bothide please file a separate issue for [>X] failing.

[retorquere]

@VH87 I can't replicate "does not work for others".

[VH87]

I sent the report 76XRMPL9

[retorquere]

@VH87 I don't see any key refresh activity in the log.

[VH87]

oh sorry for the mistake, I had to restart to enable debugging and did not refresh afterwards again. Did it again now in the right order. T4TH5XU9

[blip-bloop]

:robot: this is your friendly neighborhood build bot announcing test build 5.0.119.6263.issue-944 ("more logging for #944").

[retorquere]

Can you install 6263 and generate a new log? The logging in T4TH5XU9 is inconclusive on what is going on.

[bothide]

Using 5.0.119, I still get the wrong behaviour.

[bothide]

Then, using the 6263, the problem was solved.

[retorquere]

5.0.119 doesn't have the extra logging, so I can't get a diagnosis. I need a log from the 6263 version linked to by @blip-bloop.

[retorquere]

Uh, that was unexpected. 6263 doesn't change anything, it just adds logging.

[retorquere]

it would be expected that the formal 5.0.119 release had the same behavior, the changes weren't merged into that yet. But you're saying the problem is just fixed now?

[bothide]

This was for one single case only. I had two identical entries. Using 119, the first one yielded the citekey xxxxx1980 and the second one yielded the citekey xxxxx1980a (xxxxx stands for the author, journal etc). I removed the first one and kept the second one. Then I ran a refresh in 119 and the "a" was not removed. But after changing to 119.6623-issue944 and refreshing, the "a" was removed (as it should).

[retorquere]

ah OK. I'll merge.

[VH87]

For me, it did not make a change/it did not solve the problem, some references are still with some letter attached even though there is not a single duplicate in the library. Refreshing does not help, in 6263 neither.

[retorquere]

You've lost me. I thought you said 6263 fixes the problem for you?

If not, can you update to the latest bbt release (I've merged the changes of 6263 because I thought you said it was fixed), restart with debugging enabled, reproduce the problem, and then send a debug log?

[VH87]

No, that was bothide, after I sent report T4TH5XU9 you asked me to use the version 6263 as there was some problem with the logging. I did and generated a new report (did not post the number here though). I just did that again, using version 6263, here is the report number: ACA378B6

[retorquere]

Sorry, confusion on my part. In your logs I see that another item in the same library has Zhao2014 claimed (reference with item key P5FBV6CB). Can you export that library (the one that has the key you tried to refresh to CSV and see if you can find that key in there?

[VH87]

that is a good point, I rechecked and some of the letters come indeed from entries that are not duplicates but would have the same citekey otherwise, without letter. However, there are still some entries where this is not the case and that still come with a letter. For example the one that I just reported as DLLQKDZS. There are only 3 entries from that author and the other two have different citekeys as they are from different years.

[blip-bloop]

:robot: this is your friendly neighborhood build bot announcing test build 5.0.120.6277.issue-944 ("more logging for #944").

[retorquere]

Can you generate a new log for that case using 6277? We're talking about Thomson1990 right?

[VH87]

It works! All unneccessary letters are removed, only those entries that have identical citekeys otherwise (e.g. Lee2004a, Lee2004b) have them now. The last log was for Yoshioka 2001a and 2007a. Do you still need a log?

Thanks a lot for your help!

[retorquere]

I have again changed nothing, just added logging. If you can reproduce the problem again, I'd sure love a log, but if you're not experiencing the problem, a log won't help.

[retorquere]

I've merged the extra logging and scheduled the release of .121. Next time it happens you can generate a log using that and I'll have more info. I still don't know why you were seeing the problem -- I haven't changed anything that would fix it.

[VH87]

ok, I will check on other accounts/computers whether it works too and let you know. If it doesn't work, I will create a log (it is a group library). I don't know why it worked now but not before; I did not do anything else other than making a log and refreshing a key either.

[retorquere]

Cool, thanks.

[VH87]

Hi Emiliano,

sorry for the late reply, it works. Thanks a lot. :)

[retorquere]

Also thanks

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.