CiviCRM Community Forums (archive)

Hi,

I am helping my developer automate our contribution page creation.  We are using Joomla 1.5.22 and it looks like CiviCRM 3.2.2.  We have all the data needed to populate the _contribution_page table and the _tell_friend table.  There are only one piece left that I can't seem to figure out.  My developer can probably figure it out, but he's not available for a while and I'm trying to get ahead.

For our standard contribution page we are creating, one feature we want is the fixed contribution amounts to be set with a default to the first amount.

I found the default_amount_id field in the _contribution_page table that ties to the _option_value table to get the default amount.  However, this is the only _contribution_page field that appears to relate to the fixed amounts, yet when I insert a row of data into the table manually, the new contribution page does not list the fixed amount options.  Apparently there is some kind of function or trigger that is populating another table to make it happen, but I can't figure out what is happening.

Can someone shed some light and either explain how the page is formed, or point me to the documentation that might help me best?

Also, there may be one modification I would need to make this work best.  I notice that for each new contribution page created, the _options_value table adds new fixed payment amount options.  For our automation, each contribution page that is created would need to have the same fixed values for payment options, so we would therefore want to reuse the same group data for those fixed values.

Thanks in advance for anyone that can help or point me in the right direction!

David

Understood, and that makes sense.  Only problem is that is not the only lookup or association that we'll need to control going forward, so we're still running down the API path.

For anyone reading the thread, what we are doing is creating a list of children that are going to be available for sponsorship, and then for each child, we'll create a contribution page through CiviCRM.  We built an app using Ruby on Rails for managing the children and their sponsorship status, and then let CiviCRM handle the presentation and the accounting.

The added functionality we include is the ability to associate a child to a sponsor.  So when a child is sponsored, they are no long in the pool of available children.  When sponsorship ends (expires, or is terminated by sponsor or administratively by our staff) then the child goes back in the pool of available children.

We are on the last step of integration, so as soon as I get this question answered, we'll have a functional and integrated system that we'll be able to test and deploy.

Did I write too much?  Ha...I'm excited, and therefore sometimes get wordy. 

Thanks Lobo!

I did see the option groups, and my developer can probably work with that (I'm not savvy enough to know exactly how that gets tied in).

However, my other question is this...for our automation, do you know of any negative impact if rather than using the CONTRIBUTION_PAGE_ID, we made it static to a single ID...so all contribution pages created through our API would then have the same options available?

If I sound in over my head, then I may toss this over the fence to my developer.

I would love to...problem is, I'm basically just a BA and I've never used IRC before...so all this is pretty new to me (not BA work...10+ years there).

Is there some kind of documented process to guide me along if I were to attempt to help out?  How to developers figure all this out?

Getting a little off topic...sorry for anyone reading the thread!