See timestamp for last change to field

cboettcher
cboettcher
Community Member

I want to see when I last changed a specific field within a 1Password entry/record. How can I do this?


1Password Version: 6.8.2
Extension Version: Not Provided
OS Version: OS X 10.11.6
Sync Type: Not Provided
Referrer: forum-search:history

Comments

  • Hey @cboettcher! This may not be the simplest way of viewing this, but if you have a 1Password membership, you can use Item History on 1Password.com to view previous versions of items. These are date-stamped and you can compare previous versions to present to determine when you last changed a particular field. This is a bit simpler with passwords specifically as previously used passwords (and associated date-stamps) can be displayed in the 1Password app in the item details.

    Are you able to share some more details about why you're wanting to see when certain fields other than passwords were last altered? Knowing what you're seeking to accomplish can help us share some better tailored ideas if we've got 'em or otherwise pass along some actionable feedback to the team for future consideration. Thanks! :chuffed:

  • cboettcher
    cboettcher
    Community Member

    Thanks for replying, @bundtkate. I'd like the password field history functionality to extend to all fields within an entry, regardless of whether they are passwords.

    I understand that this is a big ask. However, entries/records within the application are used to represent assets like routers and servers. The data that's associated with those types of reified objects will change multiple times over the lifetime of the device. Rather than let things get sloppy and append field/label one after another, it be nice to have changes tracked.

  • AGAlumB
    AGAlumB
    1Password Alumni

    Thanks for letting us know. We don't have plans to do that, but it's certainly something we can consider for the future.

    We do, however, already have a similar item history feature in 1Password.com accounts. That is possible because of the granularity of the database setup we're using there, in addition to (virtually) unlimited storage and performance. It isn't something the existing local vault formats can support, and I'm not certain that it would be technically feasible given those constraints though.

This discussion has been closed.