Hi,
Thanks for maintaining the module! It's really important for our current project!
I'm proposing a small change to the Balance Tracker API, as currently the exposed hooks are not versatile enough to extend the module behavior with custom modules.
What I propose is, that the main debit and credit -functions and the two hooks use the $message -variable inside a $data -array. This data-array could then also be used for other modules to incorporate data important to them.
The way it works with other modules is, that the hook_balance_write would send the bid of the last written record. This way, if other modules want, they can call for example the balance_tracker_debit_account -function, add its own data into the data-array, and then act upon the hook_balance_write.
Example from my module:
Node Reference passed (notice the nid):
// Debit account
balance_tracker_debit_account($user->uid, $amount, array('message'=> "Message: ".$node->field_message[0]['value'], 'nid'=>$nid));
...
/**
* Implementation of hook_balance_write()
*/
function bt_node_reference_balance_write ($bid, $uid, $type, $amount, $data) {
// make sure we have the needed id's
if($type != 'debit' && (!isset($bid) || empty($data['nid'])))
return;
// update
$success = db_query("UPDATE {balance_items} SET nid = %d WHERE bid = %d", array($data['nid'], $bid));
}
I'm releasing soon an add-on module for Balance Tracker called Balance Tracker Node Reference which would use this solution. I'm releasing the code once there's a decision for this change (and after I learn some git... :) )
I've added two patches that are built to the latest dev-release. It updates the current code for balance_tracker and bt_invite_commission to this proposed logic. Tested working on my site.
| Comment | File | Size | Author |
|---|---|---|---|
| balance_tracker.module.patch | 4.26 KB | afox | |
| bt_invite_commissions.module.patch | 780 bytes | afox |
Comments
Comment #1
afox commentedAny comments or thoughts on this one?
Comment #2
brianV commentedMy main comment with respect to your proposed API changes is that we should probably put them in a new branch of BT - 6.x-2.x or something as they are not backwards compatible. While the module doesn't have a huge user base, I am sure a fair number of those that do have some sort of limited API integration with it. My main comment with respect to your proposed API changes is that we should probably put them in a new branch of BT - 6.x-2.x or something as they are not backwards compatible. While the module doesn't have a huge user base, I am sure a fair number of those that do have some sort of limited API integration with it.