undefined - Contrib.social

Comment about 2 months ago →

🇭🇺Hungary ibis

Yes, i think it so to. In my opinion the submodule way is better.

🇭🇺Hungary ibis

I tested it and out of the box not working. Together with views_field_view it's working, but if you want all data (submission + order) in one row, then you need an another approach.

🇭🇺Hungary ibis

Yes, i think so also: safer way to alter the base field info, than set the entity_id, because the entity_id is used by webform module to store the entity reference if you add a webform to an entity.
But, if you do not want to alter the base field info then the another option is to create a helper table with submission_id and order_id fields and use it in hook_views_data. But these option is much more complicated than base field info altering.

🇭🇺Hungary ibis

Ok, then we need our own field in webform_submission entity, right?
Something this would be good?

// in file webform_product.module

use Drupal\Core\Field\BaseFieldDefinition;

/**
 * Implements hook_entity_base_field_info().
 */
function webform_product_entity_base_field_info(\Drupal\Core\Entity\EntityTypeInterface $entity_type) {
  $fields = [];
  if ($entity_type->id() === 'webform_submission') {
    $fields['commerce_order'] = BaseFieldDefinition::create('entity_reference')
      ->setLabel(t('Commerce Order'))
      ->setDescription(t('The commerce order associated with this webform submission.'))
      ->setSetting('target_type', 'commerce_order')
      ->setDisplayConfigurable('form', TRUE)
      ->setDisplayConfigurable('view', TRUE);
  }
  return $fields;
}

An then in the handler:

$webform_submission->set('commerce_order', $order->id());
$webform_submission->save();

What do you think?

🐛 | Commerce PayPal | Unexpected PayPal order status CREATED

🇭🇺Hungary ibis

Anyone is using together with these module the webform_product module?
My scenario is:
I have some normal products and one webform with webform_product handler assigned.
If the webform_product is on, the users cannot buy the normal products because this issue (the webform product works good).
If i switch off the webform_product, then the normal products works fine.
And ofc. the issue is do not coming in paypal sandbox mode, only in live mode, so the testing is more complicated..

🐛 | Webform Product | Unexpected PayPal order status CREATED.

🇭🇺Hungary ibis

ibis → created an issue.

🇭🇺Hungary ibis

Hi Balint,

Thank you for your answer!
Yes, of course. I also wondered why this data is needed in the webform_submission_data table, since the order id has a place in the webform_submission table and the order URL can be retrieved from the resulting order.
But the ->set('entity_id_commerce_order', $order->id()) is essential row in this use case, because if you store this only in config, then u cannot make the relation between webform_submission.entity_id_commerce_order and commerce_order.order_id with the hook_views_data_alter function.

Regards,
István

🇭🇺Hungary ibis

There are a patch for this function, using hook_views_data_alter.

🇭🇺Hungary ibis

ibis → created an issue.

🐛 | Commerce Core | Error when trying to enable adjustments

Comment 11 months ago →

🇭🇺Hungary ibis

This is still active for me also. Composer.json attached what i used for test this.
Bug is appear when u move the Adjustments field from hidden to the visible region and hit the save button.

✨ | Node Option Premium | Support Access by Reference module

🇭🇺Hungary ibis

Yes, but the access_by_ref work with another logic, not with the common role based:
only gives access to view if the referenced field pass (eg. the visitor's uid is in the visited node's user reference field).
And nothing else: so we need any another module what deny the view of this node. And this is for example The Node Option Premium (wich deny the partial view) !
So yes, in this use case is not good to see the $entity->access('view') because we need to give the option to modules for use their own logic.
Therefore, i think, we need here invoke the hook_node_access only for specific (supported) modules.

✨ | Node Option Premium | Support Access by Reference module

🇭🇺Hungary ibis

Thanks for the answer! Then all of another modules need to implement the new hook.
I think there is better to look all of the another modules who implement hook_node_access (invokeAll('node_access')), if we want to support all node access modules what use hook_node_access to work.

✨ | Node Option Premium | Support Access by Reference module

💬 | Native PHP Search API Attachments | Offering to co-maintain Native PHP Search API Attachments

🇭🇺Hungary ibis

ibis → created an issue.