[ADD] odoo_sh: documentation

odoo_sh/advanced.rst

@@ -0,0 +1,11 @@
+:banner: banners/odoo-sh.jpg
+
+=================
+Advanced
+=================
+
+.. toctree::
+   :titlesonly:
+
+   advanced/containers
+   advanced/submodules

odoo_sh/advanced/containers.rst

@@ -0,0 +1,6 @@
+==================================
+Containers
+==================================
+
+Overview
+========

odoo_sh/advanced/submodules.rst

@@ -0,0 +1,6 @@
+==================================
+Submodules
+==================================
+
+Overview
+========

odoo_sh/documentation.rst

@@ -0,0 +1,12 @@
+:banner: banners/odoo-sh.jpg
+
+==========================
+Odoo.sh Documentation
+==========================
+
+.. toctree::
+   :titlesonly:
+
+   overview
+   getting_started
+   advanced

odoo_sh/getting_started.rst

@@ -0,0 +1,14 @@
+:banner: banners/odoo-sh.jpg
+
+=================
+Get started
+=================
+
+.. toctree::
+   :titlesonly:
+
+   getting_started/create
+   getting_started/branches
+   getting_started/builds
+   getting_started/status
+   getting_started/settings

odoo_sh/getting_started/branches.rst

@@ -0,0 +1,313 @@
+:banner: banners/odoo-sh.jpg
+
+==================================
+Branches
+==================================
+
+Overview
+========
+
+The branches view gives you an overview of the different branches your repository has.
+
+.. image:: ./media/interface-branches.png
+   :align: center
+
+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 on the stage section title.
+
+.. image:: ./media/interface-branches-stagechange.png
+   :align: center
+
+Production
+----------
+This is the branch holding the code on which your production database run.
+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,
+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.
+
+In the case the changes in the commit prevent the server to restart,
+or 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.
+
+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.
+
+Staging
+-------
+Staging branches are meant to test your new features using the production data.
+
+When you push a new commit in one of these branches,
+a new server is started, using a duplicate of the production database and the new revision of the branch.
+
+You can therefore test your latest features using the production data without compromising the actual
+production database with test records.
+
+The outgoing emails are not sent: They are intercepted by the mailcatcher,
+which provides an interface to preview the emails sent by your database.
+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.
+
+The databases created for staging branches are meant to live at least two weeks.
+After that, they can be garbage collected automatically.
+If you make configuration changes or view changes in these branches, 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 relies on the demo data, which are 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 creates new databases using the demo data and running the unit tests.
+The modules installed and tested by default are the ones included in your branches.
+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.
+
+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.
+
+The databases created for development branches are meant to live at least three days.
+After that, they can be garbage collected automatically.
+
+Merging your branches
+---------------------
+You can merge your branches easily by drag and dropping them on 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 revisions.
+
+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 git directly to merge your branches.
+Odoo.sh will be notified 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 versionning 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.
+
+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 above right 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.
+
+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.
+
+.. image:: ./media/interface-branches-mails.png
+   :align: center
+   :scale: 50%
+
+Shell
+-----
+A shell access to your container. You can perform basic linux command (:kbd:`ls`, :kbd:`top`)
+and open a shell on your database by typing :kbd:`psql`.
+
+.. image:: ./media/interface-branches-shell.png
+   :align: center
+
+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 is 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.
+
+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.
+
+Backups
+-------
+A list of the backups available for download and restore, as well as the possibility 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.
+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.
+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 :kbd:`/web/database/manager`)
+or by the Odoo.sh backup download feature.
+
+Git commands
+============
+In the above right 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.
+
+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*.
+
+* :kbd:`--recurse-submodules`: Downloads the submodules of your repository. Submodules included in the submodules are downloaded as well.
+* :kbd:`--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
+----
+Creates 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.
+
+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 `git-scm documentation about submodules <https://git-scm.com/book/en/v2/Git-Tools-Submodules>`_ can help you to know
+more about *submodules*.
+
+.. 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.
+
+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.
+
+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.

odoo_sh/getting_started/builds.rst

@@ -0,0 +1,116 @@
+:banner: banners/odoo-sh.jpg
+
+==================================
+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.
+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 closed 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 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 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.
+
+.. image:: ./media/interface-builds-build-dropdown.png
+   :align: center
+
+In the dropdown menu of the build, you can access the features `already explained for the branches view <./branches.html#tabs>`_:
+*Logs*, *Web Shell*, *Outgoing e-mails*.
+You also have the possibility to *Download a dump* of the build database.

odoo_sh/getting_started/create.rst

