From 664dfcbf18e0a9c1924a221ba1ea8aba87135122 Mon Sep 17 00:00:00 2001 From: Jairo Llopis Date: Tue, 13 Jul 2021 10:46:09 +0100 Subject: [PATCH] [IMP] add guidelines about website features [Odoo 14.0 recommends running HttpCase tests on `post_install` mode only][1]. This can help on certain situations, but increments chances of some website modules polluting others. One simple and common example are `website_sale` extensions in the OCA/e-commerce repo. If a module adds the phone as a required field and another module adds the VAT as required field, when both are installed and both test the checkout workflow, both will probably fail because none of them would be filling the other required field. Note that this is still possible without the `post_install` mode; this just increments the possibilites. In any case, since Odoo v12, we have multiple websites. So, any module that alters Odoo upstream behavior should have those alterations disabled by default, expecting the user to enable them only in the website(s) they want. This should make tests integrate properly out of the box, and should make all website addons more reliable, but it is not obvious, so I think this should be documented into a guideline. [1]: https://github.com/odoo/odoo/blob/9b0578766709b27c91d85bf6246b4bc5e43ca27d/odoo/tests/common.py#L1377 @Tecnativa TT25963 --- website/Contribution/CONTRIBUTING.rst | 50 +++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/website/Contribution/CONTRIBUTING.rst b/website/Contribution/CONTRIBUTING.rst index 6499a44..bf78076 100644 --- a/website/Contribution/CONTRIBUTING.rst +++ b/website/Contribution/CONTRIBUTING.rst @@ -404,6 +404,56 @@ QWeb `to be removed `_ after version 10. +Modifying website behavior +========================== + +This section only applies if you're targeting Odoo 12.0 or higher. + +Since Odoo 12.0, multi-websites are supported out of the box when installing +the ``website`` module. This means that modules that add or alter website +behaviors should provide a way to enable or disable those features per website. + +If your module is altering upstream Odoo behavior, the features it adds should +be disabled by default. + +This will help integrating your module with others because each module can test +how Odoo will behave, as that behavior will be predictable because no module +should pollute website workflows by default if another module happens to be +installed in the same instance before your tests are run. + +If your module adds new features that do not alter upstream Odoo behavior, then +these may be enabled by default, but users should be able to disable them too. + +Don't forget to include instructions about how to enable or disable features in +your README. The most common ways are: + +* Enabling or disabling a view, using website editor, under the *Customize* menu. +* Using the website backend configuration panel, which would save the choice + in the related ``website`` record. + +Checking if a feature is enabled +-------------------------------- + +At the technical level, how to know if a feature is enabled in current website? +Example: + +.. code-block:: python + from odoo.http import route, request, Controller + + + class SomeController(Controller): + # Add website=True to route(), to be able to get website data from request + @route(["/my/route], website=True) + def my_route(self): + # Check if feature is enabled in website; this is common if your + # feature is enabled by a field in the `website` model + if request.website.my_route_enabled: + do_something() + # Check if view is enabled in website; this is common if your + # feature is enabled by customizing some website page + if request.website.viewref("my_module.my_view").active: + do_something_else() + Naming xml_id =============