Marketplace, Multi-Tenant Implementation

[aaronjudd]

Refactor Reaction so that can be used either for single shops or to run a marketplace.

This diagram is a view of the future as we see the ecosystem, and demonstrates the different implementation possibilities that we'd like to fully support (marketplace, single tenant, multi-tenant. Reaction-drive is being tested as a private project at this time.

• Closes #236
• Closes #205
• Closes #327

  Marketplace

• individual, but consolidated consumer user accounts for all shops
• users can become tenant shops (new role, restricted admin) #327
• manual or automatic approval process for shop to become visible
• must have at least one product published to be visible
• top level domain name + SSL support for marketplace only
• wild card sub domain name support
• single, shared database
• checkout with multiple tenant order #154
• per tenant/per item order review #287
• marketplace tenants can
  • add tenant shop products
  • edit tenant shop products
  • change configuration, dashboard, etc (all admin priv)
  • fulfill orders
  • can contact customer
  • cannot view order item/history from other shops
  • cannot view user accounts that have not purchased from tenant
  • marketplace permissions to allow customization of reaction apps
  • payments
  • shipping methods
  • default to marketplace #100
• fee, rev share structure
  • default none included
  • should be extended for customization
• copyToCartOrder order contains subdocument for each shop order #154

  Single Tenant

• consumers have a single user account, unique to shop
• shops can have their own content
• private database
• top level domain

  Multi Tenant

• multiple single or marketplace tenants
• shops are isolated and independent instances
• instance management from additional application (reaction-drive)
• reaction-drive integration with launchdock / IaaS service management layer
• tenant top level domain name and SSL support
• private database per tenant
• deploy custom build or release images

  Network

• shops use DDP authenticated methods to access remote reaction host
• Reaction oAuth network for authentication.
• analyze anonymous event data within network
• event and log data storage
• shops are remote, anonymous users
• preconfigured partner apps

  Accounts

Is it important for the accounts/users to have unique authentication and accounts data for each marketplace shops?

The accounts and users schemas do not require the shopId. It is not necessary, as you have the "origination" shop at the order level, and order.item.shopId to identify marketplace origination shopId.

• "Marketplace" Tenants can only access user account / history
• if user has purchased an item from shop (order.items.shopId)
• if user created an account on shop (accounts.shopId)
• if user created an order on shop (order.shopId)
• "Single Tenant" Users can edit, use their account / history
• if user has purchased an item from tenant shop (order.items.shopId)
• if user created an account on tenant shop (accounts.shopId)
• if user created an order on tenant shop (order.shopId)
• registered an account, and confirmed email to link order history as guest
• "Marketplace" Administrators can access account info for all accounts

  Roles

A shop should only need to create this permissions matrix to become a marketplace.

• Roles control visibility and administrative access to shops.
• Accounts only are related to user, not shops
• Publications check roles for permissions.

When the OWNER grants a GROUP of users with JOIN.

When a new user is created, it should be given a "USER" ROLE = SHOPID.

If USER has the JOIN role

• JOIN gives permission to add "TENANT" to their role (manual on some confirmation)
• TENANTS can create a shop while at the top level SHOP
• TENANTS become ADMIN of created SHOP.
• REACTION OWNER has ADMIN role for all TENANTS (need to define more on this role)

The TENANT role should provides a set of PERMISSIONS (set by the REACTION admin).

	USER	OWNER	JOIN	ADMIN	TENANT
USER	SHOPID#1		x
TENANT	SHOPID#1			SHOPID#2	x
ADMIN	SHOPID#1	x		SHOPID#1
ADMIN				SHOPID#2

Roles, Groups and Publications should completely control view and edit rights.

• create products
• process orders
• fulfill orders
• publish products

It's my opinion that the majority of the work for "marketplace" lies in correctly setting up the roles, and permissions throughout.

Statistics

Query: How many users does shop XXX have?
Answer: Count roles with shopId

Query: how many order for this shop? Answer: query orders.items.shopId = shopid

If we could identify the common statistics needed, we could add transforms to the collections to update the analytics collection with a shop summary.

[markchipman]

