View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003017||OXID eShop (all versions)||1.03. Basket, checkout process||public||2011-06-30 19:01||2012-12-07 15:17|
|Product Version||4.5.0 revision 34568|
|Target Version||Fixed in Version|
|Summary||0003017: User/group assignment in payment methods works differently than all other assignments|
|Description||When assigning countries, users, groups, articles and categories to shipping methods, shipping cost rules and payment methods, all of the assignments in the popups follow the rule "nothing assigned means everything is assigned" except for the user/group assignment in payment methods, which works like "nothing assigned really means nothing assigned".|
All of the controls should work the same way, so if you do not assign groups to payment methods this should mean "valid for everyone".
Perhaps it is a feature, no bug?
Maybe the intention was to secure such a sensitive area as payments methods in this way? So you need to specifify directly which usergroups can use which payment methods.
But I agree with the basic intention of this report to do all those assignments in the same logic. For me personally it is more logical to assign something to make it work. Which means, that "nothing assigned is nothing assigned", but then use this all over the shop.
I think "nothing assigned is nothing assigned" for all controls would make delivery configuration more complicated, breaks "show delivery costs when not logged in" and would make many existing rules stop working.
||Maybe a simple extension of the documentation would do the job. ;)|
||I think even if it were documented it would still be a bug if there is no good reason for this odd behaviour.|
I too stumble upon this everytime i install a new oxid system. Its really weird that you have to assign all groups to a payment method (such as oxempty) and reassign them when you create new groups.
I'd appreciate the behaviour suggested by leofonic.
This request interferes with one of our ideas for improving module handling in eShop: we want that payments and shipments meta should be explicitly deactivatable – for instance during module (de)activation (i.e. if you deactivate PayPal module, then PayPal payment method also becomes disabled). When we will have that, we can also improve this part for user assignments and make it unique in entire eShop.
So for now this request is added to our list to keep it in mind, and here is suspended.