"After some discussion decided not to implement it out of the box. Because billing address is required in many placed. It's just much easier to insert some "Store owner" email address" - Andreis response about this particular issue.
Yes it's easier to insert some bogus address, but the issue here is not difficulty, the issue is that it is not a common professional standard to insert bogus entries to get around unnecessery restrictions. NopCommerce has multiple of those "quick solutions" which basically make the site unusable by a bigger, more professional company.
I know, because I am struggling with plenty of the "features" the site has which my company wants, that are either not in the site (which is fine, because one can make them), or because those are already implemented using those , very restricting, "quick solution" (which sucks severely, because you have to work around it, where you shouldn't have to be).
I don't want to bash, because nopCommerce is a good product, but it seems that the team lacks a proper User Experience competence here, which would help in fixing many details with the site. Those details make the site just "good" insteal of a professional product.
How do i remove email required validation from Shipping Address? Please help me...
- 1390
- 11685
- 8/10/2012
- United States
Yes, it's a frustrating kluge.
But, because this is an open-source community, the "squeakiest wheel usually gets the grease"..
When enough users find this limitation to be problematic to their business model, they will speak up and a real solution will be forthcoming...but currently, there are very few people that see it as a problem...
I've spent quite some time thinking outside the box about how to deal with the problems this causes and came up with what I think could be, at least, a simple way to deal with phone-in or walk-in/retail orders in which the customer is reluctant or unwilling to provide their email address, and it wouldn't require interfering with saving the Billing Address.
Create a new bit field in the [Order] table to indicate if the order is being "impersonated" and set a session variable, "IsImpersonationSession", when the impersonation session begins so that it is available to use in a conditional statement on the /Views/Shared/_CreateOrUpdateAddress.cshtml
We do an if/else to show the normal email text form field for all orders except impersonated orders, and make the email field a hidden form field with a randomized value for all impersonated orders.
This would also make it possible for us to easily filter orders in SQL queries which our staff actually placed on behalf of customers using the new bit field.
Just an idea...
But, because this is an open-source community, the "squeakiest wheel usually gets the grease"..
When enough users find this limitation to be problematic to their business model, they will speak up and a real solution will be forthcoming...but currently, there are very few people that see it as a problem...
I've spent quite some time thinking outside the box about how to deal with the problems this causes and came up with what I think could be, at least, a simple way to deal with phone-in or walk-in/retail orders in which the customer is reluctant or unwilling to provide their email address, and it wouldn't require interfering with saving the Billing Address.
Create a new bit field in the [Order] table to indicate if the order is being "impersonated" and set a session variable, "IsImpersonationSession", when the impersonation session begins so that it is available to use in a conditional statement on the /Views/Shared/_CreateOrUpdateAddress.cshtml
We do an if/else to show the normal email text form field for all orders except impersonated orders, and make the email field a hidden form field with a randomized value for all impersonated orders.
This would also make it possible for us to easily filter orders in SQL queries which our staff actually placed on behalf of customers using the new bit field.
Just an idea...