As it is, if you have tags DRUPAL-5 and DRUPAL-6, the latter being the current revision, and you want to edit DRUPAL-5, you have to set it as the active revision, tag it, and then set the DRUPAL-6 revision back to being active. Yuck! We need to brainstorm and implement a better workflow for simultaneously making a new revision based on a previous tag, and not changing what the current active revision of a node is.

Comments

Trejkaz’s picture

Trejkaz CreditAttribution: Trejkaz commented

I was about to create a new issue, but is it possible that if this feature existed, it could be used to edit future versions as well?

My issue at the moment is that we need to write the manual for the new version, but as the new version isn't out yet it doesn't make sense for users to see it -- yet, we cannot make the most recent revision non-public.

Ideally I thought it would make sense to lift this restriction, but it must be hard so I thought another workaround might be to make some previous revision the next version's revision, and then use this feature to edit those somehow.

franskuipers’s picture

franskuipers CreditAttribution: franskuipers commented

While i was implementing the views 2.0 functions, I was thinking the same.

In node.module we have the operations:

  • 'node/%node/revisions/%/view'
  • 'node/%node/revisions/%/revert'
  • 'node/%node/revisions/%/delete'

The most logical place for this would be to add the 'node/%node/revisions/%/edit' operation in the core node.module. But that is only possible as an issue for Drupal 8.x.

Someone would like to help me to code this in revisiontags?