Problem/Motivation
The {node} table tracks both when a node was created and when it was last modified. However, {node_revision} only saves a single timestamp for each revision, indicating when it was last saved. Given that individual revisions of nodes can be edited and overwritten with new changes, this is insufficient.
For background, see: #1528028: Add tests for reverting revisions where revision_uid and uid differ
Proposed resolution
Replace {node_revision}.timestamp with two columns—{node_revision}.created and {node_revision}.changed—to store creation and modification times for each revision.
{node}.changed would then track {node_revision}.changed for the default revision.
Remaining tasks
TBD
User interface changes
TBD (none anticipated)
API changes
TBD
Comments
Comment #1
chx CreditAttribution: chx commentedSure, we can add code to store this and how do we want to display this information? Currently the revision list shows one timestamp. Give me a mockup and I will deliver the code.
Comment #2
jstollerI'm not sure we need to display both dates in the UI. Right now the timestamp stores the creation date for each revision, so maybe its enough to replace all occurrences of {node_revision}.timestamp in the UI with {node_revision}.created.
The bigger issue seems to be having this data available in the db and exposing it through Views and Tokens, so it can be accessed if needed. If we want to change the UI to take advantage of {node_revision}.changed, then perhaps that should be saved for a follow-up issue?
Comment #3
catchLet's do this in one issue #1528028: Add tests for reverting revisions where revision_uid and uid differ.