Order Notifications Status - Pending, Delete, Cancel, etc.. Emails problem

[lindapowers]

Hi

I recently noticed this and I must say is really annoying!

This is going to fill the inbox for your vendor account with useless information a part from the issues it may cause for your host, if they don't delete or block your email for spam first. I don't want to recieve 400 emails per day and mark them as read lol

Please limit these as in VM1, this just gives more work for the vendors.

Regards

[liam09]

I 100% agree - this seriously annoying. In joomla 1.x i had zero, (0), naught, null, none forum posts asking any questions or posting frustrations. It's not that i didn't have any, but i was able to usually quickly code my own solution, or if i had a complaint, i kept it in perspective of what it is. I upgraded my primary clients website to 2.0 versions (joomla/vm) and it has been a friggin' disaster. This is yet another annoyance that i can't believe others aren't reporting on. For our company that receives a lot of orders, there are two girls that process most of these orders and they were completely confused why emails kept coming through that looked like previous emails. They obviously suspected something was up, but were tempted to reprocess orders due to the vague and ambiguous emails that are sent every time THEY update an order status.

So in short, i just want to make sure this logic makes sense: I can (in code) turn off the emails. But they also stop sending NEW order notifications. So in short, I can get an inbox clogging amount of emails per day, or i can get none?? And let me make sure i understand this additional logic: if the shop owner updates the status of the order, they also get an email letting them know that they updated the status? Doesn't the Order section plainly reflect that change RIGHT AFTER the person makes the change? And there was no thought that this might be annoying, confusing (for non tech shop owners simply running the software) and overly redundant?

[lindapowers]

So in short, i just want to make sure this logic makes sense: I can (in code) turn off the emails. But they also stop sending NEW order notifications. So in short, I can get an inbox clogging amount of emails per day, or i can get none?? And let me make sure i understand this additional logic: if the shop owner updates the status of the order, they also get an email letting them know that they updated the status? Doesn't the Order section plainly reflect that change RIGHT AFTER the person makes the change? And there was no thought that this might be annoying, confusing (for non tech shop owners simply running the software) and overly redundant?

Amen , I already proposed the change here and got no reply http://forum.virtuemart.net/index.php?topic=115735.0

I can't think of anyone or any situation that benefits from this emails.

Sometimes I wonder the same as you, do people posting here actually run a shop or they are just programmers and designers that never test how shops actually work for their customers?

If you are a shop owner managing the store or the guy or girl in charge of the order management for your company you will know how incredibly annoying this is, best thing is that we are speaking of changing one line of code to make everyone's life easier.

Once more, please consider it.

[Milbo]

In fact Linda, a simple rule in your email client, even in your email web page solves the problem.

[liam09]

Hey guys -
I am curious what you mean by, "even in your email web page"? i'm completely unsure of what this means. And respectfully, to suggest that the professional business world needs to apply a filter to their inbox is a completely unacceptable solution. I proposed VM due to the fact i believe that the shopping cart is secure, robust, and capable. When i have to suggest to a very large business that they now have to apply filters to their inbox, it makes me look foolish and like my proposed solution to take care of (over half their revenue) is incapable of handling a seemingly easy task: Turn on/off emails. Not to mention, it is something that VM 1 already did.. so i am already fielding questions like.. 'soooo, why did we upgrade and go through this year of hell?'

My only proposed solution that i am currently coding, is to check for the order status and either send an email to both or just to the client (shopper). This is a terrible hack, and yes, i am sure there is probably a better way to do this, but given the huge list of things i have to fix just to make this version of the cart work anywhere near the equivalent of what was up (VM 1), makes it not worth my time investigating. Of course beside the hours i've already spent on these forums searching for a solution. It's like when your house is on fire: you go about putting out the fires one after another with whatever is on hand. You don't have time to go to the store, by the correct fire extinguisher, and when you get back, also correctly remodel that part that was destroyed.

And let me state, as i develop this cart more and more, i like many parts of it and i completely understand the reason behind the redesign. But unfortunately for the two other businesses i am starting this year, i shutter at the idea of using VM again. It has cost me in plugins alone (for just shipping might i say! not the others i bought like, downloadable goods) more than a professional, fully supported commercial cart that would require half the amount of intercession VM has created for me. And might i add, if i moan and complain about a problem in a commercial cart, the developers and customer service are responsible for correcting my problem - if indeed it is a real bug/problem. With VM, because the cart is open source/free it gives anyone at any time the ability to say, 'i don't really feel like answering your question.' Or, 'it's an open source cart, figure it out yourself.' I can't even imagine your response of, 'apply a filter to your inbox' as an acceptable solution from a commercial cart. If i would have gotten that response back, I would have personally called them and we would having a much different discussion.

