Old question but worth an update, in case others see it or it's still relevant. That bug has now been marked 'resolved' over a year ago - if it isn't then you'll need to let them know.
For simple cases you can get the effect you want using a firewall rule on the relevant interface. The "advanced" options allow some quite sophisticated drop/pass rules, which can be used to set maximum states, connections, connection rates, connection timeouts, and scheduling (when to enforce), for a specific IP, and also (optionally) for specific remote IPs/ports. That might be all you need to find a decent solution/workaround. It could also be that their heavy traffic is on a specific port or url/IP range and you could narrow your rule to those connections.
You could also use a "captive portal", and make it transparent/inactive/non-applicable for most IPs except this one. A captive portal on that IP would provide a different means to set up/down bandwidth on an IP, without relying on traffic shaping.
(If you did want to set traffic to "1 bit", and would be allowed to do so by whoever else is involved, presumably that means blocking rather than limiting bandwidth. In that case LAN firewall rules are also your friend.)
Last thought - if you want to control that IP specifically, it might help to put your "problem" IPs in a different subnet such as 10.1.0.0/16, or as an alias, set routing if applicable so they can communicate with other 10.x.x.x LAN IPs without any change, and then you can define and maintain different rules and policies for connections from these users with ease.