[KrzysztofPajak]

Type: bugfix

Issue

Storefront sub-account management on 2.4.x was missing rules that develop already has since #991, and customer e-mails and passwords were not handled the same way in every step:

• The edit command relied on the validator to check the owner.
• HideSubAccountsTab only removed the link. The sub-account actions stayed available.
• The edit command and My account stored an e-mail or username as typed, while every lookup expects it trimmed and lowercased.
• The storefront validators checked uniqueness in the current store and on the value as typed, not in the store of the account and on the value that gets stored.
• A password change finds its account by e-mail, even when the caller already holds the account. An e-mail can change between the two steps, and with per-store identity it can belong to several stores.

Solution

• The edit command checks the owner too and changes nothing for a missing, deleted or someone else's account. The edit page redirects to the list for such an id. Delete treats a deleted account the same way.
• All sub-account actions go through one check for the owner and the setting (same as develop).
• E-mail and username are stored trimmed and lowercased, and an address differing only in case is repaired on save.
• Validators check the normalized value in the store of the edited account.
• ICustomerManagerService gets ChangePassword(Customer, PasswordFormat, string), which changes the password of that account without an e-mail lookup. The existing method resolves the e-mail and calls it. Both write only the password fields through a new ICustomerService.UpdateCustomerPassword, so a copy the caller loaded earlier cannot undo other edits. The sub-account edit and the customer's own password change use the new method.

The validator and password parts go beyond #991, so develop gets the same change in #1009.

No new resources, settings or migrations. Existing messages are reused because 2.4.x databases do not re-import the language file.

Breaking changes

No rebuild is needed for plugins built for 2.4.0. ICustomerManagerService and ICustomerService each have a new member with a default body, so an existing custom implementation keeps loading and uses its existing methods. An implementation of ICustomerManagerService compiled against the earlier interface was run against this build to confirm it.

One behavior change: with HideSubAccountsTab = true, which is the fresh-install default, sub-account pages now redirect to My account instead of staying reachable by URL. A store using them that way has to set it to false.

Testing

Unit tests pass: Grand.Web.Tests (81), Grand.Business.Customers.Tests (124), Grand.Web.Admin.Tests (1554). The full solution and the steps below were not run.

1. Set HideSubAccountsTab to false in Admin, sign in on the storefront as a registered customer, and add a sub-account.
2. Edit it: change the names, the password and the active flag, and check the sub-account can sign in with the new password.
3. With AllowUsersToChangeEmail on, change its e-mail to one with capitals. It is saved lowercased and the sub-account can sign in. An address that is already taken is rejected.
4. Open the edit page with the id of an account you do not own. You are redirected to the list and nothing changes.
5. Set HideSubAccountsTab to true. /account/subaccounts and the add and edit pages redirect to My account.
6. In My account, change your own password and sign in with the new one.
7. With Customer:RegisterCustomersPerStore on and the same e-mail registered in two stores, change the password in one store. The account in the other store keeps its password.