Keeshare does not synchronize referenced fields of clones

[JasperSch]

Overview

I like to create folders that keep track of which secrets I shared with whom. For this I create folders like 'synced_with_JohnDoe' that contain clones of secrets I have throughout my database.

I intentionally use clones such that I don't have to change anything in my own preferred folder structure. E.g. this allows me to cherry-pick a set of secrets which I want to share.

The problem: keeshare doesn't detect when a referenced field is changed in the original secret.

Steps to Reproduce

1. Create secret 'A' in database 'DB1' with username User.
2. Create folder 'sync_with_DB2' in database 'DB1'
3. Clone secret 'A' and put the clone in folder 'sync_with_DB2'. It will have as username {REF:U@my_uuid}.
4. Set up keeshare for folder 'sync_with_DB2' with synchronize, export to file 'sync_with_DB2.kdbx'.
5. In 'DB2' set up a folder 'sync_with_DB1' which synchronizes with 'sync_with_DB2.kdbx'.
6. Adjust the username of 'A' from User to User1.

The from User -> User1 in the original secret.

It gets picked up by the clone in the same database:

It gets picked up by the synchronized file:

It doesn't get picked up by the other database:

Expected Behavior

The changed user name is reflected in the other database.

Actual Behavior

The changed user name is NOT reflected in the other database.

Context

If you change a non-referenced field in the clone (for example 'notes') the change in username does get picked up. So it seems that keeshare can properly evaluate the reference when triggered, but it just can not detect that the referenced value has changed.

KeePassXC - Version 2.7.6 Revision: dd21def

Operating System: Linux Windowing System: Wayland

[droidmonkey]

Might be duplicate of #7282

[marvinkannacher]

I ran into the same problem.

I also believe that the problem lies in the history and the fact that the import algorithm only checks this (or so it seems).

The following example:

DB "1" has an entry "a". The folder "export" is in DB "1" and exports to DB "2". The entry "a" is cloned and moved to the export folder. The clone is written to DB "2". DB "3" imports DB "2".

If entry "a" is now changed, there is an entry in the history, but not in the history of the clone. DB "1" exports the change to DB "2", but without the history. DB "3" checks the history and thinks it is up to date, but it is not. as soon as the history changes (when you touch the clone) everything is updated.

to clarify why you want to use such a setup: it is absolutely necessary for us to keep the folder structure (group structure). that is why we cannot export directly (DB "3" is the DB in which entries are searched).

I hope this helps

Edit: I decided to share the original and keep the clone in out folder structure. looking at @JasperSch example, we only export to DB "2". This interrupts the workflow since you have to navigate to the shared folder if editing an entry is needed, but the importing DB now recognizes a change in history.