deleting entry removes the entry label from the other entries that crossref it

[ilippert]

JabRef 5.2--2020-10-26--3fe34a0
Linux 5.8.16-200.fc32.x86_64 amd64
Java 15.0.1

Steps to reproduce the behavior:

1. generate entry with label/key AAA
2. generate entry B that cross-references AAA
3. delete entry AAA from table

Result: Entry B misses the AAA cross-ref. It should be preserved.

[Siedlerchr]

Thinking about it, I see the behaviour of JabRef correct, as the label is an (internal) reference to the entry. When the entry no longer exists, to what should it refer? It would be inconsistent.

[ilippert]

I like to offer a friendly disagreement. Your argument seems to miss temporality. Only because now no referenced entry exists, it does not mean it will not exist in future. JabRef does and cannot know about the future. But JabRef could ask the user about their future intentions (and of course a default might follow your reasoning).
I see two options

• add this to the preferences world or
• ask the user (what do you want delete/do not delete /always keep/always delete [though still a preference option to change an "always" would be needed])

What do you think?

[koobs]

@Siedlerchr No longer waiting for feedback (OP responded)

[ruanych]

I also found another problem, different articles can have the same Citationkey. I am not sure if this is the expected behavior.

I don’t really understand how crossref works, in other words, how does it work with Citationkey.
I only found crossref in BibTeX source.
When I add A to the crossref in B and modify A, the content preview of B does not update.
A can be added to B's crossref twice.

[ilippert]

I also found another problem, different articles can have the same Citationkey. I am not sure if this is the expected behavior.

this sounds like a familiar problem. Worth checking this indeed.

I don’t really understand how crossref works, in other words, how does it work with Citationkey.
I only found crossref in BibTeX source.
When I add A to the crossref in B and modify A, the content preview of B does not update.
A can be added to B's crossref twice.

Sorry, I am not sure I understand the issue you are formulating here. Would you rephrase, please?

[ruanych]

Create First (the Citationkey of First is First) and Next, before add First to Next's corssref:

After added First to Next's corssref:
The Year of First seems to be previewable in Next.

Change the Year of First from 2020 to 2021, the Year in Next in the preview is still 2020.

I only found crossref in BibTeX source, I don’t really understand how crossref works.

[ilippert]

Thank you a lot, this helps.

you have successfully identified a bug: the year date should be updated immediately. I suggest you create a new bug report and reference the discussion here.

[k3KAW8Pnf7mkmdSMPHz27]

@ilippert you are referring to that the content of the crossref field disappear? (e.g., crossref = {CiteMe3} will disappear if the entry with citation key "CiteMe3" is deleted)

@ryyyc

I also found another problem, different articles can have the same Citationkey. I am not sure if this is the expected behavior.

Just because you can, doesn't mean that you should 😛
Citation keys are supposed to be unique, and if they are not they might lead to problems with other features as well, not just crossref.
If a user is using the generate citation keys feature, if two entries get the same citation key, JabRef will append a letter to the citation key to maintain uniqueness.

I don’t really understand how crossref works, in other words, how does it work with Citationkey.
I only found crossref in BibTeX source.

Are you referring to the need of pressing enter after typing the citation key? Otherwise I can recommend The biblatex Package for looking up information (unless you really need to use BibTeX). § 2.4.1 (page 41) is about cross referencing. biblatex/biber is often better documented

[ilippert]

@ilippert you are referring to that the content of the crossref field disappear? (e.g., crossref = {CiteMe3} will disappear if the entry with citation key "CiteMe3" is deleted)

Yes. The problem is indeed that if crossref = {CiteMe3} is deleted, then the entry with citation key "CiteMe3" gets deleted.

[ilippert]

I suggest to consider the issue here in relation to the issue/feature request proposed at #6404

[koppor]

Refs #6294

[koppor]

IT terms:

• cascading delete versus non-cascading delete
• composition versus association

[ilippert]

Might it be the case that in
JabRef 5.4--2021-08-19--05a0ce9
Linux 5.13.10-200.fc34.x86_64 amd64
Java 16.0.2
JavaFX 16+8
my desired way of not removing the crossref is already implemented? Seems so.

[koppor]

I added it to the next milestone so that the developers re-check and can close / update the issue accordingly.

[koppor]

Quick thoughts based on the dev call

• Update of the main table should work in the case of cross-referenced data, too.
• If entry A references entry B, takes field title from it. Entry B is deleted, what happens to A?
  • crossref from A to B stays (broken)
  • field title in A is just empty

@k3KAW8Pnf7mkmdSMPHz27 :)

[ilippert]

Above I had pointed to a potentially preferences based approach for handling the question (what happens to A?). Meanwhile I became aware of another concept. I could also imagine a kind of shutdown or startup wizard, that tells the user: JabRef has found references to crossrefs, that do not exist in this library. Should these references be deleted within the referencing entries? then offer a list of entries with option check boxes for removing or keeping the crossref.

[k3KAW8Pnf7mkmdSMPHz27]

I'd lean more towards clean-up actions, i.e., the default behavior should be that broken crossrefs are kept (but perhaps highlighted) and it is up to the user to decide if they should be removed. In that case, the clean-up action can be added as a Save action.

Clean-up and Save actions are already there so it shouldn't be too hard to implement.

But there is also the issue of what to do with broken ones crossrefs that you want to change, since most likely you want to change them all at the same time X)

[ilippert]

But there is also the issue of what to do with broken ones crossrefs that you want to change, since most likely you want to change them all at the same time X)

