@cballen2

Here's a patch for the behavior described in the issue:

cballenar → created an issue.

Recently had to do this for a project, here's a breakdown of what you need to do:

The Toolbar Menu module allows you to access an existing Menu, so first we need to determine what Menu we want it to display, e.g., "My Menu":

• If this is for an existing menu, we can move to the next step.
• If we want to have a custom menu, we need to first create it (/admin/structure/menu)

Once we have a menu, we can go to Toolbar Menu to create it (/admin/config/user-interface/toolbar-menu/elements). When creating the menu element, we select our menu from the previous step.

At this point we should see our new Menu Element at the top next to Manage or the User menu, if it was a new menu, this would be empty. If it was an existing menu, this would have all the elements from that menu.

Then we can proceed to customize our view(s) to appear in the Menu we created under the view's Page Settings:

1. Define the Path you want to use, e.g., "/my-menu/my view
2. Set the Menu to Normal Menu Entry, and select the Menu you selected/created before, e.g., "My Menu"
3. Ensure the permissions are set correctly at the View as well as the Toolbar Menu level.

At that point you may need to refresh a couple times to ensure the view/menu changes are loaded and your view should be displayed under the menu element we added before.

An issue has already been submitted to shariff's github repo. But this also requires they update to FontAwesome 6 so I'm not sure how soon we'll be seeing this.

In the meantime, here's a patch that relies on the FontAwesome's X icon added via a CSS block in the template. The code relies on svg mask since it's well supported and allows us to change the background color for the additional themes. The icon was optimized with SVGOMG and converted to Base64; after compression it should be under 500B.

Should this just be added as an asset instead?

This does not affect the internal labels. Front end label continues to be "tweet" this is coming from original library.

Thanks @andileco !

I tested rolling back to 5.0.4 but it still displayed the issue (assuming back then the version was different). Nonetheless let me know if you see different results. I appreciate any feedback on this!

cballenar → created an issue.

I'm also interested in this. It's not even clear what the default behavior is. Forums seem to indicate "AND" to be the default.

Ran into cases where instead of null, '_none' is returned. The update here addresses both cases and improves readability.

I was also looking at a similar option as the one described by @chrisrhymes we could take his recommendation a step further and pass this value to the revision log of the entity.

What's happening now is that even though the scheduler_content_moderation_integration_scheduler_publish_process hook returns '-1' for invalid transitions, the scheduler publish/unpublish function maintains the revision log it had before which assumes the process was completed successfully. Resulting in the messages previously mentioned.

With the change below we instead get an accurate message: "The transition from 'draft' to '' does not exist in workflow. (Draft)"

function scheduler_content_moderation_integration_scheduler_publish_process(&$entity) {
  ...
  catch (\InvalidArgumentException $exception) {
    $entity->setRevisionLogMessage($exception->getMessage());
    return -1;
  }

Now in the example above, this exception is thrown due to an empty state; to me, this handling is also a problem because it will result in recurring messages of this type until the record is corrected, if the record happens to fall on a state that is not being watched (say Draft) then this could easily turn into hundreds of revisions.

Instead, we could treat a record with no target state as 'invalid' and remove it from the list of records to be processed by Scheduler, as follows:

/**
 * Implements hook_scheduler_list_alter().
 *
 * This hook is called from schedulerManger::publish() and
 * schedulerManger::unpublish(). It passes the list of entity ids to be
 * processed, the process (publish or unpublish) and the entity type id.
 */
function scheduler_content_moderation_integration_scheduler_list_alter(&$ids, $process, $entityTypeId)
{
  /** @var \Drupal\content_moderation\ModerationInformationInterface $moderation_information */
  $moderation_information = \Drupal::service('content_moderation.moderation_information');

  // Fetch all entities and check if they have a moderation state.
  // This will prevent the processing of 'incomplete' entities by Scheduler.
  $entities = \Drupal::entityTypeManager()->getStorage($entityTypeId)->loadMultiple($ids);
  foreach ($entities as $entity) {
    // Check if entity is moderated and has no target state
    $is_moderated = $moderation_information->isModeratedEntity($entity);
    $has_no_target_state = !($process === 'publish' ? $entity->publish_state->value : $entity->unpublish_state->value);
    if ($is_moderated && $has_no_target_state) {
      // Find the key of the entity in the list of ids and remove it
      $entityKey = array_search($entity->id(), $ids);
      if ($entityKey !== false) {
          // unset($ids[$entityKey]);
      }
    }
  }
}

I've attached a patch containing both solutions since they cover different situations.

I found that the patch was not taking into consideration clicking on other elements within the fieldset. Mainly clicking on the image/thumbnails of the paragraph. By checking if the target's closest we check if the current element or a parent of it is the fieldset we need. Then we target the input of said fieldset.

Additional modification to reduce scope of js to apply only to MEDIA entity browser only. This was affecting other entity browsers which is already patched in 3354603 🐛 jquery once no longer works in Drupal 10 Needs review .

Last patch was incorrect. This version updates both instances of once correctly.

Appropriate interdiff uploaded.

Updated Chizh273's work to remove jQuery once.

I was going to submit this as an MR but not sure if there are different plans for this library moving forward. The work is under this branch which has been updated with the current default branch:

https://git.drupalcode.org/issue/thunder_admin-2900637/-/tree/2900637-re...

cballenar → made their first commit to this issue’s fork.

I'm attempting to run this in D10, with content_moderation_notifications 3.6 but no email goes out at all when Revision Author is selected. Other notifications continue to go out as normal. I'm not seeing any errors or warnings in the logs. 🤔 Anyone else seeing this?

I'm running into this issue running Drupal v9.5.8 and SCMI v2.0.0-beta1.

1. The test is done with a user that has no publishing rights. User creates record, saved with status of Draft, a Publish On value, but no Publish Status.
2. When the cron job is executed:
   • The content is updated with a new revision with the message: `Published by Scheduler. The scheduled publishing date was 10/09/2023 - 10:10. The previous creation date was 10/09/2023 - 10:08, now updated to match the publishing date. (Draft)`
   • The cron job logs the following error: `Publishing failed for [TEST] Scheduled Page - 1. scheduler_content_moderation_integration_scheduler_publish_process returned a failure code.`
3. Because the new revision is saved with the same scheduled time, the issue will repeat the next time the cron job is executed. In our case this has resulted in hundreds of revisions getting created and going unnoticed because the status was Draft and not meant to be reviewed.

In our case our intention was to allow users that don't have publishing rights to "Schedule" a time with the idea of helping signal when a content is to be scheduled for the reviewer (since the tab will be displayed when there's a time set). I'm (97%) sure I tested this case a year ago without this issue. I'm not sure when it started happening.

Thanks!

cballen2 → created an issue.