validateService $vars "configoptions" keys inconsistent

[NextToNothing]

Hey there,

Looks like a little bug.

In validateService(), when dumping $vars['configoptions'], the keys for each options can change from an ID to the given name - depending on when the function is being called.

Putting a var_dump() at the top of the function yields this, when loading the service creation/order complete page.

array(2) {
  [1]=>
  string(1) "1"
  [2]=>
  string(4) "true"
}
array(2) {
  [1]=>
  string(1) "1"
  [2]=>
  string(4) "true"
}
array(2) {
  ["coolOption"]=>
  string(1) "1"
  ["anotherAwesomeOption"]=>
  string(4) "true"
}
array(2) {
  ["coolOption"]=>
  string(1) "1"
  ["anotherAwesomeOption"]=>
  string(4) "true"
}
array(2) {
  ["coolOption"]=>
  string(1) "1"
  ["anotherAwesomeOption"]=>
  string(4) "true"
}

[Tyson]

Is this a module's validateService method, or the Service model's validateService method? Under what conditions do you see a difference?

[NextToNothing]

Hey Tyson,

Not entirely sure on the difference between a module and a service module. It's the method inside a module class - e.g. located at /components/modules/Supercoolmodule/Supercoolmodule.php

From the docs: https://docs.blesta.com/display/dev/Module+Methods#ModuleMethods-validateService($package,array$vars=null)

In the example for addService(), it's suggested to call validateService(). However, the addService() method is passed different $vars['configoptions'] keys to when the validateService() method is called internally by Blesta.

The var_dump() outputs I posted are shown when blesta is adding the service/calls addService(). 

Hopefully that makes a bit of sense?

[Tyson]

Just FYI this is assigned CORE-2735.