Creating or editing a group of cited entries triggers "Library has been modified by another program." whenever saving the library subsequently

[systemoperator]

Tested with the latest JabRef development version (master branch) on Ubuntu 16.04

Steps to reproduce the behavior (creating group):

1. Save current library (only needed, if the library is indicated as modified)
2. Create a group of cited entries with an attached *.aux file
   • Side note: even without attaching an existing *.aux file and leaving this field empty allows reproducing it as well
3. The library has been modified, indicated by the star character (*) in the tab of the main table
4. Save library

Observation:

After saving the library, the message "Library has been modified by another program." shows up, asking either to choose "Dismiss changes" or "Review changes". When such a group has been created (or updated), then this message appears whenever the library is changed and gets saved.

Steps to reproduce the behavior (editing group):

After restarting JabRef and opening the previously opened library the aforementioned issue does not arise until one does the following (or one repeats the steps above):

1. Save current library (only needed, if the library is indicated as modified)
2. Edit an existing group of cited entries
3. Click "OK" to save the changes in the dialog for editing an existing group of cited entries (no changes need to be made in the dialog)
4. A dialog appears, asking "Assign the original group's entries to this group?"
   4.1. Either click "Cancel" or "OK" (it does not matter)
5. The library has been modified, indicated by the star character (*) in the tab of the main table
6. Save library

Observation:

After saving the library, the same issue as described above arises.

Remark:

As stated in #6394, groups of cited entries also have another issue.

Removal of issue:

1. Delete the group of cited entries or change the group type to something different than "Cited entries".

Observation:

The issue vanishes.

[tobiasdiez]

Maybe the color code changes upon saving? (I slightly remember there was something like that in the code...)

[systemoperator]

I've tried to find some differences in the variable changes in

jabref/src/main/java/org/jabref/gui/collab/DatabaseChangeMonitor.java

Line 46 in 4e220f6

if (!changes.isEmpty()) {

but there is quite a lot information contained. I could not find any differences, only things which are equal.

[systemoperator]

What I could find is that in "metadata change", the originalMetaData entry had subscribers, but the newMetaData entry doesn't.

[tobiasdiez]

@ #6420 (comment)
This looks like a bug. The change scanner should only return things that are different...

What you you mean by the "subscribers" for the metadata change? What's the content of

jabref/src/main/java/org/jabref/logic/bibtex/comparator/MetaDataDiff.java

Line 35 in 4e220f6

public List<String> getDifferences(JabRefPreferences preferences) {

?

[systemoperator]

The content of changes at

jabref/src/main/java/org/jabref/gui/collab/DatabaseChangeMonitor.java

Line 46 in 4e220f6

if (!changes.isEmpty()) {

looks as follows:

The content of changes at

jabref/src/main/java/org/jabref/logic/bibtex/comparator/MetaDataDiff.java

Line 35 in 4e220f6

public List<String> getDifferences(JabRefPreferences preferences) {

is:

The subscribers I was talking about were at (but probably irrelevant):

[systemoperator]

But I suspect properly fixing #6394 could fix this as well, because everything started with that.

[tobiasdiez]

Thanks for the investigation. It's strange. I don't see any problems with the equals method of the groups:

jabref/src/main/java/org/jabref/model/groups/AbstractGroup.java

Lines 58 to 60 in 4e220f6

	AbstractGroup that = (AbstractGroup) other;
	return Objects.equals(this.name.getValue(), that.name.getValue()) && Objects.equals(this.description, that.description)
	&& Objects.equals(this.context, that.context);

It's also strange that you experience this problem since bc57d22, since this change doesn't touch anything that is relevant for the group diff.

Can you please have a closer look and see which groups fail the equality check (and why).

[systemoperator]

@tobiasdiez I have concretized the description and reproducibility of the issue in its description #6420 (comment). Can you reproduce it this way?

[systemoperator]

It's also strange that you experience this problem since bc57d22, since this change doesn't touch anything that is relevant for the group diff.

@tobiasdiez You are right about commit bc57d22. It is not the cause of this issue. I have tested this issue before this commit now and it persists. (Sorry for the confusion.)