It is not possible to override a "do" action defined in the "base" parameter part of a JSON response with a "go" action for an item in the item_loop in the JSON response.

This problem has already been discussed a bit here:
http://forums.slimdevices.com/showthread.php?p=250266#post250266

The current behaviour seems to be that if I define an action in the 'base' parameter it will be available on all items in the item_loop. If a 'do' is defined in the 'base' parameter, this will be used even if a 'go' is defined in the item_loop. So as far as I've seen, there is no way to override a "do" with a "go" with the current implementation.

So as example when I have a base parameter like this:
============
'actions' => { 
  'do' => { 
    'cmd' => ['dynamicplaylist', 'playlist', 'continue'], 
    'itemsParams' => 'params', 
  }, 
  'play' => { 
    'cmd' => ['dynamicplaylist', 'playlist', 'play'], 
    'itemsParams' => 'params', 
  }, 
  'add' => { 
    'cmd' => ['dynamicplaylist', 'playlist', 'add'], 
    'itemsParams' => 'params', 
  }, 
},
============

And on one of the items in the item_loop has defined a 'go' action like this:
============
'go' => { 
  'cmd' => ['dynamicplaylist', 'browsejive'], 
  'params' => \%itemParams, 
  'itemsParams' => 'params', 
},
============

The result is that the 'do' action will always be executed. If I remove the 'do' action from the 'base' parameter it will correctly execute the 'go' action.

I'm not sure this behaviour is wrong. I'm pretty sure it has worked in a previous SC version, but I'm not completely sure. So I think what we need to decide is how it should work.

Now some information about my problem.

I have a menu level which contains some items which should have "play", "add", "do" actions assigned to them and some other items on the same menu level should only have a "go" action.

Solution 1
==========
One solution would be to never define any action in the "base" parameter and defined the actions on each specific item in the item_loop. This would work correctly, but it would result in more data over the network and more texts to parse on the Jive side. The advantage is of course that it wouldn't need any changes in the current SC code. However, as I've understand the main purpose of the "base" parameter is to avoid this network traffic and parsing, so it would be a pity if I couldn't use it.

Solution 2 (I think it has worked this way before)
==================================================
Change the SC code so if any action is defined on an item in the item_loop it overrides all the actions defined in the "base" parameter for that particular item. I think this is how it has worked in a previous version, but I'm not completely sure. This solution would make the code sample in the beginning work correctly. The result of this is that if you define an action on an item in the "item_loop" you always need to define all the actions for that item, even if some of them already is defined in the "base" parameter. So it wouldn't be possible to define some basic actions in the "base" parameter and just add additional actions in the item_loop with this solution. The advantage is that this makes it possible to have items in the item_loop that contains less actions than what's available in the "base" parameter. As an example, you can remove the "play"/"add" action on some items and still have "play"/"add" defined in the "base" parameters since that's what most of the items wants. 

Solution 3
==========
Change the SC code so if an action is defined in the "base" parameter it is still possible to somehow specify in the item_loop that that particular action shouldn't be available on a specific item.
For example by allowing code like this in the item_loop to remove the "add","play","do" action on a specific item:
=========
my $actions = { 
  'add' => undef, 
  'play' => undef, 
  'do' => undef, 
  'go' => { 
    'cmd' => ['dynamicplaylist', 'browsejive'], 
    'params' => \%itemParams, 
    'itemsParams' => 'params', 
  }, 
}; 
$request->addResultLoop('item_loop',$cnt,'actions',$actions);
=================

Actually it already seems to work somewhat like this, because it is possible to disable the "play" and "add" actions on a specific item, but unfortunately you can't do the same for the "do" action for some reason.

Personally I think a solution like solution 3 is the one that results in most flexibility, but I'm not sure which one is the preferable from a SC/Jive point of view.