Antoine Vandevenne (anv)
e3fee2cf46
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
50 lines
1.9 KiB
ReStructuredText
50 lines
1.9 KiB
ReStructuredText
===============================
|
|
How to adapt an import template
|
|
===============================
|
|
|
|
Import templates are provided in the import tool of the most common data to
|
|
import (contacts, products, bank statements, etc.).
|
|
You can open them with any spreadsheets software (Microsoft Office,
|
|
OpenOffice, Google Drive, etc.).
|
|
|
|
How to customize the file
|
|
=========================
|
|
|
|
* Remove columns you don't need. We advise to not remove the *ID* one (see
|
|
why here below).
|
|
* Set a unique ID to every single record by dragging down the ID sequencing.
|
|
|
|
.. image:: media/dragdown.gif
|
|
:align: center
|
|
|
|
* When you add a new column, Odoo might not be able to map it automatically if its
|
|
label doesn't fit any field of the system.
|
|
If so, find the corresponding field using the search.
|
|
|
|
.. image:: media/field_list.png
|
|
:align: center
|
|
|
|
Then, use the label you found in your import template in order to make it work
|
|
straight away the very next time you try to import.
|
|
|
|
Why an “ID” column
|
|
==================
|
|
|
|
The **ID** (External ID) is an unique identifier for the line item.
|
|
Feel free to use the one of your previous software to ease the transition to Odoo.
|
|
|
|
Setting an ID is not mandatory when importing but it helps in many cases:
|
|
|
|
* Update imports: you can import the same file several times without creating duplicates;
|
|
* Import relation fields (see here below).
|
|
|
|
How to import relation fields
|
|
=============================
|
|
|
|
An Odoo object is always related to many other objects (e.g. a product is linked
|
|
to product categories, attributes, vendors, etc.). To import those relations you need to
|
|
import the records of the related object first from their own list menu.
|
|
|
|
You can do it using either the name of the related record or its ID. The ID is expected when
|
|
two records have the same name. In such a case add " / ID" at the end of the column title
|
|
(e.g. for product attributes: Product Attributes / Attribute / ID). |