Remove the patchqueue extension from the doc requirements since it isn't
maintained anymore (raising warnings for recent sphinx versions) and the
patches to specify code blocks aren't easy to maintain.
Remove hidden code patches, and replaces shown patches by code block /
literalincludes to keep the useful content.
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
- Update Enterprise & Partnership agreement (EN, FR)
- Update legal page index: hide outdated agreements, replace
with a link to an archive of the old PDFs.
- Add icons for missing files, to make index table layout more consistent
- Add `text-justify` on HTML versions of contracts, for consistency with
the PDF versions.
- Fix compatibility of PDF generation with recent sphinx versions
(\sphinxmaketitle instead of \maketitle)
- Re-add NL PDF building, still needs to be updated like all others
Backport of 5b80ed551c from 13.0
- Update Enterprise & Partnership agreement (EN, FR)
- Update legal page index: hide outdated agreements, replace
with a link to an archive of the old PDFs.
- Add icons for missing files, to make index table layout more consistent
- Add `text-justify` on HTML versions of contracts, for consistency with
the PDF versions.
- Fix compatibility of PDF generation with recent sphinx versions
(\sphinxmaketitle instead of \maketitle)
- Re-add NL PDF building, still needs to be updated like all others
Because:
- Mementos are already referenced multiple times in related toctrees.
- Only two mementos are remaining, which is not enough to justify a whole doc category.
- References to mementos are easily broken without being detected at compilation time.
Keep the language in multilang versions of pages. The canonical should look like:
/documentation/user/12.0/sale.html -> /documentation/user/13.0/sale.html
/documentation/user/11.0/fr/website.html -> /documentation/user/13.0/fr/website.html
Needs the changes at odoo/saas-automation#40 that will change the
canonical_root
- from https://www.odoo.com/documentation/user/
- to https://www.odoo.com/documentation/user/12.0/
This way, the language switcher will keep the current version,
changing from English to French will make
/documentation/user/12.0/website.html -> /documentation/user/12.0/fr/website.html
(and not -> /documentation/user/13.0/website.html as before)
Keep the language in multilang versions of pages. The canonical should look like:
/documentation/user/12.0/sale.html -> /documentation/user/13.0/sale.html
/documentation/user/11.0/fr/website.html -> /documentation/user/13.0/fr/website.html
Needs the changes at odoo/saas-automation#40 that will change the
canonical_root
- from https://www.odoo.com/documentation/user/
- to https://www.odoo.com/documentation/user/12.0/
This way, the language switcher will keep the current version,
changing from English to French will make
/documentation/user/12.0/website.html -> /documentation/user/12.0/fr/website.html
(and not -> /documentation/user/13.0/website.html as before)
Keep the language in multilang versions of pages. The canonical should look like:
/documentation/user/12.0/sale.html -> /documentation/user/13.0/sale.html
/documentation/user/11.0/fr/website.html -> /documentation/user/13.0/fr/website.html
Needs the changes at odoo/saas-automation#40 that will change the
canonical_root
- from https://www.odoo.com/documentation/user/
- to https://www.odoo.com/documentation/user/12.0/
This way, the language switcher will keep the current version,
changing from English to French will make
/documentation/user/12.0/website.html -> /documentation/user/12.0/fr/website.html
(and not -> /documentation/user/13.0/website.html as before)
Sections get an id automatically generated from the title, "journal
entries" and "chart of accounts" are pretty generic concepts, so the
widgets looking for these ids can get enabled on sections they're not
intended to live in.
On the other hand, Sphinx is not likely to generically create classes
for these concepts without being explicitly prompted (via
e.g. rst-class).
