In this design I might have "AutoOpen" 8. The above puts the onus on me to define the records into each folder that I want have opened. Processed against a new folder called AutoOpenKP2A and it ignored all other folders which includes ignoring the existing AutoOpen folder. I would be 100% "OK" with with a design wherein KP2A I would be totally OK with a KISS design.įor example, the existing KeyAutoExec pluggin uses only folder AutoOpenĪs an end user of both Keepass on a PC and KP2A on my phone Nice job.įar be it from me to tell you what the ideal design should be.įrom an end user perspective. Hi Philipp, Long time user (and donator) to your project. However, I am not sure how to detect if my app should overwrite existing non-specialized fields or create a new specialized field then.ĭo you think this will work for your use cases? Any suggestions on how to improve this? I would also like to integrate a kind of configuration dialog for AutoOpen entries. This allows device specific settings for AutoOpen. If that specialized field exists, this value is used. instead of reading the Url field, it reads URL_KP2A_1234 (with 1234=Android ID). Before KP2A reads any of the fields in the AutoOpen entry, it checks if there is a field called fieldname+" _ "+device/app-ID. My suggestion is to define a device/app-ID (e.g. Except for WebDav/FTP entries, there are no paths which are supported in KeePass as well as KP2A. many entries store absolute paths or paths relative to the Keepass executable. I don't think that a single AutoOpen entry as it is defined at present will work across devices, e.g. I am interested in feedback, both from KeePass users and Dominik, about the following thoughts:
I suppose that many users would benefit from having something like KeeAutoExec on Android as well, so I am planning to integrate this in KP2A, too. As the author of Keepass2Android, I have recently added support for having several databases open simultaneously ().
0 kommentar(er)
