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

Remove RainLab\User dependency on Mall\Customer model #1116

Open
SamBrishes opened this issue Apr 24, 2024 · 3 comments
Open

Remove RainLab\User dependency on Mall\Customer model #1116

SamBrishes opened this issue Apr 24, 2024 · 3 comments

Comments

@SamBrishes
Copy link
Collaborator

Hello,

In my opinion, the required relationship between Mall\Customer and RainLab\User model prevents a few additional use cases, above all, but not exclusively, when combining Mall with existing ERP or CRM solutions (such as eBay or Odoo).

Using an optional relationship would allow managing customers and users separately and connect them when the customer needs a login for the web-store or website.

Advantages

  1. Offline\Mall can support unique e-mail addresses on the RainLab\User model again, which is - in my opinion - a must-have.
  2. Guest-Only Mall\Customer accounts would no longer need a (placeholder) RainLab\User account.
  3. Mall\Customer can use and provide an own e-mail address for store-related data (and mails), while the RainLab\User email is just for login purposes (of course, both can also be the same).
  4. Mall\Customer accounts can be managed separately, using an existing ERP / CRM / whatever solution, without giving the customers the possibility to login (probably a more B2B related solution).
  5. We would support alternative User-Account solutions, even external ones.
  6. We open the gates for additional extensions that allow, for example, one RainLab\User account to use multiple customer accounts, or vice versa, one customer account to provide multiple RainLab\User logins. (Both B2B related solutions, of course)

Breaking-Changes

As far as I can see, there are no major breaking changes.

  1. A migration could remove existing placeholder RainLab\User models, which should also remove most duplicate e-mail addresses (I guess the most (or all?) duplicates are based on guest-orders).
  2. Existing additional solutions, which assume an existing RainLab\User account for guest orders would no longer work.

Is there anything against it?

What do you think @tobias-kuendig , @chocolata , @xyz1123581321?

Sincerely,
Sam.

@chocolata
Copy link
Contributor

Thank you for your suggestion. I understand the advantages you're highlighting.

Currently, I prefer the integration with the Rainlab User plugin, as I've developed extensive functionality around it in conjunction with the Mall plugin. For instance, in several paid membership sites I manage, the OFFLINE Mall plugin facilitates the initial membership sale and sets expiry dates in an extended column of the User model. Annually, a scheduled task prompts users to renew their membership.

Additionally, the ability to impersonate user accounts is beneficial. Furthermore, other Rainlab plugins like the Campaign Manager, which I use to send emails, also require the User plugin and only target users with valid memberships.

If the User plugin were to become incompatible, it would significantly impact my projects. Could you confirm whether your updates will maintain optional compatibility with the User plugin? I'd appreciate hearing more about your plans.

@SamBrishes
Copy link
Collaborator Author

Hello,

thanks for sharing your use-cases.

Of course, RainLab\User will stay compatible with Mall and will also stay as dependency and be required for using the web-store (or additional features). Just the requirement of the Mall\Customer model relating to a RainLab\User model would be made optional and thus preventing unnecessary RainLab\User accounts, such as those created for guest orders.

Seems like you aren't relying on guest orders anyway, and require a valid and working RainLab\User model for your (customer) projects.

However, considering your use cases, I guess the best way to handle this is to make the whole requirement-stuff configurable. This would make it even easier to prevent existing set-ups from causing any problems.

Sam.

@chocolata
Copy link
Contributor

Hi @SamBrishes,

If backward compatibility with the Rainlab User plugin is ensured, I see no reason not to consider your proposal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants