Use case:
It happens that a product is consumed in different operations.
So it needs two distinct BoM lines. Since commit [1] the stock.move
in pbm are not merged. However [1] was design for kit.
In our case we would like to have only one stock.move for all the
quantities.

The fix is not perfect because it won't work if we confirm at the
same time a move with a kit and without it. But at least it will let
people using MO without kit has the correct behavior

+ remove a duplicate of the function

[1] commit 741d2fe9

closes odoo/odoo#125733

X-original-commit: f7414901
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

The purpose of this commit is to review the responsiveness and spacing
of some settings that were visually broken.

The nested checkboxes were growing too much on smaller screens
making the content overflow.

This commit adapts these checkboxes settings to make them more readable
and consistent.

Task-3113372

closes odoo/odoo#108902

Related: odoo/enterprise#35323
Signed-off-by: Tiffany Chang <tic@odoo.com>

In the website settings, one of the fields allows you to switch settings
from one website to another. Unfortunately, as soon as the user did this
the record was considered to have changed (dirty) and therefore required
a save when it wasn't necessary. The previous commit prevents the header
settings (like the website switcher) from dirtying the record. This was
really necessary because as soon as a user had several websites, it was
impossible for him to access certain settings on all these websites
(except the first one). As soon as the setting performed an action, a
save was required (because the record was dirty) and the user was
redirected to the settings again.
Steps to reproduce the issue before the previous commit:

Install website
Have multiple websites
Go to Settings > Website Settings
Change the website
=> The user is notified that the record has changed and needs to be
saved, which is not true. So far it's annoying but not critical, but if
the user continues:

Activate the "Extra step during checkout" option
Click on "Configure Form"
=> The Save/Discard dialog appears because the record is dirty.

Click on "Save"
=> The user is redirected to the settings page again and cannot access
the form configuration of the second website. (it is the same issue for
most of actions).

The previous commit fixes the issue and this commit adds a test to
ensure that the users are able to change settings of multiple websites.

task-3265100

closes odoo/odoo#125550

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

When a user changes a header setting, the record should not be marked as
dirty. If the user clicks on a button, the save dialog should not be
shown.

Next commit will bring a functional test and "steps to reproduce" of
this issue in website.

task-3265100

Part-of: odoo/odoo#125550
Co-authored-by: "Guillaume (gdi)" <gdi@odoo.com>

closes odoo/odoo#124901

Signed-off-by: Josse Colpaert <jco@odoo.com>

The ZATCA edi has an onboarding process which happens per journal.
A private key is generated for the company and with the data from
the company and journal a CSR is made to get a certificate to sign the
invoices.  In that process that contains multiple steps (see account_journal.py),
we also have to send the compliance files which are some example (simplified or not)
invoices/debit and credit notes.  We have a separate folder with those files
and also use them in the tests.  For the onboarding, they still need to be signed however.

For the sending of the customer invoices themselves, UBL 2.1 is used, but
with ZATCA style adaptations.  That is why we inherit from that class
to be able to add those specific adaptations.  This UBL needs to be
signed XadeS and in this case we need to do the hash with the sign information
present but with empty tags.

For ZATCA invoices, as is the case with Ticketbai, the previous hash is needed
for the next invoice and is stored per journal.  (so we have a chain of hashes)

Tests written by Simon (smdc)

Part-of: odoo/odoo#124901

For SA, we need to be able to filter on the taxes exported, as
certain taxes should simply not be reported in the UBL.

Part-of: odoo/odoo#124901

+ to comply with ZATCA provide a better demo VAT number

Part-of: odoo/odoo#124901

Currently, when selecting tags for a task with no project (private
task) on mobile, a warning is displayed. On top of that, the amount
available tags is way more limited than in classical view and the
selection of some exesting tags is impossible.

Steps
=====
1. Warning when selecting tags
- Install module project
- In mobile view, go to the view "Tasks -> My Tasks"
- Open or create a private task (task with no project)
- Click on the tags field

A warning is displayed (on the server logs) stating:
"The domain term '('project_ids', 'in', False)' should use the '=' or
'!=' operator."

2. Limited tag choice
- Install module project
- In mobile view, go to the view "Tasks -> My Tasks"
- Open or create a private task (task with no project)
- Click on the tags field
- The tags that are only related to project(s) are not displayed in this
  view
