Moved items don't keep their creation date

[Atomk]

Steps to reproduce

1. Create a new item and some sub-items
2. Wait a bit, or just use one of your already existing lists
3. Use the “Move to” feature to move the item to another location, or drag it in the document panel to create a document, or drag a document to create a new item from it
4. The moved item (and its sub-items), which should be equal to the original, have the time of “moving” as the creation and last edit date instead of the original values

Expected result

Every item and their sub-items should keep their original creation date, since the items already exist (they are not new items) and they are not being edited (their content is not changing, only their location). This is also similar to how moving files works on a PC.

Actual result

See step 4 above.

Environment

Windows 7 64bit, Chrome 63 (64bit)

---

Additional comments

It doesn’t make sense to show the creation date of an item if it is this easy to change it, it is more reliable to use ![date]. Thanks for your attention and for your work!

[Alex_Pasternak]

I agree, but would argue this is a duplicate with the previous issue I created, which has obviously not been addressed yet.

Cutting and pasting items makes them lose their created date

Steps to reproduce Choose an older item, created several hours or days ago for easy comparison Cut and paste the item to a new parent 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 p…

[Atomk]

Oh, I tried to look if someone had the same issue but I had’t seen your post, sorry. I’ll add a link to this discussion there, since I also wrote about sub-items and other features that have this issue I am unsure about deleting it.

EDIT: Nevermind, it looks like I can’t delete this, I’ll just copy the link.

[Louis_Kirsch]

I would also like to see this addressed

Thank you!

[Louis_Kirsch]

Hey @Erica and @Shida,

is this bug being tracked? I hesitate to create new documents from existing nodes because it would make me lose all the creation and modification meta data.

[Shida]

Yup it’s in the tracker. We had an initial discussion on how it should be implemented last month or so but it hasn’t been in our worklist just yet.

[Shida]

Update: Fix ready and will be deployed within a week.

[Louis_Kirsch]

Would also be good if backups contained the edit and creation date and this would be applied when importing.

[P1]

Hooray!!! Thanks guys for fixing this!!! I’ve just verified it works in the web interface

[P1]

I wonder if it makes sense to create a new bug for the preservation of the metadata in backups