Add missing fields to Transmisson::send()

[djagya]

There are few important missing fields, that couldn't be set through Transmission->send() method:

• options.start_time
• options.sandbox
• content.attachments
• content.inline_images

It's easy to fix: just add these values to Transmission::$parameterMappings.
I'm ready to prepare a PR.

[j4m3s]

Agreed @djagya - these almost essential.

[j4m3s]

It's not perfect, but just reading through the closed issues it looks like you can work-around the lack of flattened fields by using the API structure (see #11). e.g. set the scheduled send time:

[  
    'options' => [
        'start_time' => '1234'
    ]
]

[djagya]

@j4m3s i don't think it can work.
To send the message we call Transmission::send($payload).
Then it calls APIResource::create($payload).
Then callResource, then it builds the body with method APIResource::buildBody() -> buildRequestModel(), that goes through all given keys (e.g. 'options' => ['start_time' => 1234]) and uses setMappedValue method.

And finally setMappedValue sets the value ONLY if $parameterMappings is empty or given key exists in that mapping:

ApiResource, line 51

  // set the value either if mapping is empty
    if( empty(static::$parameterMappings) ) {
      $mapPath = $mapKey;
// or if key exists in mapping, where e.g. 'options' key doesn't exists there
    } elseif (array_key_exists($mapKey, static::$parameterMappings)) { 
      // use only defined parameter mappings to construct $model
      $mapPath = static::$parameterMappings[$mapKey];
    } else { // or just skip the given key, value
      return;
    }

And this mapping is empty only if we use APIResource directly, but that's stupid because why to use abstract APIResource, when we have special class for Transmission emails?

[j4m3s]

You're absolutely right @djagya, sorry. I thought the mapped variables were merged into the passed-in parameters, but they aren't - so even if you pass-in the full options.start_time for example it gets dumped.

[zaporylie]

#50 has been merger already and #53 is waiting to be merged.

[beardyman]

This can be closed since #56 has been merged.