- As of v10, manifest files should be named `__manifest__.py`
- For backwards-compatibility, __openerp__.py manifest files
  will still be supported for the time being
- Limited refactoring, to add support for the 2 different
  naming conventions
- All textual references to __openerp_.py updated in
  documentation and examples

Manifest files are literal Python dictionaries, and
aren't supposed to contain expressions that require
a full-fledged eval.
`literal_eval` is therefore sufficient *and* safer.

This parsing method was already used when listing addons
during startup of the Root controller (http.py, load_addons())

The test is never started and the tour is not up to date so remove it
from the DOM until it is converted to new tour system.

in "Website Admin" settings pricelist groups were not updated because they were
not declared in the view. added now.

Also added group to pricelists menu and fix typos.

rename options, add radio widget

installing a theme redirects to the website instead of the backend menu.

Using a safe_eval is overkill and can nicely be replaced by operator

Closes #13138

+ hparfr

Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:

- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
  translated

The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).

Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).

This commit correct all the external ids tagged as from base or other incorrect
modules.

hr_gamification should be adding hr groups to the security of gamification.
Creating the group base.group_hr_manager in gamification in case hr is not
installed is confusing and redundant with existing manager groups.

Creating a external id in a different module than the one where the record is
declared is a bad practice.
Setting a correct module is both important for a correct uninstallation of the
module (which uses the module to decide which records to remove) and for the
translations (records tagged with 'base' module needs to be declared in the
base.pot file).

one2many, many2many, text and html fields should take all space in a form view
for a better rendering instead of taking only 2 col or not having the label in
front the field.

When a model has no form defined, a default view is generated displaying all
fields of the model.
The one2many and many2many fields were not displayed on the form, probably for
aesthetic or historical (2008) reasons.

The snippet section can have a color or a background. Previous commit
added the functionnality for its innercolumn too... but having a bg
image on top of another one does not make sense, so only keep the
color option for columns.

- s_references
    * Replace demo images (lighter ones)
    * Move title to left
    * Review responsiveness
- s_big_message
    * Add background
    * Use grid system

* Replace demo blog post covers
* Add xml ID to demo images so they can be easily replaced by themes
* Remove unused images

In the merge partner wizard, there's a button in the footer which
trigger the method `action_close`. This method is decorated by
an api.multi and begins with an ensure_one() and if you click
on close directly after opening the wizard, self.ensure_one
fails.

The thing is, `action_close` only return an ir.action.act_window_close
action and there's a special attribue you can set in the form
view button to make it return an ir.action.act_window_close directly.
If we use this technique, then there's no traceback anymore. So this
is the fix.

Empty merge as 7bdd4de8 has already
been forward-ported with 33167a1e.

OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal
move for the delivery to debit outgoing inventory (since the goods don't
transit by an internal stock) but the sale does credit it so there was a
build up in the holding account that has to be moved out manually.
This was also reported in #12687.

The solution implemented is to check if the invoice line is related to
sale order lines having one of its procurement_ids with a purchase_line_id
set. If yes, it means that it is a confirmed dropship and in that case we
don't call to super (we don't create the cost of sale line).

That means that:
* If the procurement is in exception at the customer invoice time, the
behavior will be as it is currently, but it's fine as you don't know how
the procurement will be solved, and it'll be only at the beginning (once
the config is done it shouldn't go in exception anymore). People will have
to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account
(received)' on supplier invoices for dropshipped goods, but rather use the
COGS directly (sounds to me logical, and that's actually why I wouldn't go
for the solution to create the stock move entries every time even for the
dropshipped goods. That, and the fact that it would pollute the accounting
with useless moves).

This is a forward-port/cherry-pick of 7bdd4de8