So I am talking in the actual 1Password software - not via any browser extensions.
Within the actual application, passwords can be defined in the "Accounts" section as well as the "Login" section however, password changes and histories are logged in the latter section only. For several of my credential items, it makes more sense to have them stored in the "Accounts" section so it would be nice to have functional parity between both the "Logins" & "Accounts" sections…
Great - thanks Kyle - this would be a really awesome enhancement. Also, I did ponder for a bit on why this would have been left out but honestly, I cannot think of any credible reason so if you come across the real story, I would be curious to hear the rationale. I can't imagine this wold be hard to implement but then again, I didn't write the code so not completely sure.
We don't generally comment on or promise if or when a feature
request will be a part of future 1Password plans, so while Kyle has
certainly passed on the request we can make no promises as to if or
when it may be part of 1Password.
Truly unfortunate - it's always a good idea to share the future
with your customers beyond just the security stuff. Most software
companies do this at some level and while agreed that making firm
commitments is a double-edged sword, keeping dark lights on the
future is not a good SOP.
This is something your mgmt team should consider changing...
Support Staff10 Posted by Kyle Swank on 21 Aug, 2012 01:15 PM
It's more than just time commitments. We hate saying we'll
include something, then see it not make the cut. It has happened in
the past and we've been burned by it. So, now we simply don't
comment on new features until they arrive. It sets
We also have customers who will buy our product based on what it
may be in the future, not what it is now, then be disappointed when
we said feature x will be available, but still isn't. That they
bought our app because of that feature.
I hope you can see the reasoning. We just set up disappointment
by saying we'll include anything at all. We'd rather under promise
and over deliver, than do the reverse.
Wanted to give a +1 to this feature request - I just hit the
same problem when updating a system account password on a machine
that cares about password history. I'm keeping that account info in
the Accounts area, just like the original poster. Since I use
1password for all my passwords (not just browser auto-fill), having
the history recorded in the Accounts section would be really