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

chx’s picture

chx commented

Sure, 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.

jstoller’s picture

jstoller
he/him
commented

I'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?

catch’s picture

catch
he/him
Primary language English
commented
Status: Active » Closed (duplicate)

Let's do this in one issue #1528028: Add tests for reverting revisions where revision_uid and uid differ.