- Try to create a tag with the same name than an existing tag that does
  not appear.
- A traceback is displayed because this tag already exists.

Cause
=====
As noted from the test of expression.py, M2M fields in the domain should
be compared to list of elements. It is not the case here. When a
project_id exits in the context, nothing happens, but there exists a
check in the ORM to ensure that '=' or '!=' operator is used if the
second element of the domain leaf is a boolean. In this case, there is
not project_id set in the context for private task, resulting in
the previous warning (False used instead of project_id).

Fix
===
We use the improved implementation of _name_search to get the ordered
list of id of records project.tags to display. This list has the
advantage to not be restricted to the current project, while still
presenting the tags of the current project at the top of the list. The
mobile view uses the method search_read to get the list of project.tags
record values, therefore we call the _name_search in this method and use
an optimized sorting function to sort the resulting records accordingly.

task-3302370

closes odoo/odoo#110814

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

When picking a mailing template, the size of the contents of the iframe
changes but we failed to signal it so the iframe could resize as well.

closes odoo/odoo#125740

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

When notification type is set as sms we need to check whether the template
which is referenced is coming from a correct model or not.

Applying this commit will fix this issue.

sentry-4195133685

closes odoo/odoo#125709

X-original-commit: 6cb268230cab571fe39ee755b06b24a2a3cd5579
Related: odoo/enterprise#42827
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Saurabh Choraria (sauc) <sauc@odoo.com>

In https://github.com/odoo/odoo/pull/123074

, the fix done did not take the formatting of numbers
bigger (or equal) than 1000 into account.
For example, 1000 become "1.000,00" and parsing it again will return a 1.

To fix this, simply modified the thousandsSep to an empty array

closes odoo/odoo#124963

Signed-off-by: Steve Van Essche <svs@odoo.com>

'replace() argument 1 must be str, not bool' is generated if the user edit a
float or monetary section in the website view.

Steps to Reproduce

- Make debugger mode ON.
- Go to Settings > Translations > Languages.
- Remove the value of the 'Thousands Separator' field from the current user
language.
- Install the 'eCommerce' module.
- Go to the website.
- Go to the shop menu, and click any product from the product list.
- Click on the Edit button and try to edit any float or
monetary section like a product price (eg. change a product price from 750 to
70) and click on the Save button.

And traceback will be generated.

Applying this commit will resolve this issue.

sentry-4148693017

closes odoo/odoo#125667

X-original-commit: b895175c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

The `sol_product_many2one` field is a sub many2one field that should
open the proper configuration system, such as the product configurator.

Before this commit, when inputting some data, then clicking on another
notebook tab, we would often see a crash, because the field has been
destroyed (since it is no longer in the current tab) and it tries to
open the configurator, which requires rpcs.

It is usually a problem when a destroyed component tries to perform some
work. Note that it happens at creation and update. Also, the field
overrides some many2one methods that display confirmation dialog. To fix
this, this commit simplifies the field by only calling the configuration
methods when its value has changed. This is a different strategy that
does not interfere with the many2one basic features. Also, it does not
crash since it will only call the configuration methods on patched, so
it is guaranteed to be alive.

It is certainly not a complete solution, since we should probably move the
code somewhere else not in a field widget, but this would require a
redesign of the code, so it is not appropriate in a bug fix anyway.

Note that the tour had to be adapted, since now the methods
_onProductUpdate/_onProductTemplateUpdate are now called in an effect
(so after a render), which is slightly later than before. But the tour
would click on confirm even before the product update code was executed,
which means that the product was not properly configurated.

This is clearly a concurrency problem: the product configuration code
should be properly coordinated with the basic model, but doing so is a
significative change. Also, in practice, it is not worse than before
this commit.

opw 3178297

closes odoo/odoo#123264

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

When user deletes 'Portal User Template' record from 'res.users' model and when
'action_open_template_user' function is executed at that time traceback is
generated on the user side as well as in the log.

Steps to reproduce:
    1. Install Website module.
    2. Go to settings > Users&Companies > Users.
    3. Remove Internal Users from default filter.
    4. Add Inactive Users in filter and delete Portal User Template.
    5. Go to Website Settings > Privacy > Customer Account.
    6. Click on Free sign up and then on Save button.
    7. Now in Website Settings click on Default Access Rights button.
    8. The error will occur.

