-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request: Ability to easily switch between databases #174
Comments
+1 |
+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. |
I am currently thinking about how this could be implemented. I think it is important to provide a good user experience both for 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:
I'm open to your suggestions! |
@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. |
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. |
@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. 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:
Did I get all the use cases here? If that's fine, then...
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? |
looks like I lost everyone... :( |
KeeAutoExec:
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. |
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... |
Hi all, |
I'm on it... I'll do a better test then, but it will require more time :) |
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. |
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. The next steps for me are to be able to search through all databases, instead of selecting the DB each time. |
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.
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:
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. 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 ;-) |
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. 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:
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 |
thanks for the feedback, @Karreg and @muchtall |
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! |
Available in online version for the moment if I'm not wrong... |
It may not available in stable yet but available in beta. |
Looking forward to it hitting stable! |
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.
The text was updated successfully, but these errors were encountered: