Key generation field

[Irismoon]

Report ID:

Expected behavior:

Actual behavior:

Hey, thanks for your awesome work. The tool is really handy and elegant. I just ask if it's possible to include a function: now the citekey use fixed number of fields. But if there is duplicate citekey, it 'll add a postfix like a,b,..., if it's possible to add additional optional fields like its title in addition to typical fields. It'll be easier to find the paper I want when I cite it. I check the wiki website. And find there is no similar functions in the citation key description.

Best, Mango

[label-gun[bot]]

It looks like you did not upload an debug report. The debug report is important; it gives @retorquere your current BBT settings and a copy of the problematic reference as a test case so he can best replicate your problem. Without it, @retorquere is effectively blind. Debug reports are useful for both bug analysis and enhancement requests; in the case of export enhancements, I need the copy of the references you have in mind.

• If your issue relates to how BBT behaves around a specific reference(s), such as citekey generation or export, select at least one of the problematic reference(s), right-click it, and submit an BBT debug report from that popup menu. If the problem is with export, please do include a sample of what you see exported, and what you expected to see exported for these references.

• If the issue does not relate to references and is of a more general nature, generate an debug report by restarting Zotero with debugging enabled (Help -> Debug Output Logging -> Restart with logging enabled), reproducing your problem, and selecting "Send Better BibTeX debug report..." from the help menu.

Once done, you will see a debug ID in red. Please post that debug id in the issue here.

Thank you!

[Irismoon]

It seems a suggestion rather than a bug. Apologize if wrong place.

[retorquere]

You can add the title or pretty much anything else you want to the citekey: https://retorque.re/zotero-better-bibtex/citing/ . What you're seeing now is just the default pattern but it's very configurable.

[Irismoon]

Hey thanks for reply. To be clear, what I mean is a special config when conflict occurs. For example, my config is [author][journal][year]. Usually the citekey is as above. But When there are two items have the same Citekey, is it possible to add an additional field to discriminate them more clearly? Like only under conflict case, the citekey could be [author][journal][year][title].

Best, Mango

[retorquere]

So you mean that if a conflict occurs, both would change?

[Irismoon]

Sorry for the delay due to time difference. Sort of. Exactly, I mean if a conflict occurs, more fields are allowed to be added rather than a postfix like a,b,c,... Let's say now, I already have an item citekey is mattNature2019([author][journal][year]). When I add a new item whose citekey is automatically assigned as mattNature2019a as default, I hope both of them could change like one is mattNature2019July, mattNature2019Jan. The benefit is that when I cite them, I could discriminate them. I don't need to check mattNature2019 and mattNature2019a refers to which paper respectively. I of course know mattNature2019July and mattNature2019Jan refers to which paper because I read them and know their publication month. To sum up, adding a postfix like a,b,... is an unknown information for me but the publication month is known information for me. I feel like it would help when citing. But if there is no conflict at all, the citekey is still mattNature2019. Glad to hear how you think.

Best, Mango

[retorquere]

That could trigger a cascade of updates. I'd rather not add that.

I could consider a feature where you could:

1. Choose to not have keys postfixed
2. More easily find duplicates
3. A way to apply a custom pattern by right-clicking

Which should get your roughly the desired behavior, if not fully automatic.

[retorquere]

closing for inactivity

[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.