Request: Ability to easily switch between databases

[GiriSrini]

Currently, the only way to switch between databases is to close out of the first one before selecting the second. This is fine on desktop, where typing the password is relatively easy, but on mobile I wouldn't like to have to go through that every time I switch databases.

Example: When opening a database for the first time, entering the full password + other key components makes complete sense, but once inside, there would be an option to switch databases (from the top-right 3-dotted menu, for example).

Also, if you're opening/switching to a database you've already opened without explicitly closing, you would only need to use QuickUnlock (or enter a PIN or use the fingerprint/pattern unlock or something else). Something to still provide some security without taking up too much time.

[Karreg]

+1
On desktop we can open multiple databases at the same time, searches are done on all databases.
A great use case is to have a personal database, and a shared one in a family for example...
Would be great to have the same feature on mobile :)

[muchtall]

+1 for the shared database use case. I keep separate databases for work, personal, shared with spouse, and shared with co-workers.

Add in the capability to work with KeeAutoExec entries, and you've got the killer feature.

[PhilippC]

I am currently thinking about how this could be implemented. I think it is important to provide a good user experience both for
1.) opening several databases which are "linked" with the AutoOpen group (from KeeAutoExec)
2.) opening several databases which are not "linked"

I think for 1.) I would integrate the mechanism to load the linked databases automatically. On the root group view, I probably would add a kind of dropdown in the action bar on top to switch between databases. Search will search all databases.

For 2.), I would add another menu option to load an additional database. (The mechanisms from 1.) are important for this use case as well, of course.)

I believe an important feature would be to be able to move entries between databases (which involves saving both the source and target database file.)

Locking would become a bit more tricky:

• which master password should be used for QuickUnlock? (In 1.) it always should be the "master" database's password, for 2.) it could be the last opened or the one which was opened first.)
• should there be an option to close specific opened databases or is it sufficient to be able to close all databases at all?

I'm open to your suggestions!

[PhilippC]

@GiriSrini @Karreg @muchtall did you see my post regarding implementation considerations? I am surprised I haven't received any feedback and definitely would appreciate if I could get some user thoughts.

[GiriSrini]

I did see it, but I didn't, and still don't, have very much to add. Your suggestions seemed like great ideas on the whole—maybe I should have responded sooner saying this, so I'm sorry for apparently leaving you hanging.

Otherwise, there isn't very much I can really single out at the moment. However, I do think that for QuickUnlock in scenario 2, you should be able to choose which database to use QuickUnlock on before opening it, if that's plausible and still secure. Also, I, at least, would appreciate an ability to individually close certain databases.

[Karreg]

@PhilippC sorry for missing this out. I almost missed your reference too... Too busy.

I have seen your suggestion, and did not see any reason to comment it out at the time.
However, I'll gladly comment it.

First of all, before talking about implementation, we should define the behavior. That's what you did, mixed up with implementation. Let's summarize it here:

