[MERGE] Forward-port of branch 13.0 to 14.0
This commit is contained in:
Antoine Vandevenne (anv)
@@ -0,0 +1,12 @@
|
||||
|
||||
=================
|
||||
Advanced
|
||||
=================
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
advanced/containers
|
||||
advanced/submodules
|
||||
advanced/upgrade_your_database
|
||||
advanced/frequent_technical_questions
|
||||
@@ -0,0 +1,237 @@
|
||||
|
||||
==================================
|
||||
Containers
|
||||
==================================
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
Each build is isolated within its own container (Linux namespaced container).
|
||||
|
||||
The base is an Ubuntu system, where all of Odoo's required dependencies,
|
||||
as well as common useful packages, are installed.
|
||||
|
||||
If your project requires additional Python dependencies, or more recent releases,
|
||||
you can define a :file:`requirements.txt` file in the root of your branches listing them.
|
||||
The platform will take care to install these dependencies in your containers.
|
||||
`The pip requirements specifiers <https://pip.pypa.io/en/stable/reference/pip_install/#requirement-specifiers>`_
|
||||
documentation can help you write a :file:`requirements.txt` file.
|
||||
To have a concrete example,
|
||||
check out the `requirements.txt file of Odoo <https://github.com/odoo/odoo/blob/14.0/requirements.txt>`_.
|
||||
|
||||
The :file:`requirements.txt` files of submodules are taken into account as well. The platform
|
||||
looks for :file:`requirements.txt` files in each folder containing Odoo modules: Not in the module folder itself,
|
||||
but in their parent folder.
|
||||
|
||||
Directory structure
|
||||
===================
|
||||
|
||||
As the containers are Ubuntu based, their directory structure follows the linux Filesystem Hierarchy Standard.
|
||||
`Ubuntu's filesystem tree overview <https://help.ubuntu.com/community/LinuxFilesystemTreeOverview#Main_directories>`_
|
||||
explains the main directories.
|
||||
|
||||
Here are the Odoo.sh pertinent directories:
|
||||
|
||||
::
|
||||
|
||||
.
|
||||
├── home
|
||||
│ └── odoo
|
||||
│ ├── src
|
||||
│ │ ├── odoo Odoo Community source code
|
||||
│ │ │ └── odoo-bin Odoo server executable
|
||||
│ │ ├── enterprise Odoo Enterprise source code
|
||||
│ │ ├── themes Odoo Themes source code
|
||||
│ │ └── user Your repository branch source code
|
||||
│ ├── data
|
||||
│ │ ├── filestore database attachments, as well as the files of binary fields
|
||||
│ │ └── sessions visitors and users sessions
|
||||
│ └── logs
|
||||
│ ├── install.log Database installation logs
|
||||
│ ├── odoo.log Running server logs
|
||||
│ ├── update.log Database updates logs
|
||||
│ └── pip.log Python packages installation logs
|
||||
└── usr
|
||||
├── lib
|
||||
│ ├── python2.7
|
||||
│ └── dist-packages Python 2.7 standard libraries
|
||||
│ ├── python3
|
||||
│ └── dist-packages Python 3 standard libraries
|
||||
│ └── python3.5
|
||||
│ └── dist-packages Python 3.5 standard libraries
|
||||
├── local
|
||||
│ └── lib
|
||||
│ ├── python2.7
|
||||
│ │ └── dist-packages Python 2.7 third-party libraries
|
||||
│ └── python3.5
|
||||
│ └── dist-packages Python 3.5 third-party libraries
|
||||
└── usr
|
||||
└── bin
|
||||
├── python2.7 Python 2.7 executable
|
||||
└── python3.5 Python 3.5 executable
|
||||
|
||||
Both Python 2.7 and 3.5 are installed in the containers. However:
|
||||
|
||||
* If your project is configured to use Odoo 10.0, the Odoo server runs with Python 2.7.
|
||||
* If your project is configured to use Odoo 11.0 or above, the Odoo server runs with Python 3.5.
|
||||
|
||||
Database shell
|
||||
==============
|
||||
|
||||
While accessing a container with the shell, you can access the database using *psql*.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
odoo@odoo-addons-master-1.odoo.sh:~$ psql
|
||||
psql (9.5.2, server 9.5.11)
|
||||
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
|
||||
Type "help" for help.
|
||||
|
||||
odoo-addons-master-1=>
|
||||
|
||||
**Be careful !**
|
||||
`Use transactions <https://www.postgresql.org/docs/current/static/sql-begin.html>`_ (*BEGIN...COMMIT/ROLLBACK*)
|
||||
for every *sql* statements leading to changes
|
||||
(*UPDATE*, *DELETE*, *ALTER*, ...), especially for your production database.
|
||||
|
||||
The transaction mechanism is your safety net in case of mistake.
|
||||
You simply have to rollback your changes to revert your database to its previous state.
|
||||
|
||||
For example, it may happen that you forget to set your *WHERE* condition.
|
||||
|
||||
.. code-block:: sql
|
||||
|
||||
odoo-addons-master-1=> BEGIN;
|
||||
BEGIN
|
||||
odoo-addons-master-1=> UPDATE res_users SET password = '***';
|
||||
UPDATE 457
|
||||
odoo-addons-master-1=> ROLLBACK;
|
||||
ROLLBACK
|
||||
|
||||
In such a case, you can rollback to revert the unwanted changes that you just mistakenly did, and rewrite the statement:
|
||||
|
||||
.. code-block:: sql
|
||||
|
||||
odoo-addons-master-1=> BEGIN;
|
||||
BEGIN
|
||||
odoo-addons-master-1=> UPDATE res_users SET password = '***' WHERE id = 1;
|
||||
UPDATE 1
|
||||
odoo-addons-master-1=> COMMIT;
|
||||
COMMIT
|
||||
|
||||
However, do not forget to either commit or rollback your transaction after having done it.
|
||||
Open transactions may lock records in your tables
|
||||
and your running database may wait for them to be released. It can cause a server to hang indefinitely.
|
||||
|
||||
In addition, when possible, use your staging databases to test your statements first. It gives you an extra safety net.
|
||||
|
||||
Run an Odoo server
|
||||
==================
|
||||
|
||||
You can start an Odoo server instance from a container shell. You won't be able to access it from the outside world
|
||||
with a browser, but you can for instance:
|
||||
|
||||
* use the Odoo shell,
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ odoo-bin shell
|
||||
>>> partner = env['res.partner'].search([('email', '=', 'asusteK@yourcompany.example.com')], limit=1)
|
||||
>>> partner.name
|
||||
'ASUSTeK'
|
||||
>>> partner.name = 'Odoo'
|
||||
>>> env['res.partner'].search([('email', '=', 'asusteK@yourcompany.example.com')], limit=1).name
|
||||
'Odoo'
|
||||
|
||||
* install a module,
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ odoo-bin -i sale --without-demo=all --stop-after-init
|
||||
|
||||
* update a module,
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ odoo-bin -u sale --stop-after-init
|
||||
|
||||
* run the tests for a module,
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ odoo-bin -i sale --test-enable --log-level=test --stop-after-init
|
||||
|
||||
In the above commands, the argument:
|
||||
|
||||
* ``--without-demo=all`` prevents demo data to be loaded for all modules
|
||||
* ``--stop-after-init`` will immediately shutdown the server instance after it completed the operations you asked.
|
||||
|
||||
More options are available and detailed in the
|
||||
`CLI documentation <https://www.odoo.com/documentation/14.0/reference/cmdline.html>`_.
|
||||
|
||||
You can find in the logs (*~/logs/odoo.log*) the addons path used by Odoo.sh to run your server.
|
||||
Look for "*odoo: addons paths*":
|
||||
|
||||
::
|
||||
|
||||
2018-02-19 10:51:39,267 4 INFO ? odoo: Odoo version 13.0
|
||||
2018-02-19 10:51:39,268 4 INFO ? odoo: Using configuration file at /home/odoo/.config/odoo/odoo.conf
|
||||
2018-02-19 10:51:39,268 4 INFO ? odoo: addons paths: ['/home/odoo/data/addons/13.0', '/home/odoo/src/user', '/home/odoo/src/enterprise', '/home/odoo/src/themes', '/home/odoo/src/odoo/addons', '/home/odoo/src/odoo/odoo/addons']
|
||||
|
||||
**Be careful**, especially with your production database.
|
||||
Operations that you perform running this Odoo server instance are not isolated:
|
||||
Changes will be effective in the database. Always, make your tests in your staging databases.
|
||||
|
||||
Debugging in Odoo.sh
|
||||
====================
|
||||
|
||||
Debugging an Odoo.sh build is not really different than another Python app. This article only explains the specificities and limitations of the Odoo.sh platform, and assumes that you already know how to use a debugger.
|
||||
|
||||
.. note:: If you don't know how to debug a Python application yet, there are multiple introductory courses that can be easily found on the Internet.
|
||||
|
||||
You can use ``pdb``, ``pudb`` or ``ipdb`` to debug your code on Odoo.sh.
|
||||
As the server is run outside a shell, you cannot launch the debugger directly from your Odoo instance backend as the debugger needs a shell to operate.
|
||||
|
||||
- `pdb <https://docs.python.org/3/library/pdb.html>`_ is installed by default in every container.
|
||||
|
||||
- If you want to use `pudb <https://pypi.org/project/pudb/>`_ or `ipdb <https://pypi.org/project/ipdb/>`_ you have to install it before.
|
||||
|
||||
To do so, you have two options:
|
||||
|
||||
- temporary (only in the current build):
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ pip install pudb --user
|
||||
|
||||
or
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ pip install ipdb --user
|
||||
|
||||
- permanent: add ``pudb`` or ``ipdb`` to your project ``requirements.txt`` file.
|
||||
|
||||
|
||||
Then edit the code where you want to trigger the debugger and add this:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
import sys
|
||||
if sys.__stdin__.isatty():
|
||||
import pdb; pdb.set_trace()
|
||||
|
||||
The condition :code:`sys.__stdin__.isatty()` is a hack that detects if you run Odoo from a shell.
|
||||
|
||||
Save the file and then run the Odoo Shell:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ odoo-bin shell
|
||||
|
||||
Finally, *via* the Odoo Shell, you can trigger the piece of code/function/method
|
||||
you want to debug.
|
||||
|
||||
.. image:: ./media/pdb_sh.png
|
||||
:align: center
|
||||
:alt: Console screenshot showing ``pdb`` running in an Odoo.sh shell.
|
||||
@@ -0,0 +1,32 @@
|
||||
|
||||
.. _odoosh-advanced-frequent_technical_questions:
|
||||
|
||||
==================================
|
||||
Frequent Technical Questions
|
||||
==================================
|
||||
|
||||
"Scheduled actions do not run at the exact time they were expected"
|
||||
-------------------------------------------------------------------
|
||||
|
||||
On the Odoo.sh platform, we cannot guarantee an exact running time for scheduled actions.
|
||||
|
||||
This is due to the fact that there might be multiple customers on the same server, and we must guarantee a fair share of the server for every customer. Scheduled actions are therefore implemented slightly differently than on a regular Odoo server, and are run on a *best effort* policy.
|
||||
|
||||
.. warning::
|
||||
Do not expect any scheduled action to be run more often than every 5 min.
|
||||
|
||||
Are there "best practices" regarding scheduled actions?
|
||||
-------------------------------------------------------
|
||||
|
||||
**Odoo.sh always limits the execution time of scheduled actions (*aka* crons).**
|
||||
Therefore, you must keep this fact in mind when developing your own crons.
|
||||
|
||||
We advise that:
|
||||
|
||||
- Your scheduled actions should work on small batches of records.
|
||||
- Your scheduled actions should commit their work after processing each batch;
|
||||
this way, if they get interrupted by the time-limit, there is no need to start over.
|
||||
- Your scheduled actions should be
|
||||
`idempotent <https://stackoverflow.com/a/1077421/3332416>`_: they must not
|
||||
cause side-effects if they are started more often than expected.
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 6.1 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
@@ -0,0 +1,111 @@
|
||||
|
||||
.. _odoosh-advanced-submodules:
|
||||
|
||||
==================================
|
||||
Submodules
|
||||
==================================
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
A `Git submodule <https://git-scm.com/book/en/v2/Git-Tools-Submodules>`_ allows you to integrate other Git projects
|
||||
into your code, without the need to copy-paste all their code.
|
||||
|
||||
Indeed, your custom modules can depend on modules from other repositories.
|
||||
Regarding Odoo, this feature allows you to add modules from other Git repositories into the branches of your repository.
|
||||
Adding these dependencies in your branch through submodules makes the deployment of your code and servers easier,
|
||||
as you can clone the repositories added as submodules at the same time you clone your own repository.
|
||||
|
||||
Besides, you can choose the branch of the repository added as submodule
|
||||
and you have the control of the revision you want.
|
||||
It's up to you to decide whether you want to pin the submodule to a specific revision and when you want to update
|
||||
to a newer revision.
|
||||
|
||||
In Odoo.sh, the submodules give you the possibility to use and depend on modules available in other repositories.
|
||||
The platform will detect that you added modules through submodules in your branches
|
||||
and add them to your addons path automatically so you can install them in your databases.
|
||||
|
||||
If you add private repositories as submodules in your branches,
|
||||
you need to configure a deploy key in your Odoo.sh project settings and in your repository settings.
|
||||
Otherwise Odoo.sh won't be allowed to download them.
|
||||
The procedure is detailed in the chapter :ref:`Settings > Submodules <odoosh-gettingstarted-settings-submodules>`.
|
||||
|
||||
Adding a submodule
|
||||
==================
|
||||
|
||||
With Odoo.sh (simple)
|
||||
---------------------
|
||||
|
||||
.. warning::
|
||||
For now it is not possible to add **private** repositories with this method. You can nevertheless
|
||||
do so :ref:`with Git <odoosh-advanced-submodules-withgit>`.
|
||||
|
||||
On Odoo.sh, in the branches view of your project, choose the branch in which you want to add a submodule.
|
||||
|
||||
In the upper right corner, click on the *Submodule* button, and then on *Run*.
|
||||
|
||||
.. image:: ./media/advanced-submodules-button.png
|
||||
:align: center
|
||||
|
||||
A dialog with a form is shown. Fill the inputs as follows:
|
||||
|
||||
* Repository URL: The SSH URL of the repository.
|
||||
* Branch: The branch you want to use.
|
||||
* Path: The folder in which you want to add this submodule in your branch.
|
||||
|
||||
.. image:: ./media/advanced-submodules-dialog.png
|
||||
:align: center
|
||||
|
||||
On Github, you can get the repository URL with the *Clone or download* button of the repository. Make sure to *use SSH*.
|
||||
|
||||
.. image:: ./media/advanced-submodules-github-sshurl.png
|
||||
:align: center
|
||||
|
||||
.. _odoosh-advanced-submodules-withgit:
|
||||
|
||||
With Git (advanced)
|
||||
---------------------
|
||||
|
||||
In a terminal, in the folder where your Git repository is cloned,
|
||||
checkout the branch in which you want to add a submodule:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git checkout <branch>
|
||||
|
||||
Then, add the submodule using the command below:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git submodule add -b <branch> <git@yourprovider.com>:<username/repository.git> <path>
|
||||
|
||||
Replace
|
||||
|
||||
* *<git@yourprovider.com>:<username/repository.git>* by the SSH URL of the repository you want to add as submodule,
|
||||
* *<branch>* by the branch you want to use in the above repository,
|
||||
* *<path>* by the folder in which you want to add this submodule.
|
||||
|
||||
Commit and push your changes:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git commit -a && git push -u <remote> <branch>
|
||||
|
||||
Replace
|
||||
|
||||
* <remote> by the repository on which you want to push your changes. For a standard Git setup, this is *origin*.
|
||||
* <branch> by the branch on which you want to push your changes.
|
||||
Most likely the branch you used :code:`git checkout` on in the first step.
|
||||
|
||||
You can read the `git-scm.com documentation <https://git-scm.com/book/en/v2/Git-Tools-Submodules>`_
|
||||
for more details about the Git submodules.
|
||||
For instance, if you would like to update your submodules to have their latest revision,
|
||||
you can follow the chapter
|
||||
`Pulling in Upstream changes <https://git-scm.com/book/en/v2/Git-Tools-Submodules#_pulling_in_upstream_changes_from_the_submodule_remote>`_.
|
||||
|
||||
Ignore modules
|
||||
==============
|
||||
|
||||
If you're adding a repository that contains a lot of modules, you may want to ignore some of them in case there are any
|
||||
that are installed automatically. To do so, you can prefix your submodule folder with a :code:`.`. The platform will
|
||||
ignore this folder and you can hand pick your modules by creating symlinks to them from another folder.
|
||||
@@ -0,0 +1,48 @@
|
||||
|
||||
=====================
|
||||
Upgrade your database
|
||||
=====================
|
||||
|
||||
.. _odoosh-advanced-upgrade_your_database:
|
||||
|
||||
Download and Upload your database
|
||||
=================================
|
||||
|
||||
Download a dump of your database (from the :ref:`Builds view <odoosh-gettingstarted-builds-download-dump>`), choose the
|
||||
exact copy and without filestore options. Upload the .sql.gz dump on https://upgrade.odoo.com/upload and
|
||||
select the Testing Purpose. If you have custom code, you can choose to have it upgraded by us, or do it yourself. Once
|
||||
it's processed, you'll get a dump of the database in return.
|
||||
|
||||
.. warning::
|
||||
Do *not* upload *backups* of your production database (found in the Backups tab of the production branch) as these
|
||||
are incompatible with the Upgrade platform - they contain your complete sources, etc. that are not needed for the
|
||||
upgrade. Make sure to download a **Dump** instead - either through the Backups tab using the *Download Dump* button
|
||||
or through the Builds page by using the *Download Dump* entry of the contextual menu of your latest production build.
|
||||
|
||||
Test your upgraded database
|
||||
===========================
|
||||
|
||||
Create a staging branch that will run the upgraded database. Either make sure your production branch's code is
|
||||
compatible between the two Odoo versions and fork your production branch, or make a new staging branch containing
|
||||
the upgraded code.
|
||||
|
||||
Once the staging build is done (it doesn't matter if it failed due to the version incompatibility), import your
|
||||
upgraded dump in the backups tab of the branch. The platform will automatically detect the version of the dump and
|
||||
change the version of Odoo's source code to the corresponding version for the build.
|
||||
|
||||
Test the upgraded database and make sure everything runs as it's supposed to.
|
||||
|
||||
Replace your existing production database
|
||||
=========================================
|
||||
|
||||
Once you've tested everything and you're satisfied, start the process over to get an up-to-date upgraded dump:
|
||||
|
||||
* Make a new dump of your production database (as described in step 1)
|
||||
* Upload it on upgrade.odoo.com and select the Production purpose
|
||||
* Receive the newly upgraded dump and import it in your production branch. The build might get marked as failed because
|
||||
the platform will run it with the upgraded databases' Odoo version together with the old custom code.
|
||||
* Merge or commit the upgraded custom code in the production branch
|
||||
|
||||
If anything goes wrong, remember you can restore a backup. The platform will always make one before you make any
|
||||
Odoo.sh operation on the production database. If the restored backup comes from a previous version, the platform will
|
||||
detect it and change the project's Odoo version back if it needs to.
|
||||
@@ -0,0 +1,15 @@
|
||||
|
||||
=================
|
||||
Get started
|
||||
=================
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
getting_started/create
|
||||
getting_started/branches
|
||||
getting_started/builds
|
||||
getting_started/status
|
||||
getting_started/settings
|
||||
getting_started/online-editor
|
||||
getting_started/first_module
|
||||
@@ -0,0 +1,538 @@
|
||||
|
||||
==================================
|
||||
Branches
|
||||
==================================
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
The branches view gives you an overview of the different branches your repository has.
|
||||
|
||||
.. image:: ./media/interface-branches.png
|
||||
:align: center
|
||||
|
||||
.. _odoosh-gettingstarted-branches-stages:
|
||||
|
||||
Stages
|
||||
===============
|
||||
|
||||
Odoo.sh offers three different stages for your branches: production, staging and development.
|
||||
|
||||
You can change the stage of a branch by drag and dropping it into the stage section title.
|
||||
|
||||
.. image:: ./media/interface-branches-stagechange.png
|
||||
:align: center
|
||||
|
||||
.. _stage_production:
|
||||
|
||||
Production
|
||||
----------
|
||||
This is the branch holding the code on which your production database runs.
|
||||
There can be only one production branch.
|
||||
|
||||
When you push a new commit in this branch,
|
||||
your production server is updated with the code of the new revision and is then restarted.
|
||||
|
||||
If your changes require the update of a module, such as a change in a form view,
|
||||
and you want it to be performed automatically,
|
||||
increase the version number of the module in its manifest (*__manifest__.py*).
|
||||
The platform will then take care to perform the update during which the
|
||||
instance will be held temporarily unavailable for maintenance reason.
|
||||
|
||||
|
||||
This method is equivalent to perform an upgrade of the module through the Apps menu,
|
||||
or through the :code:`-u` switch of
|
||||
`the command line <https://www.odoo.com/documentation/14.0/reference/cmdline.html>`_.
|
||||
|
||||
In the case the changes in the commit prevent the server to restart,
|
||||
or if the modules update fails,
|
||||
the server is automatically reverted to the previous successful code revision and
|
||||
the database is roll-backed as it was before the update.
|
||||
You still have access to the log of the failed update, so you can troubleshoot it.
|
||||
|
||||
The demo data is not loaded, as it is not meant to be used in a production database.
|
||||
The unit tests are not performed, as it would increase the unavailability time of the production
|
||||
database during the updates.
|
||||
|
||||
Partners using trial projects should be aware their production branch, along with all the staging branches,
|
||||
will automatically be set back to the development stage after 30 days.
|
||||
|
||||
Staging
|
||||
-------
|
||||
Staging branches are meant to test your new features using the production data without compromising
|
||||
the actual production database with test records. They will create databases that are neutralized
|
||||
duplicates of the production database.
|
||||
|
||||
The neutralization includes:
|
||||
|
||||
* Disabling scheduled actions. If you want to test them, you can trigger their action manually or
|
||||
re-enable them. Be aware that the platform will trigger them less often if no one is using the
|
||||
database in order to save up resources.
|
||||
* Disabling outgoing emails by intercepting them with a mailcatcher. An
|
||||
:ref:`interface to view <odoosh-gettingstarted-branches-tabs-mails>` the emails sent by your
|
||||
database is provided. That way, you do not have to worry about sending test emails to your contacts.
|
||||
* Setting payment acquirers and shipping providers in test mode.
|
||||
* Disabling IAP services
|
||||
|
||||
The latest database will be kept alive indefinitely, older ones from the same branch may get garbage collected
|
||||
to make room for new ones. It will be valid for 3 months, after which you will be expected to rebuild the branch.
|
||||
If you make configuration or view changes in these databases, make sure to document them or write them directly
|
||||
in the modules of the branch, using XML data files overriding the default configuration or views.
|
||||
|
||||
The unit tests are not performed as, in Odoo, they currently rely on the demo data, which is not loaded in the
|
||||
production database. In the future, if Odoo supports to run the unit tests without the demo data,
|
||||
Odoo.sh will then consider running the tests on staging databases.
|
||||
|
||||
|
||||
Development
|
||||
-----------
|
||||
Development branches create new databases using the demo data to run the unit tests.
|
||||
The installed modules are the ones included in your branches. You can change this list of modules
|
||||
to install in your :ref:`project Settings <odoosh-gettingstarted-settings-modules-installation>`.
|
||||
|
||||
When you push a new commit in one of these branches,
|
||||
a new server is started, with a database created from scratch and the new revision of the branch.
|
||||
The demo data is loaded, and the unit tests are performed by default.
|
||||
This verifies your changes do not break any of the features tested by them. If you wish, you can
|
||||
disable the tests or allow specific tests to be run with custom tags in the :ref:`branch's settings
|
||||
<odoosh-gettingstarted-branches-tabs-settings>`.
|
||||
|
||||
Similar to staging branches, the emails are not sent but are intercepted by a mailcatcher and
|
||||
scheduled actions are not triggered as often is the database is not in use.
|
||||
|
||||
The databases created for development branches are meant to live around three days.
|
||||
After that, they can be automatically garbage collected to make room for new databases without prior notice.
|
||||
|
||||
.. _odoosh-gettingstarted-branches-mergingbranches:
|
||||
|
||||
Merging your branches
|
||||
---------------------
|
||||
You can merge your branches easily by drag and dropping them into each other.
|
||||
|
||||
.. image:: ./media/interface-branches-merge.png
|
||||
:align: center
|
||||
|
||||
When you want to test the changes of your development branches with the production data,
|
||||
you can either:
|
||||
|
||||
* merge the development branch into your staging branch, by drag and dropping it onto the desired staging branch,
|
||||
* drag and dropping the development branch on the staging section title, to make it become a staging branch.
|
||||
|
||||
When your latest changes are ready for production,
|
||||
you can drag and drop your staging branch onto your production branch
|
||||
to merge and deploy in production your newest features.
|
||||
|
||||
If you are bold enough,
|
||||
you can merge your development branches into your production branch as well.
|
||||
It just means you skip the validation of your changes with the production data through a staging branch.
|
||||
|
||||
You can merge your development branches into each other, and your staging branches into each other.
|
||||
|
||||
Of course, you can also use :code:`git merge` directly on your workstation to merge your branches.
|
||||
Odoo.sh will be notified when new revisions have been pushed in your branches.
|
||||
|
||||
Merging a staging branch in the production branch only merges the source code: Any configuration changes you made in the
|
||||
staging databases are not passed to the production database.
|
||||
|
||||
If you test configuration changes in staging branches, and want them to be applied in the production, you have to either:
|
||||
|
||||
* write the configuration changes in XML data files
|
||||
overriding the default configuration or views in your branches,
|
||||
and then increase the version of your module in its manifest (*__manifest__.py*) to trigger the update of the module
|
||||
when you merge your staging branch in your production branch.
|
||||
This is the best practice for a better scalability of your developments as you will use the Git versioning features
|
||||
for all your configuration changes, and therefore have a traceability for your changes.
|
||||
* pass them manually from your staging to your production database, by copy/pasting them.
|
||||
|
||||
.. _odoosh-gettingstarted-branches-tabs:
|
||||
|
||||
Tabs
|
||||
=============
|
||||
|
||||
History
|
||||
-------
|
||||
An overview of your branch history:
|
||||
|
||||
* The messages of the commits and their authors,
|
||||
* The various events linked to the platform, such as stage changes, database imports, backup restores.
|
||||
|
||||
.. image:: ./media/interface-branches-history.png
|
||||
:align: center
|
||||
|
||||
For each event, a status is displayed in the top right-hand corner.
|
||||
It can provide information about the ongoing operation on the database (installation, update, backup import, ...),
|
||||
or its result (tests feedback, successful backup import, ...).
|
||||
When an operation is successful, you can access the database thanks to the *connect* button.
|
||||
|
||||
.. _odoosh-gettingstarted-branches-tabs-mails:
|
||||
|
||||
Mails
|
||||
-----
|
||||
This tab contains the mail catcher. It displays an overview of the emails sent by your database.
|
||||
The mail catcher is available for your development and
|
||||
staging branches as the emails of your production database are really sent instead of being intercepted.
|
||||
|
||||
.. image:: ./media/interface-branches-mails.png
|
||||
:align: center
|
||||
:scale: 50%
|
||||
|
||||
Shell
|
||||
-----
|
||||
A shell access to your container. You can perform basic linux commands (:code:`ls`, :code:`top`)
|
||||
and open a shell on your database by typing :code:`psql`.
|
||||
|
||||
.. image:: ./media/interface-branches-shell.png
|
||||
:align: center
|
||||
|
||||
You can open multiple tabs and drag-and-drop them to arrange the layout as you wish,
|
||||
for instance side by side.
|
||||
|
||||
|
||||
.. Note::
|
||||
Long running shell instances are not guaranteed. Idle shells can be
|
||||
disconnected at anytime in order to free up resources.
|
||||
|
||||
Editor
|
||||
------
|
||||
An online integrated development environment (IDE) to edit the source code.
|
||||
You can also open terminals, Python consoles and even Odoo Shell consoles.
|
||||
|
||||
.. image:: ./media/interface-branches-editor.png
|
||||
:align: center
|
||||
|
||||
You can open multiple tabs and drag-and-drop them to arrange the layout as you wish,
|
||||
for instance side by side.
|
||||
|
||||
Monitoring
|
||||
----------
|
||||
This link contains various monitoring metrics of the current build.
|
||||
|
||||
.. image:: ./media/interface-branches-monitoring.png
|
||||
:align: center
|
||||
|
||||
You can zoom, change the time range or select a specific metric on each graph.
|
||||
On the graphs, annotations help you relate to changes on the build (database import, git push, etc...).
|
||||
|
||||
Logs
|
||||
----
|
||||
A viewer to have a look to your server logs.
|
||||
|
||||
.. image:: ./media/interface-branches-logs.png
|
||||
:align: center
|
||||
|
||||
Different logs are available:
|
||||
|
||||
* install.log: The logs of the database installation. In a development branch, the logs of the tests are included.
|
||||
* pip.log: The logs of the Python dependencies installation.
|
||||
* odoo.log: The logs of the running server.
|
||||
* update.log: The logs of the database updates.
|
||||
* pg_long_queries.log: The logs of psql queries that take an unusual amount of time.
|
||||
|
||||
If new lines are added in the logs, they will be displayed automatically.
|
||||
If you scroll to the bottom, the browser will scroll automatically each time a new line is added.
|
||||
|
||||
You can pause the logs fetching by clicking on the according button in the upper right corner of the view.
|
||||
The fetching is automatically stopped after 5 minutes. You can restart it using the play button.
|
||||
|
||||
.. _odoo_sh_branches_backups:
|
||||
|
||||
Backups
|
||||
-------
|
||||
A list of the backups available for download and restore, the ability to perform a manual backup and to import a
|
||||
database.
|
||||
|
||||
.. image:: ./media/interface-branches-backups.png
|
||||
:align: center
|
||||
|
||||
Odoo.sh makes daily backups of the production database. It keeps 7 daily, 4 weekly and 3 monthly backups.
|
||||
Each backup includes the database dump, the filestore (attachments, binary fields), logs and sessions.
|
||||
|
||||
Staging and development databases are not backed up.
|
||||
You nevertheless have the possibility to restore a backup of the production database in your staging branches, for
|
||||
testing purposes, or to manually recover data that has been deleted by accident from the production database.
|
||||
|
||||
The list contains the backups kept on the server your production database is hosted on.
|
||||
This server only keeps one month of backups: 7 daily and 4 weekly backups.
|
||||
|
||||
Dedicated backup servers keep the same backups, as well as 3 additional monthly backups.
|
||||
To restore or download one of these monthly backups, please `contact us <https://www.odoo.com/help>`_.
|
||||
|
||||
If you merge a commit updating the version of one or several modules (in :file:`__manifest__.py`), or their linked python
|
||||
dependencies (in :file:`requirements.txt`), then Odoo.sh performs a backup automatically (flagged with type Update in the list),
|
||||
as either the container will be changed by the installation of new pip packages, either the database itself will be
|
||||
changed with the module update triggered afterwards. In these two cases, we are doing a backup as it may potentially
|
||||
break things.
|
||||
|
||||
If you merge a commit that only changes some code without the above-mentioned modifications, then no backup is done
|
||||
by Odoo.sh, as neither the container nor the database is modified so the platform considers this safe enough. Of course,
|
||||
as an extra precaution, you can make a backup manually before making big changes in your production sources in case
|
||||
something goes wrong (those manual backups are available for about one week). To avoid abuse, we limit manual backups
|
||||
to 5 per day.
|
||||
|
||||
The *import database* feature accepts database archives in the format provided by:
|
||||
|
||||
* the standard Odoo databases manager,
|
||||
(available for on-premise Odoo servers under :code:`/web/database/manager`)
|
||||
* the Odoo online databases manager,
|
||||
* the Odoo.sh backup download button of this *Backups* tab,
|
||||
* the Odoo.sh dump download button in the :ref:`Builds view <odoosh-gettingstarted-builds>`.
|
||||
|
||||
.. _odoosh-gettingstarted-branches-tabs-settings:
|
||||
|
||||
Settings
|
||||
--------
|
||||
Here you can find a couple of settings that only apply to the currently selected branch.
|
||||
|
||||
.. image:: ./media/interface-branches-settings.jpg
|
||||
:align: center
|
||||
|
||||
**Behaviour upon new commit**
|
||||
|
||||
For development and staging branches, you can change the branch's behavior upon receiving a new
|
||||
commit. By default, a development branch will create a new build and a staging branch will update
|
||||
the previous build (see the :ref:`Production Stage <stage_production>`). This is especially useful
|
||||
should the feature you're working on require a particular setup or configuration, to avoid having
|
||||
to manually set it up again on every commit. If you choose new build for a staging branch, it will
|
||||
make a fresh copy from the production build every time a commit is pushed. A branch that is put
|
||||
back from staging to development will automatically be set to 'Do nothing'.
|
||||
|
||||
**Modules installation**
|
||||
|
||||
Choose the modules to install automatically for your development builds.
|
||||
|
||||
.. image:: ./media/interface-settings-modulesinstallation.png
|
||||
:align: center
|
||||
|
||||
* *Install only my modules* will install the modules of the branch only. This is the default option.
|
||||
The :ref:`submodules <odoosh-advanced-submodules>` are excluded.
|
||||
* *Full installation (all modules)* will install the modules of the branch, the modules included in the submodules
|
||||
and all standard modules of Odoo. When running the full installation, the test suite is disabled.
|
||||
* *Install a list of modules* will install the modules specified in the input just below this option.
|
||||
The names are the technical name of the modules, and they must be comma-separated.
|
||||
|
||||
If the tests are enabled, the standard Odoo modules suite can take up to 1 hour.
|
||||
This setting applies to development builds only.
|
||||
Staging builds duplicate the production build and the production build only installs base.
|
||||
|
||||
|
||||
**Test suite**
|
||||
|
||||
For development branches, you can choose to enable or disable the test suite. It's enabled by default.
|
||||
When the test suite is enabled, you can restrict them by specifying test tags `test tags
|
||||
<https://www.odoo.com/documentation/12.0/reference/testing.html#test-selection>`_.
|
||||
|
||||
**Odoo Version**
|
||||
|
||||
For development branches only, you can change the version of Odoo, should you want to test upgraded code or develop
|
||||
features while your production database is in the process of being upgraded to a newer version.
|
||||
|
||||
In addition, for each version you have two options regarding the code update.
|
||||
|
||||
* You can choose to benefit from the latest bug, security and performance fixes automatically. The
|
||||
sources of your Odoo server will be updated weekly. This is the 'Latest' option.
|
||||
* You can choose to pin the Odoo sources to a specific revision by selecting them from a list of
|
||||
dates. Revisions will expire after 3 months. You will be notified by mail when the expiration
|
||||
date approaches and if you don't take action afterwards, you will automatically be set to the
|
||||
latest revision.
|
||||
|
||||
**Custom domains**
|
||||
|
||||
Here you can configure additional domains for the selected branch. It's possible to add other
|
||||
*<name>.odoo.com* domains or your own custom domains. For the latter you have to:
|
||||
|
||||
* own or purchase the domain name,
|
||||
* add the domain name in this list,
|
||||
* in your registrar's domain name manager,
|
||||
configure the domain name with a ``CNAME`` record set to your production database domain name.
|
||||
|
||||
For instance, to associate *www.mycompany.com* to your database *mycompany.odoo.com*:
|
||||
|
||||
* in Odoo.sh, add *www.mycompany.com* in the custom domains of your project settings,
|
||||
* in your domain name manager (e.g. *godaddy.com*, *gandi.net*, *ovh.com*),
|
||||
configure *www.mycompany.com* with a ``CNAME`` record with as value *mycompany.odoo.com*.
|
||||
|
||||
Bare domains (e.g. *mycompany.com*) are not accepted:
|
||||
|
||||
* they can only be configured using ``A`` records,
|
||||
* ``A`` records only accept IP addresses as value,
|
||||
* the IP address of your database can change, following an upgrade, a hardware failure or
|
||||
your wish to host your database in another country or continent.
|
||||
|
||||
Therefore, bare domains could suddenly no longer work because of this change of IP address.
|
||||
|
||||
In addition, if you would like both *mycompany.com* and *www.mycompany.com* to work with your database,
|
||||
having the first redirecting to the second is amongst the
|
||||
`SEO best practices <https://support.google.com/webmasters/answer/7451184?hl=en>`_
|
||||
(See *Provide one version of a URL to reach a document*)
|
||||
in order to have one dominant URL. You can therefore just configure *mycompany.com* to redirect to *www.mycompany.com*.
|
||||
Most domain managers have the feature to configure this redirection. This is commonly called a web redirection.
|
||||
|
||||
**HTTPS/SSL**
|
||||
|
||||
If the redirection is correctly set up, the platform will automatically generate an SSL certificate
|
||||
with `Let's Encrypt <https://letsencrypt.org/about/>`_ within the hour and your domain will be
|
||||
accessible through HTTPS.
|
||||
|
||||
While it is currently not possible to configure your own SSL certificates on the Odoo.sh platform
|
||||
we are considering the feature if there is enough demand.
|
||||
|
||||
|
||||
**SPF and DKIM compliance**
|
||||
|
||||
In case the domain of your users email addresses use SPF (Sender Policy Framework) or DKIM
|
||||
(DomainKeys Identified Mail), don't forget to authorize Odoo as a sending host in your domain name
|
||||
settings to increase the deliverability of your outgoing emails.
|
||||
The configuration steps are explained in the :ref:`Discuss app documentation <discuss-email_servers-spf-compliant>`.
|
||||
|
||||
.. Warning::
|
||||
Forgetting to configure your SPF or DKIM to authorize Odoo as a sending host can lead to the
|
||||
delivery of your emails as spam in your contacts inbox.
|
||||
|
||||
|
||||
Shell commands
|
||||
==============
|
||||
In the top right-hand corner of the view, different shell commands are available.
|
||||
|
||||
.. image:: ./media/interface-branches-shellcommands.png
|
||||
:align: center
|
||||
|
||||
Each command can be copied in the clipboard to be used in a terminal,
|
||||
and some of them can be used directly from Odoo.sh by clicking the *run* button
|
||||
in such case a popup will prompt the user in order to define eventual placeholders
|
||||
such as ``<URL>``, ``<PATH>``, ...
|
||||
|
||||
Clone
|
||||
-----
|
||||
Download the Git repository.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git clone --recurse-submodules --branch master git@github.com:odoo/odoo.git
|
||||
|
||||
Clones the repository *odoo/odoo*.
|
||||
|
||||
* :code:`--recurse-submodules`: Downloads the submodules of your repository. Submodules included in the submodules are downloaded as well.
|
||||
* :code:`--branch`: checks out a specific branch of the repository, in this case *master*.
|
||||
|
||||
The *run* button is not available for this command, as it is meant to be used on your machines.
|
||||
|
||||
Fork
|
||||
----
|
||||
Create a new branch based on the current branch.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git checkout -b feature-1 master
|
||||
|
||||
Creates a new branch called *feature-1* based on the branch *master*, and then checkouts it.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push -u origin feature-1
|
||||
|
||||
Uploads the new branch *feature-1* on your remote repository.
|
||||
|
||||
Merge
|
||||
-----
|
||||
Merge the current branch in another branch.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git merge staging-1
|
||||
|
||||
Merges the branch *staging-1* in the current branch.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push -u origin master
|
||||
|
||||
Uploads the changes you just added in the *master* branch on your remote repository.
|
||||
|
||||
SSH
|
||||
---
|
||||
Setup
|
||||
~~~~~
|
||||
In order to use SSH, you have to set up your profile SSH public key (if it is not already done).
|
||||
To do so, follow these steps:
|
||||
|
||||
#. `Generate a new SSH key
|
||||
<https://help.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#generating-a-new-ssh-key>`_
|
||||
#. `Copy the SSH key to your clipboard
|
||||
<https://help.github.com/en/github/authenticating-to-github/adding-a-new-ssh-key-to-your-github-account>`_
|
||||
(only apply the step 1)
|
||||
#. Paste the copied content to your profile SSH keys and press "Add"
|
||||
|
||||
.. image:: ./media/SSH-key-pasting.png
|
||||
:align: center
|
||||
|
||||
#. The key should appear below
|
||||
|
||||
.. image:: ./media/SSH-key-appearing.png
|
||||
:align: center
|
||||
|
||||
Connection
|
||||
~~~~~~~~~~
|
||||
|
||||
To connect to your builds using ssh use the following command in a terminal:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ssh <build_id>@<domain>
|
||||
|
||||
You will find a shortcut for this command into the SSH tab in the upper right corner.
|
||||
|
||||
.. image:: ./media/SSH-panel.png
|
||||
:align: center
|
||||
|
||||
Provided you have the :ref:`correct access rights <odoosh-gettingstarted-settings-collaborators>` on the project,
|
||||
you'll be granted ssh access to the build.
|
||||
|
||||
.. Note::
|
||||
Long running ssh connections are not guaranteed. Idle connections will be
|
||||
disconnected in order to free up resources.
|
||||
|
||||
|
||||
Submodule
|
||||
---------
|
||||
|
||||
Add a branch from another repository in your current branch as a *submodule*.
|
||||
|
||||
*Submodules* allows you to use modules from other repositories in your project.
|
||||
|
||||
The submodules feature is detailed in the chapter
|
||||
:ref:`Submodules <odoosh-advanced-submodules>` of this documentation.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git submodule add -b master <URL> <PATH>
|
||||
|
||||
Adds the branch *master* of the repository *<URL>* as a submodule under the path *<PATH>* in your current branch.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git commit -a
|
||||
|
||||
Commits all your current changes.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push -u origin master
|
||||
|
||||
Uploads the changes you just added in the *master* branch on your remote repository.
|
||||
|
||||
Delete
|
||||
------
|
||||
|
||||
Delete a branch from your repository.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push origin :master
|
||||
|
||||
Deletes the branch in your remote repository.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git branch -D master
|
||||
|
||||
Deletes the branch in your local copy of the repository.
|
||||
@@ -0,0 +1,123 @@
|
||||
|
||||
.. _odoosh-gettingstarted-builds:
|
||||
|
||||
==================================
|
||||
Builds
|
||||
==================================
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
In Odoo.sh, a build is considered as a database loaded by an Odoo server
|
||||
(`odoo/odoo <https://github.com/odoo/odoo>`_ & `odoo/enterprise <https://github.com/odoo/enterprise>`_)
|
||||
running on a specific revision of your project repository in a containerized environment.
|
||||
Its purpose is to test the well-behavior of the server, the database and the features with this revision.
|
||||
|
||||
.. image:: ./media/interface-builds.png
|
||||
:align: center
|
||||
|
||||
In this view, a row represents a branch, and a cell of a row represents a build of this branch.
|
||||
|
||||
Most of the time, builds are created following pushes on your Github repository branches.
|
||||
They can be created as well when you do other operations,
|
||||
such as importing a database on Odoo.sh or asking a rebuild for a branch in your project.
|
||||
|
||||
A build is considered successful if no errors or warnings come up during its creation.
|
||||
A successful build is highlighted in green.
|
||||
|
||||
A build is considered failed if errors come up during its creation.
|
||||
A failed build is highlighted in red.
|
||||
|
||||
If warnings come up during the creation, but there are no errors, the build is considered almost successful.
|
||||
It is highlighted in yellow to notify the developer warnings were raised.
|
||||
|
||||
Builds do not always create a database from scratch.
|
||||
For instance, when pushing a change on the production branch, the build created just starts the server
|
||||
with your new revision and tries to load the current production database on it.
|
||||
If no errors come up, the build is considered successful, and otherwise failed.
|
||||
|
||||
Stages
|
||||
======
|
||||
|
||||
Production
|
||||
----------
|
||||
|
||||
The first build of a production branch creates a database from scratch.
|
||||
If this build is successful, this database is considered as the production database of your project.
|
||||
|
||||
From then, pushes on the production branch will create new builds that attempt to load the database
|
||||
using a server running with the new revision.
|
||||
|
||||
If the build is successful, or has warnings but no errors, the production database will now run with this build, along
|
||||
with the revision associated to this build.
|
||||
|
||||
If the build fails to load or update the database, then the previous successful build is re-used to load the database,
|
||||
and therefore the database will run using a server running with the previous successful revision.
|
||||
|
||||
The build used to run the production database is always the first of the builds list. If a build fails, it is
|
||||
put after the build currently running the production database.
|
||||
|
||||
Staging
|
||||
-------
|
||||
|
||||
Staging builds duplicate the production database,
|
||||
and try to load this duplicate with the revisions of the staging branches.
|
||||
|
||||
Each time you push a new revision on a staging branch, the build created uses a new copy of the production database.
|
||||
The databases are not re-used between builds of the same branch. This ensures:
|
||||
|
||||
* staging builds use databases that are close to what the production looks like,
|
||||
so you do not make your tests with outdated data,
|
||||
|
||||
* you can play around as much as you want in the same staging database,
|
||||
and you can then ask for a rebuild when you want to restart with a new copy of the production.
|
||||
|
||||
Nevertheless, this means that if you make configuration changes in staging databases
|
||||
and do not apply them in the production,
|
||||
they will not be passed on the next build of the same staging branch.
|
||||
|
||||
Development
|
||||
-----------
|
||||
|
||||
Development builds create new databases, load the demo data and run the unit tests.
|
||||
|
||||
A build will be considered failed and highlighted in red if tests fail during the installation,
|
||||
as they are meant to raise errors if something wrong occurs.
|
||||
|
||||
If all tests pass, and there is no error, the build will be considered successful.
|
||||
|
||||
According to the list of modules to install and test, a development build can take up to 1 hour to be ready.
|
||||
This is due to the large number of tests set in the default Odoo modules suite.
|
||||
|
||||
Features
|
||||
========
|
||||
|
||||
The production branch will always appear first,
|
||||
and then the other branches are ordered by last build created. You can filter out the branches.
|
||||
|
||||
.. image:: ./media/interface-builds-branches.png
|
||||
:align: center
|
||||
|
||||
For each branch, you can access the last build's database using the *Connect* link and jump to the branch code using
|
||||
the *Github* link. For other branches than the production, you can create a new build which will use the latest revision
|
||||
of the branch using the link *rebuild*. This last link is not available when there is already a build in progress for
|
||||
the branch.
|
||||
|
||||
.. image:: ./media/interface-builds-build.png
|
||||
:align: center
|
||||
|
||||
For each build, you can access the revision changes using the button with the Github icon.
|
||||
You can access the build's database as the administrator using the *Connect* button.
|
||||
Also, you can access the database with another user using the *Connect as* button,
|
||||
in the dropdown menu of the *Connect* button.
|
||||
|
||||
.. _odoosh-gettingstarted-builds-download-dump:
|
||||
|
||||
.. image:: ./media/interface-builds-build-dropdown.png
|
||||
:align: center
|
||||
|
||||
.. _odoosh-gettingstarted-builds-dropdown-menu:
|
||||
|
||||
In the dropdown menu of the build, you can access the same features than in :ref:`the branches view <odoosh-gettingstarted-branches-tabs>`:
|
||||
*Logs*, *Web Shell*, *Editor*, *Outgoing e-mails*.
|
||||
You also have the possibility to *Download a dump* of the build's database.
|
||||
@@ -0,0 +1,187 @@
|
||||
|
||||
.. _odoosh-gettingstarted-create:
|
||||
|
||||
==================================
|
||||
Create your project
|
||||
==================================
|
||||
|
||||
Deploy your platform
|
||||
====================
|
||||
|
||||
Go to `Odoo.sh <https://www.odoo.sh/>`_ and hit the *Deploy your platform* button.
|
||||
|
||||
.. image:: ./media/deploy.png
|
||||
:align: center
|
||||
|
||||
Sign in with Github
|
||||
===================
|
||||
|
||||
Sign in with your Github account. If you do not have an account yet, hit the *Create an account* link.
|
||||
|
||||
.. image:: ./media/github-signin.png
|
||||
:align: center
|
||||
|
||||
Authorize Odoo.sh
|
||||
=================
|
||||
|
||||
Grant Odoo.sh the required accesses to your account by clicking the *Authorize* button.
|
||||
|
||||
.. image:: ./media/github-authorize.png
|
||||
:align: center
|
||||
|
||||
Odoo.sh basically needs:
|
||||
|
||||
* to know your Github login and email,
|
||||
* to create a new repository in case you decide to start from scratch,
|
||||
* to read your existing repositories, including the ones of your organizations, in case you want to start from an existing repository,
|
||||
* to create a webhook to be notified each time you push changes,
|
||||
* to commit changes to make your deployment easier, merging branches or adding new `submodules <https://git-scm.com/book/en/v2/Git-Tools-Submodules>`_ for example.
|
||||
|
||||
Submit your project
|
||||
===================
|
||||
|
||||
Choose if you want to start from scratch by creating a new repository, or if you want to use an existing repository.
|
||||
|
||||
Then, choose a name or select the repository you want to use.
|
||||
|
||||
Choose the Odoo version you want to use. If you plan to import an existing database or an existing set of applications, you might need to choose the according version. If you start from scratch, use the latest version.
|
||||
|
||||
Enter your *subscription code*. This is also called *subscription referral*, *contract number* or *activation code*.
|
||||
|
||||
It should be the code of your Enterprise subscription that includes Odoo.sh.
|
||||
|
||||
Partners can use their partnership codes to start a trial. Should their clients start a project, they ought to get an Enterprise subscription including Odoo.sh and use its subscription code. The partner will get the full amount as back commission.
|
||||
Contact your sales representative or account manager in order to get it.
|
||||
|
||||
When submitting the form, if you are notified your subscription is not valid, it either means:
|
||||
|
||||
* it is not an existing subscription,
|
||||
* it is not a partnership subscription,
|
||||
* it is an enterprise subscription, but which does not include Odoo.sh,
|
||||
* it is neither a partnership subscription or an enterprise subscription (e.g. an online subscription).
|
||||
|
||||
In case of doubt with your subscription, please contact the `Odoo support <https://www.odoo.com/help>`_.
|
||||
|
||||
.. image:: ./media/deploy-form.png
|
||||
:align: center
|
||||
|
||||
You're done !
|
||||
=============
|
||||
|
||||
You can start using Odoo.sh. Your first build is about to be created. You will soon be able to connect to your first database.
|
||||
|
||||
.. image:: ./media/deploy-done.png
|
||||
:align: center
|
||||
|
||||
.. _odoo_sh_import_your_database:
|
||||
|
||||
Import your database
|
||||
====================
|
||||
|
||||
You can import your database in your Odoo.sh project as long as this is an Odoo 10.0, 11.0 or above database.
|
||||
|
||||
Push your modules in production
|
||||
-------------------------------
|
||||
|
||||
If you use community or custom modules, add them in a branch in your Github repository.
|
||||
Databases hosted on the Odoo.com online platform do not have any custom modules.
|
||||
Users of these databases can therefore skip this step.
|
||||
|
||||
You can structure your modules as you wish, Odoo.sh will automatically detect the folders containing Odoo addons.
|
||||
For instance, you can put all your modules folder in the root directory of your repository,
|
||||
or group the modules in folders by categories that you define (accounting, project, ...).
|
||||
|
||||
For community modules available in public Git repositories,
|
||||
you can also consider to add them using :ref:`Submodules <odoosh-advanced-submodules>`.
|
||||
|
||||
Then, either :ref:`make this branch the production branch <odoosh-gettingstarted-branches-stages>`,
|
||||
or :ref:`merge it into your production branch <odoosh-gettingstarted-branches-mergingbranches>`.
|
||||
|
||||
Download a backup
|
||||
-----------------
|
||||
|
||||
On-premise databases
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Access the URL :file:`/web/database/manager` of your on-premise database and download a backup.
|
||||
|
||||
.. Warning::
|
||||
|
||||
If you cannot access the database manager, it may have been disabled by your system administrator.
|
||||
See the `database manager security documentation
|
||||
<https://www.odoo.com/documentation/14.0/setup/deploy.html#database-manager-security>`_.
|
||||
|
||||
You will need the master password of your database server. If you do not have it, contact your system administrator.
|
||||
|
||||
.. image:: ./media/create-import-onpremise-backup.png
|
||||
:align: center
|
||||
|
||||
Choose a zip including the filestore as the backup format.
|
||||
|
||||
.. image:: ./media/create-import-onpremise-backup-dialog.png
|
||||
:align: center
|
||||
|
||||
Odoo Online databases
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
`Access your databases manager <https://accounts.odoo.com/my/databases/manage>`_ and download a backup of your database.
|
||||
|
||||
.. image:: ./media/create-import-online-backup.png
|
||||
:align: center
|
||||
|
||||
.. Warning::
|
||||
|
||||
Saas releases (e.g. *saas-**) are not supported on Odoo.sh.
|
||||
|
||||
Upload the backup
|
||||
-----------------
|
||||
|
||||
Then, in your Odoo.sh project, in the backups tab of your production branch, import the backup you just downloaded.
|
||||
|
||||
.. image:: ./media/create-import-production.png
|
||||
:align: center
|
||||
|
||||
Once the backup imported, you can access the database using the *Connect* button in the history of the branch.
|
||||
|
||||
.. image:: ./media/create-import-production-done.png
|
||||
:align: center
|
||||
|
||||
Check your outgoing email servers
|
||||
---------------------------------
|
||||
|
||||
There is a default mail server provided with Odoo.sh.
|
||||
To use it, there must be no enabled outgoing mail server configured in your database in
|
||||
:menuselection:`Settings --> Technical --> Outgoing Mail Servers`
|
||||
(:doc:`Developer mode <../../../../applications/general/developer_mode/activate>` must be activated).
|
||||
|
||||
After the import of your database,
|
||||
all outgoing email servers are disabled so you use the Odoo.sh email server provided by default.
|
||||
|
||||
.. Warning::
|
||||
|
||||
Port 25 is (and will stay) closed. If you want to connect to an external SMTP server, you should use ports 465 and 587.
|
||||
|
||||
Check your scheduled actions
|
||||
----------------------------
|
||||
|
||||
All scheduled actions are disabled after the import.
|
||||
|
||||
This is to prevent your newly imported database to perform actions that could impact your running production,
|
||||
such as sending the mails remaining in the queue, processing mass mailings, or third-party services synchronization
|
||||
(Calendars, files hosting, ...).
|
||||
|
||||
If you plan to make the imported database your production, enable the scheduled actions you need.
|
||||
You can check what is enabled in the database of origin and enable the same actions in the imported database.
|
||||
Scheduled actions are located under :menuselection:`Settings --> Technical --> Automation --> Scheduled Actions`.
|
||||
|
||||
Register your subscription
|
||||
--------------------------
|
||||
|
||||
Your subscription is unlinked after the import.
|
||||
|
||||
The imported database is considered a duplicate by default and the enterprise subscription is therefore removed,
|
||||
as you can only have one database linked per subscription.
|
||||
|
||||
If you plan to make it your production,
|
||||
unlink your former database from the subscription, and register the newly imported database.
|
||||
Read the :ref:`database registration documentation <db_premise>` for instructions.
|
||||
@@ -0,0 +1,520 @@
|
||||
|
||||
==================================
|
||||
Your first module
|
||||
==================================
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
This chapter helps you to create your first Odoo module and deploy it in your Odoo.sh project.
|
||||
|
||||
This tutorial requires :ref:`you created a project on Odoo.sh <odoosh-gettingstarted-create>`, and you know your Github repository's URL.
|
||||
|
||||
Basic use of Git and Github is explained.
|
||||
|
||||
The below assumptions are made:
|
||||
|
||||
* *~/src* is the directory where are located the Git repositories related to your Odoo projects,
|
||||
* *odoo* is the Github user,
|
||||
* *odoo-addons* is the Github repository,
|
||||
* *feature-1* is the name of a development branch,
|
||||
* *master* is the name of the production branch,
|
||||
* *my_module* is the name of the module.
|
||||
|
||||
Replace these by the values of your choice.
|
||||
|
||||
Create the development branch
|
||||
=============================
|
||||
|
||||
From Odoo.sh
|
||||
-------------
|
||||
|
||||
In the branches view:
|
||||
|
||||
* hit the :code:`+` button next to the development stage,
|
||||
* choose the branch *master* in the *Fork* selection,
|
||||
* type *feature-1* in the *To* input.
|
||||
|
||||
|pic1| |pic2|
|
||||
|
||||
.. |pic1| image:: ./media/firstmodule-development-+.png
|
||||
:width: 45%
|
||||
|
||||
.. |pic2| image:: ./media/firstmodule-development-fork.png
|
||||
:width: 45%
|
||||
|
||||
|
||||
Once the build created, you can access the editor and browse to the folder *~/src/user* to access
|
||||
to the code of your development branch.
|
||||
|
||||
.. image:: ./media/firstmodule-development-editor.png
|
||||
:align: center
|
||||
|
||||
.. image:: ./media/firstmodule-development-editor-interface.png
|
||||
:align: center
|
||||
|
||||
From your computer
|
||||
------------------
|
||||
|
||||
|
||||
Clone your Github repository on your computer:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ mkdir ~/src
|
||||
$ cd ~/src
|
||||
$ git clone https://github.com/odoo/odoo-addons.git
|
||||
$ cd ~/src/odoo-addons
|
||||
|
||||
Create a new branch:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git checkout -b feature-1 master
|
||||
|
||||
|
||||
Create the module structure
|
||||
===========================
|
||||
|
||||
Scaffolding the module
|
||||
----------------------
|
||||
|
||||
While not necessary, scaffolding avoids the tedium of setting the basic Odoo module structure.
|
||||
You can scaffold a new module using the executable *odoo-bin*.
|
||||
|
||||
From the Odoo.sh editor, in a terminal:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ odoo-bin scaffold my_module ~/src/user/
|
||||
|
||||
Or, from your computer, if you have an `installation of Odoo
|
||||
<https://www.odoo.com/documentation/14.0/setup/install.html#source-install>`_:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ./odoo-bin scaffold my_module ~/src/odoo-addons/
|
||||
|
||||
If you do not want to bother installing Odoo on your computer,
|
||||
you can also :download:`download this module structure template <media/my_module.zip>` in which you replace every occurrences of
|
||||
*my_module* to the name of your choice.
|
||||
|
||||
The below structure will be generated:
|
||||
|
||||
::
|
||||
|
||||
my_module
|
||||
├── __init__.py
|
||||
├── __manifest__.py
|
||||
├── controllers
|
||||
│ ├── __init__.py
|
||||
│ └── controllers.py
|
||||
├── demo
|
||||
│ └── demo.xml
|
||||
├── models
|
||||
│ ├── __init__.py
|
||||
│ └── models.py
|
||||
├── security
|
||||
│ └── ir.model.access.csv
|
||||
└── views
|
||||
├── templates.xml
|
||||
└── views.xml
|
||||
|
||||
.. Warning::
|
||||
|
||||
Do not use special characters other than the underscore ( _ ) for your module name, not even an hyphen ( - ).
|
||||
This name is used for the Python classes of your module,
|
||||
and having classes name with special characters other than the underscore is not valid in Python.
|
||||
|
||||
Uncomment the content of the files:
|
||||
|
||||
* *models/models.py*,
|
||||
an example of model with its fields,
|
||||
* *views/views.xml*,
|
||||
a tree and a form view, with the menus opening them,
|
||||
* *demo/demo.xml*,
|
||||
demo records for the above example model,
|
||||
* *controllers/controllers.py*,
|
||||
an example of controller implementing some routes,
|
||||
* *views/templates.xml*,
|
||||
two example qweb views used by the above controller routes,
|
||||
* *__manifest__.py*,
|
||||
the manifest of your module, including for instance its title, description and data files to load.
|
||||
You just need to uncomment the access control list data file:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
# 'security/ir.model.access.csv',
|
||||
|
||||
Manually
|
||||
--------
|
||||
|
||||
If you want to create your module structure manually,
|
||||
you can follow `Build an Odoo module <https://www.odoo.com/documentation/14.0/howtos/backend.html>`_ to understand
|
||||
the structure of a module and the content of each file.
|
||||
|
||||
Push the development branch
|
||||
===========================
|
||||
|
||||
Stage the changes to be committed
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git add my_module
|
||||
|
||||
Commit your changes
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git commit -m "My first module"
|
||||
|
||||
Push your changes to your remote repository
|
||||
|
||||
From an Odoo.sh editor terminal:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push https HEAD:feature-1
|
||||
|
||||
The above command is explained in the section
|
||||
:ref:`Commit & Push your changes
|
||||
<odoosh-gettingstarted-online-editor-push>` of the
|
||||
:ref:`Online Editor <odoosh-gettingstarted-online-editor>`
|
||||
chapter.
|
||||
It includes the explanation regarding the fact you will be prompted to type your username and password,
|
||||
and what to do if you use the two-factor authentication.
|
||||
|
||||
Or, from your computer terminal:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push -u origin feature-1
|
||||
|
||||
You need to specify *-u origin feature-1* for the first push only.
|
||||
From that point, to push your future changes from your computer, you can simply use
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push
|
||||
|
||||
Test your module
|
||||
================
|
||||
|
||||
Your branch should appear in your development branches in your project.
|
||||
|
||||
.. image:: ./media/firstmodule-test-branch.png
|
||||
:align: center
|
||||
|
||||
In the branches view of your project,
|
||||
you can click on your branch name in the left navigation panel to access its history.
|
||||
|
||||
.. image:: ./media/firstmodule-test-branch-history.png
|
||||
:align: center
|
||||
|
||||
You can see here the changes you just pushed, including the comment you set.
|
||||
Once the database ready, you can access it by clicking the *Connect* button.
|
||||
|
||||
.. image:: ./media/firstmodule-test-database.png
|
||||
:align: center
|
||||
|
||||
If your Odoo.sh project is configured to install your module automatically,
|
||||
you will directly see it amongst the database apps. Otherwise, it will be available in the apps to install.
|
||||
|
||||
You can then play around with your module, create new records and test your features and buttons.
|
||||
|
||||
|
||||
Test with the production data
|
||||
=============================
|
||||
|
||||
You need to have a production database for this step. You can create it if you do not have it yet.
|
||||
|
||||
Once you tested your module in a development build with the demo data and believe it is ready,
|
||||
you can test it with the production data using a staging branch.
|
||||
|
||||
You can either:
|
||||
|
||||
* Make your development branch a staging branch, by drag and dropping it onto the *staging* section title.
|
||||
|
||||
.. image:: ./media/firstmodule-test-devtostaging.png
|
||||
:align: center
|
||||
|
||||
* Merge it in an existing staging branch, by drag and dropping it onto the given staging branch.
|
||||
|
||||
.. image:: ./media/firstmodule-test-devinstaging.png
|
||||
:align: center
|
||||
|
||||
You can also use the :code:`git merge` command to merge your branches.
|
||||
|
||||
This will create a new staging build, which will duplicate the production database and make it run using a server
|
||||
updated with your latest changes of your branch.
|
||||
|
||||
.. image:: ./media/firstmodule-test-mergedinstaging.png
|
||||
:align: center
|
||||
|
||||
Once the database ready, you can access it using the *Connect* button.
|
||||
|
||||
.. _odoosh-gettingstarted-firstmodule-productiondata-install:
|
||||
|
||||
Install your module
|
||||
-------------------
|
||||
|
||||
Your module will not be installed automatically, you have to install it from the apps menu.
|
||||
Indeed, the purpose of the staging build is to test the behavior of your changes as it would be on your production,
|
||||
and on your production you would not like your module to be installed automatically, but on demand.
|
||||
|
||||
Your module may not appear directly in your apps to install either, you need to update your apps list first:
|
||||
|
||||
* activate the :doc:`Developer mode <../../../applications/general/developer_mode/activate>`
|
||||
* in the apps menu, click the *Update Apps List* button,
|
||||
* in the dialog that appears, click the *Update* button.
|
||||
|
||||
.. image:: ./media/firstmodule-test-updateappslist.png
|
||||
:align: center
|
||||
|
||||
Your module will then appear in the list of available apps.
|
||||
|
||||
.. image:: ./media/firstmodule-test-mymoduleinapps.png
|
||||
:align: center
|
||||
|
||||
Deploy in production
|
||||
====================
|
||||
|
||||
Once you tested your module in a staging branch with your production data,
|
||||
and believe it is ready for production, you can merge your branch in the production branch.
|
||||
|
||||
Drag and drop your staging branch on the production branch.
|
||||
|
||||
.. image:: ./media/firstmodule-test-mergeinproduction.png
|
||||
:align: center
|
||||
|
||||
You can also use the :code:`git merge` command to merge your branches.
|
||||
|
||||
This will merge the latest changes of your staging branch in the production branch,
|
||||
and update your production server with these latest changes.
|
||||
|
||||
.. image:: ./media/firstmodule-test-mergedinproduction.png
|
||||
:align: center
|
||||
|
||||
Once the database ready, you can access it using the *Connect* button.
|
||||
|
||||
Install your module
|
||||
-------------------
|
||||
|
||||
Your module will not be installed automatically,
|
||||
you have to install it manually as explained in the
|
||||
:ref:`above section about installing your module in staging databases
|
||||
<odoosh-gettingstarted-firstmodule-productiondata-install>`.
|
||||
|
||||
Add a change
|
||||
============
|
||||
|
||||
This section explains how to add a change in your module by adding a new field in a model and deploy it.
|
||||
|
||||
From the Odoo.sh editor,
|
||||
* browse to your module folder *~/src/user/my_module*,
|
||||
* then, open the file *models/models.py*.
|
||||
|
||||
Or, from your computer,
|
||||
* use the file browser of your choice to browse to your module folder *~/src/odoo-addons/my_module*,
|
||||
* then, open the file *models/models.py* using the editor of your choice,
|
||||
such as *Atom*, *Sublime Text*, *PyCharm*, *vim*, ...
|
||||
|
||||
Then, after the description field
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
description = fields.Text()
|
||||
|
||||
Add a datetime field
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
start_datetime = fields.Datetime('Start time', default=lambda self: fields.Datetime.now())
|
||||
|
||||
Then, open the file *views/views.xml*.
|
||||
|
||||
After
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<field name="value2"/>
|
||||
|
||||
Add
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<field name="start_datetime"/>
|
||||
|
||||
These changes alter the database structure by adding a column in a table,
|
||||
and modify a view stored in database.
|
||||
|
||||
In order to be applied in existing databases, such as your production database,
|
||||
these changes requires the module to be updated.
|
||||
|
||||
If you would like the update to be performed automatically by the Odoo.sh platform when you push your changes,
|
||||
increase your module version in its manifest.
|
||||
|
||||
Open the module manifest *__manifest__.py*.
|
||||
|
||||
Replace
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
'version': '0.1',
|
||||
|
||||
with
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
'version': '0.2',
|
||||
|
||||
The platform will detect the change of version and trigger the update of the module upon the new revision deployment.
|
||||
|
||||
Browse to your Git folder.
|
||||
|
||||
Then, from an Odoo.sh terminal:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ cd ~/src/user/
|
||||
|
||||
Or, from your computer terminal:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ cd ~/src/odoo-addons/
|
||||
|
||||
Then, stage your changes to be committed
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git add my_module
|
||||
|
||||
Commit your changes
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git commit -m "[ADD] my_module: add the start_datetime field to the model my_module.my_module"
|
||||
|
||||
Push your changes:
|
||||
|
||||
From an Odoo.sh terminal:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push https HEAD:feature-1
|
||||
|
||||
Or, from your computer terminal:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push
|
||||
|
||||
The platform will then create a new build for the branch *feature-1*.
|
||||
|
||||
.. image:: ./media/firstmodule-test-addachange-build.png
|
||||
:align: center
|
||||
|
||||
Once you tested your changes, you can merge your changes in the production branch, for instance by drag-and-dropping the
|
||||
branch on the production branch in the Odoo.sh interface. As you increased the module version in the manifest,
|
||||
the platform will update the module automatically and your new field will be directly available.
|
||||
Otherwise you can manually update the module within the apps list.
|
||||
|
||||
Use an external Python library
|
||||
==============================
|
||||
|
||||
If you would like to use an external Python library which is not installed by default,
|
||||
you can define a *requirements.txt* file listing the external libraries your modules depends on.
|
||||
|
||||
The platform will use this file to automatically install the Python libraries your project needs.
|
||||
|
||||
The feature is explained in this section by using the `Unidecode library <https://pypi.python.org/pypi/Unidecode>`_ in
|
||||
your module.
|
||||
|
||||
Create a file *requirements.txt* in the root folder of your repository
|
||||
|
||||
From the Odoo.sh editor, create and open the file ~/src/user/requirements.txt.
|
||||
|
||||
Or, from your computer, create and open the file ~/src/odoo-addons/requirements.txt.
|
||||
|
||||
Add
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
unidecode
|
||||
|
||||
Then use the library in your module, for instance to remove accents from characters in the name field of your
|
||||
model.
|
||||
|
||||
Open the file *models/models.py*.
|
||||
|
||||
Before
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from odoo import models, fields, api
|
||||
|
||||
Add
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from unidecode import unidecode
|
||||
|
||||
After
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
start_datetime = fields.Datetime('Start time', default=lambda self: fields.Datetime.now())
|
||||
|
||||
Add
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
@api.model
|
||||
def create(self, values):
|
||||
if 'name' in values:
|
||||
values['name'] = unidecode(values['name'])
|
||||
return super(my_module, self).create(values)
|
||||
|
||||
def write(self, values):
|
||||
if 'name' in values:
|
||||
values['name'] = unidecode(values['name'])
|
||||
return super(my_module, self).write(values)
|
||||
|
||||
Adding a Python dependency requires a module version increase for the platform to install it.
|
||||
|
||||
Edit the module manifest *__manifest__.py*
|
||||
|
||||
Replace
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
'version': '0.2',
|
||||
|
||||
with
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
'version': '0.3',
|
||||
|
||||
Stage and commit your changes:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git add requirements.txt
|
||||
$ git add my_module
|
||||
$ git commit -m "[IMP] my_module: automatically remove special chars in my_module.my_module name field"
|
||||
|
||||
Then, push your changes:
|
||||
|
||||
In an Odoo.sh terminal:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push https HEAD:feature-1
|
||||
|
||||
In your computer terminal:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 6.1 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.4 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 7.9 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.2 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 3.2 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.8 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 27 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 10 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 4.2 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 3.4 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 3.7 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.9 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 66 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.4 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 84 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 78 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.3 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 4.9 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 5.6 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.4 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 1.6 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 6.9 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 2.0 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 7.8 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 43 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 10 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 3.9 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 5.1 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 4.9 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.8 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
Binary file not shown.
@@ -0,0 +1,200 @@
|
||||
|
||||
.. _odoosh-gettingstarted-online-editor:
|
||||
|
||||
==================================
|
||||
Online Editor
|
||||
==================================
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
The online editor allows you to edit the source code of your builds from a web browser.
|
||||
It also gives you the possibility to open terminals, Python consoles, Odoo Shell consoles and
|
||||
`Notebooks <https://jupyterlab.readthedocs.io/en/stable/user/notebook.html>`_.
|
||||
|
||||
.. image:: ./media/interface-editor.png
|
||||
:align: center
|
||||
|
||||
You can access the editor of a build through
|
||||
:ref:`the branches tabs <odoosh-gettingstarted-branches-tabs>`,
|
||||
:ref:`the builds dropdown menu <odoosh-gettingstarted-builds-dropdown-menu>`
|
||||
or by adding */odoo-sh/editor* to your build domain name
|
||||
(e.g. *https://odoo-addons-master-1.dev.odoo.com/odoo-sh/editor*).
|
||||
|
||||
Edit the source code
|
||||
====================
|
||||
|
||||
The working directory is composed of the following folders:
|
||||
|
||||
::
|
||||
|
||||
.
|
||||
├── home
|
||||
│ └── odoo
|
||||
│ ├── src
|
||||
│ │ ├── odoo Odoo Community source code
|
||||
│ │ │ └── odoo-bin Odoo server executable
|
||||
│ │ ├── enterprise Odoo Enterprise source code
|
||||
│ │ ├── themes Odoo Themes source code
|
||||
│ │ └── user Your repository branch source code
|
||||
│ ├── repositories The Git repositories used by your project
|
||||
│ ├── data
|
||||
│ │ ├── filestore database attachments, as well as the files of binary fields
|
||||
│ │ └── sessions visitors and users sessions
|
||||
│ └── logs
|
||||
│ ├── install.log Database installation logs
|
||||
│ ├── odoo.log Running server logs
|
||||
│ ├── update.log Database updates logs
|
||||
│ └── pip.log Python packages installation logs
|
||||
|
||||
You can edit the source code (files under */src*) in development and staging builds.
|
||||
|
||||
.. note::
|
||||
Your changes won't be propagated to a new build, you must commit them in your
|
||||
source code if you want to make them persist.
|
||||
|
||||
|
||||
For production builds, the source code is read-only, because applying local changes on a production
|
||||
server is not a good practice.
|
||||
|
||||
* The source code of your Github repository is located under */src/user*,
|
||||
* The source code of Odoo is located under
|
||||
|
||||
* */src/odoo* (`odoo/odoo <https://github.com/odoo/odoo>`_),
|
||||
* */src/enterprise* (`odoo/enterprise <https://github.com/odoo/enterprise>`_),
|
||||
* */src/themes* (`odoo/design-themes <https://github.com/odoo/design-themes>`_).
|
||||
|
||||
To open a file in the editor, just double-click on it in the file browser panel on the left.
|
||||
|
||||
.. image:: ./media/interface-editor-open-file.png
|
||||
:align: center
|
||||
|
||||
You can then begin to make your changes. You can save your changes with the menu
|
||||
:menuselection:`File --> Save .. File` or by hitting the :kbd:`Ctrl+S` shortcut.
|
||||
|
||||
.. image:: ./media/interface-editor-save-file.png
|
||||
:align: center
|
||||
|
||||
If you save a Python file which is under your Odoo server addons path,
|
||||
Odoo will detect it and reload automatically so your changes are reflected immediately,
|
||||
without having to restart the server manually.
|
||||
|
||||
.. image:: ./media/interface-editor-automaticreload.gif
|
||||
:align: center
|
||||
|
||||
However, if the change is a data stored in database, such as the label of a field, or a view,
|
||||
you have to update the according module to apply the change.
|
||||
You can update the module of the currently opened file by using the menu
|
||||
:menuselection:`Odoo --> Update current module`. Note that the file considered as currently opened
|
||||
is the file focused in the text editor, not the file highlighted in the file browser.
|
||||
|
||||
.. image:: ./media/interface-editor-update-current-module.png
|
||||
:align: center
|
||||
|
||||
You can also open a terminal and execute the command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ odoo-bin -u <comma-separated module names> --stop-after-init
|
||||
|
||||
.. _odoosh-gettingstarted-online-editor-push:
|
||||
|
||||
Commit & Push your changes
|
||||
==========================
|
||||
|
||||
You have the possibility to commit and push your changes to your Github repository.
|
||||
|
||||
* Open a terminal (:menuselection:`File --> New --> Terminal`),
|
||||
* Change the directory to *~/src/user* using :code:`cd ~/src/user`,
|
||||
* Stage your changes using :code:`git add`,
|
||||
* Commit your changes using :code:`git commit`,
|
||||
* Push your changes using :code:`git push https HEAD:<branch>`.
|
||||
|
||||
In this last command,
|
||||
|
||||
* *https* is the name of your *HTTPS* Github remote repository
|
||||
(e.g. https://github.com/username/repository.git),
|
||||
* HEAD is the reference to the latest revision you committed,
|
||||
* <branch> must be replaced by the name of the branch to which you want to push the changes,
|
||||
most-likely the current branch if you work in a development build.
|
||||
|
||||
.. image:: ./media/interface-editor-commit-push.png
|
||||
:align: center
|
||||
|
||||
.. Note::
|
||||
The SSH Github remote is not used because your SSH private key
|
||||
is not hosted in your build containers (for obvious security concerns)
|
||||
nor forwarded through an SSH Agent (as you access this editor through a web browser)
|
||||
and you therefore cannot authenticate yourself to Github using SSH.
|
||||
You have to use the HTTPS remote of your Github repository to push your changes,
|
||||
which is added automatically named as *https* in your Git remotes.
|
||||
You will be prompted to enter your Github username and password.
|
||||
If you activated the two-factor authentication on Github,
|
||||
you can create a
|
||||
`personal access token <https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/>`_
|
||||
and use it as password. Granting the ``repo`` permission suffices.
|
||||
|
||||
|
||||
.. Note::
|
||||
The Git source folder *~/src/user* is not checked out on a branch but rather on a detached revision:
|
||||
This is because builds work on specific revisions rather than branches.
|
||||
In other words, this means you can have multiple builds on the same branch, but on different revisions.
|
||||
|
||||
Once your changes are pushed,
|
||||
according to your :ref:`branch push behavior <odoosh-gettingstarted-branches-tabs-settings>`,
|
||||
a new build may be created. You can continue to work in the editor you pushed from,
|
||||
as it will have the same revision as the new build that was created, but always make sure to be
|
||||
in an editor of a build using the latest revision of your branch.
|
||||
|
||||
Consoles
|
||||
========
|
||||
|
||||
You can open Python consoles, which are
|
||||
`IPython interactive shells <https://ipython.readthedocs.io/en/stable/interactive/tutorial.html>`_.
|
||||
One of the most interesting addition to use a Python console
|
||||
rather than a IPython shell within a terminal is the
|
||||
`rich display <https://ipython.readthedocs.io/en/stable/config/integrating.html#rich-display>`_
|
||||
capabilities.
|
||||
Thanks to this, you will be able to display objects in HTML.
|
||||
|
||||
You can for instance display cells of a CSV file using
|
||||
`pandas <https://pandas.pydata.org/pandas-docs/stable/tutorials.html>`_.
|
||||
|
||||
.. image:: ./media/interface-editor-console-python-read-csv.png
|
||||
:align: center
|
||||
|
||||
You can also open an Odoo Shell console to play around
|
||||
with the Odoo registry and model methods of your database. You can also directly read or write
|
||||
on your records.
|
||||
|
||||
.. Warning::
|
||||
In an Odoo Console, transactions are automatically committed.
|
||||
This means, for instance, that changes in records are applied effectively in the database.
|
||||
If you change the name of a user, the name of the user is changed in your database
|
||||
as well.
|
||||
You therefore should use Odoo consoles carefully on production databases.
|
||||
|
||||
You can use *env* to invoke models of your database registry, e.g. :code:`env['res.users']`.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
env['res.users'].search_read([], ['name', 'email', 'login'])
|
||||
[{'id': 2,
|
||||
'login': 'admin',
|
||||
'name': 'Administrator',
|
||||
'email': 'admin@example.com'}]
|
||||
|
||||
The class :code:`Pretty` gives you the possibility
|
||||
to easily display lists and dicts in a pretty way, using the
|
||||
`rich display <https://ipython.readthedocs.io/en/stable/config/integrating.html#rich-display>`_
|
||||
mentioned above.
|
||||
|
||||
.. image:: ./media/interface-editor-console-odoo-pretty.png
|
||||
:align: center
|
||||
|
||||
You can also use
|
||||
`pandas <https://pandas.pydata.org/pandas-docs/stable/tutorials.html>`_
|
||||
to display graphs.
|
||||
|
||||
.. image:: ./media/interface-editor-console-odoo-graph.png
|
||||
:align: center
|
||||
@@ -0,0 +1,197 @@
|
||||
|
||||
==================================
|
||||
Settings
|
||||
==================================
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
The settings allow you to manage the configuration of your project.
|
||||
|
||||
.. image:: ./media/interface-settings.png
|
||||
:align: center
|
||||
|
||||
Project name
|
||||
============
|
||||
|
||||
The name of your project.
|
||||
|
||||
.. image:: ./media/interface-settings-projectname.png
|
||||
:align: center
|
||||
|
||||
This defines the address that will be used to access your production database.
|
||||
|
||||
Addresses of your staging and development builds are derived from this name and assigned automatically.
|
||||
However, when you change your project name, only future builds will use the new name.
|
||||
|
||||
.. _odoosh-gettingstarted-settings-collaborators:
|
||||
|
||||
Collaborators
|
||||
=============
|
||||
|
||||
Manage the Github users who can access your project.
|
||||
|
||||
.. image:: ./media/interface-settings-collaborators.png
|
||||
:align: center
|
||||
|
||||
There are two levels of users:
|
||||
|
||||
* Admin: has access to all features of Odoo.sh.
|
||||
* User: does not have access to the project settings nor to the production and staging databases.
|
||||
|
||||
The user group is meant for developers who can make modifications in your code but are not allowed to access the
|
||||
production data.
|
||||
Users of this group cannot connect to the production and staging databases using the *1-click connect* feature,
|
||||
but they can of course use their regular account on these databases if they have one, using their regular credentials.
|
||||
|
||||
In addition, they cannot use the webshell nor have access to the server logs.
|
||||
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | | User | Admin |
|
||||
+=====================+=================+===========+===========+
|
||||
|Development | History | X | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | 1-click connect | X | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | Logs | X | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | Shell/SSH | X | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | Mails | X | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | Settings | X | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
|Production & Staging | History | X | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | 1-click connect | | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | Logs | | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | Shell/SSH | | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | Mails | | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | Monitoring | | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | Backups | | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | Settings | X | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
|Status | | X | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
|Settings | | | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
|
||||
Public Access
|
||||
=============
|
||||
|
||||
Allow public access to your development builds.
|
||||
|
||||
.. image:: ./media/interface-settings-public.png
|
||||
:align: center
|
||||
|
||||
If activated, this option exposes the Builds page publicly, allowing visitors to connect to your development builds.
|
||||
|
||||
In addition, visitors have access to the logs, shell and mails of your development builds.
|
||||
|
||||
Production and staging builds are excluded, visitors can only see their status.
|
||||
|
||||
.. _odoosh-gettingstarted-settings-modules-installation:
|
||||
|
||||
|
||||
Custom domains
|
||||
==============
|
||||
|
||||
To configure additional domains please refer to the corresponding branch's :ref:`settings tab <odoosh-gettingstarted-branches-tabs-settings>`.
|
||||
|
||||
.. _odoosh-gettingstarted-settings-submodules:
|
||||
|
||||
Submodules
|
||||
==========
|
||||
|
||||
Configure the deploy keys for the private repositories you use
|
||||
as submodules in your branches to allow Odoo.sh to download them.
|
||||
|
||||
.. Warning::
|
||||
These settings are required for **private repositories** only.
|
||||
If you are looking on how to set up your submodules,
|
||||
instructions are available in the chapter :ref:`Submodules <odoosh-advanced-submodules>` of this documentation.
|
||||
|
||||
.. image:: ./media/interface-settings-submodules.png
|
||||
:align: center
|
||||
|
||||
When a repository is private, it is not possible to publicly download its branches and revisions.
|
||||
For that reason, you need to configure a deploy key for Odoo.sh,
|
||||
so the remote Git server allows our platform to download the revisions
|
||||
of this private repository.
|
||||
|
||||
To configure the deploy key for a private repository, proceed as follows:
|
||||
|
||||
* in the input, paste the SSH URL of your private sub-repository and click on *Add*,
|
||||
|
||||
* e.g. *git@github.com:USERNAME/REPOSITORY.git*
|
||||
* it can be another Git server than Github, such as Bitbucket, Gitlab or even your own self-hosted server
|
||||
|
||||
* copy the public key,
|
||||
|
||||
* it should look like *ssh-rsa some...random...characters...here...==*
|
||||
|
||||
* in the settings of the private sub-repository, add the public key amongst the deploy keys.
|
||||
|
||||
* Github.com: :menuselection:`Settings --> Deploy keys --> Add deploy key`
|
||||
* Bitbucket.com: :menuselection:`Settings --> Access keys --> Add key`
|
||||
* Gitlab.com: :menuselection:`Settings --> Repository --> Deploy Keys`
|
||||
* Self-hosted: append the key to the git user’s authorized_keys file in its .ssh directory
|
||||
|
||||
Storage Size
|
||||
============
|
||||
|
||||
This section shows the storage size used by your project.
|
||||
|
||||
.. image:: ./media/interface-settings-storage.png
|
||||
:align: center
|
||||
|
||||
Storage size is computed as follows:
|
||||
|
||||
* the size of the PostgreSQL database
|
||||
|
||||
* the size of the disk files available in your container: database filestore, sessions storage directory...
|
||||
|
||||
.. Warning::
|
||||
In case you want to analyze disk usage, you can run the tool `ncdu <https://dev.yorhel.nl/ncdu/man>`_ in your Web Shell.
|
||||
|
||||
Should your production database size grow to exceed what's provisioned in your subscription, it
|
||||
will automatically be synchronized with it.
|
||||
|
||||
Database Workers
|
||||
================
|
||||
|
||||
Additional database workers can be configured here. More workers help increase the load your
|
||||
production database is able to handle. If you add more, it will automatically be synchronized
|
||||
with your subscription.
|
||||
|
||||
.. image:: ./media/interface-settings-workers.png
|
||||
:align: center
|
||||
|
||||
.. Warning::
|
||||
Adding more workers will not magically solve all performance issues. It only allows the server
|
||||
to handle more connections at the same time. If some operations are unusually slow, it's most
|
||||
likely a problem with the code, if it's not due to your own customizations you can open a ticket
|
||||
`here <https://www.odoo.com/help>`_.
|
||||
|
||||
Staging Branches
|
||||
================
|
||||
|
||||
Additional staging branches allow you to develop and test more features at the same time. If you
|
||||
add more, it will automatically be synchronized with your subscription.
|
||||
|
||||
.. image:: ./media/interface-settings-staging-branches.png
|
||||
:align: center
|
||||
|
||||
Activation
|
||||
==========
|
||||
|
||||
Shows the status of the project's activation. You can change the project's activation code if needed.
|
||||
|
||||
.. image:: ./media/interface-settings-activation.png
|
||||
:align: center
|
||||
@@ -0,0 +1,12 @@
|
||||
|
||||
==================================
|
||||
Status
|
||||
==================================
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
The status page shows statistics regarding the servers your project uses. It includes the servers availability.
|
||||
|
||||
.. image:: ./media/interface-status.png
|
||||
:align: center
|
||||
@@ -0,0 +1,9 @@
|
||||
|
||||
=================
|
||||
Overview
|
||||
=================
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
overview/introduction
|
||||
@@ -0,0 +1,11 @@
|
||||
|
||||
==============================
|
||||
Introduction to Odoo.sh
|
||||
==============================
|
||||
|
||||
.. youtube:: QuNsa9n9PMg
|
||||
:align: right
|
||||
:width: 700
|
||||
:height: 394
|
||||
|
||||
The documentation will help you go live with your Odoo.sh project in no time.
|
||||
Reference in New Issue
Block a user