Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix customer address form #17526

Merged
merged 13 commits into from
Mar 26, 2020
Merged

Conversation

zuk3975
Copy link
Contributor

@zuk3975 zuk3975 commented Feb 6, 2020

Questions Answers
Branch? 1.7.7.x
Description? After trying to fix addresses required fields and format relation in #17293 we found out it needs more work than expected, so this pr only fixes mandatory bugs and leaves the BO address form simple, without considering the required fields(in customer->addresses settings) or Address format (in country settings). The above mentioned relation of addressFormat and fields is planned to be reworked in 1.7.8
Type? bug fix
Category? BO
BC breaks? no
Deprecations? no
Fixed ticket? part of #17282, finishes #10558, improve #17549, fix #17032 #17549
How to test? Customer address form in BO now should always render all fields as optional (= you can leave blank). Only firstname, lastname, address1, country and city fields are mandatory. We dont try to guess what fields are required or not based on country on whatever. We keep it simple 😄 NOTE I had to leave some of required fields check in BO anyway to ensure that it works like before and nothing breaks in FO.

This change is Reviewable

@zuk3975 zuk3975 requested a review from a team as a code owner February 6, 2020 10:18
@prestonBot prestonBot added the 1.7.7.x Branch label Feb 6, 2020
@prestonBot prestonBot added Bug Type: Bug Waiting for wording Status: action required, waiting for wording labels Feb 6, 2020
@zuk3975 zuk3975 changed the title [WIP] Fix customer address form Fix customer address form Feb 6, 2020
@LouiseBonnard LouiseBonnard removed the Waiting for wording Status: action required, waiting for wording label Feb 6, 2020
@zuk3975 zuk3975 mentioned this pull request Feb 6, 2020
19 tasks
@prestonBot prestonBot added the Waiting for wording Status: action required, waiting for wording label Feb 7, 2020
@matks matks added the migration symfony migration project label Feb 7, 2020
matks
matks previously approved these changes Feb 7, 2020
@LouiseBonnard LouiseBonnard added Wording ✔️ Status: check done, wording approved and removed Waiting for wording Status: action required, waiting for wording labels Feb 7, 2020
return [];
}

$states = State::getStatesByIdCountry($countryId, $resolvedOptions['only_active']);
$choices = [];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$choices must be decalred above. If there is an exception in new Country, $choices will be undefined

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get what you mean it would be cleaner, but it shoudn't be a problem here since an exception is thrown in the catch block It will never reach the return $choices;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if it's not a PrestaShopException 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then it's not caught by this class and either the process crashes or it's caught by something higher In both cases it still won't reach the return

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you just move the return $choices after the foreach to have a cleaner code :D 🙏

Copy link
Contributor

@PierreRambaud PierreRambaud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see my comment

Copy link
Contributor

@jolelievre jolelievre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing blocking for me But I always have concerns regarding this "Address" feature, it is mixed/common with brand addresses, manufacturer addresses But each one has been developed separately, so we fix bugs separately as well And the improvement are never ported from one to another
Since you said some improvement should be made in 178 about the customer address, maybe it would be worth refactoring all the address management so all rules are clear everywhere?

@@ -46,7 +46,7 @@ final class SetRequiredFieldsForAddressHandler implements SetRequiredFieldsForAd
*/
public function handle(SetRequiredFieldsForAddressCommand $command)
{
$address = new Address();
$address = new CustomerAddress();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One question, how does it work for brand or manufacturer address? Because I believe they all share the same Address class But using CustomerAddress here means it's only dedicated to customer addresses, but not the other ones? Then shouldn't the handler name and namespace reflect this limitation?
=> SetRequiredFieldsForCustomerAddressHandler::handle(SetRequiredFieldsForCustomerAddressCommand $command)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only customer address is affected 🤷‍♂️
Maybe as you say it could be reworked in 178.
It came from legacy that in db required_fields are saved by classname of the object (in this case CustomerAddress. By providing Address it doesn't work at all).

return [];
}

$states = State::getStatesByIdCountry($countryId, $resolvedOptions['only_active']);
$choices = [];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get what you mean it would be cleaner, but it shoudn't be a problem here since an exception is thrown in the catch block It will never reach the return $choices;

@zuk3975
Copy link
Contributor Author

zuk3975 commented Feb 12, 2020

see my comment

moved var declaration up before try-catch

@prestonBot prestonBot added the Waiting for wording Status: action required, waiting for wording label Feb 12, 2020
@zuk3975
Copy link
Contributor Author

zuk3975 commented Feb 13, 2020

Related issue: #17647

@LouiseBonnard LouiseBonnard removed the Waiting for wording Status: action required, waiting for wording label Feb 13, 2020
@zuk3975
Copy link
Contributor Author

zuk3975 commented Feb 14, 2020

@jolelievre, @PierreRambaud addressed.
also i put back checks for required DNI and POSTCODE fields in js
31f6e85 . Somehow those checks are essential only for these 2 fields so those cannot be always optional, but no other configurable requiredFields need it 🤷‍♂️

PierreRambaud
PierreRambaud previously approved these changes Feb 14, 2020
PierreRambaud
PierreRambaud previously approved these changes Mar 24, 2020
@Progi1984 Progi1984 added the Waiting for QA Status: action required, waiting for test feedback label Mar 25, 2020
@Robin-Fischer-PS
Copy link
Contributor

Robin-Fischer-PS commented Mar 26, 2020

I tested again, with France and Spain addresses, both BO & FO are OK (except the "issue" which was already there in 176) !

Thanks @zuk3975 :)

@Robin-Fischer-PS Robin-Fischer-PS added QA ✔️ Status: check done, code approved and removed Waiting for QA Status: action required, waiting for test feedback labels Mar 26, 2020
@zuk3975
Copy link
Contributor Author

zuk3975 commented Mar 26, 2020

I tested again, with France and Spain addresses, both BO & FO are OK (except the "issue" which was already there in 176) !

Thanks @zuk3975 :)

Thank you, doing a great job!

@Progi1984
Copy link
Member

Hello @zuk3975, thanks for your contribution, would you mind to rebase your pull request? Thanks

@PierreRambaud PierreRambaud merged commit 7e8e1b7 into PrestaShop:1.7.7.x Mar 26, 2020
@PierreRambaud
Copy link
Contributor

Thanks @zuk3975

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.7.7.x Branch Bug Type: Bug migration symfony migration project QA ✔️ Status: check done, code approved Wording ✔️ Status: check done, wording approved
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Adresses page - Required Fields cannot be selected which occurs issues in the BO & the FO
10 participants