Module for resource management.
===============================

A resource represent something that can be scheduled (a developer on a task or a
work center on manufacturing orders). This module manages a resource calendar
associated to every resource. It also manages the leaves of every resource.

This module adds a shortcut on one or several opportunity cases in the CRM.
===========================================================================

This shortcut allows you to generate a sales order based on the selected case.
If different cases are open (a list), it generates one sales order by case.
The case is then closed and linked to the generated sales order.

We suggest you to install this module, if you installed both the sale and the crm
modules.

This module provides facility to the user to install mrp and sales modulesat a time.
====================================================================================

It is basically used when we want to keep track of production orders generated
from sales order. It adds sales name and sales Reference on production order.

This module allows you to schedule your Sales Order based on the product configuration.

For products on which the "Plan Services" option is enabled, you will have the opportunity
to automatically plan the shifts for employees whom are able to take the shift
(i.e. employees who have the same role as the one configured on the product).

Plan shifts and keep an eye on the hours consumed on your plannable products.

Configure your products
Technical module installed when the user checks the "module_sale_product_configurator" setting.
The main purpose is to override the sale_order view to allow configuring products in the SO form.

It also enables the "optional products" feature.

Task Generation from Sales Orders
Allows to create task from your sales order
=============================================
This module allows to generate a project/task from sales orders.

This module allows you to schedule your Sales Order based on the product configuration.

For products on which the "Plan Services" option is enabled, you will have the opportunity
to automatically forecast the shifts for employees whom are able to take the shift
(i.e. employees who have the same role as the one configured on the product).

Forecast shifts and keep an eye on the hours consumed on your plannable products.

Sale based on service outsourcing.
Allows the outsourcing of services. This module allows one to sell services provided
by external providers and will automatically generate purchase orders directed to the service seller.

SO/PO relation in case of MTO
Add relation information between Sale Orders and Purchase Orders if Make to Order (MTO) is activated on one sold product.

This module adds a shortcut on one or several opportunity cases in the CRM.
===========================================================================

This shortcut allows you to generate a rental order based on the selected case.

Ease SMS integration with sales capabilities Ease SMS integration with sales capabilities

Quotation, Sales Orders, Delivery & Invoicing Control
Manage sales quotations and orders
==================================

This module makes the link between the sales and warehouses management applications.

Preferences
-----------
* Shipping: Choice of delivery at once or partial delivery
* Invoicing: choose how invoices will be paid
* Incoterms: International Commercial terms

Sell based on timesheets
Allows to sell timesheets in your sales order
=============================================

This module set the right product on all timesheet lines
according to the order/contract you work on. This allows to
have real delivered quantities in sales orders.

Configure timesheet invoicing
When invoicing timesheets, allows invoicing either all timesheets
linked to an SO, or only the validated timesheets

Bridge module between Sales Margin and Sales Timesheet
Allows to compute accurate margin for Service sales.
======================================================

Only view Created Contacts
This Module allows only the contacts created by the logged-in user to be seen. It applies to sales, Inventory, CRM, etc.
The group with administrator role can see all the contacts

move some configurations out of the database '======================================
server configuration environment files
======================================

.. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! This file is generated by oca-gen-addon-readme !!
!! changes will be overwritten. !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

.. |badge1| image:: https://img.shields.io/badge/maturity-Production/Stable-green.png
:target: https://mycbms.com/page/development-status
:alt: Production/Stable
.. |badge2| image:: https://img.shields.io/badge/licence-LGPL--3-blue.png
:target: http://www.gnu.org/licenses/lgpl-3.0-standalone.html
:alt: License: LGPL-3
.. |badge3| image:: https://img.shields.io/badge/github-OCA/server--env-lightgray.png?logo=github
:target: https://github.com/OCA/server-env/tree/15.0/server_environment
:alt: OCA/server-env
.. |badge4| image:: https://img.shields.io/badge/weblate-Translate me-F47D42.png
:target: https://translation.mycbms.com/projects/server-env-15-0/server-env-15-0-server_environment
:alt: Translate me on Weblate
.. |badge5| image:: https://img.shields.io/badge/runbot-Try me-875A7B.png
:target: https://runbot.mycbms.com/runbot/254/15.0
:alt: Try me on Runbot

|badge1| |badge2| |badge3| |badge4| |badge5|

This module provides a way to define an environment in the main CBMS
configuration file and to read some configurations from files
depending on the configured environment: you define the environment in
the main configuration file, and the values for the various possible
environments are stored in the ``server_environment_files`` companion
module.

The ``server_environment_files`` module is optional, the values can be set using
an environment variable with a fallback on default values in the database.

The configuration read from the files are visible under the Configuration
menu. If you are not in the 'dev' environment you will not be able to
see the values contained in the defined secret keys
(by default : '*passw*', '*key*', '*secret*' and '*token*').

**Table of contents**

.. contents::
:local:

Installation
============

By itself, this module does little. See for instance the
``mail_environment`` addon which depends on this one to allow configuring
the incoming and outgoing mail servers depending on the environment.

You can store your configuration values in a companion module called
``server_environment_files``. You can copy and customize the provided
``server_environment_files_sample`` module for this purpose. Alternatively, you
can provide them in environment variables ``SERVER_ENV_CONFIG`` and
``SERVER_ENV_CONFIG_SECRET``.

Configuration
=============

To configure this module, you need to edit the main configuration file
of your instance, and add a directive called ``running_env``. Commonly
used values are 'dev', 'test', 'production'::

[options]
running_env=dev

Values associated to keys containing 'passw' are only displayed in the 'dev'
environment.

