Moved items don't keep their creation date

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.


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!


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


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.


I would also like to see this addressed

Thank you!

1 Like

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.

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.

1 Like

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


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

1 Like

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

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