crossreferenced entry citekey changed when pasing into a new library

[ilippert]

JabRef version

Other (please describe below)

Operating system

GNU / Linux

Details on version and operating system

JabRef 5.14--2024-04-02--bb5ef81 Linux 6.7.9-200.fc39.x86_64 amd64 Java 21.0.2 JavaFX 22+30

Checked with the latest development build (copy version output from About dialog)

• I made a backup of my libraries before testing the latest development version.
• I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

1. mark two entries, one of which crossreferences the other; while only the parent entry has a year/date information
2. copy both entries
3. paste in a new library

I find that the cite key of the child entry in the new library is generated without taking into account the parent entry('s date/year information) that is also copied.

This needs to be fixed, I guess, for #6404 to make sense.

[alpha951]

Hey, I'm looking for pickup my first issue. Could you please assign this to me?

[github-actions]

As a general advice for newcomers: check out Contributing for a start. Also, guidelines for setting up a local workspace is worth having a look at.

Feel free to ask here at GitHub, if you have any issue related questions. If you have questions about how to setup your workspace use JabRef's Gitter chat. Try to open a (draft) pull-request early on, so that people can see you are working on the issue and so that they can see the direction the pull request is heading towards. This way, you will likely receive valuable feedback.

[alpha951]

Hey, I'm new to this project. I've successfully setup the project in my local machine. I'm using a Manjaro Linux machine.

• mark two entries, one of which crossreferences the other; while only the parent entry has a year/date information

I tried to reproduce the issue. But couldn't notice the expected issue.

Here are the entries in first library :

Parent entry

@Article{Carpenter2024,
  author  = {Keshav Carpenter},
  journal = {Spring},
  title   = {Demo to reproduce github issue},
  year    = {2024},
}

Child entry

@Article{Keshav,
  author   = {Child Keshav},
  journal  = {Linuxtalks},
  title    = {Demo-2 to create child entry},
  crossref = {Carpenter2024},
}

On pasted in new library :

The year information is reflecting in child entry.

It got pasted as the original library.

@Article{Keshav2024,
  author   = {Child Keshav},
  journal  = {Linuxtalks},
  title    = {Demo-2 to create child entry},
  crossref = {Carpenter2024},
}

Hey @ilippert, please let me know if there is anything I missed while reproducing the issue.

[ilippert]

thanks for checking. I just used your entries and pasted these into my library. And already at this point it does not work. The reason being here maybe:
the library's default citekey pattern changes the parent's citekey information BEFORE going through the set of pasted entries and checking whether any citeky in the (I suppose) buffer is crossreferenced. I guess if a citekey is updated in the pasting process also the crossreferencing entries need to be adapted.

Sorry, not sure whether this makes sense - happy to spend some more time, in 2 weeks, as alas, right now I cannot take 20 minutes to spell this out in more systematic ways. Thanks for your understanding.

[alpha951]

Alright, so one thing I got, in my case the citekey of child entry in new library changes from
Keshav to Keshav2024.
So is this the issue ?
Also the child entry shows the year 2024 in new library since it's crossref to it's parent entry which has year as 2024. Is this expected or it's a bug ?
This confirmation will help me in starting out with debugging.
Thanks

[ilippert]

Alright, so one thing I got, in my case the citekey of child entry in new library changes from
Keshav to Keshav2024.

this is expected and good, imho. Because the child's citekey is generated according to the default pattern and the available information. So: ✔️

So is this the issue ?
Also the child entry shows the year 2024 in new library since it's crossref to it's parent entry which has year as 2024. Is this expected or it's a bug ?

expected.

I suggest you now edited your second library's defaults for the generation of citekeys. In my case, I always add the title's first word, or something like that.

[alpha951]

I update the default key generation pattern to [title][year]
Now when I pasted the entries in new library. The year info which suppose to be taken from parent entry is missing from ciekey. While the pasted parent entry has year in citekey.

@Article{Demo2toCreateChildEntry,
  author   = {Child Keshav},
  journal  = {Linuxtalks},
  title    = {Demo-2 to create child entry},
  crossref = {DemotoReproduceGithubIssue2024},
}

So, can I assume that I've successfully reproduced the issue ?

[ilippert]

To confirm, if you can: maybe paste both entries in first library and both as well for the second library after pasting? -- Sent from my LineageOS device with K-9 Mail. Please excuse my brevity.

[alpha951]

To confirm, if you can: maybe paste both entries in first library

I couldn't understand it clearly. What I tried is : Copied both entries form second lib and tried to paste them in first lib. But it show duplication conflict, and ask to solve it (similar to merge conflict with git).

and both as well for the second library after pasting
This step is not at all clear to me.

[ilippert]

I apologise. I wanted to suggest: like in your first/earlier post, paste the entries here on the github issue interface, so we can see your versions. Cheers -- Sent from my LineageOS device with K-9 Mail. Please excuse my brevity.

…

On 14 April 2024 13:34:08 CEST, Keshav Carpenter ***@***.***> wrote: > To confirm, if you can: maybe paste both entries in first library I couldn't understand it clearly. What I tried is : Copied both entries form second lib and tried to paste them in first lib. But it show duplication conflict, and ask to solve it (similar to merge conflict with git). > and both as well for the second library after pasting This step is not at all clear to me. -- Reply to this email directly or view it on GitHub: #11136 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[alpha951]

Original lib

@Article{Carpenter2024,
  author  = {Keshav Carpenter},
  journal = {Spring},
  title   = {Demo to reproduce github issue},
  year    = {2024},
}
@Article{Keshav2024,
  author   = {Child Keshav},
  journal  = {Linuxtalks},
  title    = {Demo-2 to create child entry},
  crossref = {Carpenter2024},
}

New lib

@Article{DemotoReproduceGithubIssue2024,
  author  = {Keshav Carpenter},
  journal = {Spring},
  title   = {Demo to reproduce github issue},
  year    = {2024},
}
@Article{Demo2toCreateChildEntry,
  author   = {Child Keshav},
  journal  = {Linuxtalks},
  title    = {Demo-2 to create child entry},
  crossref = {DemotoReproduceGithubIssue2024},
}

Before pasting these two entries to new lib I changed the default key generation pattern for citekey to [title][year]

[alpha951]

I think, I've reproduced the issue. But I'm not sure how to approach from here. I tried to navigating the code by finding snippets with keywords like crosref, comparator, Paste etc. but I couldn't find the logic.
What I'm trying to do is, find the code which is causing this behaviour and add some breakpoints in IDE to debug the issue. Any help is much appreciated.

[koppor]

@alpha951 Maybe set a breakpoint at org.jabref.gui.externalfiles.ImportHandler#handleBibTeXData and follow the logic there.

[alpha951]

Hey @koppor,
I tried debugging from above point. But surprisingly I couldn't reproduce the issue during debugging. Also I tried reproducing the bug without debugging too, and failed this time. May be in my last comment I might have made a mistake in observing the results. I apologies for my oversight.
Let me explain what I was trying to do.

• My defaultKey pattern for first library is unchanged.
• defaultKey patter for second library is [title][year]
• I created these two entries (I deliberately used new example values to avoid any chance of confusion)

@Article{Carpenter2020,
  author  = {Keshav Carpenter},
  journal = {Spring},
  title   = {Demo to reproduce github issue},
  year    = {2020},
}

@Article{Keshav,
  author   = {Child Keshav},
  journal  = {Linuxtalks},
  title    = {Demo-2 to create child entry},
  crossref = {Carpenter2020},
}

• Now I copy pasted these two newly added entries in new library where default key pattern is set as [title][year] as described earlier as well.
• Here are results

@Article{DemotoReproduceGithubIssue2020,
  author  = {Keshav Carpenter},
  journal = {Spring},
  title   = {Demo to reproduce github issue},
  year    = {2020},
}

@Article{Demo2toCreateChildEntry2020,
  author   = {Child Keshav},
  journal  = {Linuxtalks},
  title    = {Demo-2 to create child entry},
  crossref = {DemotoReproduceGithubIssue2020},
}

• As you can see for newly pasted child entry the generated cite key is Demo2toCreateChildEntry2020 which has the year property from it's crossref newly pasted parent key.
• So I think it is expected. I found the many proof of this output during debugging as well.

So, please help me what I'm doing wrong, or is there any other default cite key pattern I should try to reproduce the bug.

[koppor]

@alpha951 Reproducer:

1. Open Notepad++

2. Paste following content to NotePad++

@Article{child,
  author   = {Child Keshav},
  journal  = {Linuxtalks},
  title    = {Demo-2 to create child entry},
  crossref = {parent},
}

@Article{parent,
  author  = {Keshav Carpenter},
  journal = {Spring},
  title   = {Demo to reproduce github issue},
  year    = {2020},
}

3. Mark everything in Notepad++

4. Copy to clipboard (Ctrl+C)

5. Paste in JabRef

Result for the child entry:

@Article{Demo2toCreateChildEntry,
  author   = {Child Keshav},
  journal  = {Linuxtalks},
  title    = {Demo-2 to create child entry},
  crossref = {2020DemotoReproduceGithubIssue},
}

crossref entry is correct, but citation key is not.

[koppor]

@alpha951 The issue is probably happening if the cross-referenced entry is imported after the child entry. Therefore, you had no issue with your example: The parent came before the child in your case.

[tom-pjobrien]

Hello @koppor ! I am doing a university project with a few other students and would love to have this as my first contribution. I am able to reproduce the issue using the above reproducer so can hopefully work towards resolving it quickly.

[github-actions]

Welcome to the vibrant world of open-source development with JabRef!

Newcomers, we're excited to have you on board. Start by exploring our Contributing guidelines, and don't forget to check out our workspace setup guidelines to get started smoothly.

In case you encounter failing tests during development, please check our developer FAQs!

Having any questions or issues? Feel free to ask here on GitHub. Need help setting up your local workspace? Join the conversation on JabRef's Gitter chat. And don't hesitate to open a (draft) pull request early on to show the direction it is heading towards. This way, you will receive valuable feedback.

Happy coding! 🚀

[tom-pjobrien]

Just a small clarification on this issue: should a child inherit its parent's year field if it doesn't have its own value there? Or should it just affect how its citekey is generated?

[koppor]

Just a small clarification on this issue: should a child inherit its parent's year field if it doesn't have its own value there?

You can use org.jabref.model.entry.BibEntry#getResolvedFieldOrAlias(org.jabref.model.entry.field.Field, org.jabref.model.database.BibDatabase) to get field contents. It climbs up the hierarchy of CROSSREF.

Longer answer: Depends on the context.

• In the entry editor: No, because we edit the plain entry
• In the maintable: Yes. See Display files from referenced crossref in entry table (HighCrit version) #9717 for a work-in-progress PR to display it.
• In the BibEntry - see above; the code can access the field directly or use the resovled ting.

---

For the issue at hand, I think, you need to dive into the paste handling. I would assume that currently the entries are pasted one after another. If the "child" entry is pasted first and then the "parent" entry, the key generator cannot find the parent entry. This, you need to re-order the pasted entries -- or execute the citation key generator after pasting all entries. Maybe, the latter is more easy.