If you don't provide any value, `test` is used as a safe default.

You have several possibilities to set configuration values:

server_environment_files
~~~~~~~~~~~~~~~~~~~~~~~~

You can edit the settings you need in the ``server_environment_files`` addon. The
``server_environment_files_sample`` can be used as an example:

* values common to all / most environments can be stored in the
``default/`` directory using the .ini file syntax;
* each environment you need to define is stored in its own directory
and can override or extend default values;
* you can override or extend values in the main configuration
file of your instance;

Environment variable
~~~~~~~~~~~~~~~~~~~~

You can define configuration in the environment variable ``SERVER_ENV_CONFIG``
and/or ``SERVER_ENV_CONFIG_SECRET``. The 2 variables are handled the exact same
way, this is only a convenience for the deployment where you can isolate the
secrets in a different, encrypted, file. They are multi-line environment variables
in the same configparser format than the files.
If you used options in ``server_environment_files``, the options set in the
environment variable override them.

The options in the environment variable are not dependent of ``running_env``,
the content of the variable must be set accordingly to the running environment.

Example of setup:

A public file, containing that will contain public variables::

# These variables are not CBMS ODOO standard variables,
# they are there to represent what your file could look like
export WORKERS='8'
export MAX_CRON_THREADS='1'
export LOG_LEVEL=info
export LOG_HANDLER=":INFO"
export DB_MAXCONN=5

# server environment options
export SERVER_ENV_CONFIG="
[storage_backend.my_sftp]
sftp_server=10.10.10.10
sftp_login=foo
sftp_port=22200
directory_path=CBMS
"

A second file which is encrypted and contains secrets::

# This variable is not an CBMS ODOO standard variable,
# it is there to represent what your file could look like
export DB_PASSWORD='xxxxxxxxx'
# server environment options
export SERVER_ENV_CONFIG_SECRET="
[storage_backend.my_sftp]
sftp_password=xxxxxxxxx
"

**WARNING**

`my_sftp` must match the name of the record.
If you want something more reliable use `server.env.techname.mixin`
and use `tech_name` field to reference records.
See "USAGE".


Default values
~~~~~~~~~~~~~~

When using the ``server.env.mixin`` mixin, for each env-computed field, a
companion field ``<field>_env_default`` is created. This field is not
environment-dependent. It's a fallback value used when no key is set in
configuration files / environment variable.

When the default field is used, the field is made editable on CBMS.

Note: empty environment keys always take precedence over default fields


Server environment integration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Read the documentation of the class `models/server_env_mixin.py
<models/server_env_mixin.py>`_.

Usage
=====

You can include a mixin in your model and configure the env-computed fields
by an override of ``_server_env_fields``.

::

class StorageBackend(models.Model):
_name = "storage.backend"
_inherit = ["storage.backend", "server.env.mixin"]

@property
def _server_env_fields(self):
return {"directory_path": {}}

Read the documentation of the class and methods in `models/server_env_mixin.py
<models/server_env_mixin.py>`__.


If you want to have a technical name to reference::

class StorageBackend(models.Model):
_name = "storage.backend"
_inherit = ["storage.backend", "server.env.techname.mixin", "server.env.mixin"]

[...]

Known issues / Roadmap
======================

* it is not possible to set the environment from the command line. A
configuration file must be used.
* the module does not allow to set low level attributes such as database server, etc.
* `server.env.techname.mixin`'s `tech_name` field could leverage the new option
for computable / writable fields and get rid of some onchange / read / write code.

Bug Tracker
===========

Bugs are tracked on `GitHub Issues <https://github.com/OCA/server-env/issues>`_.
In case of trouble, please check there if your issue has already been reported.
If you spotted it first, help us smashing it by providing a detailed and welcomed
`feedback <https://github.com/OCA/server-env/issues/new?body=module: server_environment
version: 15.0

**Steps to reproduce**
- ...

**Current behavior**

**Expected behavior**>`_.

Do not contact contributors directly about support or help with technical issues.

Credits
=======

Authors
~~~~~~~

* Camptocamp

Contributors
~~~~~~~~~~~~

* Florent Xicluna (Wingo) <florent.xicluna@gmail.com>
* Nicolas Bessi <nicolas.bessi@camptocamp.com>
* Alexandre Fayolle <alexandre.fayolle@camptocamp.com>
* Daniel Reis <dgreis@sapo.pt>
* Holger Brunn <hbrunn@therp.nl>
* Leonardo Pistone <leonardo.pistone@camptocamp.com>
* Adrien Peiffer <adrien.peiffer@acsone.com>
* Thierry Ducrest <thierry.ducrest@camptocamp.com>
* Guewen Baconnier <guewen.baconnier@camptocamp.com>
* Thomas Binfeld <thomas.binsfeld@acsone.eu>
* Stéphane Bidoul <stefane.bidoul@acsone.com>
* Simone Orsi <simahawk@gmail.com>

Maintainers
~~~~~~~~~~~

This module is maintained by the OCA.

.. image:: https://mycbms.com/logo.png
:alt: CBMS Community Association
:target: https://mycbms.com

OCA, or the CBMS Community Association, is a nonprofit organization whose
mission is to support the collaborative development of CBMS features and
promote its widespread use.

This module is part of the `OCA/server-env <https://github.com/OCA/server-env/tree/15.0/server_environment>`_ project on GitHub.

You are welcome to contribute. To learn how please visit https://mycbms.com/page/Contribute.

SMS Text Messaging
This module gives a framework for SMS text messaging
----------------------------------------------------

The service is provided by the In App Purchase CBMS ODOO platform.

Allows users to send documents by post
=====================================================