Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crossreferenced entry citekey changed #11136

Open
2 tasks done
ilippert opened this issue Apr 3, 2024 · 16 comments
Open
2 tasks done

crossreferenced entry citekey changed #11136

ilippert opened this issue Apr 3, 2024 · 16 comments
Assignees
Labels
FirstTimeCodeContribution Triggers GitHub Greeter Workflow good first issue An issue intended for project-newcomers. Varies in difficulty. keygenerator

Comments

@ilippert
Copy link

ilippert commented Apr 3, 2024

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.

@koppor koppor added the good first issue An issue intended for project-newcomers. Varies in difficulty. label Apr 12, 2024
@alpha951
Copy link

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

@ThiloteE ThiloteE added the FirstTimeCodeContribution Triggers GitHub Greeter Workflow label Apr 13, 2024
Copy link
Contributor

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
Copy link

alpha951 commented Apr 14, 2024

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 :
image

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 :
image
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
Copy link
Author

ilippert commented Apr 14, 2024

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
Copy link

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
Copy link
Author

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
Copy link

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
Copy link
Author

ilippert commented Apr 14, 2024 via email

@alpha951
Copy link

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
Copy link
Author

ilippert commented Apr 14, 2024 via email

@alpha951
Copy link

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
Copy link

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
Copy link
Member

koppor commented Apr 15, 2024

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

@alpha951
Copy link

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
Copy link
Member

koppor commented Apr 15, 2024

@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},
}
  1. Mark everything in Notepad++

  2. Copy to clipboard (Ctrl+C)

  3. 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
Copy link
Member

koppor commented Apr 15, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FirstTimeCodeContribution Triggers GitHub Greeter Workflow good first issue An issue intended for project-newcomers. Varies in difficulty. keygenerator
Projects
Status: Reserved
Status: Reserved
Development

No branches or pull requests

5 participants