Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.

- Move the empty res_config class and the related view from
  base_setup to sales_team (base_setup only contains the 'General Settings'
  model and views
- Move the 'sale' related content from product to sale module (Access rights,
  menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
  crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
  purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)

[FIX] account: move some ir.model.access to sale module
[FIX] payment: Move some ir.rule to website_sale
[FIX] stock: move some ir.model.access rule to sale_stock
[FIX] project: Move some ir.model.access rules to crm_project_issue
[FIX] mrp: Move some ir.model.access rules to sale_mrp
[FIX] calendar: move some ir.model.access rules to crm

Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.

[ADD] sales_team: See own documents => See only his sales team
Moved the "User: Own Leads Only", "User: All Leads" and "Manager" groups from sale and crm
into sales_team module. Add the record rules so that user can see only his Own Sales Team
if "See Own Leads" is sales right and can see all sales teams if he is having sales rights
of "See All Leads" or manager.

When doing an internal trasnfer, you can choose any destination
location in the header, but not on the line

This is problematic when doing a pick-pack-ship transfer. For the pick
move, you may want to change the source destination location (maybe another
warehouse why not) but as the transfer is already validated you cannot
modify it on the form. But with the Operation Details (Pencil button) you
can modify the source/destination location. The only problem is that a domain
is forcing the user to choose a source destination that is a child of the source
destination on the transfer, which makes impossible to choose a destination on
another warehouse. This tool is pretty much advanced, so we don't need to be so
restrictive.

The expected revenue in opportunity.report is in fact the probable
turnover. It was confusing with the field expected revenue in crm.lead.

opw:678062

The color of the button "create_move" in a depreciation line is
green if the related move is posted, orange if it exists but not posted and
red in the other case.

opw:678905

Specifically, replace `not node.getparent()` by `node.getparent() is None`.

portal_sale adds the security rules for website_portal_sale to work proprerly

Closes #12283

When tracking value is converted to be rendered as a message_post, we convert
the date/datetime with the current local from momentjs.

Related to #12327

Courtesy of @aab-odoo for help and review.

In odoo at many places the filter items are having repeated strings eventhough the
fiter works differently , so find all the places where this happens and give
proper string to each filter..

Purpose:
When we create a return transfer, the return location should be selected as
the default destination location of the "Picking type for return". Odoo should
be using that return location as the default return location during reverse transfer,
but only if the default destination location of the "Picking type for return" is a
return location

Specification:
For all transfers, if the default destination location of the "Picking type for return"
is a return location, then the return location should be selected as the default
destination location during reverse transfer.

The evaluated lang is within the variable
`d.context['lang']`

`lang` contains the non-evaluated `t` attribute,
so, in the case of `report_saleorder`,
`doc.partner_id.lang`

opw-680074

Add methods to query work days (entire) for resources for systems
working daily insted of hourly.

dict.fromkeys doesn't duplicate the passed 'values', hence the code
created a table with several times the same instance of values dict.

opw-679203

When the content of a Many2Many tag is too large, it is truncated. This
is an issue since there is no easy way to see it.

The fix adds a title on the tag with the content.

X-port of commit odoo/enterprise@bd3bfe04221b685d4e4eb7dbf000c4cd8b0b9d69

The product_id is the one of the timesheet line, not the one of the order (which
actually is the one of the first line).
Closes #12013

In the Filters, Group By and Favorites dropdowns,
when clicking outside the `li` elements but still
inside the dropdown menu itself
(like on the dividers,
or next to the advanced search `Apply` button),
the dropdowns was closed.

This behavior was annoying when doing an advanced search
with a field using the datetime picker, as, to close the datetime
picker, you have to click outside it, and when you did, it closed
automatically the filter dropdown... So you had to open it again to
finally apply the filter.

opw-674310

Having the number 8 in the code makes developers wonder 'why this number ?'. Naming it eases tensions in geek's mind.

- removed unnecessary/unused records from existing unittest cases
- converted yml test cases to python unitttest

Also,
- removed unused hr_bel_holidays_2008.xml file
- removed unused action with xml_id 'act_hr_employee_holiday_request_approved' from hr_holidays_views.xml

Both website_sale and website_quote have logic to independently
confirm sales orders when a successful payment transaction is
processed.
Rev 46c5f93b introduced an extra
check and logging for transactions with mismatching amounts in
website_sale, but the same change was not done in website_quote.

Consequently, when both modules were installed, the tx mismatch
check was bypassed by website_quote, and a spurious logging message
was emitted by website_sale if the website_quote logic had executed
first.

This patch makes tx handling consistent in both modules, and avoids
the misleading log message when both modules are installed.

this avoid to overwrite the configuration file at each update.

closes  #11722