The 'xmlrpc'-based configuration parameters have been a misnomer since
the introduction of the generic HTTP service, years ago.

Hide these options from the server parameters, and replace them with
more appropriate 'http' ones:

 --xmlrpc-interface -> --http-interface
 --xmlrpc-port      -> --http-port
 --no-xmlrpc        -> --no-http

The config entries for these have been adapted as well.

The old parameter names are still silently supported in both
command-line arguments and config files. However they are
stored with the new names in the `tools.config` dict,
and when saving config files (with the -s option).

Also clarified and cleaned up the descriptions of the HTTP/WEB server
parameters.

And finally, added a short version `-p`, for the `--http-port` option.
Credits to @dreispt for this (via #19518)

Closes #19518
Closes #19778

opw:774104

While the currency code of the Algerian Dinar is DZD, (latin) currency symbol is DA.

Closes #13902

* Fix a bunch of ill-documented/incomplete/incorrect method docs
* add start of Sphinx extension to extract & integrate jsdoc into
  Sphinx documentation:

  - parse JS files (and don't blow up), uses a fork of pyjsparser as
    the project currently does not parse comments
  - extract cross-module dependency information
  - parse JsDoc comments using pyjsdoc and infer structure from code &
    jsdoc
  - ``ast`` CLI printing a simplified AST of the input files
  - ``dependencies`` creating a dependency graph of either all modules
    in the provided input files or the modules matching the specified
    filters (warning: will not work if missing dependencies),
    generates a .dot file
  - ``extractor`` generating a plain text module documentation (mix of
    rst and markdown styles, not anything formal)
* sphinx extension with an "automodule" directive taking a module name
  and generating the documentation for it

* crm, project

Add a new feature which allows to put a progressbar in the kanban
columns. The progressbar shows with the same color the amount of
records whose value of a given field are the same in the column.
It also indicate the sum of another given field or simply the total
number of records. It also allows to subgroup the column content.

To define a progressbar, add this as a direct child of the kanban
arch:

<progressbar field="<name of the field to use for subgroups>"
             colors="{<one possible value for the above field>: <success, warning or danger>, ...}"
             sum="<name of the field to sum or nothing to use total number of records>"/>

Also:
- Properly update record model data's parentID when moving a record
- ...

Closes #19425

Done at #19025

Closes #18989 

Closes #18852

Done at #18420

Some bits posterior or leftover from fffaf735

See also parent commit.

Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.

All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.

Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.

Also removed some dead code or improved the API to remove unnecessary
conversions.

* remove references to basestring & unicode (use relevant pycompat
  helpers)
* remove some str calls (either entirely or replaced by relevant
  helper, either text or native)
* use better API to avoid unnecessary conversions
* remove some XML declarations in views

* StringIO removed from stdlib, replace with io
* try to correctly handle BytesIO/StringIO (one is for bytes the other
  is for text)
* fix base64: Python 3 removed bytes-encoding and bytes-bytes
  codecs (via #encode) so replace all calls to str.encode('base64'),
  also b64encode is a bytes->bytes conversion so attempt to properly
  handle that

issue #8530

Before 9.0, it was possible to display aggregate values in grouped
Kanban view (like sum, average...). The aggregate was displayed in
the header of the column (see for example in 8.0 in Project >
Tasks).

This feature has been dropped in 9.0 because it didn't work
correctly, but the documentation hasn't been updated accordingly.

* mass_mailing, payment, point_of_sale, portal, survey, web, web_tour,
  website_blog, website_crm_partner_assign, website_event,
  website_event_questions, website_form, website_forum, website_gengo,
  website_hr_recruitment, website_links, website_mail,
  website_mail_channel, website_mass_mailing, website_quote,
  website_sale, website_sale_options, website_slides, website_twitter

This commit reviews the whole "JS side" of the web_editor and website
apps. This is a first step to be able to improve them with new and
better functionnalities; this commit is not supposed to change any
visual behavior.

The main goal was to achieve a structure similar to the backend one.
Now, the frontend side also has a root widget (like the WebClient)
and all other widgets are attached to it one way or another. This allows
the benefits of using the 'trigger_up' functionnality for example.

As RPC are now mainly done with the `this._rpc` functionnality (being
possible thanks to the parent hierarchy), the frontend will also be
possible to test thanks to QUnit in a future update (besides the "text"
editor side which still requires a refactoring to be able to do that).

---

Here are some of the changes:

(-) conventions and documentation

The code has been updated to follow JS conventions and a lot of code has
been commented (around +2000 lines of comment). This also means that
lots of functions have been renamed to use camelCase or simply to make
their name understandable.
See https://github.com/odoo/odoo/wiki/Javascript-coding-guidelines.

(-) deprecated: web_editor.base

The "web_editor.base" module has been split and does not force the
modules which require it to wait for DOM ready anymore. This was indeed
slowing loading times, but also prevented to use some modules in some
contexts (see the LESS editor use in web_studio which is the subject of
another task).
Now the "editor context" can be got thanks to the "web_editor.context"
JS module with its "get" function.
The "web_editor.base" module should probably not be used anymore (see
its code and recent updates).

(-) new: web.dom_ready

If a JS module should wait for the DOM to be ready to be executed, a
new JS module has been created: "web.dom_ready". This should always
be used in a module which only want to instantiate stuff. Do not
extend (or worst, include) classes after DOM ready.

(-) website.website

The "website.website" module has been split. "website.website" does not
return anything useful anymore, it just initialize some miscellaneous
stuff, without waiting for the DOM to be ready. You might want to check
"website.utils", "website.content.compatibility" or `WebsiteRoot`. Also
`website.form` has been deleted (use `this._rpc`), so has been
`website.error`. `website.prompt` will be removed in a future update to
be replaced by `Dialog.prompt`.

(-) widgets are great

Many classes which were not widgets are now widgets. This allows them to
use the 'events', the 'xmlDependencies' and the 'this._rpc' features for
example. Here are some of the main ones:

- Snippet options: these were classes with a `$el` for the menu element
    and `$target` for the customized element. This is still the case
    but following standard `Widget` structure (one exception: using
    `this.$(...)` searches in the `$target` as before this update).

- Snippet animations: instead of class instances with a `$target`
    element which can be `start` and `stop`, these are now standard
    widgets which can be `start` and `destroy`. `this.$target` is
    an alias to `this.$el` for ease of compatibility.

- Snippet editors: instead of class instances in charge of an editor
    overlay, these are now widgets. Each "child" snippet editor is
    properly attached as a "child", which allows editors to communicate
    and to be properly destroyed.

(-) root widgets and website navbar

The frontend is different of the backend. In the backend, the page has
an empty <body/> element and all the components are instantiated from
parent to children (i.e. the `WebClient` is instantiated and is in
charge of instantiating the `ControlPanel`, etc). The frontend cannot
work like that on page loadings as they are way more frequent than in
the backend and we do not want them to flicker. A frontend page is
loaded as a <body/> element which already contains the website navbar
and its menus and the whole content page. JS code has to be "attached"
to these existing elements. This is possible thanks to the `RootWidget`
instances and the specialized `WebsiteRoot`, `IframeRoot` and
`WebsiteNavbar` (see code for details).

(-) lazy loading

No more (or at least a lot less) XML/JS has to be loaded on page
loading, thanks to the use of the `Widget.xmlDependencies` feature.
XML which have to be lazy loaded is loaded only on related Widget
instantiation if necessary, which allows to execute a lot of JS code
before the DOM is ready and to start many widgets on DOM ready (not
later). A visual benefit of this is clicking on the 'edit' button as
soon as it is possible: before this commit, this was sometimes not
doing anything as event handlers were not binded yet.

Still a possible exception: loading the session and locales. This may
be asynchronous stuff which is still required before widget
instantiations but this will be the subject of another task.

(-) deprecated code and code location

More than reviewing code and organizing it, many apparent dead code was
removed. More importantly, mislocated code was put in the right app.
This is the case for snippet animations which is a concept for website
apps but was defined in the web_editor app, or some translation concepts
which were part of website but should have been part of web_editor.

---

There are probably more things to say about this commit but I will let
the comments speak for those.

The %d %h options in db-filter are case sensitive but the URL are not.
If you happen to use databases with uppercase in the name, using (?i) may be
needed to match the correct database.

Fixes #17407

Done at #18820

9a07a459 added "override=True" to silence a Sphinx warning in about
the address node already existing, however the override=True parameter
was added in Sphinx 1.4 (alongside the warning), so this breaks in
1.2.

Only pass in override=True if we're in 1.4 or later.

Closes #18232

This reverts commit bb7fef79.
Because now odoo merge report module into web one

Closes #18530

Done at #18591

Done at #18332

Done at #18314

To show forward slash in paths are needed and to use path guidelines

Closes #17989

Done at #18301

Done at #18000

to avoid "WARNING: Hunk"

Closes #18286

to highlight the modified line

Closes #18230

To be able to correctly use report features.
It is auto-install but a good idea to make sure it is present and to show the
report module

Closes #18220

The attendee_ids line was highlighted instead of the session_ids

Remove one excerice that was in the workflow section
Adapt the diff

Because now is no longer required

Closes #18144

The old release of wkhtmltopdf are no longer published on the download page.
The developer explicitely asks to use the github link

cf: wkhtmltopdf/wkhtmltopdf#3524
    wkhtmltopdf/wkhtmltopdf#3521
    wkhtmltopdf/wkhtmltopdf#3518
    wkhtmltopdf/wkhtmltopdf#3508

Closes #18146