SplashID conversion help (DoctorBrown)
Comments
-
Hello MrC, I also have SplashID which has many records, many Web logins types, some credit cards, some other record types. I also have these records assigned to a number of Splash ID defined Categories. I decided to try the 1.08 version of the converter and see how it would do with my SplashID data. The data did not get imported into the 1Password Categories as I expected. NONE were imported into Logins category. Most of the items that were imported ended up in the 1Password Secure Notes Category. Of the items that were imported into the Secure Notes category, most have a title that starts with the Splash ID Record Type.
For example:
Bank Acct: Wells Fargo Checking
Software: Norton GhostThe following table shows how the Splash ID Type records were imported into 1Password Categories.
Splash ID type:------------Imported 1Password Category:
Bank Accts (4)------------Secure Notes w/ title: Bank Accts: *
Computer Login (14)----Secure Notes w/ title: Computer Login: *
Credit Cards (5)----------Wallet: Credit card
Frequent Flyer (2)-------Wallet: Reward Program
Identification (8)----------Wallet: Membership
Insurance (4)--------------Wallet: Membership
Membership (1)-----------Secure Notes (no title prefix)
Software (4)---------------Secure Notes w/ title: Software: *
Web Inactive (50)-------Secure Notes w/ title: Web Inactive: *
Web Login (253)--------Secure Notes w/ title: Web Login: *The items that ended in Wallet do make some sense. But the items that imported into Secure Notes make no sense to me. I don't understand what I'm doing to get this result. How is this data intended to be used once it is imported? How is it intended that I can use these records to create 1P login items that can login?
My environment is:
Windows 7 x64 Pro
Splash ID Version 6.2.0.0
1Password Version 4.6.0.598
Convert_to_1p4 version 1.08.0 -
I've moved your question from what was a RoboForm thread into your own thread here.
SplashID "categories" are essentially just labels (1Password's Tags). They have no meaning, and provide no context or semantics. That you call or label something as "Bank Account" does not have any meaning to the converter, because a label does not supply field semantics.
About your various "login" types. SplashID does not have a stock "Computer Logins" type - it has, as you know, "Web Logins". So your computer logins aren't recognized as Login types. And SplashID has "Web Logins", not "Web Login". Did you customize that type name?
And likewise for your "Bank Accts". SplashID's stock template name for a bank account is "Bank Accounts".
This is the poison that users must swallow when they customize types, categories, and records in password managers. Export and conversion becomes far less robust. You've essentially created a code that only you (or some other smart human) can decipher.
Now, when I designed the converters, I took customized data into account. And the converter can handle a wide range of customization. But it has to be taught, and I can't know ahead of time what users have done to their data. I tried to design the converters such that customizing them was not too difficult as well. So we can add additional entries in the input table, or change the existing entries to match yours. We can even make it so that some field matching can handle any number of values, but it has to be told to do that.
The stock import names that are matched are the textname values in this table fragment:
addressses => { textname => 'Addresses', type_out => 'note', fields => [ bankacct => { textname => 'Bank Accounts', fields => [ clothes => { textname => 'Clothes Size', type_out => 'note', fields => [ combinations => { textname => 'Combinations', type_out => 'login', fields => [ creditcard => { textname => 'Credit Cards', fields => [ email => { textname => 'Email Accounts', fields => [ files => { textname => 'Files', type_out => 'note', fields => [ frequentflyer => { textname => 'Frequent Flyer', type_out => 'rewards', fields => [ identification => { textname => 'Identification', type_out => 'membership', fields => [ insurance => { textname => 'Insurance', type_out => 'membership', fields => [ membership => { textname => 'Memberships', fields => [ phonenumbers => { textname => 'Phone Numbers', type_out => 'note', fields => [ prescriptions => { textname => 'Prescriptions', type_out => 'note', fields => [ serialnum => { textname => 'Serial Numbers', type_out => 'note', fields => [ server => { textname => 'Servers', fields => [ vehicles => { textname => 'Vehicles', type_out => 'note', fields => [ weblogins => { textname => 'Web Logins', type_out => 'login', fields => [Those are the names that must match exactly. Anything that doesn't match goes to Secure Notes.
Does that make sense?
0 -
It does make sense once I see fundamentally how the tool is making the matches. Yes, I had modified the stock types. Once I reset the modified SplashID types back to the 'stock' types, where possible, the import worked better.
I took some time to look over the README.pdf file in more detail and see how I overlooked some important information on the capabilities of the tool. There are few areas where the documentation could be improved which would help those like me avoid some time consuming mistakes.
I can only talk about the conversions I've attempted. The following would have helped me immensely:
- Emphasize more fully what the tool can and can't do. For example, that some (in my case, many) imported login may need to be edited after conversion and import. Describe why and how to one would approach fixing the logins, if possible, or using the data that has been imported. For example, if the login doesn't successfully login, tell the user to manually navigate to the login page, copy and paste the login info, and re-save the login item.
- In the case of SplashID, in the Export instructions, highlight what are the supported types and exact matches that can be made. (Conversions for other managers may have similar limitations.)
- In the Usage text for the SplashID --help cmd, the list of supported import types, does not match the list you provided above. I think I see why the list was written as it is, but somewhere the exact match (including any spaces) must be documented, in the README or Usage text.
0 -
Another thought that may or may not be feasible or wanted... It sounds like the custom mapping may need to be created and compiled into the tool. Is there a way for the user to feed the mapping into the tool? Say from a specially formatted input file? Many GUI based import tools have a windows where you can map the fields from one system to another.
0 -
Hi @DoctorBrown,
I'm happy to hear you've made positive progress, with better results.
I'll address each of your requests individually. I'm worried by doing this, as it often comes off as argumentative. I accept your feedback, and will also offer some counter-position.
Emphasize more fully what the tool can and can't do. For example, that some (in my case, many) imported login may need to be edited after conversion and import. Describe why and how to one would approach fixing the logins, if possible, or using the data that has been imported. For example, if the login doesn't successfully login, tell the user to manually navigate to the login page, copy and paste the login info, and re-save the login item.
This is one of those "make it better" requests, that's impossible to satisfy, because it is neither measurable nor quantifiable. No documentation can describe the universe of all things that are not covered. I could refer to AgileBit's documentation regarding next steps, but I won't try to duplicate what is already covered by that documentation. Every author has to know both his audience and his scope. I feel it is a user's responsibility to learn about the product he or she purchased, and AgileBits does a very nice job documenting their product.
In the case of SplashID, in the Export instructions, highlight what are the supported types and exact matches that can be made. (Conversions for other managers may have similar limitations.)
There is nothing to highlight, as ALL of the SplashID stock types are supported (as I try do to with every converter). It is not practical to explain the specifics of how categories and fields are matched. The mechanics are different for each converter, there are special cases, localization issues, and such documentation would become sick with the over-documentation syndrome (TL;DR).
There is some documentation that generally addresses this area:
Customized Fields and Types
Many password management programs have limitations with exported data. Some do not export the meaning of fields, and use only simple, generic labels, often the same label across all entry types (making type detection difficult or impossible). And some do not output the field label at all. When no type information is present, converters attempt to determine the type of entry based on matching certain key field labels against a table of stock, known entries. When no field labels exist, the specific number of fields may be used. And some converters may use other information present in the export file to hint at the entry type.
Some password management programs provide support for customized templates or for customizing the fields in an entry. Customized field names which are not recognized by the converter will be included in the standard notes section of the entry as Field:Value pairs. When no field labels exist, generic field labels such as Field_n (where n is 1, 2, …) are used. And customized entries which cannot be matched against the known types will converted into 1Password Secure Notes.
In the Usage text for the SplashID --help cmd, the list of supported import types, does not match the list you provided above. I think I see why the list was written as it is, but somewhere the exact match (including any spaces) must be documented, in the README or Usage text.
The list of import type keywords is listed in the help command, and it matches the supported categories one for one (since the import type table is used to generate that list). However, you may be confusing the string used that names the template within the password manager with the keyword used for the
--imptypesand--exptypesoptions. From the docs:Options: --imptypes and --exptypes
By default, all exported entries will be processed and converted to types that 1Password can import. The options
--imptypesand--exptypesallow you to selectively choose which entry types to process on import and which entry types to export to the 1Password 1PIF file, respectively.For example, if you only wanted eWallet’s types bankacct and votercard converted, the option
--imptypes bankacct,votercardwould be added to the command line. And if you only wanted note types to be exported to the 1Password 1PIF file, then the option--exptypes notewould be added. This may result in more entries than you expect, as some password manager entry types will be split into two or more different 1Password entry types (aka Categories).I think the match between these keywords and the password manager stock string representation is obvious. But even if I wanted to present such a keyword-to-password-manager's-category-string, it is often not possible or practical. In many cases, they aren't used, or I don't have those strings, or they are localized, or they are pattern based (and users don't understand regular expression patterns). More importantly, they really aren't that useful, since the overarching rule is that the converters work against stock category and/or field names, sometimes field positions, and sometimes entirely based on heuristics.
Another thought that may or may not be feasible or wanted... It sounds like the custom mapping may need to be created and compiled into the tool. Is there a way for the user to feed the mapping into the tool? Say from a specially formatted input file? Many GUI based import tools have a windows where you can map the fields from one system to another.
The script file is just a well-formatted text file. Edit the source of the script itself when doing customizations. The import table was created in such a way as to be readable, editable and quickly customized. It is the formatted input file you are asking for. Remember, this is almost always a one-shot converter for users. They don't really care about how it operates, want a full discussion on customization techniques, or want to learn about how to format one file so that it can be read in by another file so that it can be run through the converter.
So, in closing, almost everything you've asked for is addressed in some way by the documentation. But here's the rub, and you said it yourself, "I took some time to look over the README.pdf file in more detail and see how I overlooked some important information on the capabilities of the tool." You, like all users, don't have the time or inclination to review all of the documentation, and even when fully read, the implications cannot be fully understood upon a single reading or single use of the tool. More and more documentation by definition can never trump the inherent complexity and the TL;DR issue.
0 -
You, like all users, don't have the time or inclination to review all of the documentation, and even when fully read, the implications cannot be fully understood upon a single reading or single use of the tool.
And here is the rub with a tool as complex as this. A tool like this is generally going to be a one time usage. You are correct that more documentation will not overcome the inherent limitations in the tool. For me, the limitations were not clear at all in the documentation, even after repeated readings. Understanding these limitations in the beginning would go a long way to toward setting the user's expectations of what the tool can and cannot do and what preparation to perform ahead of time to get the best chance of getting a conversion that is useful for them.
I'm sure some of my ideas won't work, but I'm just trying to be helpful. If my ideas are not appreciated, then so be it. I'm finished with what I can accomplish with the tool. I hope this and your future projects go well.
0 -
Your ideas have been both helpful and much appreciated. For me, its an iterative process of improving the facility, based on feedback such as yours and all others who hasve used the converters to start using 1Password as soon as possible.
So, thanks!
0
