Order Notification E-Mail Address

Next topic

Author	Message
Felix Leimbach	Friday 29 December 2006 12:21:50 am Hi everyone, After a customer completes an order notification emails are being sent to the customer and the AdminEmail defined in site.ini (see sendOrderEmails() in kernel/shop/ezshopoperationcollection.php). The customer part is fine, but I want the email address of the notification to be different from the Admin-Email. However, kernel/shop/ezshopoperationcollection.php fetches the receiver address at around line 514 like this: $email = $ini->variable( 'MailSettings', 'AdminEmail' ); It seems strange to me that the Admin of a site receives order emails. At our site, the sales departments needs the order emails, while the Admin is concerned about the technical stuff. Changing the AdminEmail in site.ini to a sales mail address is not an option, as AdminEmail is used for various other emails (as sender mostly, AFAICS). Hacking kernel/shop/ezshopoperationcollection.php is my solution ATM, but it's too hacky for my taste and tends to break at updates. How is everyone else dealing with that? Maybe I'm overlooking something ... Greets & thanks for the otherwise great ezPublish :-) Felix
Betsy Gamrat	Friday 29 December 2006 7:47:35 pm Felix, This may help. {* Use this line to specify the e-mail in the template, can read this from the object to make it dynamic pr form *} {set-block scope=root variable=email_receiver}{$object.data_map.reciver.content}{/set-block} Additional information: http://ez.no/community/forum/setup_design/how_can_i_specify_email_receiver_for_different_form/re_how_can_i_specify_email_receiver_for_differ__3
Felix Leimbach	Monday 01 January 2007 7:24:19 am Betsy, sorry for not being clear, but the email sending process does NOT recognize or even look at that variable. Instead, it directly fetches it from the ini file in kernel/shop/ezshopoperationcollection.php: $email = $ini->variable( 'MailSettings', 'AdminEmail' ); IMHO, it _should_ honor the email_receiver as you supposed, but the fact is it doesn't. I'm talking about the shop's order emails here, not about information collection forms. I'm on eZP 3.8.6. Has anyone else stumbled across this issue?
Betsy Gamrat	Monday 01 January 2007 3:25:23 pm Felix, I apologize for not reading your post more carefully. I agree that patching eZ would be the most expedient solution. Another option would be to add an additional ini setting in a future version of eZ. Betsy
Felix Leimbach	Monday 01 January 2007 11:05:23 pm Anyone interested in this can track the bug report at http://issues.ez.no/IssueView.php?Id=9919&activeItem=1
kracker (the)	Tuesday 02 January 2007 12:06:29 am <i>Smart Move!</i> I wish more people would validate their ideas an an open forum and as a direct result of the conversation submit a well thought out issue. I'd vote for a feature improvement request like this one. //kracker Member since: 2001.07.13 \|\| http://ezpedia.se7enx.com/
Felix Leimbach	Tuesday 02 January 2007 1:18:04 am Thanks for the feedback <i>kracker</i>. I agree with your reply in the bugreport, that a new ini variable should be preferred over burrying the address in a template (hard to find). Of course having the ini variable and the possibility to override it from the template would give the greatest flexibility. Think: Sending book orders to the book dept. and other orders elsewhere. Felix
kracker (the)	Tuesday 02 January 2007 3:13:23 am Your welcome Felix, Thank you for speaking up, being detailed, reporting your issue cross linking your issue to your forum thread. I simply believe that in the end the shop admin user or group setting should for now remain consistent with the existing implementation. This means the email address would remain an ini setting variable. This variable can be an email list, alias or real mail account. The variable allows for the shop email information to be separated from the admin email in a simple way. I think that being able to send the order information to a unique email address has real value. In the end the logic for the sending of the order resides in PHP code. Because of this simple fact, I have an idea that it would be best to override or extend the system which controls this behavior in PHP not in TPL. It would be nice if this functionality could be augmented to allow for extension on an as needed basis but not by default. This would allow you to extend that part how ever you see fit. Extending the TPL + kernel to support overriding parts of the kernel seems awkward. I could be wrong and it could be a terrible mistake but ... I think the problem filters back to an individual's functional needs (as implemented in PHP) may not meet everyones unique needs. Further compounded (I can only guess) with a kernel design which does not allow for overriding all the files in a kernel; like the ones required to be modified to meet your own unique functional needs. This might make an interesting conversation surrounding workflows and extending the parts of the kernel to support this extension? I just see a larger problem that happens to cover the use case you describe ... <i>//kracker i write too much!</i> Member since: 2001.07.13 \|\| http://ezpedia.se7enx.com/