Lastly i will say - it's tough when a community invests so much time and effort into a project, only to read posts like this complaining about things. Max, i am sure there are times when you think, "why am i even doing this".. at least that is the way it seems reading some of your posts. I believe you should get paid for what you are doing to the point it is worth it. I know donations and advertising are probably minimal. But if this cart were a fully inclusive, polished piece of software, i would have paid to use it (given that it was comparable to the commercial equivalents of course). But as it is, the online support community looks to be tired of the users, and the users are expecting more of the developers. This seems to make for a vicious cycle that will only lead to a terrible end.

[Milbo]

Hey guys -
I am curious what you mean by, "even in your email web page"? i'm completely unsure of what this means. And respectfully, to suggest that the professional business world needs to apply a filter to their inbox is a completely unacceptable solution.

Lets say it so, I agree that we must add another configuration so that you can adjust the emails sent. I do not question this. But lets think about HOW!. Just by orderstatus? Should it be configured there? Must it be adjustable by used payment/shipment? Or just a simple dropdown like for the invoices in the config?
In fact I think it depends on the used shipment/payment. So lets discuss this constructive, then we can add it.

My only proposed solution that i am currently coding, is to check for the order status and either send an email to both or just to the client (shopper). This is a terrible hack, and yes, i am sure there is probably a better way to do this, but given the huge list of things i have to fix just to make this version of the cart work anywhere near the equivalent of what was up (VM 1), makes it not worth my time investigating.

okey, you use the orderstatus. Which bugs do you mean? Which fixes you did ot make the cart work near vm1? I think that since multiple prices vm2 can do at least what vm1 could do and a lot more. So please post your sugestions here http://forum.virtuemart.net/index.php?board=139.0

And might i add, if i moan and complain about a problem in a commercial cart, the developers and customer service are responsible for correcting my problem - if indeed it is a real bug/problem. With VM, because the cart is open source/free it gives anyone at any time the ability to say, 'i don't really feel like answering your question.' Or, 'it's an open source cart, figure it out yourself.' I can't even imagine your response of, 'apply a filter to your inbox' as an acceptable solution from a commercial cart. If i would have gotten that response back, I would have personally called them and we would having a much different discussion.

When a customer of the store extensions.virtuemart.net complains it is of course different, then some user. It is a matter of priority, what is really important. We use vm2 ourself, so we have our own the email problem. But I have maybe 20 filters in my email client, for me it was just another one. No reason to get crazy.

At the end there must be a kind of calculation, what is more expensive? to write a common function working for all and donate it to the core? As a project is meant? or to create a simple rule in the email client (and yes even most web email client support it), or to hack the core. Of course the best solution is when you are annoyed about it, to read here http://dev.virtuemart.net/projects/virtuemart/wiki/Developer_guideline, write a patch, start a thread, post it there, lets discuss about it. If we do not notice, write a pn to me.

I believe you should get paid for what you are doing to the point it is worth it. I know donations and advertising are probably minimal.

There are atm 2 people payed to develop the core fulltime since a year. I did it the 2 years before for free, but not completly fulltime. We concentrate on bugs, so why we have so many new featueres, they are donated by people. This is the strange thing, how much you gave to the project? I mean directly? for example as code, helping others in the forum. There is only complaining about that the Shipment plugins cost money now. In vm1 times there were this plugins available as simple community version, but also sold.


Anyway the question is left, how we should add the email stuff. As vm config setting? or as payment/shipment option

[lindapowers]

Anyway the question is left, how we should add the email stuff. As vm config setting? or as payment/shipment option

IMO as a vm config setting so that you can easily disable the emails to the shop owner. This doesnt mean removing the "notify customer" option, just leaving it unchecked so if you want to notify a particular customer you can still click it.

A dropdown will do yes, but Isn't easier to change that line of code to remove the "preselected" notify so the ones that need it can still use it? I guess is the same maybe.

I can understand the other option of "per payment/shipment" but I believe this should be a global basic setting initially, a different thing is that in the future you extend it to the payment/shipment config.



Regards

[liam09]

wow - 90% of your response was defensive and accusatory. That doesn't fuel anything but contempt and malice from everyone. Aren't you a leader? You can't say: everyone is at fault, deflect our questions, but  oh yes.. please.. lets come together for a solution. The only reason there is a discussion, is that linda proposed this a while ago.. very simply stated might i add.. and he got ZERO responses in terms of trying to 'come together' and figure out a solution. All the while, people are just adding 20-30 email filters to their client assuming that is how the rest of the world should deal with it.

This is the strange thing, how much you gave to the project? I mean directly? for example as code, helping others in the forum. There is only complaining about that the Shipment plugins cost money now. In vm1 times there were this plugins available as simple community version, but also sold.

