Single-Customer Support on Multi-Store- same customer should be treated differently

@Akash,
Email and username are not primary keys.  The  "... is already registered" is handled in the CustomerController.
  
@talex
NopC can handle B2B -  E.g. I have client selling janitorial supplies to health clubs.  We use Customer Roles ("... Member") and Tier Pricing.
The one piece that is missing is not having a single "Account" (Company), so that multiple employees (Customers) can each login with their own email, and yet their orders are all under the same account.
(I don't follow your example "... other businesses would not want someone elses employee to be able to order new napkin rings ")

talex wrote:

OK, I think I see where you are coming from.

But I'm still questioning why one would lock Customer to a StoreId. IMO, that is confusing Authentication with Authorization. I'm not going to give a text book definition, but for the sake of this discussion, I'm simply going to write explicitly what that means to me:

Authentication: Who is the user
Authorization: What can the user do

So, to me, Customer is best associated with the Authentication concern. Typically, roles are brought in to handle authorization, and even though that might be a slightly more complex implementation, I would wholeheartedly endorse that as the 'correct' direction for anyone extending NopCommerce to go for these scenarios.

As far as implementation, eing able to add/revoke roles from an admin environment is pretty straightforward, and you could enforce it either by decorating your actions with a RoleAuthorization attribute or intercept them from a plugin using ActionFilters

New York wrote:

sorry, bad example. Perhaps a better example would be someone that markets customized products for various national chains, in this example we'll use McDonalds and Burger King as our client. Now the customized products for each client are pretty unique, so each chain gets it's own store with the product offerings. Furthermore, because there are hundreds of these restaurants, the option is to let each branch register a couple of manager employees from each branch to access the site and order the customized products. Now Burger King doesn't want some random McDonalds employee to come across the Burger King site and be able to select, customize and order products for some branch with which they have nothing to do. This is just a simple use-case. Hope this clarifies better than my last example (it was getting late).

talex wrote:

I don't think that's even the biggest concern, here. If you trust a manager to buy stuff for your store, it is unlikely that person will risk their job to buy some Burger King paper hats. I think the bigger concern is when McDonalds has a Store Manager and 3 Shift Managers (for example), and Store Manager might want to buy, and then might make the 3 Shift Managers responsible for their transaction reporting, so they might need order history reports.

You would want to provide 4 logins and 2 different roles. Since the roles are already enforcing behavior (you don't want the Store Manager as an Admin), you can extend the roles to be store (domain) specific.

mattsoundworld wrote:

Yes, you highlight much better use-cases for the potential for development along these lines. There are also potentials for approval workflows etc. The fact is that the NopCommerce permissions are not very sophisticated, yet sufficient for most standard use-cases.

But to my original point, I would not tie Customer to a StoreId in any use case (directed towards the OP)

Agree. our business requirements as well required Customer per Store.
Was reached by adding StoreId to Customer table. All the methods of customer verifications was changed to custom methods.

But as you can see this problem is wider then couple of companies. Might be that could be setting (CustomerLimitedToStore) and depend on it customer verification methods will work ?

kaunuk wrote:

even if this was to support a 1-many, and not just 1-one relationship it's fine, but for now it's just 1-all without significant customization. perhaps this is a topic that will gain some traction going forward? we can hope :)

talex wrote:

If you want something could be released you need to post in Suggestions And Feedback, not in development )

If you can customize your registration and login logic to assign/look for a storeId, you can just as easily assign/look for a role. This allows the 1-many scenario without modding tables