Store general "previous data" for more than just passwords? In my case specifically old credit card?
I just had a few credit card numbers rotated due to the 2014 Home Depot security breach. I'm here entering all my new numbers and I realized that its a PITA because I have to store a bunch of old data in the Notes field for each card so that I can look it up if I need to. 1P already has the right "store old passwords in a hidden field, just in case" feature. I'd like the same thing for a few fields in my Credit Card object since I frequently want to know "what was the previous number for this card?" or "did I used to have a card ending in x1234 and what's the right number now?". Similarly, if I look up an old card number, I'm going to want to know the associated CVV2, Exp Date, and maybe some other info.
Three questions stem from this issue:
(1) Does this feature exist now? Maybe I just need to turn it on? Maybe I'm just an idiot and someone can point out how I do it already?
(2) Is it possible to do the scalable feature request here: add a flag for any 1p object that allows me to persistently store old versions of that field? IFAIK fields have UUIDs that I can't see, so this should be easy to just track the string of UUIDs and tag them as "previous" types, so they are hidden by default.
(3) Is it possible to store complex tuples of "previous" type UUIDs? This is useful in cases like Credit Cards, where the number, CVVx, and security codes are all logically connected.
Comments
-
So I guess that's a no? ha
0 -
This might best be handled by duplicating the existing card, and renaming it as (perhaps appending something like OLD or the last 4-digits to the title), and then using the duplicate for the new card. You retain history, can file it under some folder such as Obsolete or move the record to a separate Obsolete vault. Lots of options.
0 -
That's what I used to do, but storing the relationship between the old card and the one one was a bit cumbersome, hence now I use the Notes field. 1P thought of this "rotation problem" / "persistent history" for some items, but I guess not all of them. Hopefully they'll get there!
0 -
FYI: Your solution complicates and changes significantly the 1PIF format of the exported data, so this will break all the other 1Password program varieties that use it (so they would have to all be updated in lockstep), as well as any program that consumes or produces 1PIF.
I use two approaches, both of which you've used: notes, as well as a soft Title relationship between the old and new. Not to take the wind from your sails, but it might be the best you'll get (at least for the immediate future).
0