+1 for Multi-tenancy... if you need help with this let me know. I was planning on building it out for my use case... I see you have done much consideration on this as have I. If you'ld like Aaron, I can discuss my plans and see how well they fit with your vision on this.

[aaronjudd]

@markchipman multi-tenancy we support now with a private package. it was a bit of a stopgap, for the "alpha" release, and will need some updating before we can decide if it should made public, or provide an alternate approach. It's really the "marketplace" that requires the most thought/work in the core. Conceptually - it's just a matter of filtering content by shopId[s] in all the publications, but the administration, order workflow UX is a more complex and needs updating for marketplace/multi-vendor.

Love to hear any ideas, as we're beginning the discussion on a UI/UX refresh to clean up everything and tie everything together for the beta release (which also means that we're ok with some PRs even if the UI isn't fully finished right now).

[stabenfeldt]

@aaronjudd, will you release the private package anytime? I'd love to get support for multiple vendors myself. :+1:

[boboci9]

Hi @aaronjudd,

I took a look at the changes you added here and compared them to the schema changes you added in the version 0.1.0. I have some questions if you could clear out some details: Regarding the shipping entry in the Cart collection, you changed it to be an array but the entries doesn't contain a shopId, how were you planning to identify which shipping entry is linked to which shop?

[aaronjudd]

https://github.com/reactioncommerce/launchdock is the multi-tenancy application we are working on. I will be updating this issue soon, as it's still very much a work in progress.

[boboci9]

We were discussing with @mikemurray some cart.shipping details. I have some suggestions for when the multi vendor is implemented. With the current cart.shipping schema you can't identify from which shop was the particular shippingMethod selected. I needed to add cart.shipping.$.shopId to my schema in order to have different shipping selected for different shops participating in the same order. I didn't need the cart.shipping.$.items as you have in the order but not in the cart because using this shopId you can identify which items are considered for this shop.

[aaronjudd]

Most pieces of this issue are now in place, and we should be rolling this out over the next couple releases.

I'm closing this issue, with the remaining issues for marketplace being:

799 - Market place shop selection / UI

798 - Market place checkout and shipping

800 - Market place owner invitation

[mariusa]

Hi,

Since the docs reference this https://docs.reactioncommerce.com/reaction-docs/development/reaction-shops Reaction Core provides a single tenant shop.

would you please document how to setup a multi-tenant install? That is, allowing completely different businesses to have their own shops & domains, on a single server instance.

Thanks

[impactmass]

@mariusa At the moment you can follow this using the marketplace branch https://github.com/reactioncommerce/reaction-docs/blob/spencer-marketplace-docs/developer/tutorial/running-a-marketplace.md

This is not in the main (master) docs yet, because the multi-shop (marketplace) work is still in progress on the marketplace branch.

[mariusa]

Thanks Seun! To confirm, that looks like a marketplace, which is allow multiple vendors have different products and sell in a single shop.

We're looking for completely different shops, each with it's own looks/products/owner and domain. Multi tenant on the same install, instead of requiring an install/server for each shop. Is this being worked on? (would like to help)

[impactmass]

Okay, I misread you earlier. I thought you were referring to marketplace - which I know we're working on right now.

[spencern]

Hi @mariusa

This idea, true multi-tenant, multi-domain, etc is on our roadmap right now as well. Our backend architecture supports this already though we currently don't have any examples of deployed shops with multiple domains. There's some work you'd have to do on the UI to support this use case, but we'd welcome any contributions towards that.

We've (@aaronjudd specifically) had this specific use case in mind from the beginning, so I'd love it if you could offer more details of what you require that we can start to build towards.

I'd imagine that a lot of the features we're working on towards supporting a multi-shop marketplace will also help with the multi-tenant/domain as well, so now is a good time to start working towards this.

[mariusa]

Thanks Spencer, that's good news!

A great example is Shopify.com We'd like to have something similar, but for a specific niche. Customer A would register, and get a subdomainA.niche.com with a fully functional store. Customer B would get a different subdomain & store. Nothing between those stores is shared (just like separate reaction installs)

Hope this clarifies?

[herdjeaf]

hello !!!! please i need your help. how can i do to implement muti-vendor marketplace using reaction commerce ???