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

if copy of complete bibtex entry that uses a crossref, then also copy the crossreferenced entry #6404

Open
ilippert opened this issue May 3, 2020 · 8 comments
Assignees

Comments

@ilippert
Copy link
Contributor

ilippert commented May 3, 2020

This comes from https://discourse.jabref.org/t/seamless-crossreferencing/100/4

Describe the solution you'd like
Consider an entry A that uses a crossref to another entry B.
When I copy entry A from one library I to another library II, I want B to be also copied there IF B is not already present in database II.

Advanced request: when inserting entry B, then the normal procedure should be used, checking whether a potential equivalent entry already exists (e.g. same title, editor, but not same citekey).

Equivalently, if library II is a export bib file, it should work, too.

@ilippert
Copy link
Contributor Author

ilippert commented Dec 8, 2020

oh, this would be such an amazing feature!

@ilippert
Copy link
Contributor Author

ilippert commented Jun 8, 2021

please let us keep this open

@JabRef JabRef deleted a comment from github-actions bot Jun 8, 2021
@koppor koppor moved this to Normal priority in Features & Enhancements Nov 7, 2022
koppor pushed a commit that referenced this issue Feb 15, 2023
9926b48cf3 Create biomolecular-concepts.csl (#6355)
4b4ebeeeba Create life-science-alliance.csl (#6353)
153790afc9 Update ucl-university-college-apa.csl (#6390)
a30604c0b4 Update geophysical-journal-international.csl (#6385)
3fda5f30ca Create nursing-open.csl (#6402)
103b607948 Update natur-und-landschaft.csl (#6404)

git-subtree-dir: buildres/csl/csl-styles
git-subtree-split: 9926b48cf3e20e60142e35b3cd160015aebed9d3
@HoussemNasri HoussemNasri self-assigned this Apr 3, 2024
@HoussemNasri
Copy link
Member

HoussemNasri commented Apr 4, 2024

I'm thinking about how this feature would be integrated into the usual copy-paste workflow of entries, and I'm finding edge cases that need to be considered. Say we want to copy an entry from Library A to Library B. In Library B when we receive the paste request, we check the crossref field for the referenced entries' citation keys and search for these entries in the opened libraries. This process would result in a conflict if an entry with the same key exists in library C too (Do we fetch the entry from B or C?).

One idea is to remember the last library where we copied something (in the scenario above it would be library A). But then another problem arises if we copy an entry from the web or another program. Let's say we copy from Library A, then copy another entry from the web, and paste it back into JabRef. If JabRef detects that the entry has a crossref field, it'll try to find the referenced entries in Library A because that's where we last copied from. This could result in the fetching of unwanted entries.

We could add a metadata field to the entry that stores the name of the library it came from and delete the field as soon as the entry was pasted. However, when the entry is pasted somewhere else the metadata field stays. Im not sure if that is a big problem, though.

The main issue here is we don't know where the entry came from when we paste it. But when we drag an entry from one library to another, we do know, so that works fine. Another idea is to add a new option called "Copy to" in the right-click menu of the entry. This would let us choose which library to copy the entry to.

There are still some things to figure out:

  • Should we copy referenced entries automatically, or ask the user first?
  • Should we keep looking for referenced entries recursively and copy them too? (For example, if entry A references B and B references C, should we copy C as well?)

@Siedlerchr
Copy link
Member

Present a dialog with choices: This entry references x other entries.

  1. Copy only the current entry
  2. Copy all associated/references entries recursively
  3. Abort
  4. Remember decision checkbox

This would be the first thing.
Regarding cite key clashes: If an entry with the same cite key is already found in the new library:

a) the user has auto generation of citation keys activated -> This would work after copying. I think similar to importing.
b) no auto generation: we skip it and show a warning at the end (e.g. in a "Result dialog" like I did for copying of BibTeX strings)

@koppor
Copy link
Member

koppor commented Apr 11, 2024

Follow-up: #7057

@Siedlerchr
Copy link
Member

Regarding recursive, I just stumbled across this section in Tame the BeaST section 12:

One other important remark is that cross-referenced entries must be defined after entries containing
the corresponding crossref field. And you can’t embed cross-references, that is, you cannot crossref
an entry that already contains a crossref.

So we only have entry A crossref entry B
B crossref C would not work

@ilippert
Copy link
Contributor Author

ilippert commented May 20, 2024 via email

@Siedlerchr
Copy link
Member

Siedlerchr commented May 20, 2024

Yes, is primarily related to BibTeX processing, it is the order in the bib file itself that needs to be respected, e.g. when saving/writing entries. JabRef respects this so that Entry B is written before Entry A in the file itself.
But it does not affect the order in the table itself.

@JabRef JabRef deleted a comment from github-actions bot Aug 7, 2024
@github-project-automation github-project-automation bot moved this to Normal priority in Prioritization Nov 13, 2024
@calixtus calixtus removed the status in Prioritization Nov 13, 2024
@calixtus calixtus moved this to Normal priority in Prioritization Nov 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Normal priority
Development

Successfully merging a pull request may close this issue.

4 participants