I guess we might have this scenario: user is about to quit JabRef, the Clean-up & Save action recognises broken crossrefs. What to do? I would appreciate a UI dialogue with four choices

• remove broken crossrefs
• do not quit JabRef and sort out crossrefs now
• quit JabRef now and remind me next time I start JabRef to sort out these specific entries for their broken CrossRefs.
• ignore

[k3KAW8Pnf7mkmdSMPHz27]

I could also imagine a kind of shutdown or startup wizard, that tells the user: JabRef has found references to crossrefs, that do not exist in this library. Should these references be deleted within the referencing entries?

Shouldn't something like this (ideally) be triggered when you delete the entry or remove the crossref field? A warning saying "x entrie(s) references this entry, are you sure you want to delete it?"

I would suspect that most broken crossrefs are created by the key generation.

Thought I think we are starting to move away from the original issue ^^

[ilippert]

Shouldn't something like this (ideally) be triggered when you delete the entry or remove the crossref field? A warning saying "x entrie(s) references this entry, are you sure you want to delete it?"

this sounds good to me

I would suspect that most broken crossrefs are created by the key generation.

not in my use case - but I have no idea about the statistics.

Thought I think we are starting to move away from the original issue ^^

I think we are discussing the approach to a user-friendly fix.

[koppor]

Meanwhile I became aware of another concept. I could also imagine a kind of shutdown or startup wizard, that tells the user: JabRef has found references to crossrefs, that do not exist in this library. Should these references be deleted within the referencing entries? then offer a list of entries with option check boxes for removing or keeping the crossref.

Some years ago, we wanted to move away from pop ups to more user-driven actions. That check should be added to our "Integrity Check": https://docs.jabref.org/finding-sorting-and-cleaning-entries/checkintegrity

[koppor]

Our Integrity Checks also offer checking for missing cross referenced entries:

What is missing, is following:

I guess we might have this scenario: user is about to quit JabRef, the Clean-up & Save action recognises broken crossrefs. What to do? I would appreciate a UI dialogue with four choices

* remove broken crossrefs

* do not quit JabRef and sort out crossrefs now

* quit JabRef now and remind me next time I start JabRef to sort out these specific entries for their broken CrossRefs.

* ignore

Thus,

• offer fix action at the found issue
• ignore integrity check (this should be available for all integrity checks). IMHO the decision should be stored within the BibTeX as JabRef-comment

[koppor]

Current action points:

• We need to check whether deletion of an entry also deletes the cross-referenced one
  • Deleting a bib item that another item cross-reference, will clear the second item's crossref field (if it is a perfect match)
• We need to split this issue into several ones

[k3KAW8Pnf7mkmdSMPHz27]

Also refs. koppor#542 (clarify how cross-refs are displayed)

[ilippert]

JabRef 5.5--2022-01-09--7d4916e
Linux 5.15.13-200.fc35.x86_64 amd64
Java 16.0.2
JavaFX 17.0.1+1

Here is a use problem that problematises potentially
this point

• Deleting a bib item that another item cross-reference, will clear the second item's crossref field (if it is a perfect match)

mistakingly the collection entry existed several times. search for its key
now, deleting one of these removes the entry label from the other cross-referencing entries.

Now Ctrl+z actually reverses the action, but in the corresponding view (search key), the crossreferencing entries are not reappearing.

Now I close jabref, restart, and I find the crossreferencing entries are still referencing the key (good).

[k3KAW8Pnf7mkmdSMPHz27]

Now I close jabref, restart, and I find the crossreferencing entries are still referencing the key (good).

This is strange. If I save the library after having undone (ctrl + z) the "delete entry" action, I don't find the cross-referencing entries again. (the field is deleted)

[k3KAW8Pnf7mkmdSMPHz27]

(Mostly notes for me) It seems likely it is caused by https://github.com/JabRef/jabref/blob/main/src/main/java/org/jabref/model/entry/ParsedEntryLink.java holding on to a BibEntry reference, although I can't explain

close jabref, restart, and I find the crossreferencing entries are still referencing the key

---

jabref/src/main/java/org/jabref/model/database/KeyChangeListener.java

Line 40 in ff47dae

citeKey.ifPresent(oldkey -> updateEntryLinks(null, oldkey));

clears the "linked" field if the parent entry is removed.

Regarding undo not restoring #1645 (comment)

[ilippert]

Note, working with
JabRef 5.6--2022-03-15--6406619
Linux 5.16.13-200.fc35.x86_64 amd64
Java 17.0.2
JavaFX 17.0.2-ea+3

I sense the issue is also relevant for merging entries: consider this real case:

1. create a collection type entry with the entry label X.
2. copy that entry and change the entry label to Y (I do that occasionally mistakenly, but it is a real use case)
3. create a new entry Z that crossreferences either, X.
4. merge X and Y and now have only the label X

I find that even if Z referenced X, now the crossref to X is removed in Z.

[ilippert]

JabRef 5.6--2022-04-25--5c9d898
Linux 5.17.4-200.fc35.x86_64 amd64
Java 17.0.2
JavaFX 18+12

Also, combined with search it is tricky.

Search for entry label X
when I have several entries with the same entry label X, and I delete all-1 of these entries, then the crossreferencing entries disappear. Undoing that action then does not make the crossreferencing entries reappear within the search results.

In the video, after the beginning action till 00:14 you can jump forward to 00:53 to then see what next happens (long period of calculation in between).

Peek.2022-05-05.10-56.mp4

[ilippert]

I like #6404 (comment) suggestion of a dialogue that informs users that an entry is related to certain other entries, and provides the user with various options.