Applying this commit will fix this issue.

sentry-4184456381

closes odoo/odoo#121757

Signed-off-by: Rémy Voet <ryv@odoo.com>

The values for the key "async" found in some services is used to declare
async methods that should be "protected". The hook "useService" makes sure
that no code used to process results of those protected methods is
executed by a destroyed component. The orm method "webSearchRead" was
not protected due to a "typo".

closes odoo/odoo#125679

X-original-commit: 2899888a
Signed-off-by: Géry Debongnie <ged@odoo.com>

The values for the key "async" found in some services is used to declare
async methods that should be "protected". The hook "useService" makes sure
that no code used to process results of those protected methods is
executed by a destroyed component. The orm method "nameGet" was
not protected due to a "typo".

closes odoo/odoo#125627

Signed-off-by: Géry Debongnie <ged@odoo.com>

Let us consider the search arch

    <search>
        <field name="foo"/>
        <searchpanel>
            <field name="bar"/>
        </searchpanel>
    </search>

The two tags "field" are supposed to generate different objects:
 - the first one should generate an entry in the search bar autocompletion
 - the second one should generate a search panel section.

It turns out that the second field did also generate an entry in the
search bar. This is of course wrong. We fix that problem and add a test.

closes odoo/odoo#125594

X-original-commit: 15aefa56
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>

Commit 1e82e273 adds cogs account move lines for 'ship later'
config at the picking validation. The issue appears if the delivery flow
is in multiple steps. The account move lines will be created for each
pickings.

This commit ensure the last one actually create the aml only

closes odoo/odoo#125358

Opw: 3324972
X-original-commit: b7e3db6f16e0ce42b226fecce05dfa5b586190fd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Commit 1e82e273 makes ship later option create additionnal account
move line for Cogs at delivery validation. The issue is the accounts was
not correct. The desire result should be the following for a product of
cost 10, sale price 11 and 15% taxes.

 At PoS Closing                             | Debit | Credit
-------------------------------------------------------------
215000 Taxes 15%                            |  0.00 |   1.50
200000 Pos account                          |  0.00 |  11.00
600000 Expenses                             |  0.00 |   0.00
101200 Account Receivable                   | 11.50 |   0.00
110300 Stock interim (delivered)            |  0.00 |   0.00
-------------------------------------------------------------
                                            |       |
 At delivery validation (manually created)  |       |
-------------------------------------------------------------
110300 Stock interim (delivered)            |  0.00 |  10.00
600000 Expenses                             | 10.00 |   0.00
-------------------------------------------------------------
                                            |       |
 At delivery validation (from stock layers) |       |
-------------------------------------------------------------
110100 Stock valuation                      |  0.00 |  10.00
110300 Stock interim (delivered)            | 10.00 |   0.00

Opw: 3324972
X-original-commit: b7e3db6f16e0ce42b226fecce05dfa5b586190fd
Part-of: odoo/odoo#125358

If there are some dependencies between BoM's operations, a traceback
will appear when the user removes one WO.

Steps to produce:
- From Manufacturing > Configuration: Enable Work Orders.
- Open any Bills of Material.
- In 'Miscellaneous' tab tick the 'Operation Dependencies' boolean.
- Set 3 or more operations in the 'Operations' tab.
- After saving the BOM add 'Blocked By' in the operations.
- Now Create Manufacturing Order for that BOM.
- Delete the one or more workorder(s) from mrp order.
- Now click on the 'Confirm' button, and the error will be raised.

The loop is incorrect because we iterate on the BoM's operations but
the keys of the dict `workorder_per_operation` are based on the MO's
work orders. Therefore, if we remove one WO, the dict will not have
any key for the related operation, hence the traceback.

sentry-4146643254

closes odoo/odoo#120745

Related: odoo/enterprise#41956
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

This commit improves the performance of `_is_applicable_for`, by:

1) Leveraging the `product.category.parent_path` field.
2) Use `applied_on` for the `if` conditions, which is ~100% faster than using
   the many2one fields due to the related record initialization.

These micro-optimizations are important because of the way `_is_applicable_for`
is used.