@@ -0,0 +1,70 @@
+:banner: banners/odoo-sh.jpg
+
+==================================
+Create your project
+==================================
+
+Deploy your platform
+====================
+
+Go to `Odoo.sh <https://www.odoo.sh/>`_ and hit the button *Deploy your platform*.
+
+.. 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 link *Create an account*.
+
+.. image:: ./media/github-signin.png
+   :align: center
+
+Authorize Odoo.sh
+=================
+
+Grant Odoo.sh the required accesses to your account by clicking the button *Authorize*.
+
+.. 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* or *contract number*.
+
+For partners, Odoo.sh is free. If the free offer changes in the future, we guarantee that any project created under this offer will remain free for the same set of features.
+
+For customers, your Enterprise subscription needs to include Odoo.sh.
+
+After 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).
+
+.. image:: ./media/deploy-form.png
+   :align: center
+
+You're done !
+=============
+
+You can begin to use 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/getting_started/settings.rst

@@ -0,0 +1,191 @@
+:banner: banners/odoo-sh.jpg
+
+==================================
+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 is the domain that will be used to access your production database.
+
+The domain to access your staging and development builds will contain this name as well.
+However, when you change your project name, only future builds will use the new name.
+
+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           |     X     |     X     |
++---------------------+-----------------+-----------+-----------+
+|                     | Mails           |     X     |     X     |
++---------------------+-----------------+-----------+-----------+
+|Production & Staging | History         |     X     |     X     |
++---------------------+-----------------+-----------+-----------+
+|                     | 1-click connect |           |     X     |
++---------------------+-----------------+-----------+-----------+
+|                     | Logs            |           |     X     |
++---------------------+-----------------+-----------+-----------+
+|                     | Shell           |           |     X     |
++---------------------+-----------------+-----------+-----------+
+|                     | Mails           |           |     X     |
++---------------------+-----------------+-----------+-----------+
+|Status               |                 |     X     |     X     |
++---------------------+-----------------+-----------+-----------+
+|Settings             |                 |           |     X     |
++---------------------+-----------------+-----------+-----------+
+
+Public Access
+=============
+
+Allow public access to your development builds.
+
+.. image:: ./media/interface-settings-public.png
+   :align: center
+
+Expose 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.
+
+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.
+  The ` submodules <https://git-scm.com/book/en/v2/Git-Tools-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.
+* *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.
+
+All installed modules will be tested.
+The tests in 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.
+
+Custom domains
+==============
+
+Configure your own domain name.
+
+.. image:: ./media/interface-settings-customdomains.png
+   :align: center
+
+If you would like to access your production database using your own domain name, you have to:
+
+* own or purchase the domain name,
+* add the domain name in this list,
+* in your 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, an 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 domains managers have the feature to configure this redirection. This is commonly called a web redirection.
+
+HTTPS/SSL
+---------
+
+You can use a third-party CDN such as *Cloudflare.com* to enable the *HTTPS* support for your custom domain:
+  * `Create a Cloudflare account <https://support.cloudflare.com/hc/en-us/articles/201720164-Step-2-Create-a-Cloudflare-account-and-add-a-website>`_
+  * `Change your domain name servers to Cloudflare <https://support.cloudflare.com/hc/en-us/articles/205195708-Step-3-Change-your-domain-name-servers-to-Cloudflare>`_
+  * `Choose an SSL mode <https://support.cloudflare.com/hc/en-us/articles/201897700-Step-4-Recommended-First-Steps-for-all-Cloudflare-users#sslmode>`_
+  * `Redirect your visitors to HTTPS <https://support.cloudflare.com/hc/en-us/articles/200170536-How-do-I-redirect-all-visitors-to-HTTPS-SSL->`_
+
+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 `Advanced/Submodules <../advanced/submodules.html>`_ chapter of this documentation.
+
+.. image:: ./media/interface-settings-submodules.png
+   :align: center
+
+When a repository is private, this 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 git server allows our platform to download the revisions
+of this private repository.
+
+To configure the deploy key for a private repository, proceed as follow:
+
+* 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: Settings > Deploy keys > Add deploy key
+  * Bitbucket.com: Settings > Access keys > Add key
+  * Gitlab.com: Settings > Repository > Deploy Keys
+  * Self-hosted: append the key to the git user’s authorized_keys file in its .ssh directory

odoo_sh/getting_started/status.rst

@@ -0,0 +1,13 @@
+:banner: banners/odoo-sh.jpg
+
+==================================
+Status
+==================================
+
+Overview
+========
+
+The status page shows statistics regarding the servers your project use. It includes the servers availability.
+
+.. image:: ./media/interface-status.png
+   :align: center

odoo_sh/overview.rst

@@ -0,0 +1,10 @@
+:banner: banners/odoo-sh.jpg
+
+=================
+Overview
+=================
+
+.. toctree::
+   :titlesonly:
+
+   overview/introduction

odoo_sh/overview/introduction.rst

@@ -0,0 +1,12 @@
+:banner: banners/odoo-sh.jpg
+
+==============================
+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.

practical.rst

@@ -6,6 +6,7 @@ Practical Information
    :titlesonly:
 
    getting_started/documentation
+   odoo_sh/documentation
    db_management/documentation
    db_management/db_online
    db_management/db_premise