Problem/Motivation

A customer wants to curate revisioned, workflow nodes with a taxonomy term, so that the set of unpublished changes (never-published draft nodes and draft pending versions of previously published nodes) can be filtered with a common term and bulk published. The terminology exposed in views UI led to some confusion and required multiple attempts until a solution was found.

Steps to reproduce

Since /admin/content isn't revision aware, it doesn't offer the term associated with a pending version. We turned to /admin/content/moderated and spotted relationship "Get the actual content from a content revision." - since that talks about revisions - but it turned out to use nid for join so while it did show term values for node, it didn't expose any term assigned to a pending revision. It turned out that we could get what we want by adding a column and filter using the unlikely views category "Content (historical data)", along with Views Bulk Ops.

Proposed resolution

I have two UX issues arising:
* views relation "Get the actual content from a content revision." is not revision-aware (uses nid). Also a colleague had a different interpretation of the relation based on a different understanding of what from might relate to (the current base table, or the table being joined). Perhaps this relation could be labelled better?
* views category "Content (historical data)" is "revision-aware" and was the key to our solution, but the term "historical" is not ideal when we are using it to access pending version data. Could it be relabelled "Content (revision data)" or similar?

Remaining tasks

Unsure, but wanted to feed into ongoing discussions re revision-related terminology and UX.

Comments

jonathan_hunt created an issue. See original summary.

lendude’s picture

lendude
Primary language Dutch
Location Amsterdam
commented
Category: Feature request » Task
Related issues: +#2844820: Improve Views revision integration for all revisionable entities

Thanks for opening this, marking this as related to #2844820: Improve Views revision integration for all revisionable entities

The big question of course here is, what would be better terminology?

The "Content (historical data)" probably comes from a time when forward revisions were not a thing and revisions were always historical, so it used to be accurate (and still is until you install content moderation I guess). I think not using the term 'revisions' here was probably in an attempt to make this less tech-y? But if you are using the Views UI I would feel safe in assuming that the user knows what revisions are.
So should that just say "Content (revision data)"?

"Get the actual content from a content revision." yeah that is pretty unclear, but no suggestions come to mind right now.

Marking this a task, since this is about making existing functionality a bit better. And as there will probably be string changes here, moving this to the feature version

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.