If the current version is deleted, the ModifiedOn date of the previous version is updated to today's date. I think this is not ideal because we are losing information about the date of change. The file itself was not modified.
Is the modifiedon field referring to a specific version - or is it just to the overall file (effectively describing all versions)?
> Is the modifiedon field referring to a specific version - or is it just to the overall file
That's a good question. The answer is, it's the former. For example, consider this file
Click on File Tools > Version History to see that there are two versions. The first has "modifiedOn"="
2018-03-14", the second, "2018-09-13". Now retrieve the first version programmatically and check the modified on date:
So you can see that modifiedOn describes the version. I think what might be seeing is that the version is deleted and then, in some corollary activity, the previous version (now the current/latest version) gets modified, bumping the time stamp to the present time. To test this I visited
which has just one version, modifiedOn=2018-08-06. Now I upload a new file version and confirm that there are two versions, the second having modifiedOn=
2019-12-20. Now I delete the new (second) version and see that the first version has modifiedOn=
2019-12-20. Yep, it's just as experienced.
You can see in our code base that bumping the time stamp of the new latest version is done explicitly when deleting a version:
So we must have felt that this was the right behavior when implementing version deletion. do you recall the rationale? shall we change the behavior?
Seems like we should change the behavior, but I’m curious if John (or others) remember the rationale
Per changing modifiedOn is intertwined with marking the object as changed for optimistic concurrency and migration. Disentangling the two is possible but awkward so we should be sure about the need not to change modifiedOn before going forward.