At present the manual payment method for a conference shows the payer when they click [Register] a paragraph listing the rego payment options and the total amount to pay.
The Conference Manager gets an email saying:
A manual payment needs to be processed for the conference Blah…
and the user Foo Bar (username “foobar”).
The item being paid for is “Registration”.
The cost is 600 (AUD).
This email was generated by Open Conference Systems’ Manual Payment plugin.
The Conf Manager can see what the items are only by going into the Registrations section and clicking Edit for that user. They had better not accidentally change anything.
This is what we need in Australia to make it a valid invoice.
When the payer clicks [Register] an itemised list with the amount per item and the total is displayed rather than just the plain paragraph of the purchased items…
This is displayed to the payee and emailed to the payee and is either mailed to conf manager or can be viewed on a page as read-only by the conf manager.
I see that the total amount is in the data field of the queued_payments table.
(s:12 being a string of 12 chars, etc )
O:16:“OCSQueuedPayment”:9:
{
s:12:“conferenceId”; s:1:“1”;
s:11:“schedConfId”; s:1:“1”;
s:4:“type”; i:1;
s:10:“requestUrl”; s:75:“http:/myconf/index.php/blah-blah/payment/landing”;
s:9:“paymentId”; N;
s:6:“amount”; i:600;
s:12:“currencyCode”; s:3:“AUD”;
s:6:“userId”; s:1:“3”;
s:7:“assocId”; s:2:“12”;
}
Clearly some pulling out the item prices from the other tables would be needed. Then formatting into a table.
Producing an itemised invoice is quite important for us at present.
That’ll return an array of the registration option IDs for a given registration. If you want to fetch information about each of those options, you can use the same DAO:
To get prices, you can use the RegistrationTypeDAO function called getRegistrationOptionCosts.
The best way to get a sense of how this is all done is to look at the registration form, classes/registration/form/UserRegistrationForm.inc.php, particularly in the execute function.
Regards,
Alec Smecher
Public Knowledge Project Team
I sorta know roughly what to do but I’m not a PHP programmer (more Perl/Python) and its mainly the classes and methods to use that I’m having probs with.
In plugins/paymethod/manual/ManualPaymentPlugin.inc.php I need something like:
I need to get the optionsId for that specific registrationId but that later variable isn’t available with that class/file.
Once I have optionsId I need to get it into a list of tuples of itemDescription & itemAmount and call that array say regoOptions.
Then I can pass that regoOptions to the template
$templateMgr->assign(‘regoOptions’, $regoOptions);
and in the template loop over the options as rows in a table.
In UserRegistrationForm.php I have added to execute(): $optionIds = $registrationOptionDao->getRegistrationOptions($registrationId);
before the $queuedPayment line.
In manualPaymenrPlugin.php I can assign this var to be passed to the template: $templateMgr->assign('optionIds', $optionIds);
The paymentForm.tpl then can show the vars: DEBUG queuedPaymentId = { $queuedPaymentId } and options = { $optionIds } END
The $queuedPaymentId shows OK but the $optionIds is empty.
How do I pass $optionIds from within function execute() to function displayPaymentForm() ?
displayPaymentForm gets its variables from its arg $queuedPayment but I should not probably change that.
So as you can see I’m not even yet at the stage where I can loop over $optionIds
for optionId in $optionIds;
$registrationOption = $registrationOptionDao->getRegistrationOption($optionId);
I also have been trying to get the users name, email and current date on the registration payment page.
In ManualPaymentPlugin.php, function displayPaymentForm() have added:
# $user is already defined above.
$templateMgr->assign('userName', $user->getFullName() );
$templateMgr->assign('userEmail', $user->getEmail() );
# datetime gives me a call to undefined function
#$currentDate = datetimeToDB(Core::getCurrentDate() );
But Im not getting the userName and userEmail displaying.
I also need the current date on the page.
Another issue is that users need to be able to return to this page to see what they have previously entered. At present there seems to be no way for users to get back to here without going through the rego procedure again.
Check your Smarty syntax – to display variables you’ll need to use e.g. {$userName}, not { userName }. Smarty documentation is pretty good – see http://www.smarty.net.
Regards,
Alec Smecher
Public Knowledge Project Team
That error is not occurring everytime. I thought it may be from when I was changing the templates, did some incorrect code, and the templates were cached. I have cleared the data and template caches. What are duplicate rego options? On my local test site I just have two rego types and options. Both of those have different URLs or ids.
I now have the users full name and email in the template so am progressing. Have to now get current date into template.
This could happen if e.g. the system was trying to add a registration option to a user’s registration, but they had already been granted that option. If it’s an old error message and you’re not sure what caused it, I’d suggest poking around a little further to try triggering the problem; otherwise it’ll be hard to track down.
Regards,
Alec Smecher
Public Knowledge Project Team
Just an update. I paid a programmer I know to do some changes so that we now have itemised invoices. Plus the user can return later and look at their invoice at any time.
I will put together some files and a set of patches for this and send to Alec so they can check them out and maybe commit to the repo. Have still to do a bit more testing on them first so it will prob be late August after we get some real regos rolling in and I’m less busy.
That fixes the email which is now displaying.