I can only speak for 1Password, but apart from username/password, it also saves URL and auto fill settings. It would be cool to import/convert such a credential as/to a Web Page connection with not only username and password, but URL and autofill set.
URLs are already imported. They are surfaced in the credential object's "Auto Fill" properties. Does that not work for you?
Regarding auto fill: While I admit it would be nice if we could import those settings as well, it's hard to implement as 1Password's auto fill is based on a more automatic "guessing" system. Royal TSX basically requires a one-on-one mapping between HTML fields and values of the credential. So without having similar logic as 1Password for guessing which fields correspond to which values it's not possible to translate the auto fill mappings from 1Password.
Well, being an idea it's not about a lack of possibility, but more lack of convenience. When adding a Web Page, I cannot access Credentials to fetch the URL. It only works if I first find the Credential in the big list, filtering, then right click, copy URL, then add web page, paste URL, go to Credentials, search the list again for the same credential... Life is getting shorter every second, this hassle could be improved, and that's what I suggest.
I think the best would be a button next to URL field on the Web Page plugin properties, which would allow to select a credential and optionally set it as the Web Page's Autofill credential too. Could be a dialogue with a drop down and a checkbox, or just a drop down with a "Do you want to use this credential for Auto-fill?" Something like that would work much better.
Guessing the autofill fields is a feature I suggested in another 'idea', so it's related. After all, this is not bug reports, but ideas, feature suggestions, so why not think big at this point. In my mind, TSX's purpose is to replace/integrate a tool set a developer uses in a single integrated environment, which for internet development consists of a browser, credentials management, file management, remote control (terminal/RDP/VNC) and remote editing. The more integration it provides, and the more basic features of the tools it integrates it makes accessible, the more convenient it is to use - the more reason for people like me to switch to it from using those tools separately. It should be easier/more pleasant to use TSX than reach out for 1Password or ForkLift or whatever. That's what I have in mind when suggesting such ideas. It doesn't have to replicate the full functionality, but it should grab the essentials, the reasons why the tools are used, so they will become reasons to use TSX. That's my thinking.
In addition, just FYI, 1Password has overrides for its automatic guessing feature, which could be imported too. And one more thing, 1Password can store several URLs per login, so although taking the first URL is perfectly fine, it might be nice to allow for multiple URLs, or at least show a warning about it. For example, I don't remember if a Credential has two URLs, and when I copy URL in TSX, I don't know which one I take - until I paste it, and then I have to go all the way back...
Hmm, I'm not sure I follow you there.
Are you aware of the fact that you can configure a credential with an URL and autofill parameters and then right-click it in the navigation panel and select "Web Page (Ad Hoc)" to launch an ad hoc web page connection based on the credential? So basically, if you just want to have a web page connection with everything set to default you don't have to create a separate object and can just use the credential itself.
I am talking about 1Password credentials, which display a small message 'Because this object is dynamic, it's not possible to save any changes' on their Properties pane. From my observations, these credentials are not imported into TSX document, but loaded from the Vault on each TSC restart. Which is good, they are always up to date.
Also, I want to keep my things in order. I have 1.5K credentials for all sorts of logins, and I don't use any structure there, because browser plugin finds the right login by URL. But in TSX I organise connections by project. Each must be in its own folder, that's the whole benefit of it.
Basically, each iPhone has a "Migrate from Android" feature, and each Android phone has "Migrate from iPhone". That's how they compete for markets. They don't make you recreate the contacts one by one with copy-paste. I only suggest a similar tactic for your system, to smoothen migration of customers from other programs they already use, to get them invested in your product, enjoy its convenience, which increases the chances of them staying with it. That's my logic behind this suggestion.
Oh, I see now.
Well, Google and Apple have thousands of engineers working on their software. I'm building the Mac version of Royal TSX basically alone. So while I would love to have all kinds of features available, I have to very carefully consider each single one of them and also take into consideration the amount of work to maintain that feature in the future.
That being said, I think what you want is to actually import (or in your own words: "migrate") your 1Password credential vaults. To do so, open your 1Password vault in Royal TSX, then go to "File - Save Document As…" and choose a location to save the newly migrated document. Now you're free to make changes to the credentials contained within this new document. It's however no longer tied to 1Password, thus it's more of an import than a sync from that point on.
I understand your situation, and I don't intend my ideas to be treated as anything top priority, but I personally wouldn't rush to reject an idea completely if it makes a commercial sense, but is not technically feasible at the moment. 1Password (or similar) are available for Windows as well, so it's not a Mac-exclusive feature.
And by the way, quantity is usually the opposite of quality ;) In case of TSX, it certainly is.
Yes, we always aim for quality instead of quantity! I didn't dismiss the idea (otherwise I would've marked the idea as "Not taken"). I just wanted to explain the difficulties in implementing such a feature.
For the next major release, one of our focus area will be password/credential management and I'm pretty certain that lots of neat features similar to this suggestion will make it into the final release. So stay tuned!