See: https://github.com/odoo/odoo/blob/0a5d84289/addons/product/models/product_pricelist.py#L169-L193



Which, for demostration purposes, could be simplified to:

```
for product, qty, partner in products_qty_partner:
    for rule in items:
        if not rule._is_applicable_for(product, qty_in_product_uom):
            continue
```

On a database with 470 products, and about the same number of pricelist items,
these optimization result in a ~30% speedup when computing prices for all
products at once. It may be even better depending on how many nested product
categories are used in the database and in the pricelist rules.

closes odoo/odoo#125553

X-original-commit: ab121290
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

`_lt` must be used instead of `_t` for `gettext`s that are called when
the file is loaded.

closes odoo/odoo#125538

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Commit 91d0e9c6 made sure that excluded
combination did not appear in /shop search results, but it significantly
slowed down searches, even in databases without exclusions.

Since the excluded combinations cannot be added to the cart (and the
original feedback did not come from an effective ticket), we believe
the gain is not worth the cost.

This commit reverts that change.

Task-3326948

closes odoo/odoo#125187

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Because if a tag is still linked to a tax or an account, then it's probably also still referenced in a report line, and it makes no sense allowing to delete such a tag.

closes odoo/odoo#124789

Signed-off-by: William André (wan) <wan@odoo.com>

This commit separates the test that was added together with the "not
move images twice within image wall" fix because it requires additional
fixes for working in 16.0.

task-2990053

closes odoo/odoo#124608

X-original-commit: fa233f80
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>

*: web_editor

During the masonry layout calculation of the images wall snippet, the
image height is used to determine into which column each image is
inserted. Their height is zero until they are actually loaded. Because
of this, the column into which an image is inserted can be wrong.

This becomes more obvious in 16.0 because since [1] the image selection
is lost when moving it within an Image Wall because it is replaced by a
clone when using masonry mode.

This commit makes sure that the images are loaded before taking their
height into account when building the masonry layout.

This involves two changes:

1. By awaiting `wUtils.onceAllImagesLoaded(this.$target)` after the
insertion of each cloned image, we are sure that the reached height of
each column is available before deciding where to insert the next image.

2. Before re-selecting the previously selected image, we need to be
sure that it is loaded. Therefore we keep track of the last masonry
layout operation and await for it. This way, we rely on the await of
the last image as described in point 1.

Additionally, as of 16.0, there is a race condition with
`snippet_option_update`: in some situations, `notify` is called before
`snippet_option_update` is completed, and before the masonry layout is
applied.  To make sure it is completed, the whole notify is run within
the mutex through a `snippet_edition_request` event.

To uphold the stable policy, making `mode` async will only be done in
master.
In stable, a new `_modeWithImageWait` is added which is called only
for the situations that causing an issue, and which enables the fix
of the masonry layout.
In 14.0, it is used when computing the layout from `start` and
`addImages`.
In 16.0, it is also used in `notify` when images are removed or moved
around - because masonry clones the images.
In master, it is always applied.

Additionally, this commit also rounds the computed size of images inside
the masonry layout calculations.

Steps to reproduce:
- Drop an Images Wall.
- Add four images, the first one being taller than the others.

=> The fourth image sometimes appeared below the tall image.

[1]: https://github.com/odoo/odoo/commit/0d43aec24baad6420e0fe150a9c19d33c0b74198

task-2990053

Part-of: odoo/odoo#124608

Since [1] the "Images Add/Remove All" buttons are on top of the
background options in order to appear as the first option for the
"Image Wall" snippet.
This makes the JS related to the handling of the options of that
snippet created twice: once for the buttons above and once for the
options below.
Because of this, events are registered by both instances and they both
get notified on option update. Therefore, when an image is moved, it is
moved twice instead of once.

This commit differentiates both instances, and makes the one that
handles the "Add" and "Remove All" buttons be the only one that works on
the images.
In stable the differentiation is done with conditional statements.
In master the instances should be of distinct classes.

Steps to reproduce:
- Drop an "Images Wall" block.
- Switch the "Mode" option to "Grid" instead of "Masonry".
- Select the wine glass image in the third column.
- Click on "Move to previous".

=> The wine glass image ended up in the first column because it was
moved twice.

[1]: https://github.com/odoo/odoo/commit/b6494fcf284edcddaa36b5fcfd407a6d7186fbd7

