Signing back into the Community for the first time? You'll need to reset your password to access your account. Find out more.
Forum Discussion
"Created" and "Modified" dates not set properly on item duplication
I know this has been reported previously, but I can't seem to find it. There's a bug in the beta where if you right-click an item and choose the Duplicate… command from the contextual menu (don't try...
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.
