"Created" and "Modified" dates not set properly on item duplication

Thank you! It's definitely helpful to offer more meaningful feedback to first understand some of the reasoning behind a decision.

As to that most common use case... yep, I've done that, too. However, at root, these use cases are really about access control, and the use of copies is merely a workaround for lack of better functionality to solve the problem at hand. Data duplication for access control is a terrible practice even for basic users -- multiple, independent representations of the same secret is a sure path to confusion down the road and can easily lead to accidental account lock-outs and other problems -- so instead of encouraging it, 1P should offer solutions to the underlying challenges.

For the short-term version of this problem, 1P has done just that. These are cases when, for example, you want to give a wifi password to a friend, and they're addressed by the recently released web-based sharing feature where one can share an item without requiring the recipient to sign up for an account. It was waaaay overdue, but it's a wonderful implementation that perfectly solves the problem, with no data duplication in sight.

The long-term version of the problem is still present. Think, a team that needs to accommodate a contractor on a particular project, or the family who wants to share some accounts with a foreign study student residing with them for a few months. What's needed here is to share a handful of items scattered across existing vaults without blowing up the vault organization (which can't even solve the problem in some cases) -- enter item copies as the solution. Which, well, sucks.

As to the custom template feature, I'm very much looking forward to it, but it's not a whole solution. There are two primary reasons I use copies as a "template clone", as you called it. One is the situation that custom templates would solve, namely, when I want to define a new type of item. For example, I might want an item type to track combination locks with a serial number, description, and combination. Going forward, I'll periodically create independent new instances of this item type.

The other case is just to shortcut data entry time on an ad hoc basis. For example, maybe I just bought one of those software bundles that sites like MacUpdate sells, where you get 10 or 15 apps in one purchase but you still register them separately. I might register the first app and record all the purchase details in 7 or 8 fields of the item, then as I get around to registering the others, I'll duplicate the first item, edit the app name, serial number and publisher information, and leave all the purchase details. An example on the biz side is when a dev or QA team is creating a bunch of test accounts that share URLs and other info. In all these cases, the goal of the copy is just to save time in the moment, not to make a template to reuse in the future or share with others. (I don't think custom templates would even work here, since values also need to be preserved, not just fields, but it's been a long time since I looked at the feature.)

Speaking of a long time, there's also the small matter that custom templates transitioned to vaporware a long time ago, at least in GA guise. I mean, it's been in beta for, what, six, seven years now? And only on the business side, to boot. You folks just did an entire rewrite in far less time. The feature has obviously had a very low priority.

The Watchtower point is a good one. Interestingly, when I use copy as "template clone" feature, I always replace the password. Which makes sense - I'm using copy as a starter shortcut, not for access control. That also explains why I don't want the field histories in there.

Maybe what's really needed for my use case is a slightly different feature. YouTrack, an issue tracker I use at work, has a "clone issue as draft" feature that could fit the bill here:

https://www.jetbrains.com/help/youtrack/standalone/Clone-Issues.html

If 1P offered a similar feature, it would make a shallow copy of the item (no history) in unsaved state and dump you right in edit mode on it; canceling the edit would leave you without an item. The password would be cleared to discourage reuse and maintain full accountability from an audit perspective. Basically, this feature would be a shortcut route to a new item with its own audit history. This would actually be a great feature for my workflow, and it would allow the Duplicate feature to maintain its newfound purity.

Hi folks,

This specific "item specification" has not been changed for several years and I believe it goes back as far as 1Password 4. If one of the 1Password apps were not following this, it would be a bug in that version. That's part of the reason we're doing this new 1Password Core project, to use a unified codebase that follows the same specs across all platforms and also why we chose to rename this from Copy to Duplicate to better reflect its use.

BobW,

How are people out there using the duplicate feature? If they're using it because they want to create a second, archive-quality copy of an item that retains cross-item audit-ability, then this approach makes sense.

The most common use case is to duplicate the item into another vault they're sharing with friends, family members or teammates. So, it is meant to be a "duplicate" of the same item with the same timestamps. It's not meant to be used as a "template clone" in this case, even though we are aware of this use case and have even recommended this.

For that specific use case, we do want to bring our custom template feature out of beta that's available in 1Password for Teams/Business to everyone but we don't have an ETA on this.

Another reason to keep the same timestamps is that Watchtower depends on this data as well; to indicate when a password hasn't been changed for an example. So if you share an item that has no password history but has a password, the CreatedAt timestamp is used to calculate when the password was created or last modified; which is where our Watchtower's Compromised Logins feature kicks in. If we duplicate to another vault and change the timestamps, then it would throw off the audits and folks may not know they are using a compromised Login item.

We do want to look for a different approach for this as well.

Yeah, I'm not a fan, either. Not only is it a change from v7, it's also the opposite of how the mobile apps (at least iPhone and iPad) still work. A super-confusing behavioral change, IMHO.

How are people out there using the duplicate feature? If they're using it because they want to create a second, archive-quality copy of an item that retains cross-item audit-ability, then this approach makes sense. But I really can't think of any use-cases where one would need to do that, given other features in 1P that better fill those sorts of needs. I suspect that most people are using the feature as I am: using an existing item as a template/starting point for a new item, either because the setup is similar (custom fields, etc.) or because most of the information is staying the same (URL, etc.). In these cases, a "shallow" copy is more useful, that is, bump the created and modified dates and toss the value history on fields.

Thanks to this change, I've now got a bunch of items created in the last few months that look like they were created many months or even years in the past, and which look like they had password values in the past that they really didn't. For me, this behavior makes a mess of my 1P data and makes for a lot more work for me -- work that will get the job done less reliably, to boot. Boo.

Hi 1P_Ben!

OK, thanks for that :)
I just find this behaviour odd, because when I duplicate an item it’s obviously created on another date and not one that is specified :) this way you can’t really tell which item is an original one and which one is a duplicate, they are the same so I edit one of them.
I also have a template items for system connections which I duplicate each time when I create a new connection. So afterwards I cannot find them sorting by create date (only by modification date). I can’t say it’s a major issue, it’s just odd to me :) maybe I’m in a minor group of people, so no worries :)
Maybe you could share the reason why the dates are inherited from the original item?

Hey @akozhin 😃

Our spec for creating duplicates says that the creation and modification timestamps from the original item should be retained on the duplicate, rather than the behavior suggested in the OP of updating those timestamps. I did open an internal discussion on the topic, but thus far there hasn't been any buy-in for changing the behavior. As such, I don't anticipate any changes in this regard.

Ben

Hi guys! Any updates on it? :)
I'm on 1Password for Mac 8.8.0 (80800021, on BETA channel) and still experience this feature :)

Hi BobW

I'm not seeing an existing discussion on this, and it appears the behavior in question may've been an intentional decision on our part:

• CreatedAt and UpdatedAt values should be retained.

I've gone ahead and opened an issue for the team to further discuss the point.

Ben

ref: dev/core/core#12611