Allow logging push params and push success

Created a branch in the issue fork and attached a patch. Please review, thanks!

Updated patcch adding missing service config.factory.

I like the idea here. If you could please open a merge request, I have some feedback to help get this ready to go

The method \Drupal\salesforce_mapping\Plugin\SalesforceMappingField\DrupalConstant::pullValue is nearly identical to the parent \Drupal\salesforce_mapping\Plugin\SalesforceMappingField\PropertiesBase::pullValue

Would be much better to adjust this so we can inherit, rather than re-implement. May require changing \Drupal\salesforce_mapping\Plugin\SalesforceMappingField\PropertiesBase::pullValue

For example, in \Drupal\salesforce_mapping\Plugin\SalesforceMappingField\PropertiesBase:

  public function pullValue(SObject $sf_object, EntityInterface $entity, SalesforceMappingInterface $mapping) {
    $field_selector = $this->config('drupal_field_value');
    $pullValue = parent::pullValue($sf_object, $entity, $mapping);
    ...

could become

  protected function getPullValue($sf_object, $entity, $mapping) {
    return parent::pullValue($sf_object, $entity, $mapping);
  }
  public function pullValue(SObject $sf_object, EntityInterface $entity, SalesforceMappingInterface $mapping) {
    $field_selector = $this->config('drupal_field_value');
    $pullValue = $this->getPullValue($sf_object, $entity, $mapping);
    ...

Then in \Drupal\salesforce_mapping\Plugin\SalesforceMappingField\DrupalConstant, instead of re-implementing pullValue, all we have to do is:

  protected function getPullValue($sf_object, $entity, $mapping) {
    return $this->config('drupal_constant');
  }

Also, not sure what test coverage looks like for this right now, but i would want to see extended test coverage for this before committing.

There were conflicts with main branch, I've tried to solve them.

Tests still required.

Instead of merging branch 5.x into this MR I've just rebased the MR, so the MR doesn't include itself changes already committed. This was if anyone (like me) wants to use the MR patch can do it without including a bunch of unrelated changes.

I've added 2 commits with corrections that already were present in thepatch. Now the MR is canonical, so the patch will be hidden to prevent confussions.

Now it is ready to review through the MR.

Great idea, I like the increased granularity of logging settings.

I'd be interested in adopting this more widely.

MR needs update after some other commits, and needs some more eyes on it before RTBC

Thanks for the feedback.

MR has been updated and now is up to date with 5.0.

This is looking good to me, but is a big enough change I'd like to get some more eyes on it before merging.

Committed and released in 5.0.5 and 5.1.0

Thanks all

Automatically closed - issue fixed for 2 weeks with no activity.