[MERGE] forward port branch saas-11.2 up to fed775bc0c

doc/cla/corporate/vauxoo.md

@@ -39,6 +39,7 @@ Jesus Zapata jesus@vauxoo.com https://github.com/JesusZapata
 Germana Oliveira germana@vauxoo.com https://github.com/goliveirab
 Mariano Fernandez mariano@vauxoo.com https://github.com/Batuto
 Edgar Rivero edgar@vauxoo.com https://github.com/egrivero
+Edilianny Sánchez esanchez@vauxoo.com https://github.com/edy1192
 Alexander Olivares alexander@vauxoo.com https://github.com/alxolivares
 Jose Manuel Robles josemanuel@vauxoo.com https://github.com/keylor2906
 Erick Birbe erick@vauxoo.com https://github.com/ebirbe

doc/reference/reports.rst

@@ -190,7 +190,7 @@ Barcodes
 --------
 
 Barcodes are images returned by a controller and can easily be embedded in
-reports thanks to the QWeb syntax:
+reports thanks to the QWeb syntax (e.g. see :ref:`reference/qweb/attributes`):
 
 .. code-block:: html
 

doc/setup/deploy.rst

@@ -442,6 +442,10 @@ security-related topics:
   only for controlling/managing the installation.
   *Never* use any default passwords like admin/admin, even for test/staging databases.
 
+- Do **not** install demo data on internet-facing servers. Databases with demo data contain
+  default logins and passwords that can be used to get into your systems and cause significant
+  trouble, even on staging/dev systems.
+
 - Use appropriate database filters ( :option:`--db-filter <odoo-bin --db-filter>`)
   to restrict the visibility of your databases according to the hostname.
   See :ref:`db_filter`.
@@ -474,6 +478,12 @@ security-related topics:
   and then enable the :option:`proxy mode <odoo-bin --proxy-mode>` option.
   See also :ref:`https_proxy`.
 
+- If you need to allow remote SSH access to your servers, make sure to set a strong password
+  for **all** accounts, not just `root`. It is strongly recommended to entirely disable
+  password-based authentication, and only allow public key authentication. Also consider
+  restricting access via a VPN, allowing only trusted IPs in the firewall, and/or
+  running a brute-force detection system such as `fail2ban` or equivalent.
+
 - Whenever possible, host your public-facing demo/test/staging instances on different
   machines than the production ones. And apply the same security precautions as for
   production.