link plan_id to product.template not product.product

[njeudy]

Hello,

I'm working on V11 and would clean up code and functional things in saas_portal_sale

I think we need to link plan_id to product.template and not to product.product?

For me:

• Create a product.template linked to plan_id (template of database)
• Create spéciale attribute (variante) with filestore limit, user limit, db limite and setup price that depends of it (more disk space = more money)
• All variant will have same plan_id

When you buy from ecommerce web site, you chose your product.template, select variante and all is deployed correctly ?

@yelizariev @iledarn @W360S what do you think about it ?

I want to restore trial button to with good process to select database, name, payment .. etc ..

[W360S]

I think we cloud do something like this:
client sign up go to plan chose a plan to want to start, additional user, storage just slide to get that for what they want and confirm (done) system auto-generate db for them.
https://system.w360s.com/cart.php

[njeudy]

@W360S I think to add this:

that does not actually work on V11

[njeudy]

WIP in #746

[W360S]

@njeudy if we could do like this: https://www.openeducat.org/page/openeducat-enterprise
it really huge innovation :)

[W360S]

[njeudy]

@W360S this case is not for me a plan :) A plan is a database template with some data.

here we have a "plan constructor" .. I think we can achieve this by creating a base database (without modules) as plan, and then add options to install apps and/or modules in this plan ..

[iledarn]

In Prior:

1. To subscribe customers: we used website_sale module with product.template special Period/Number of Users/... attributes, and there was plan_id in product.template model.

Bt It is complex to configure with all its SAAS_CODEs and leads to excessive product.product records - odoo multiplexes variants for each attribute. Say we need one more Number of users variant - this will create product.product for each Period and Storage and maybe other attributes for this specific Number of users.

2. There was no smooth way for customers to continue subscriptions - in cases of expiration when the period passed

In Current:

1. We need an analog of website_sale for saas only - without using attributes for Number of users and other saas-specific parameters - not done yet

2. Now customers may see their invoices in /my/home portal page and there is Pay now button.
   The idea was to create a new contract (https://github.com/OCA/contract) along with a new saas_portal.client record (and new saas instance) and periodically (monthly, quarterly, yearly) generate invoices according to the contract's settings.
   These settings also have product.product the invoice lines should use.

Why do I think that it is better to link a plan with product.product rather than product.template

1. We requested several times to customize the signup controller - so that instances would be created using signup form - there is field on sign-up form to select saas product (not template - no need for attribute stuff there, the same product is used in the periodic invoces).

2. On apps.it-projects.info Odoo version is an attribute of product - database with our module installed (8.0, 9.0, 10.0, 11.0 variants). In this case we cannot link plan with product.template because each version of Odoo has to have its own template database

[njeudy]

@iledarn thank for your comment. I have a question:

• As plan is linked to only one template, one plan = one version of odoo = on set of modules préinstalled so for me it is a product.template directly availaible in odoo ecommerce product and can be bought ...

In you example, with variant or not, all cases can be managed .. when you create a product template, product.product is directly created .. and if you use variant (but it is not necessary) you have on product.product by variants ..

So for me plan = product_template and some option of the plan can be manage by other product ..
For me sale.order generate a contract but not a plan directly .. in sale order you can have a plan, support, external product like domain name, https certificate etc .. and this contract as all products: -

1. one for the plan (or plan + variant if you use it)
2. one for the domaine name
3. one for https access etc ...

@iledarn in your case if you don't use variant one product_template = on product_product = one plan and if someone want to user variant to manager some option / price etc it works to ..