🇩🇰Denmark @Birk

After I've been working more with the tmgmt module, I realized my previous assumption about the conditions in findReferenceEntity() was wrong (and introduced an error where the first paragraph was chosen for cloning each time).
Sorry if this has caused any confusion!

Anyway, I think the problem (in my use case) is the $entity passed to the doSaveTranslations() function, is not using the jobs source language.

I've supplied a patch that sets the entity language in the saveTranslation() function.

This is the correct patch.

The patch from #33 ✨ Integration with paragraphs asymmetric translation RTBC almost did it for me.
But if the target translation had less paragraphs than the source, the extra paragraphs wasn't added.

I've moved around on some parentheses, so the condition is (OR):

• $referenced_entity->id() == $field_item[$property]['#id'] Same entity
• ($item_delta === $delta && !$is_target_type_translatable) Same delta, and not translatable
• $is_asymmetric_translation_mode Is asymmetric paragraph

I recently had some caching issues with the "Redirecting when not in context of a controller". And without knowing about the existing EnforcedResponseException solution, I implemented an almost identical workaround.
I'll make a shameless plug to an article where I summarize the implementation: https://blog.birk-jensen.dk/drupal-http-redirection-from-anywhere

I've just tested the #29 patch on version 2, it applied and worked as expected.

The (optional) part of the label is not optimal UI, but I don't think removing it will better the experience.
Do reopen this, if I'm wrong here.

I'll share a quick overview of our implementation in case it has value for anyone ending in this issue.

We ended up implementing a skipsend in the $params argument, and then having a PHASE_POST_RENDER hook (I think this could be any phase hook) set the the transport DSN to a

NullTransport</mail>.
The hook is as follows:

<?php
function hook_mailer_post_render($email) {
  if ($legacy_message = $email->getParam('legacy_message')) {
    if (!empty($legacy_message['params']['skipsend'])) {
      $email->setTransportDsn('null://default');
    }
  }
}
?>

This assumes there's a <code>NullTransport

transporter named null for it to work. And in our preview controller we're calling the mail with the extra parameter but with $send TRUE (so MailManagerReplacement::mail() and LegacyEmailBuilder::buil() wont end the process to early) :

// ...
$params['__skipsend__'] = TRUE;
$result = $mailManager->mail($module, $key, $to, $langcode, $params);
// ...

Thank you for your input on the issue, and all your work on the module!

I can't find any issue related to this, so I'll ask here.

What are the blockers for creating a new beta/rc?

I don't think the patch would have any performance impact for sending mails (it would though for not sending mails with $send FALSE).

I hadn't thought about using the NullTransporter, thank you for the idea, we should be able to implement a non intrusive module with that approach.

It might be an unusual requirement, but it's a feature we have provided clients, to give them peace of mind before sending out emails.

This issue is out of scope for this module, so I'm closing it.

Included a proof of concept patch that works in my particular situation.

It's a quick fix, and I've not looked into any side effects of the patch.
Maybe someone with more experience in the symfony_mailer module could point out any obvious flaws.

Birk → created an issue.

I've been looking into this a bit, and it seems relationships is almost supported (and I'm sorry if my observations below is all over the place, I'm just brainstorming out loud).

Like Graber stated the relationship needs to map to the correct keys, which is here: https://git.drupalcode.org/project/views_bulk_operations/-/blob/7a991c4c...

    $base_field_values = [];
    foreach ($batch_list as $item) {
      $base_field_values[$item[0]] = $item[0];
    }

The item[0] is the base ID, but the seems the ViewsBulkOperationsViewData::getEntity() already supports relationship and gets the correct entity, it's inserted in $item[3].

So by simply changing the $base_field_alias to the field alias of the relationship it should work.

I'm making the assumption that the table alias is [relationship base]_[relationship_id], I'm doing this because I can't find a reliable way of getting the table from a relationship. So if I rewrite the code in ViewsBulkOperationsActionProcessor::popuplateQueue() to this:

if (empty($this->bulkFormData['relationship_id'])) {
      if (isset($this->view->query->fields[$base_field])) {
        if (!empty($this->view->query->fields[$base_field]['table'])) {
          $base_field_alias = $this->view->query->fields[$base_field]['table'] . '.' . $this->view->query->fields[$base_field]['alias'];
        }
        else {
          $base_field_alias = $this->view->query->fields[$base_field]['alias'];
        }
      }
      else {
        $base_field_alias = $base_field;
      }
    }
    else {
      $viewsData = Views::viewsData();

      $relationship = $this->view->getDisplay()->getOption('relationships')[$this->bulkFormData['relationship_id']];
      $table_data = $viewsData->get($relationship['table']);

      $relationship_table_alias = $table_data[$relationship['field']]['relationship']['base'] . '_' . $relationship['table'];
      $base_field_alias = $relationship_table_alias . '.' . $table_data[$relationship['field']]['relationship']['base field'];
    }

It seems to work in my particular case.

I know this is a hot mess, it's a hack that did it for my use case. Maybe a proper fix is not that far away, the current project I'm working on just don't allow me to spend the time I need to dig any deeper.

I have a view I can't "reverse" as well, has anyone had any luck getting VBO working with relationships?

(A hack would work for me as well)