Cutting and pasting items makes them lose their created date


#1

Steps to reproduce

  1. Choose an older item, created several hours or days ago for easy comparison
  2. Cut and paste the item to a new parent
  3. Observe that both Created and Modified date are set to now date/time by hovering over item bullet

Expected result

Expecting only Modified date to be updated, not Created.

Actual result

Original Created date is lost, making it difficult to track how long a to-do has been open, for example.

Environment

Web macOS 10.13.2, FF 57.0.1


Additional comments

Cut and paste should function essentially as a keyboard-based move, which does not create a new item and therefore should not touch the created date.

I understand that your implementation for this feature seems to be recreating the item(s) completely, so they get a new date, but in this aspect this is wrong. Even if creating a new item behind the scenes, it should copy the Created date value from the old items.

The created date is a key aspect of tracking the age of a to-do, or when a particular piece of information came in. The current behavior really throws this usefulness out the window when an item is re-parented, and the only workaround is to start putting in manual dates on every item, which would really clutter up the display.


Moved items don't keep their creation date
#3

I’ve created a report for the same bug, I’ll summarize here the relevant points.

Features which have this issue:

  • Cut and paste with keyboard shortcuts
  • “Move to” feature
  • Dragging an item in the document panel to create a document
  • Drag a document to create a new item from it

The issue also affects all the sub-items of the moved element.

I am not sure if the last edit date should change, moved items are not being edited (their content is not changing, only their location), at least this is how moving files works on most operative systems.


#4

28 days later with no dev comment, or even a tag. @Erica, is there a chance this can get on the fix roadmap?


#5

@Erica can this at least get a Tracked status as a bug? It seems like it should be a relatively easy fix, to get the created date from the entity being moved (if you’re actually creating a new one behind the scenes when it’s a cut and paste operation for example).