task-2990053

X-original-commit: fa233f80
Part-of: odoo/odoo#124608

Inside the Images Wall snippet, images are dispatched to columns
depending on the height already reached by each column. This computation
relies on a sub-pixel height which leads to a confusing behavior.

This commit rounds the sub-pixel height to a visible pixel height to
avoid the confusion.

Steps to reproduce:
In the default images of the Images Wall snippet, the third image (sign)
is one pixel taller than the other ones.
- Drop an Images Wall snippet.
- Select the "sign" image.
- Move it to the first position.
(Because of another bug involving a race condition with the loading of
images, you might observe a different behavior. Move to first position
again to recompute the layout several times.)

=> The compass image moved to the first column.

task-2990053

X-original-commit: 1fc45be924e904dc595af61e0845b91cc5d24a49
Part-of: odoo/odoo#124608

When using the previous button in an image wall, the image wraps around
but skips the last position.
When using the next button in an image wall, the image does not wrap
around.

This commit fixes this inconsistency by using the same behavior as the
one in 15.0 since [1]: wrap through all positions in both directions.

Steps to reproduce:
- Drop an "Images Wall" snippet.
- Add 6 images.
- Select an image.
- Click repeatedly on "Move to previous".

=> The image wraps around all positions except the last one.

- Click repeatedly on "Move to next".

=> The image does not move anymore once it reached the last position.

[1]: https://github.com/odoo/odoo/commit/3931f0a67f904daea6c891a3a80aa984760a7682

task-2990053

Part-of: odoo/odoo#124608

If applied, this commit will solve the issue of unsupported operand type in
journal item(s) when currency is not set.

Steps to produce:
- Accounting > Journal Entries > Create new entry.
- Add a line in Journal Items and remove the currency from that line.
- Save > Error will be generated.

Fix this issue by calling the compute of the currency when the currency is not
available.

sentry - 4069681536

closes odoo/odoo#122462

Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

Steps to reproduce
==================

- Go to Accounting > Accounting > Journal Entries

The total at the bottom is not displayed and there is a `-` instead.

Cause of the issue
==================

The `amount_total_signed` field uses the currency_field
`company_currency_id`.
It should be present in the view for the web client to be aware of it's
value.

opw-3316448

closes odoo/odoo#125360

Signed-off-by: William André (wan) <wan@odoo.com>

In JavaScript, createTextNode() escapes it's contents, so instead of
appending ' ' as text, we should append the character corresponding
to a non-breaking space. Alternative would be to use innerHTML.

odoo-helpdesk ticket 3372476

closes odoo/odoo#125089

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

To reproduce (V16):
 0. Install Accounting (can also be reproduced with just Invoicing, but
 there is no "journal item" menu that will ease the process to show the
 issue)
 1. (In debug), change the dollar currency rounding to 0.0001
 (instead of 0.01)
 2. Go to Accounting > Customers > Invoices
 3. Create a first invoice with:
  - a partner P1
  - set an invoice date
  - make sure that there is a payment term set (for example "30 days")
  - at least one invoiced line (the product does not matter) with the
  tax 15 % and the price to 12.36
 DO NOT confirm the invoice
 4. Create another invoice with
  - ANOTHER partner P2
  - set an invoice date
  - make sure that there is a payment term set (for example "30 days")
  - at least one invoiced line (the product and the price does not
  matter)
 5. Go back to the Invoices list view and select the 2 new (unposted)
 invoices then Action > Post entries.
 6. Check Force and "Post Journal Entries"
 7. Go to Accounting > Reporting > Journal Items
 8. Group by "Journal Entry" and unfold the 2 last invoices (that should
 be the one validated in 6.)
=> The "Partner" set on the Debit Line is the one of the other invoice
(and vice versa)

