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

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

Open
ilippert opened this issue Oct 31, 2020 · 30 comments
Assignees
Labels
bug Confirmed bugs or reports that are very likely to be bugs ui

Comments

@ilippert
Copy link
Contributor

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

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.

@Siedlerchr Siedlerchr added the status: waiting-for-feedback The submitter or other users need to provide more information about the issue label Nov 8, 2020
@ilippert
Copy link
Contributor Author

ilippert commented Nov 9, 2020

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

koobs commented Jan 20, 2021

@Siedlerchr No longer waiting for feedback (OP responded)

@Siedlerchr Siedlerchr removed the status: waiting-for-feedback The submitter or other users need to provide more information about the issue label Jan 20, 2021
@ruanych
Copy link
Contributor

ruanych commented May 9, 2021

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

ilippert commented May 9, 2021

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

ruanych commented May 9, 2021

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

before


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

next


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

after


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

question

@ilippert
Copy link
Contributor Author

ilippert commented May 9, 2021

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

k3KAW8Pnf7mkmdSMPHz27 commented May 27, 2021

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

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

ilippert commented Jun 8, 2021

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

@koppor koppor changed the title deleting entry removes the entry label from the other entires that crossref it deleting entry removes the entry label from the other entries that crossref it Jun 10, 2021
@koppor
Copy link
Member

koppor commented Jun 10, 2021

Refs #6294

@koppor
Copy link
Member

koppor commented Jun 10, 2021

IT terms:

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

@ilippert
Copy link
Contributor Author

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 koppor added this to the v5.4 milestone Aug 29, 2021
@koppor
Copy link
Member

koppor commented Aug 29, 2021

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

@koppor
Copy link
Member

koppor commented Sep 27, 2021

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

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

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

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

k3KAW8Pnf7mkmdSMPHz27 commented Sep 29, 2021

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

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

koppor commented Oct 25, 2021

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

koppor commented Oct 25, 2021

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

grafik

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

koppor commented Nov 22, 2021

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

@koppor koppor removed this from the v5.4 milestone Dec 6, 2021
@k3KAW8Pnf7mkmdSMPHz27
Copy link
Member

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

@ilippert
Copy link
Contributor Author

ilippert commented Jan 11, 2022

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

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

k3KAW8Pnf7mkmdSMPHz27 commented Jan 20, 2022

(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


citeKey.ifPresent(oldkey -> updateEntryLinks(null, oldkey));
clears the "linked" field if the parent entry is removed.

Regarding undo not restoring #1645 (comment)

@ilippert
Copy link
Contributor Author

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

ilippert commented May 5, 2022

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

ilippert commented Apr 4, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed bugs or reports that are very likely to be bugs ui
Projects
Status: Normal priority
Development

No branches or pull requests

6 participants