Posted by moshe weitzman on September 4, 2006 at 2:24pm
I think many stores online offer the anonymous purchasing (i.e. no need to choose a username/password during checkout). What are the reasons that we propose to remove this? Is Drupal not capable of cleanly supporting this? I'd love to keep this capability, so I'm eager to architect with others until we find a clean implementation.
Comments
Ditto
I agree, I am keen to keep anonymous purchasing in ecommerce and work on getting it to work rather than removing it.
Maybe each product type could decide if the buyer needs to be a user first - like the file product.
Just an idea...
The main issue is private
The main issue is private information so easily leaks out. ATM if you bang away at store/transaction/txnid, you will find anonymous information.
If someone can provide an acceptable method of securing the privacy of customers then I will reconsider, the removal of anonymous customers in the release.
On the other side, I am going to be making the registration of new users during check much simplier and being able to submit less information that what is required for anonymous users.
--
Gordon Heydon
just don't allow order history viewing
i must be missing some complexity ... seems to me that we can simply disallow viewing of orders placed by uid=0. a slight improvement on that would be to tie transactions to sessionID for anonymous purchases. that means that order history would be available until the user lost his cookie. after that, he could follow a special hashed link in his confirmation email (assume for the moment that he provided an email address).
This will not work, because
This will not work, because if the user loses their session before they have viewed the invoice, which is a complete display of the transaction unlike the email which is sent. They will not have had the change to view it.
What I would accept is a adding of a token which is put into the email as part of the view invoice link and then the user can just click on the link and it will display the invoice.
the url would be something like.
http://example.com/store/transaction/123?token=123456AFGHI...
--
Gordon Heydon
Need to maintain backward compatibility
We definately need to have some kind of policy about backward compatibilty with new releases for E-commerce. I had endless headaches with upgrading to 4.7 e.g. removal of flat-rate shipping from 4.6 to 4.7 (still unresolved).
Removing anonymous purchasing sounds like another step backwards. While I understand the need for privacy and security to be improved, the solution is code improvements, not hacking and slashing functionality. If that was the way Windows had been developed, we'd be back in pre-DOS days and still facing security issues. Kind of like cutting out your eyes to cure itchiness...
I have been thinking about
I have been thinking about backwards compatibility and the upgrade path. With the resources we have working on ecommerce (about 6+ modules per coder) we can either keep up with Drupal releases or we can maintain backwards compatibility and a stable upgrade path. It is not possible to do both.
Certainly we try not to break stuff. But when the crunch time comes we don't have enough testers, and I can't remember one bounty offered during the 4.7 cycle (apologies if I missed anyone).
My position is with Gordon, I'd prefer not to have any code where security is a risk. It's not worth it. (Of course, I am really happy to see discussion about alternative methods.)
Not really moving forward then
The problem is that without backwards compatibilty in a very important module such as E-commerce, it puts up a huge roadblock for all sites that are dependent on it so that they can't be upgraded to newer Drupal versions as they are released, at least not without substantial reworking.
I honestly believe it's better to hold off on new functionality and focus on improved security and continuity first. That way, when new functionality is introduced, albeit at a slower pace, the code will be secure, and all dependent sites will be able to implement the new versions.
Whilst E-commerce is treated as a non-core module, it is such an important part of Drupal that it needs to be managed along the same upgrade path as the core modules if it is not to slow a big percentage of Drupal sites from the upgrading to recent, more secure versions of Drupal core.
Not sure how best to balance the limited development resources, that's always a stumbling block, but I think the core releases also need to factor in the impact on E-commerce-based sites. I'm not one to favour holding back core releases so modules can catch up, but I think E-commerce, being a financial driver and therefore critical component for so many Drupal sites, needs to be treated almost as a part of the Drupal core modules.
Backward compatibility is not an option.
We have no choice in the matter. Even without making any improvements, going between major Drupal releases is going to break everything. Drupal does not retain backward compatibilty, so E-Commerce can't either.
Even now you cannot run HEAD on 4.7, and this was true since the day after EC 4.7 was released, by just making simple changes to keep E-Commerce compatible with Drupal HEAD.
And so far I have only made incremental steps to rid ECommerce of some of the Bad code, to make it much more stable, and more accountable.
The gap would have been a lot bigger. At the moment there are only a handful of regular developers and just keeping in line with HEAD is a big enough job. At this point in time, we still have a lot of work just to get E-Commerce ready for Drupal 5.0 without making any improvements.
With your logic we will never be able to fix anything properly, Like the issue where paypal url's can be altered before payment. This cannot be fixed properly without completely breaking the paymentapi. A major update in Drupal gives us the opportunity to fix these things properly, and make things better.
With more people testing and helping out with coding, documentation, and testing we can make a much better release for Drupal 5.0
We have under 3 months to get E-Commerce ready for a 5.0 release.
ARE YOU GOING TO HELP!
Lastly. No one is forcing you to upgrade.
--
Gordon Heydon
Core functionality needs to have stability
Of course no one is forced to upgrade, but not maintaining a basic level of consistent standard basic functionality forces us NOT to upgrade. That's bad for Drupal in general. Imagine if with every Drupal version we lost some of the core functionality. Nobody would bother upgrading anymore, and only use it for new developments that are intended to remain static forever.
Happy to help where I can, although admittedly I have a steep learning curve. Let me know what I can do, and how best to get started.
The only thing that did get
The only thing that did get dropped out due to lack of time, was the flat rate shipping.
Now to this point NO ONE was created a replacement that can be included. There have not even been any attempts to create a flat rate shipping partner for the shipcalc module.
People can help by just testing the CVS version, because any fixes need to be done there first before they can be put into 4.7. Submitting bug reports, creating patches (even if they are wrong) just getting involved so that more work can be done, more ideas can be implemented, and make a better E-Commerce system.
--
Gordon Heydon
Important
That should be mentioned on the Drupal.org project page asap. As discussed here, there is no general way for Drupal or contrib modules, so each project maintainer should make this point obvious and clear.
IMHO, people (including me) do not understand why there are project issues at Drupal.org, an ecommerce group at groups.drupal.org and additionally a mailing list at heydon.com.au. What is used by ecommerce core developers? The mailing list or the groups? I've subscribed to the group and am receiving many notifications per day, so my first question is: Where happens the important stuff regarding ecommerce?
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
All of these areas have
All of these areas have different uses and all of them are used by the EC developers.
We also frequent #drupal-ecommerce as well, which is most likely where we do a lot of our conversation.
--
Gordon Heydon
I'm guilty!
asimov. I want to say that /also/ have 4.7 sites that may never get upgraded because I don't have time to sort out potential ecommerce problems. So I do understand where you're coming from.
Therefore, if backwards compatibility and upgrade paths are low on my agenda, this is not because I don't care about your situation. The real reason is they are simply off the radar. At various times I have accepted personal responsibility for the following: flat-rate shipping, flexible charges, austpost shipping, ecommerce install profile, site recipes for handbook, improve install documentation for handbook, add dutch auctions to auction, add ebay interface to auction... (and that's just ecommerce). These are all important (they are interesting and desireable). But they still not done.
So it's not that you are wrong about what is "right" - it's just that your expectations are unrealistic.
Hmmm
Oh well, guess I can't complain until my skill level is good enough to help fill in the gaps.
Please try and keep it in mind though where possible, I'd really love to be able to feel confident about upgrading my E-commerce-based sites to the next Drupal version.
+1
I didn't read all the comments here, but I'll add that I find anonymous purchasing an invaluable feature.
i.e. one client (www.jewishcenter.org) doesn't have registered users at all (aside for staff who can post content), but any (unregistered) visitor needs to be able to make an online donation or pay for an event. It's been working nicely thus far.
--
http://www.wovenlabs.com
--
http://www.woven.org
http://www.davidnotik.com
Anonymous purchasing is a mandatory feature
I'm in the same boat as most others here. I feel anon purchasing is vital to many sites. In fact, i've just finished working on the new ec_useracc module as part of my changes to the recurring products and roles functionality. This module is targeting user account purchasing and, as a byproduct, supports anon purchasing. Among all that the module also confirms the customer's email address when the purchase total is $0. Only a small amount of code is required to add the anon invoice viewing functionality to the system.
Don't get me started on the debate of backward compatibility. I'll express my thoughts on that with one word - funding.
There's one other reason for lack of backward compatibility that others haven't pointed out (or at least that I haven't read yet). Maintainability of EC is absolutely terrible right now. The code is highly coupled. E.g Role assignments at purchase has code in 3 modules (store, cart, payment) rather than one.
We are working on improvments to the EC core design and, starting with 5.0, you're definitely going to see improvements in this realm.
--
Sammy Spets
Synerger
http://synerger.com
--
Sammy Spets
Synerger
http://synerger.com