Network_Firewall_AccessControlList service not respecting new object mask

[cbreden]

We are finally getting around to merging our own api wrapper with the 2.x+ gem here so we can start work on the new semantic models, but we're hitting a few bumps.

We've found at least one service that seems to ignore the new object mask string. Here's some test code that isolates this behavior along with the outputs.

## vvvvv Comment in/out gem version along with appropriate object mask

#gem 'softlayer_api', '=1.0.7'
#OBJECT_MASK = { 'id' => '', 'rules' => { 'id' => ''} }

#gem 'softlayer_api', '=2.1.1'
#OBJECT_MASK = "mask[ id, rules [ id ] ]"

## ^^^^^ Comment in/out gem version along with appropriate object mask 

require 'softlayer_api'
require 'pp'

user = "abc" 
api_key  = "xyzxyz"
firewall_id = 2132  # provide a valid firewall ID

service = SoftLayer::Service.new("SoftLayer_Network_Firewall_AccessControlList", :username => user, :api_key => api_key)
result = service.object_mask(OBJECT_MASK).object_with_id(firewall_id).getObject
pp result

with v1.0.7:

{"id"=>2132,
 "rules"=>
  [{"id"=>1273226},
   {"id"=>1273228},
   {"id"=>1273230},
   {"id"=>1273232},
......

with v2.1.1:

{"direction"=>"in", "firewallContextInterfaceId"=>4235, "id"=>2132}

We haven't found any way to get this mask to work.

[SLsthompson]

After some discussion with the development team, this appears to be a bug in the way extended object masks are applied to "getObject" calls. The work around would be to use object masks in the "old" format (which the current Ruby client will not allow you to do). Or to make a separate call to request the rules of the ACL directly

service.object_with_id(firewall_id).object_mask("mask.id").getRules

Given that information... it may be most prudent to add some mechanism to the gem that allows you to provide object masks in the 'old' format if you wish.

[cbreden]

Do you have any idea if the bug will be addressed by the dev team soon? This is the main issue holding us back at the moment. While I'm not opposed to an interim fix that accepts the old mask, it would get messy to bounce between the two masks constantly.

[SLsthompson]

I do not have any information about how (or when) the bug might be addressed by the development team.

[SLsthompson]

The bug concerning the application of object_masks in the getObject call has been addressed and passed QE. It still must work it's way through the production process, but should be in place next week.

[cbreden]

That's great news, thank you.

[SLsthompson]

The bug fix for using extended object masks with the firewall rules is released and in production. Please re-visit the issue and let me know if it still does not work for you.

I noticed and reported a similar problem where using a mask while calling "getRules" for a server firewall does not apply the mask to the rules (you always get back the full set of information).