Analyse:
 This issue is a mix of different sub-issues. Solving any of this
 sub-issue would solve the issue but as other sub-issues may exists we
 will fix each of them individually.

 Sub-issue 1:
  The account.move.line (=AML) partner is set correctly before the post
  (6.), this is during the "mass posting" process that the issue happens.
  The partner is changed because of this line:
  https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2094-L2096
  The value written to AML of id `line_id` include `move_id` which
  overwrite the account.move that was originally set on the AML.
  As the `partner` is computed only in certain circumstances, if the
  `move_id` written differ from the one of the AML, most of the values
  will be updated with the write values, but the `partner_id` will keep
  its value (this is why the swap of partner happen).

  In other words, this issue happen as `line_id.move_id` order is
  different from `key["move_id"]`. So we write on the "wrong" AML.

 Sub-issue 2:
  In theory, this issue should not have happened in the first place.
  The line:
  https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2061
  should have prevent the re-edition of the AML (as actually no relevant
  datas are written). But the equality between the dictionaries fail due to some rounding errors.
  Here:
   - needed_after[<key Invoice 1>]["balance"] --> 14.214000000000002
   - needed_before[<key Invoice 1>]["balance"] -> 14.213999999999999
  N.B: if we don't set an "invoice date" on the invoice, a rewrite is
  done before which would prevent our issue to reproduce.

 Sub-issue 3:
  If we try to reproduce the issue without setting a "payment term", the
   issue would not reproduce.
  By setting a "payment term" the `to_delete` computation change at:
  https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2067


  This happens as the `existing_before` keys and `needed_after` keys are
   different:
  - existing_before[<key Invoice 1>]["discount_date"] -> False
  - needed_after[<key Invoice 1>]["discount_date"] ----> None
  As the values are different, Odoo all the AML to the `to_delete` which
   then trigger their overwrite.

  In other words, if no "payment terms" were set on the invoices, the
  issue would not happen either

opw-3270471,3292931,3333799

closes odoo/odoo#124517

Signed-off-by: William André (wan) <wan@odoo.com>

before this commit, in the mobile view, in the search bar
of the website users(forum) and events leader board,
the placeholder is shown as Search courses

after this commit, the wrong placeholder will be updated
to Search users in the placeholder as in the normal view.

closes odoo/odoo#123016

X-original-commit: 7e94e8a147cc1344b87d9800db7428384aa4b8e2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Hennecart Jérémy (jeh) <jeh@odoo.com>

At the moment, there is no test that checks that normal credit notes
(i.e. of type TD04, not reverse-charge refunds) are correctly exported
in FatturaPA.

So we're adding one. We're making it a complicated credit note (it
contains some negative amounts) in order to improve the test coverage.

closes odoo/odoo#122930

Signed-off-by: Josse Colpaert <jco@odoo.com>

When we go into customer preview of a quotation for example and change the language different than English (to fr_BE for example)
we see that some of the content isn't translated  and still displaying in english.

Steps to reproduce the error :
1-Install sales and website app
2-Create a quotation for a customer and just save it don't confirm it.
3-Go to customer preview
4-Change the language to fr_BE
5-Click on "signer & payer"
6-You can see that it still display 'Full Name' in english and also some other terms

The origin of the problem is that all the parts that were rendered via a t-call gets rendered in english.
I investigated the problem and it turns out that the language code for the _t is alwyas english(https://github.com/odoo/odoo/blob/06719a84c52c7a97487b7ee0bef3bbe166d5b502/addons/portal/static/src/js/portal_signature.js#L45)
The problem is that the user_context.lang is always undefined here (https://github.com/odoo/odoo/blob/06719a84c52c7a97487b7ee0bef3bbe166d5b502/addons/web/static/src/legacy/js/core/session.js#L201)
As a solution I copied the code from 15.0 which was working fine (https://github.com/odoo/odoo/blob/4fa2dbcaf777c23758519ab0feb9707a7592cd6b/addons/web/static/src/legacy/js/core/session.js#L199-L209

).

opw-3192666
.

closes odoo/odoo#122447

Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

By RPC an other user in other company can access to an other fec.

closes odoo/odoo#125391

X-original-commit: 857f2e02
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

In this commit we have made the following changes.
- Add new refuse reasons:
       - Languages issues
       - Role already fulfilled
       - Duplicate
       - Spam
       - Refused by Applicant
- Modify refuse reasons:
       - Refused by Applicant: don't like job
       - Refused by Applicant: better offer
- Clickable job position breadcrumb in website.
- Set default applicant when we create new email template
- Use the `selection_badge` widget in Refuse Reason wizard

task-3336247

closes odoo/odoo#122434

Signed-off-by: Kevin Baptiste <kba@odoo.com>