In reality, you have no concept of how much i have contributed, not contributed etc.. I am posting under a different name/location that i wanted to use for specific VM2 issues. Does that make me more or less a voice of reason when a fair question is brought to the table? Plus i have spent hundreds of dollars on past plugins and am already in the hundreds for current plugins that i bought. So read it this way.. i have already paid YOU, DIRECTLY $120+ for adding JUST shipping functionality (UPS and USPS), and you are going to bitch at me for not contributing?!!!!?!?!? If you aren't able to eat, you're going to stop this and get a job that does allow you to eat. I've already been there. At this point, I will not purchase anything else from you.

This is precisely another issue - how much should I add to the global community before i, or anyone says for that matter, becomes worthy of credibility? Maybe you should have that in the doc's. And mind you, the forum was created to do................ what again?

I assume the VM project is literally just the "bird in the tree scenario" at this point: all the birds at the bottom of the tree get covered in crap, and when they look up, all they see is assholes.


My hack/fix is just that.. a hack/fix.. that is why i said it's like putting out fires. I have no desire to submit a core enhancement at the moment.. I'm just trying to keep my biggest client happy so i can feed my family! Do i think basing it off the order status is the way to go? Sure? No? I don't care at this point?

Off the top of my head, in config you can pick your status you desire to be notified upon, and select email shop owner/vendor only on that status.. all other statuses default to the typical setup in the order area. That's all i am doing in code, except it is just hard coded for now, as i don't have time to create settings, interfaces, read submission faq's/doc's get flamed some more from core team members etc.. for something so cut and dry for my usage.

However, Linda if you still need a fix like this, i would be happy to post my code.
It will be very basic, but will do two things: send the owner of the shop an email when an order is placed, and keep the shopping cart from sending five million emails when the order status is updated. Let me know if you're interested.

I am completely disappointed in this discussion. Linda mentioned this a while ago (like he said) and got pretty much no answers.. and i believe this is a real issue. And proposing email filters is simply horrible and not addressing the issue. You keep pointing to us, the users, the community, the lifeblood of this project with contempt... and yeah i get it, there are a lot of unreasonable people posting around here wanting the fastest solution with the minimal amount of work, but i'm not that person. Build whatever you want, but if people don't use it, what then do you have? I'll tell you: a lot of wasted time.

[Milbo]

liam09, I am sorry for that.

In the time you wrote this accusements against me, I just added it to the core, will be in 2.0.21D. I asked you what you did for the project, without getting something for it. Just for the community itself. When you use 3 different names. I cannot know, I just took the time to read your posts under that nick.

and Linda helped us really a lot, with nice reports and nice ideas. We are also via skype connected and if it would have been such a serious issue, he would tell me different. I did not see it yet as a real probelm.

[lindapowers]

Well out of this "war" we seemed to get a solution to make VM2 even better, thanks liam for your offering and thanks Milbo for implementing it in a future version, this is more than welcome to VM and as mentioned would make life easier for us shop owners.

[liam09]

Linda (or anyone else) - until the changes get made (thank you milbo),
I simply hacked shopfunctions with this. Just pick a status and change the variable accordingly. I doubt this is the best way to do this, even as a hack, but for now it seems to test out OK.
I personally override the MVC in my template, but if you wanted to hack the core, go to components->VM->helpers->shopfunctionsf.php

Around line 249 there is this chunk of code

Code Select Expand


$user= self::sendVmMail($view, $recipient,$noVendorMail); //this is sent to the user

                 if ( isset( $view->doVendor) && !$noVendorMail ) {
self::sendVmMail( $view, $view->vendorEmail, TRUE );  //this is the annoying one sent to the admin, vendor
}


replace with this:

Code Select Expand


$user= self::sendVmMail($view, $recipient,$noVendorMail);
 
if( stripos($view->subject ,"confirmed")>0 ) {
if ( isset( $view->doVendor) && !$noVendorMail ) {
self::sendVmMail( $view, $view->vendorEmail, TRUE );
}
}


the stripos looks in the subject line for your order status (the stripos is not case sensitive). I picked "confirmed" (believe it is default). So in my testing, i got the first email, but all my subsequent updates to the customer (my other account) only went through which was my desired outcome. Obviously if you have another status that you would like to check for, replace the "confirmed" with whatever your status that you would like to check for. Ideally the real solution would be configurable through the admin area

[Chuck0]

the stripos looks in the subject line for your order status (the stripos is not case sensitive). I picked "confirmed" (believe it is default). So in my testing, i got the first email, but all my subsequent updates to the customer (my other account) only went through which was my desired outcome. Obviously if you have another status that you would like to check for, replace the "confirmed" with whatever your status that you would like to check for. Ideally the real solution would be configurable through the admin area

We tried this code and it shut down all email notifications to the vendor. What order status should be used if you just want to shut down notifications when a customer changes an order? The vendor needs to get the first order notification in order to get the last part of the credit card number.

Thanks!

Chuck