When the user clones a key and maintains a reference to the original, the key that uses a reference is displayed grayed out with "Ref: " prefixing the field. The original key appears normal, as it did before cloning. If the original key is deleted and moved to the "Recycle Bin" there is no issue and things continue to function. If the original key is deleted from the Recycle Bin the cloned field remains gray but the Ref is broken and the underlying syntax is shown. Any keys that REF'd that key are now useless. I propose that a warning would be useful here to ensure the user is okay with this potentially dangerous choice.

It is understandable to expect user caution to be enough protect from this breakage accidentally, but with a large number of objects, especially when nested in folders, it's not hard to imagine this happening without due diligence on the user's part to prevent it or notice the broken REF before saving the database.

At the very least, perhaps some documentation nudging users towards organizing ref'd objects in a thoughtful manner and preferring to delete ref clones over originals would be useful.

At the same time, it seems an easy thing to scan through the open database for.

Expected Behavior

I expect that when deleting a file that other files currently REF a field from that a warning be displayed mentioning this fact and providing an opportunity to cancel the deletion in response.

Current Behavior

The file gets deleted and any REFs silently break.

Possible Solution

When the above situation occurs, it would be nice to give a chance for automatically redistributing the REF (fill-in the value so they are no longer ref'd, or choose one of them as the new value holder and re-REF any others to that one). This would need to happen for each REF'd field, as there could be multiple.

Steps to Reproduce (for bugs)

1. Add a new entry (Ctrl+N) named test with user/pass "123"
2. Clone entry (Ctrl+K) and check "Replace username and password with references" and hit OK
3. Select the original "test" entry and hit Delete entry (Ctrl+D) and hit Yes
4. Notice that "test - Clone"'s Username is still linked by the username showing as "Ref: 123"
5. Click "Recycle Bin" to go there
6. Select the original, now deleted "test" entry and hit Delete entry (Ctrl+D) and hit Yes
7. Click back to original location where steps were started from
8. Notice that "test - Clone"'s Username is broken by the username showing as "Ref: {REF:U@....}"

Context

I was organizing some keys by Group and noticed that one key fit best in two groups, but duplicating the objects may result in them falling out of sync upon next password rotation. Therefore I felt the Refs feature would be perfect for this use case, but find it hard to determine which group should be the "master" group that the others REF.

While I can see solutions I can implement by care and convention, I want to trust my REF objects to always be up-to-date and in-sync with their REFs without having to concern myself with the very organizational details the REFs seemed meant to save me from.

Debug Info

KeePassXC - 2.2.0
Revision: caa49a8

Libraries:

• Qt 5.9.0
• libgcrypt 1.7.7

Operating system: Windows 8.1 (6.3)
CPU architecture: x86_64
Kernel: winnt 6.3.9600

Enabled extensions:

• KeePassHTTP
• Auto-Type
• YubiKey