• Search should be done on all opened databases
• In case of multiple entries (it's more prone to happen with multiple databases), there should be a way to select which entry to use
• Users should be able to move entrie between databases
• Users should be able to automatically open a group of databases
• Users should be able to manually open another database without closing the previous one
• Users should be able to create a database group from all currently opened databases

Did I get all the use cases here?

If that's fine, then...

• There should be no issue with searching through all opened databases right?
• In case of multiple entries, do we currently have the select frame? I don't have this use case personnally, but this will come in handy with multiple database. Indentified use cas is: a shared databases for family, containing a family account, and a personal database with a personal account for the same service.
• Moving entrie between databases will require to:
  • keep the entry
  • allow group browsing in dest db
  • allow group creation in dest db
  • drop the entry in dest db
  • save the dest db (to secure the entry)
  • remove the entry from src db
  • save src db
  • what do we do if save fails on one or another?
• How are defined db groups? KeeAutoExec works like a master db and slave dbs... It could be enough. There's no user doc for this plugin, so I guess we create a group or entries with reference to the other database, with password to open it. However, I see a caveat here: reference won't be transposable between desktop and mobile world. KP2A mainly works with clouds, not local dbs. Where KP works with local files. I don't think KeeAutoExec groups will work, but maybe I'm wrong? A simplier solution would be to store the group in KP2A cache data, like references to databases. If we lose the cache it will require to recreate it, but it's not that often, also it will ease the creation of multicloud environnement (one db in one cloud, another db in another cloud). Looks like a simplier and less error prone than KeeAutoExec to me
• Manually opening a db without closing the previous one could be the norm. When multiple dbs are open, we could have a menu item appearing, proposing to create the db group, with a checkbox to select which db should be in that group. This is were we could define the master password for this group, and the quick unlock could be based on this group master password.

After all this thoughts, I think the easiest and safest way to create a group would be to create a local kbdx file, with good security, containing the references to the group databases, with master password (this is why a good security is required, maybe based on strongest security settings of the group databases). This way, handling the group could have the same behavior as handling a single db : closing it will close the group for instance.

What are your thoughts about all this?

[Karreg]

looks like I lost everyone... :(

[muchtall]

KeeAutoExec:

However, I see a caveat here: reference won't be transposable between desktop and mobile world. KP2A mainly works with clouds, not local dbs. Where KP works with local files. I don't think KeeAutoExec groups will work, but maybe I'm wrong?

At least in my use-case, I have an "Auto-open" database that contains just KeeAutoExec entries for my other databases. I open that database, plug in my password, and it opens everything else up automatically. That database is stored on Google Drive, however I have gone through times where I have copied that database locally as well. In either case, each of the auto-opened child databases was stored via WebDAV. I'm not sure of the capabilities of KeeAutoExec with other cloud services as I've not personally had need for them. I don't think adding support for local child databases should be a problem as, in that case, you probably aren't sharing the parent database between devices (why would you, since one of the child databases is local after all). I'm not sure what the URL would look like for a local database, but I don't think that it matters much just as long as KP2A knows what to do with it.

I think it would be best to implement this in a way that keeps KeeAutoExec compatibility, however I'd just be happy with being able to open multiple databases as a group. I'm not terribly partial to how it gets implemented.

Quick-lock and closing: I also agree that quick-unlock should be based on the parent database. From a user standpoint, I think people just want it to work as if it's one monolithic database that they are interacting with, so authenticating against the parent just makes sense IMO.

Same goes with closing databases. I don't see a lot of reason to close individual databases alacarte. Would probably just be easier to understand if it closes them all at once. Again, just my opinion.

[Karreg]

If compatibility is working fine, great. But if compatibility means an half baked solution, I would be very disappointed. It would not be usable for me. And from what I see, this is most probably the case.

However, this would need a survey with as much user as possible, because I guess we aren't representative of all KP2A users...

[PhilippC]

Hi all,
I have just uploaded the first version (1.07-pre1) with multi-database support to the beta channel. If you're not yet a tester, please join https://play.google.com/apps/testing/keepass2android.keepass2android and give feedback on the current implementation.
Make sure you always have a database backup while testing!
Note that I have not yet implemented KeeAutoExec support, you have to open the databases manually. But KeeAutoExec support is planned for the final 1.07 release (that's why this issue is not yet closed)

[Karreg]

I'm on it...
First dumb test is failing though. I just wanted to open the same DB (2 copies) but it's failing because ID are existing in the two DBs.
This may or may not be an issue... I don't have any insight on this.

I'll do a better test then, but it will require more time :)

[muchtall]

I'm seeing this error when opening two different databases:

System.Exception: Database contains entry id 34697A408A5B41C09F36897D623ECB31(KeePassHttp Settings) which is already contained in (redacted).kdbx! Please close the other database before opening this one.
at keepass2android.LoadDb.TryLoad (System.IO.MemoryStream databaseStream) [0x0017c] in <966410b7a74740cbb01a90546f9ca377>:0
at keepass2android.LoadDb.Run () [0x000ac] in <966410b7a74740cbb01a90546f9ca377>:0

[Karreg]

The functionnality is there, and usable. It's a good first version, but I think the search through all databases is what is missing the most.
Switching databases is not the easiest, but since it should not happen often, I wouldn't say it's an issue.

The next steps for me are to be able to search through all databases, instead of selecting the DB each time.
And auto-opening a set of DB, this one requires a bit more thinking (I still think that KeeAutoExec is a bad idea in mobile env).

[muchtall]

In regards to the usability, I had to delete all my "KeePassHttp Settings" entries to get the databases to load, so probably need to fix that since I'm sure there's plenty of chromeiPass users out there.

It looks like searching across databases isn't yet supported (apologies if this needs a separate feature ticket). Having multiple databases open but being unable to seamlessly search across them seems only slightly more convenient than just opening the individual databases when you need them.

I still think that KeeAutoExec is a bad idea in mobile env

Why is it a "bad idea"? I still don't see what the problem is with that. What makes mobile so much different than a desktop environment? I think it would make sense to tap into an already supported method for handling this, as KeeAutoExec does it quite well. Why re-invent the wheel by coming up with a new method? I could definitely see a use case personally where I have one "master" DB that contains only AutoOpen entries for each of my personal and shared databases, each available using a cloud service sudh as WebDAV. That exact same master DB could be used in KeePass2Android if the KeeAutoExec method were supported (again, maybe needs a separate feature request). Coming up with a new method unique to KeePass2Android would in effect make that method incompatible with KeePass.

I think perhaps the confusion with this comes back to these statements:

KP2A mainly works with clouds, not local dbs. Where KP works with local files.

Not true. KP2A works fine with local files, if that's your use case. And KP works great with clouds as well, as 100% of my databases are being accessed via cloud services on KP. If someone is using all cloud, all local, or a mix of both, there's still no good reason not to support KeeAutoExec. If someone has all local databases, the path format doesn't really matter since the databases aren't going to be used on any other platform. Even if they were to be manually copied to another platform, the same path inconsistency issue would exist between Windows, Linux, and Mac platforms, and that hasn't stopped people from using KeeAutoExec so far.
</my-humble-opinion>

I'm not looking to start an argument. Just trying to advocate for what I think is probably the most flexible and cross-compatible implementation.

Thanks all for their input, and thanks @PhilippC for your work on this project! Much deserved beer coming your way ;-)

[Karreg]

Yep, we could discussed again about it, I see a lot of issues with KeeAutoExec, even in its original environment, that I exposed before. The only reason I see here to re-use the same paradigm is that "it exists". This is not a good reason.
Also, it's still re-inventing the wheel, since the code will still to be written... Or copy-pasted, which is even worse.

Just to continue the discussion - because it can take long, but it does not mean it's useless - what would be a KeeAutoExec entry to:

• Auto open a database B from database A
• database B is in Google Drive, shared from the drive of someone else
• database A is in Dropbox

I think this is the most weird behavior you can find, but still probably a good use case of multiple DB. If KeeAutoExec knows how to describe this use case, in a way that works both with KeePass on Windows and Keepass2Android (at least the implementation you could expect), then I will accept that this KeeAutoExec stuff could work... Because I may be wrong, but I think you can't describe this "not so weird" use case

[PhilippC]

thanks for the feedback, @Karreg and @muchtall
@muchtall did you try the search? Both the "quick search" in the activity title as well as the advanced search should find entries in all open databases (and display the database file name)
@Karreg I do think your "weird situation" should be describable with KeeAutoExec. Please let's move that discussion to https://sourceforge.net/p/keepass/discussion/329220/thread/509d35a111/

[lee-tts]

Sorry to revive this thread but is this function available in the main app yet? I'm using the latest (Offline) version from the play store and don't see anywhere I can open a second database. Thanks!

[Karreg]

Available in online version for the moment if I'm not wrong...

[Small-Ku]

It may not available in stable yet but available in beta.

[lee-tts]

Looking forward to it hitting stable!