1Password 8: Import or open .PIF file
I am considering moving from Bitwarden to 1Password 8. I installed 1Password 8. I also found the converter suite and exported my Bitwarden vault to a .PIF file. However, the option to open or import a .PIF file seems to have been removed from 1Password 8 (or is at least very well hidden).
1Password Version: 8.7.0
Extension Version: Not Provided
OS Version: macOS 12.4
Comments
-
Hey @Chr1sS :
As of this writing, 1Password 8 does not have the import functionality, but it's something that we're actively working on and will be implemented in the app in the near future.
As a work around, let's temporarily install 1Password 7 on your Mac to import your data.
- Download and install the 1Password 7 for Mac app from our website: Download 1Password 7 for Mac.
- Open and sign in to the app.
- From the menu bar, select File > Import...
- Select Other > Import a 1PIF file.
Once you've imported your data, can you please verify that your data is correct / complete on my.1Password.com (in a web browser)? Once you've verified that your data on my.1Password.com is correct / complete, you can remove 1Password 7 with the following steps:
- Quit all open web browsers.
- Open the main 1Password app. Choose 1Password > Quit 1Password Completely from the menu bar.
- Drag 1Password from the Applications folder to the Trash. Do not use an "app cleaner" or "uninstaller" tool to remove the app or additional files. If prompted, enter the password you use to sign in to your Mac.
Let me know how everything goes or if you have any questions along the way. 😊
Alvin
0 -
Deleted. I found the option I was looking for...
0 -
-
Hello @Alvin,
Many thanks for your support!
Yes, I was able to import my data. But I was not satisfied with the result. All fields of my software licences are jumbled together in the notes field. To edit this manually would be very tedious.
I am currently trying to import these data using a CSV file. But I always get the error message "No objects found". 1Password is very picky. I exported a test entry from 1Password to a CSV file and imported it again - even this also does not work as expected because all fields are mapped incorrectly.
Do you have a CSV template processed correctly by the 1Password import filter?
0 -
@Chr1sS ,
I assume you used the converter suite.
Bitwarden does not have a stock Software License category, so the converter would have no idea what to do with any custom fields.
That said, the converters were designed to be highly customizable.
Do you have a clear set of fields for your software licenses? Is so, and you want to try again with a custom version, let’s discuss how your data is labeled or structured.
Alternatively, the csv converter could be used.
0 -
@MrC,
The fact that Bitwarden does not have a Software License category makes things a bit more tricky. No question! That's why I exported the software licenses in CSV format and "cleaned" the dataset before importing it into 1Password.
I was now able to import the following example. I used as field description the "official" 1Password field names:
Name,Version,Lizenzschlüssel,Lizenziert für,Registrierte E-Mail-Adresse,Kaufdatum,Auftragsnummer,Auftragssumme,Download-Seite,Herausgeber,Notizen
1Password,8,1234,Me,me@me.com,01.05.2022,1P1234,10.00 EUR,http://download.com,1Password,No bundleI have two issues:
- The fields are not mapped correctly. The first line is also imported. 1Password does obviously not need the field names. I thought that 1Password would use to map the fields correctly.
- 1Password does not use the German field descriptions but the English ones.
I have the impression that 1Password does not want the field labels in the first line and expects the fields in a certain order.
0 -
Sorry, I'm not sure if you are done, or still are looking for help.
The 1Password.com CSV does not do software license imports.
1Password 7 for macOS does, but it requires a specific order to the columns. It does not want a column labels header row.
The csv converter in the converter suite supports import of software licenses. It does not care about column order, but does require specific column labels to match columns, and to perform category auto-detection. These labels are described in the README, but are summarized here:
Labels in bold trigger category detection, at least one of those is required.
I created a CSV with your data, including your header, and added my own header row using the required column names. Here are the results.
$ perl convert.pl csv -v ~/Desktop/Ch1rsS.csv Imported 2 items Exported 2 software items Exported 2 total items You may now import the file /Users/cappella/Desktop/1P_import.1pif into 1Password
The first record is your data, the second was your header that I left in the file to show that the columns mapped when correctly labeled. Note that the purchase date value went to notes, since that data value does not meet the requirement for the converter (but that can be customized if your date data is consistent and well formatted).
I can't speak to the ultimate localization of your 1Password vault's labels. The 1Password folks will have to address that.
0 -
@MrC,
Thanks for the hint to look in the Readme.html! I had already tried to open it, but in Safari it's a blank page. I thought this was a dummy file for future additions. Now I was able to open it with Firefox. I found the order to put the information in the CSV file. Let's hope there is also a way to use the localized field labels.
0 -
@MrC,
I ended up successfully migrating several hundred software licenses. A very important recommendation was to convert the CSV file to a PIF file using the Perl tool. This also solved the localization problem.
Since it may be helpful to others, I will briefly describe my workflow:
- I exported the software licenses from Bitwarden into a CSV file.
- I opened the CSV file with Apple Numbers. As Bitwarden does not have a software license category, all licenses were exported with the type "note". As I had all licenses in a folder, I could easily select them. However, all user-defined fields have been combined into one field named "fields".
- I split the contents of "fields" into individual fields. This is an example of the formula I used to extract the version information: IFERROR(REGEX.EXTRACT(E2,"(Version: )(.*)$",1,2),"").
- I copied the table to a new table (Edit > Paste Formula Results) and fixed some entries manually.
- I removed the columns I did not need anymore, such as "fields" and changed the column labels to match the list given in the readme.html.
- I exported the table to a new CSV file.
- I ran the Perl script. Two comments: The argument "--sepchar" mentioned in the readme.html is obviously not supported anymore, and it is obviously also not required. The Apple Numbers CSV export format uses ";" as the delimiter. However, the argument "--sepchar ;" was not required. The Perl script still worked beautifully. Moreover, the date format has to be yyyy-mm-dd, not mm/yyyy or mmyyyy as mentioned in the readme.html.
- I finally imported the generated PIF file into 1Password.
- Done :-)
Again, many thanks to everybody for supporting me!
0 -
Great work!
Looks like the most difficult part was getting the "fields" split and labeled.
I looked at the sep_char issue. I've reproduced it and believe this is a simple typo bug in the CSV parsing module used by the converter suite. I'm checking a fix now, and if I am correct, will contact the author.
[ edit: I've confirmed the bug, and will create an bug case for this issue ]
I had not noticed this issue, so thanks for your thorough testing here. Without feedback like yours, the suite would not have become what it is today.
Cheers, and Enjoy 1Password!
0 -
Moreover, the date format has to be yyyy-mm-dd, not mm/yyyy or mmyyyy as mentioned in the readme.html.
Note 4 regarding Purchase Date in the README is incorrect. I think this was a brain-skid on my part.
The date parser detects dates of the form:
yyyy-mm-dd
yyyy/mm/dd
M/D/YYYY (where M and D are one or two digit months and days, respectively)
mm/yyyy
mmyyyyThese templates were determined empirically based on user's exports. I'll update the README.
I've also fixed the sepchr issue.
Update has been posted.
0 -
Dear @MrC,
I have just discovered that you are the author of the amazing import tool and not an employee of 1Password. I am very impressed with your dedication. Many, many thanks! This tool is a game changer and should be officially supported by 1Password, perhaps even integrated into the main program. Have you ever considered to publish the code on Github? This would make discussions and feedback even easier.
0 -
Hi @Chr1sS
Thank you for your most kind words; they are much appreciated.
The good news is that you were able to achieve your goal. The bad news is that I failed to make it clear(er) that I'm not a 1Password employee, as I don't want anyone to be mislead. I'm keenly aware that there is a significant amount of trust (or code review) required by users to use a tool such as the converter suite given the highly sensitive nature of data such as their passwords and personal life information.
Regarding storing code on GitHub, this has come up a few times. I've considered it, and periodically revisit my thinking and reasoning on this. Thus far, I've avoided it for a several reasons:
- it adds to my workload and provides me personally with very little benefit
- it creates yet another branch of communication and tracking (I'm not a fan of multiple mechanisms for bug reporting, issue tracking, feedback). I'm fairly certain, based on feedback, that the vast majority of converter suite users have come in through this forum, and it has seemed best to use their help request thread as the point of communication.
- my self-imposed requirement is to ensure that (almost all) communication regarding the suite is available in one area, for openness, transparency, any oversight, and long-term trust building / maintenance. It also makes search, and thread referencing much easier. When I have offline conversations, I summarize here.
- GitHub is not a site / service geared towards non-technical users. A landing page of a listing of code files is just plain wrong for the suite's primary audience.
- My build workflow for the documentation won't generally work for others, as it requires some local tools and configuration.
That said, I'm still receptive to the idea. I just need a sufficiently large enough overall value-add or benefit to nudge me in that direction.
Related to the sepchar issue, I just now received an email from the developer:
Thanks, fixed, committed and pushed.
MrC
0