It has been reported that it is quite difficult to determine, much less change, the current status and workflow state of a revision.

If we were to expose these in /content as selects, managing revisions and workflow would be massively improved.

See attached video.

image

This concept was reviewed by the UX team in the weekly meeting on 6/21/2016, and the issue was proposed with no objections.

Additional comment/suggestions in the meeting were to add color to the Status (red) in the meta area if the status is unpublished to further draw attention. That was seconded and it was also suggested that the text color be a configuration option of a workflow state.

CommentFileSizeAuthor
#2 Screen Shot 2016-06-22 at 9.25.57 AM.png54.99 KBtkoleary
moderation-from-table.mov5.62 MBtkoleary

Comments

tkoleary created an issue. See original summary.

tkoleary’s picture

tkoleary commented
Issue summary: View changes
StatusFileSize
new Screen Shot 2016-06-22 at 9.25.57 AM.png54.99 KB
tkoleary’s picture

tkoleary commented
Issue summary: View changes
anavarre’s picture

anavarre
Primary language French
Location 🇪🇺
commented

I very much like how this suggestion immediately improves the usability. One thing we should keep in mind however is that when viewing the content page from a mobile device, a few columns are being hidden.

  • Full page view: TITLE | CONTENT TYPE | AUTHOR | STATUS | UPDATED | OPERATIONS
  • Mobile view: TITLE | CONTENT TYPE | AUTHOR | STATUS | UPDATED | OPERATIONS

What I'd suggest is that in mobile view we make it such as WORKFLOW STATE is present, by hiding CONTENT TYPE instead. This would give something like this: TITLE | CONTENT TYPE | AUTHOR | STATUS | WORKFLOW STATE | UPDATED | OPERATIONS

tkoleary’s picture

tkoleary commented

@anavarre

+1

Bojhan’s picture

Bojhan commented

I am very unsure about making this select lists, showing the information great. But allowing them to change it directly will open a can of worms, as this is disrupting a major screen without auto-save.

anavarre’s picture

anavarre
Primary language French
Location 🇪🇺
commented

this is disrupting a major screen without auto-save

I expect you'd still have a confirmation page after hitting Apply. This would ideally list the nodes for which the Status / Workflow State has been modified. E.g.


Are you sure you want to modify these items?

- my-test-node: Status changed from Published to Unpublished
- my-second-test-node: Workflow state changed from Draft to Needs Review
- my-third-test-node: Workflow state changed from Approved to Needs Review, Status changed from Published to Unpublished

tkoleary’s picture

tkoleary commented

I am very unsure about making this select lists, showing the information great. But allowing them to change it directly will open a can of worms, as this is disrupting a major screen without auto-save.

There is zero difference between this and block layout UI, it's the same pattern applied in a different place.

tkoleary’s picture

tkoleary commented

@anavarre

I expect you'd still have a confirmation page after hitting Apply.

Yes, in addition to the same type of row highlighting and warning provided in /block-layout.

yoroy’s picture

yoroy commented

I think I remember discussing that these state changes could also be made part of the bulk operations at the top of the screen.

tkoleary’s picture

tkoleary commented

@yoroy

I think I remember discussing that these state changes could also be made part of the bulk operations at the top of the screen.

Yes! We need that too. Thanks for the reminder.

anavarre’s picture

anavarre
Primary language French
Location 🇪🇺
commented
Project: Workbench Moderation » Drupal core
Version: 8.x-1.x-dev » 9.x-dev
Component: User interface » content_moderation.module
Priority: Major » Normal
anavarre’s picture

anavarre
Primary language French
Location 🇪🇺
commented
Version: 9.x-dev » 8.3.x-dev
timmillwood’s picture

timmillwood
Primary language English
Location 🏴󠁧󠁢󠁷󠁬󠁳󠁿 Wales, UK
commented
Issue tags: +Workflow Initiative
scookie’s picture

scookie commented

I have a question - sorry if it seems like a silly question. Why does the user have to change both the Status and the Workflow State? What happens if I were to select Published as the Status and Draft as the Workflow State? Would I see an error message? Since each state can only have 1 status, why can't I just select the state - when I Apply, the status will change based on the status of the state that I select.

Thanks!

timmillwood’s picture

timmillwood
Primary language English
Location 🏴󠁧󠁢󠁷󠁬󠁳󠁿 Wales, UK
commented

I'd say once content moderation is enabled the status column, and option to change the status, is removed.

scookie’s picture

scookie commented

Thanks, @timmillwood, that's what I was hoping - or at least make the status column display-only for content types for which content moderation is enabled.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

guldi’s picture

guldi commented

Any chance that this is going to happen?

timmillwood’s picture

timmillwood
Primary language English
Location 🏴󠁧󠁢󠁷󠁬󠁳󠁿 Wales, UK
commented

We're getting closer to this with issues like #2902187: Provide a way for users to moderate content, so I guess it's just a matter of time.

timmillwood’s picture

timmillwood
Primary language English
Location 🏴󠁧󠁢󠁷󠁬󠁳󠁿 Wales, UK
commented
Status: Needs work » Active

Moving this to "Active" as there is no patch that "Needs work".

xjm’s picture

xjm
she/her
Primary language English
commented
Status: Active » Postponed

This needs to be postponed on adding Content Moderation to the Standard profile (do we have an issue for that yet?)

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

anruether’s picture

anruether
Primary language German
Location Bonn
commented
Status: Postponed » Active

Seems like we have this now Editorial workflow config moved from content_moderation into standard profile | Change Record, so setting back to active. This would be a huge usability improvement.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.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, which currently accepts only minor-version allowed changes. 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.