Shared database: Entries are additionally assigned to groups of another user logged in

[m-mauersberger]

JabRef version

5.5 (latest release)

Operating system

Windows

Details on version and operating system

openSUSE Leap 15.3

Checked with the latest development build

• 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. Login to shared database (PostgreSQL) with two different users (different login data).
2. User B adds entries to group G2.
3. User A adds an entry to group G1. The entries from user B (step 2) are automatically assigned to group G1 as well. It seems like user A added more entries than intended.

We use JabRef to collaboratively work on our common literature. JabRef runs on Windows and Linux as well. But most of us - especially when this problem occurred - use Windows. We name our groups and subgroups in the pattern: group -> subgroup1:group, subgroup2:group -> subsubgroup1:subgroup1:group and so on. Our database contains more than 7500 entries so that every action (e.g. adding an entry) takes about 5 seconds. Processing time is hence not negligible for us.

It is my overall impression that the database synchronization is not stable.

Thank you for your help!

Edit: The problem appears as well when accepting changes that are suggested with #8586: All entries accepted by user A are automatically assigned to the group in which user A added an entry recently. Here it does not seem that user B needs to be incorporated.

[Siedlerchr]

Regarding the group issue: That is expected, Group information is stored in the entry

Regarding the performance, yes, I know where the bottleneck is, it's all executed on the main thread. I recently looked into it and tried to fix it but occasionally ran into kind of deadlocks because of the underlying architecture. This will need some major refactoring.
#8496 (comment)

[m-mauersberger]

Thank you for checking up so far.

That is interesting, that it seems to be solely a performance issue. But is it correct, that wrong group assignments are expected? Users A and B add completely different entries (e.g. from different DOIs) which are supposed to be in completely different groups G1 and G2. The entry from user B should not actually be in group G1 as well, but just in group G2. That means that user A sees the entry from user B in "his" group G1 after synchronization.

[Siedlerchr]

Okay, I think I misunderstood your issue, I thought that user A and B are putting the same entry to the group. But for different entries this seems odd.

[m-mauersberger]

Could it be a problem with the clipboard? It seemed plausible if the additionally assigned entries were still in the clipboard - but from the other user. I. e. when user A pastes some entries JabRef would gather the content from both the clipboards from users A and B, which are logged in at the same time.

Or, if it would not be the clipboard, then it could be somehow an entry list, which is still filled by some actions of user B (e.g. batch group assignment) and is incorporated when user A pastes his entries.

[m-mauersberger]

I have got new insights regarding the problem above:

1. User A adds/copies entries E to group S1.
2. User B pulls changes from the shared database while focussing group S2. After pulling changes the entries E from user A are additionally assigned to group S1.
3. User A pulls changes and gets conflicts in the database as he has the correct local E (only in group S1) but there are wrong E in the shared database (in groups S1 and S2). That means that wrong assignments of E to S2 are directly synchronized to the shared database by user B in step 2.

If user B focusses group S1 and pulls changes then everything is fine. Maybe there is a wrong group assignment in the "pull changes" part of the code.

[Siedlerchr]

@m-mauersberger A thanks for the insights. @HoussemNasri recently resolved some issues regarding group merging in #8994
Maybe that was the same underlying issue?

[ThiloteE]

The latest development build of JabRef is available here: https://builds.jabref.org/main/

[m-mauersberger]

Now I was able to test the new development version (JabRef 5.8--2022-12-08--8ebdb52) with this issue. It seems to be solved and the issue can be closed now. Thank you very much for your efforts!