NextERP/documentation
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

typos

Browse Source
This commit is contained in:
Denis Ledoux 2018-03-26 18:11:00 +02:00
parent d4a81dff3d
commit 77ec0bbcd6
4 changed files with 79 additions and 64 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
odoo_sh/advanced/containers.rst
View File

@ -9,23 +9,23 @@ Overview
Each build is isolated within its own container (Linux namespaced container).
The base is an Ubuntu 16.04 system, where are installed all required Odoo dependencies
as well as common useful packages.
The base is an Ubuntu 16.04 system, where all of Odoo's required dependencies,
as well as common useful packages, are installed.
The Odoo.sh team is open to install any system packages
as long as they are distributed by the official Ubuntu repositories.
`Leave us a feedback <https://www.odoo.sh/feedback>`_ if you would like a package which is not yet installed.
as long as they are distributed in the official Ubuntu repositories.
`Leave us a feedback <https://www.odoo.sh/feedback>`_ if you would like a package not yet installed.
If your project requires Python dependencies not installed by default in the container, or more recent releases,
you can define a *requirements.txt* file, listing your Python modules dependencies,
in the root of your branches. The platform will take care to install these dependencies in your containers.
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 to know how to write a *requirements.txt* file.
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/11.0/requirements.txt>`_.
The *requirements.txt* files of submodules are taken into account as well. The platform
looks for *requirements.txt* files in each folders containing Odoo modules: Not in the module folder itself,
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
@ -35,7 +35,7 @@ As the containers are Ubuntu based, their directory structure follows the linux
`Ubuntu's filesystem tree overview <https://help.ubuntu.com/community/LinuxFilesystemTreeOverview#Main_directories>`_
explains the main directories.
The Odoo.sh pertinent directories are presented in the below list:
Here are the Odoo.sh pertinent directories:
::
@ -95,11 +95,12 @@ While accessing a container with the shell, you can access the database using *p
odoo-addons-master-1=>
**Be careful !**
Use transactions (*BEGIN...COMMIT/ROLLBACK*) for every *sql* requests leading to changes
`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.
It happens to be distracted, and the transaction mechanism may save you.
Indeed, it gives you the opportunity to rollback your changes in case you make a mistake.
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.
@ -112,7 +113,7 @@ For example, it may happen that you forget to set your *WHERE* condition.
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 request:
In such a case, you can rollback to revert the unwanted changes that you just mistakenly did, and rewrite the statement:
.. code-block:: sql
@ -123,11 +124,11 @@ In such a case, you can rollback to revert the unwanted changes that you just mi
odoo-addons-master-1=> COMMIT;
COMMIT
However, do not forget to either commit or rollback your request after having done it.
An opened transaction may have locked records in your tables,
and your running database may wait for them to be released. It can cause a server to hang up indefinitely.
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 requests first. It gives you an extra safety ney.
In addition, when possible, use your staging databases to test your statements first. It gives you an extra safety net.
Run an Odoo server
==================
@ -173,6 +174,9 @@ In the above commands, the argument:
* *--max-cron-threads=0* is to prevent the scheduled tasks to run,
* *--stop-after-init* is to 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/11.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*":
@ -184,4 +188,4 @@ Look for "*odoo: addons paths*":
**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. As much as possible, make your tests in your staging databases.
Changes will be effective in the database. Always, make your tests in your staging databases.

22
odoo_sh/advanced/submodules.rst
View File

@ -14,8 +14,8 @@ 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 within your branch through submodules makes easier the deployment of your code and servers,
as you can clone the repositories added as submodules in the same time you clone your own 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.
@ -23,8 +23,8 @@ It's up to you to decide wether you want to pin the submodule to a specific revi
to a newer revision.
In Odoo.sh, the submodules gives you the possibility to use and depends on modules available in other repositories.
The platform will detect automatically that you added modules through submodules within your branches,
and add them within your addons path so you can install them in your databases.
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.
@ -44,7 +44,7 @@ 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 follow:
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.
@ -58,7 +58,7 @@ On Github, you can get the repository URL with the *Clone or download* button of
.. image:: ./media/advanced-submodules-github-sshurl.png
:align: center
At the moment, this is not possible to use this method to add private repositories.
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>`.
.. _odoosh-advanced-submodules-withgit:
@ -66,22 +66,22 @@ You can nevertheless do so :ref:`with Git <odoosh-advanced-submodules-withgit>`.
With Git (advanced)
---------------------
In a terminal, in the folder where is cloned your Git repository,
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 below command:
Then, add the submodule using the command below:
.. code-block:: bash
$ git submodule add -b <branch> <git@yourprovider.com:<username/repository.git> <path>
$ 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,
* *<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.
@ -95,7 +95,7 @@ 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 checkouted in the above steps.
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.

