Post by DBI » Thu Apr 08, 2021 6:49 am

Edit: See my reply later in this thread for the solution to this problem.

Hi,

This problem existed in 2.x and seems to have survived into 3.x.

When adding a custom field (under customers tab in admin) the field shows up during checkout (it's in the address section) for all stores despite being assigned to a customer group for only one store. It also shows as required for all stores despite being set required for just one customer group.

Is there something I'm missing? I'm hoping to avoid needing to write an extension to fix this.
Last edited by DBI on Tue Apr 20, 2021 5:58 am, edited 2 times in total.

DBI
New member

Posts

Joined
Tue Oct 14, 2014 10:58 am

Post by straightlight » Thu Apr 08, 2021 7:17 am

Precise OC version.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by DBI » Thu Apr 08, 2021 8:47 am

3.0.3.7

DBI
New member

Posts

Joined
Tue Oct 14, 2014 10:58 am

Post by straightlight » Thu Apr 08, 2021 10:15 am

The relative custom fields won't be associated with any stores until reaching the orders. Prior, they are associated with customer groups which, by the way, is a problematic with the Orders API which is why the master branch version, still under development, shows a different approach to use these fields with the Orders API.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by DBI » Thu Apr 08, 2021 10:35 am

I take that to mean it's a bug and there's no workaround?

DBI
New member

Posts

Joined
Tue Oct 14, 2014 10:58 am

Post by straightlight » Thu Apr 08, 2021 7:23 pm

DBI wrote:
Thu Apr 08, 2021 10:35 am
I take that to mean it's a bug and there's no workaround?
It's not a bug but a lack of design. Nowhere to be said there's no workaround. Self-assumption. What's been said, however, is that the solution has been developed on the master branch already but still in progress.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by DBI » Fri Apr 09, 2021 3:55 am

I appreciate the information about the potential fix in the pipeline.

In the present, though, still looking for a solution :)

DBI
New member

Posts

Joined
Tue Oct 14, 2014 10:58 am

Post by straightlight » Fri Apr 09, 2021 6:53 pm

DBI wrote:
Fri Apr 09, 2021 3:55 am
I appreciate the information about the potential fix in the pipeline.

In the present, though, still looking for a solution :)
If no extensions are provided on the Marketplace matching your request, you could always create a new service request in the Commercial Support section of the forum to get this done as a custom job.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by DBI » Tue Apr 20, 2021 5:55 am

Finally found the time to look at the code for this issue. It's is, in fact, a bug.

For anyone else that runs into this, here are the causes...

In these files:
> catalog > controller > checkout > guest.php
> catalog > controller > checkout > register.php

The call to the model that loads custom fields is missing the customer group argument.

Note that this is not a design issue as suggested above. The relevant config variable is available to the controller at runtime with the code as it is now, it's just omitted in the call to the model. The same call in the payment_address.php and shipping_address.php files (which are used for logged in users) does not omit the variable and works as expected.

So, editing the code via an extension solves it.

Note that there is another bug here that's semi related: Because an account created at one store in a multi-store setup is valid for other stores in the same setup, a customer could create an account at a store where a required custom field wasn't present, which would then let them bypass that field at a store where it was. That's probably rare enough that it will never matter, just thought I'd mention it.

DBI
New member

Posts

Joined
Tue Oct 14, 2014 10:58 am
Who is online

Users browsing this forum: nonnedelectari and 409 guests