CiviCRM Community Forums (archive)

Hi,

I've looked around a bit, and don't see any documentation for this problem. Asked briefly in IRC, but decided to follow up here. I'm running a brand new installation of Drupal 7 and CiviCRM 4. Building a Drupal Module that allows admins to associate a CiviEvent with a price set, and a membership type. Thus a certain event could offer one price for members, and another for non-members, presenting the user with the correct option based on their membership status. I'm nearly finished except that I am running in to a problem with  hook_civicrm_buildAmount.

I can't seem to add a price. The documentation (http://wiki.civicrm.org/confluence/display/CRMDOC33/CiviCRM+hook+specification) clearly shows adding a price to the list, so I'm thinking it's possible. From documentation:
// lets add an arbitrary amount here, just to show folks
// the power of a hook :)
$amount[1000] = array( 'value'    => 400,
   'label'     => 'Hook',
   'amount_id' => 1000 );
Looks pretty simple and arbitrary. Here is what I'm trying as of the moment:
function civicrm_membership_prices_civicrm_buildAmount ($pageType, &$form, &$amount) {
  $amount[4] = array(
    'id' => 4,
    'label'     => 'testing',
    'amount_id' => 225,
    'amount' => 150.00,
      'options' => array(
        4 => array(
        'id' => 4,
         'price_field_id' => 2,
         'name' => 'Event_Registration_Fee',
           'label' =>'test',
           'amount' => 150.00,
           'weight' => 3,
        ),
      ),
  );
  drupal_set_message('<pre>' . print_r($amount, true) . '</pre>');
}
I tried mimicking the example exactly, but had not luck. Here I am trying the structure found in the amount array. Maybe I'm missing something. Any thoughts or suggestions?

Thanks for the reply Lobo,

We ended up using normal fees instead. This granted the control we required (add/alter amounts). Here is the module:

http://drupalcode.org/sandbox/lkacenja/1094800.git/commit/458f95a

Creates a Drupal DB table to store event_id -> fee -> membership_id relationship. We then use several hooks and some core/template overrides to get the final effect. Maybe this would be useful for someone else.  Thanks again.

I have just finished doing something similar, but I did it by using groups and allowing the admin to assign permissions to price set options when they are created. Thus, my method will not work with standard prices, but only price sets.

I am considering submitting my code as a feature to CiviCRM, but I don't know which method makes the most sense in the long term. Any thoughts on this are welcome.

Hi Again Lobo and qjensen,

Lobo: I'm always happy to support the Civi Community. I can blog something about this module if you think it would be useful for others. The core overrides were to add a membership type drop down to the fee form, and to change the prices on the event preview to reflect the users' membership. There may have been a way around using core overrides, but neither of us developers here at OMF are particularly well versed in html quickform or smarty.

qjensen: I think your method sounds interesting. We had a such a hard time manipulating the price sets that it made more sense for us to go the fees route. Also, our client needed this functionality to center around membership types, and for these relationships to be somewhat extensible. I feel like what we came up with was a pretty light weight solution (other than the overrides). How were you able to manipulate the price sets? Did your approach require any core overriding?

lkacenja / qjensen:

I think blogging about it and letting other folks know what u'll have done and how will help other people in the same boat (and i do think there are quite a few of them). Will also help the two of u'll (and others) to figure out how to combine forces and potentially come up with one module that meets both your needs without hacking core (and if needed we can add more hooks etc)

lkacenja: based on your brief description, i think u can accomplish both those tasks via hooks. BUT, we can hold off on any changes till we have a better idea of how you / qjensen will combine forces and then we can ensure that the "new" module is clean and does not need core overrides

really cool that we are seeing a lot more people extending civicrm definitely good signs for a healthy ecosystem

lobo