75
odoo_sh/getting_started/branches.rst
View File

@ -32,16 +32,20 @@ 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 for a change in a form view,
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.
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/11.0/reference/cmdline.html>`_.
In the case the changes in the commit prevent the server to restart,
or the modules update fails,
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 nevertheless have access to the logs of the failed updates so you can analyze what happened.
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 unavailabity time of the production database during the updates.
@ -63,7 +67,7 @@ That way, you do not have to worry about sending test emails to your contacts.
Scheduled actions are disabled. If you want to test them, you have to enable them or trigger their action manually.
Be careful though: If these actions perform changes on third-party services (FTP servers, email servers, ...)
used by your production database as well,
you might make unwanted changes in your production.
you might cause unwanted changes in your production.
The databases created for staging branches are meant to live at least two weeks.
After that, they can be garbage collected automatically.
@ -84,11 +88,9 @@ You can change this list of modules to install in your projects settings.
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.
This verifies your changes do not break any of the features tested by them.
You can therefore verify your changes do not break any of the unit tests,
and therefore any of the features tested thanks to them.
As for staging branches, the emails are not sent: They are intercepted by the mailcatcher.
Similar to staging branches, the emails are not sent: They are intercepted by the mailcatcher.
The databases created for development branches are meant to live at least three days.
After that, they can be garbage collected automatically.
@ -110,7 +112,7 @@ you can either:
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 revisions.
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.
@ -124,14 +126,15 @@ 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.
* Either, pass them manually from your staging to your production database, by copy/pasting them.
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:
@ -148,16 +151,16 @@ An overview of your branch history:
.. image:: ./media/interface-branches-history.png
:align: center
For each event, a status is displayed in the above right corner.
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 also got
the possibility to access the database thanks to the *connect* button.
When an operation is successful, you can access the database thanks to the *connect* button.
Mails
-----
A preview of the emails sent by your database. This is available only for your development and staging branches,
as the emails of your production database are really sent instead of being intercepted.
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
@ -180,7 +183,7 @@ A viewer to have a look to your server logs.
Different logs are available:
* install.log: The logs of the database installation. In a development branch, the logs of the tests is included.
* 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. This is available only for the production database.
@ -193,35 +196,41 @@ The fetching is automatically stopped after 5 minutes. You can restart it using
Backups
-------
A list of the backups available for download and restore, as well as the possibility to import a database.
A list of the backups available for download and restore, as well as the ability to import a database.
.. image:: ./media/interface-branches-backups.png
:align: center
Odoo.sh keeps backups for production databases: 7 daily, 4 weekly and 3 monthly.
Staging databases and development databases are not backuped.
Each backup includes the database dump, the filestore (attachments, binary fields), logs and sessions.
Staging databases and development databases are not backed up..
You nevertheless have the possibility to restore a backup of the production database on your staging databases, for
testing purposes, or to manually recover data that has been deleted unexpectedly 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 backups servers keep the same backups, as well as 3 additional monthly 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>`_.
The *import database* feature accepts database archives in the format provided by the standard Odoo database manager
(available for on-premise Odoo servers under :code:`/web/database/manager`)
or by the Odoo.sh backup download feature.
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>`.
Git commands
============
In the above right of the view, different Git commands are available.
In the top right-hand corner of the view, different Git commands are available.
.. image:: ./media/interface-branches-gitcommands.png
:align: center
Each can be copied in the clipboard to be used in a terminal,
and some can be used directly from Odoo.sh by clicking the *run* button.
Each command 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.
Clone
-----
@ -240,7 +249,7 @@ The *run* button is not available for this command, as it is meant to be used on
Fork
----
Creates a new branch based on the current branch.
Create a new branch based on the current branch.
.. code-block:: bash

2
odoo_sh/getting_started/builds.rst
View File

@ -1,5 +1,7 @@
:banner: banners/odoo-sh.jpg
.. _odoosh-gettingstarted-builds:
==================================
Builds
==================================