Add ability to sync group structure with KeeShare

[welusa]

Summary

Hi there, first of all, sorry for my terrible english and sorry for wasting your time, but I am too much of a noob to deal with this myself. I stumbled across the KeeShare feature in KeePassXC. Now I am trying to get a hang of how this is working. I am able to synchronize two databases with it. Now to my problem. Synchronizing the entrys works just fine, but the groups aren't getting synchronized. Is there any way to get this to work, so that i can create a subgroup in a synchronized group and it is going to synchronize it as well? I really don't know if this is a feature request, maybe it's only me being to stupid to use this. But when I import or synchronize it on a different device i only get the entrys, all in the group i activatet the keeshare feature for.

Desired Behavior

If i create a sub group in a shared group it should be synchronized / imported to other devices as well. Not only the entrys.

Possible Solution

Context

I would really like this, because i kinda like sorting things. In the future i want everyone in the office to have his own database, in which i can synchronize only the groups he needs or he is supposed to have. Giving him the structure of the groups i chose in my database would make it way more easily to use.

[SnejPro]

I would really like to see this feature ... or maybe it could be made easier to do a full sync with another file (For example with presaved credentials).

[krodelabestiole]

The advantage of only sharing entries is, that receiver is free to rearrange shared entries (moving them into new subgroups, moving them outside of the importing group the share since the synchronize feature will locate those entries - or even deleting them locally).

I'm sorry I don't understand this point. Actually I don't see any reason in favor of this behavior (flattening synced db), unless it's a technical limitation ? If the receiver wants to rearrange, well he/she can. And the "remote" changes will reflect in the "local" database, hence the sync. I don't understand why keys and groups would be treated differently in that regard. Imagine a file manager that would remove every directories and give a bulky bunch of files in no particular arrangement when "syncing" it... (and that would remove the distant tree structure every time it get "synced" again, deleting any arrangement done in the meantime) ?

It is a destructive behavior. Unless I miss something I think this "feat" should be treated a bugfix, not even some kind of option...

[droidmonkey]

Where did you pull that quote from? I agree this is more of a bugfix because the original behavior doesn't make sense in terms of have a shared "container".

[krodelabestiole]

Where did you pull that quote from?

I've just "quote replied" this message above : https://github.com/keepassxreboot/keepassxc/issues/3045#issuecomment-485407646

[N0W0RK]

I quickly want to share my usecase here as it might affect the functionality of the sync DB. I use a WebDAV server to share one keyfile between all my devices. My mobile app(Strongbox) stores a local copy of my Database for quick access and syncs it with the server if there are changes and an internet connection present. I would like simmilar behaviour for the new KeeShare. An added bonus of having the shared file beeing a fully functioning database would be, that my mobile devices could just use that database as the "upstream source" and as far as I understand any change from any device could be properly merged.

[elRicharde]

[> I hope I don't repeat the documentation, but it looks like a misunderstanding for using this feature. Therefore I'll try to clarify the usage of KeeShare:

Neither the database used by the synchronize feature nor the import/export of KeeShare is intended to be used as real database. They are just a transfer format which happens to be a database readable by KeePass. The containers should be in between real databases opened by KeePassXC which use KeeShare to pull or push the changes to the transfer container. The transfer container can an be overwritten or updated anytime by any client - therefore you shouldn't open such a database in a regular scenario - it is intended to be written and read only be KeeShare.

The idea is the following: Client A <=[synchronizes with KeeShare]=> (Transfer container) <=[synchronizes with KeeShare]=> Client B

There is no explicit support for scenarios like this (unless the KeePassXC team says otherwise): Client A <=[synchronizes with KeeShare]=> (Transfer container) <=[opens directly]=> Client B in this case, I think you can use the standard synchronize feature of KeePassXC.

Nonetheless, if you want to open a transfer container directly - make sure it is read only since every change maybe overwritten by another client using KeeShare. At least from my side, there is no guarantee, that transfer format doesn't change, so this may not work in future versions.](https://github.com/keepassxreboot/keepassxc/issues/3045#issuecomment-515361157)

Thanks for clarifying, but i seem to have trouble understanding it correctly.

Is there a User Guide on How to

• Use a DB on Multiple Devices Correctly (i used one KP-File located in my GoogleDrive with 2 PC with KeePassXC and one Mobile with KeePassDX and always got trouble of Dataloss thru overwriting)
• Use a Subset of an DB on Multiple Devices

I switched today to Keyshare-principle, but now i read your post and if i Understand correct I do it wrong now (i open the File generated with KeyShare directly in other Device) I just came to this thread while searching how to handle a third or more devices.

It would be great to have this also Mentioned in the Manual. Thanks in Advance, great tool!

Edit: Also there is no manual for this and I´ve only saw it her as an Answer in an Issue, sould be part of Documentation as well as showing the limits of this functionality.

The advantage of only sharing entries is, that receiver is free to rearrange shared entries (moving them into new subgroups, moving them outside of the importing group the share since the synchronize feature will locate those entries - or even deleting them locally).

Thanks

[jay7x]

Maybe we can get rid of this problem in another way. What if a DB can be "mounted" under some path in the "main" DB? For example, I have my personal DB personal.kdbx and I want a work.kdbx file contents (which is synced from my office workstation e.g.) to appear under the /Work path. Then one can just share the sub-DB and have the proper structure always.