Before this commit field width was not as expected because
its label defined in container(Ex: div,span)

This commit fix field width issue by giving o_td_label class
to container of label to properly compute its width

task-3032518

closes odoo/odoo#104727

Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

Change the way the uniqueness of the sequence numbers is ensured.
Instead of using a `SELECT FOR UPDATE` approach inspired from the
`ir.sequence`, or even a true UPDATE, we can use a constraint approach.

SELECT FOR UPDATE
=================

By doing a FOR UPDATE NO WAIT, we are throwing an exception when another
transaction is creating a move using the same sequence as this one, by
locking the row that holds the current greatest sequence.
Since the row doesn't change, the lock is released and the following
UPDATE is allowed. Because of this, a "useless" UPDATE was always done
on the previous row to ensure a SerializationFailureError if two
concurrent transactions were trying to assign the same number.
This means that in a database with a lot of concurrent transactions
(typically with an online shop), many transactions were
aborted/rollbacked.
This approach also has the drawback of having the constraint implemented
python side, which is less robust.

UNIQUE CONSTRAINT
=================

Using a constraint on the database level means that the database knows
when some transactions will try to do something similar. It will
therefore make the concurrent transactions wait instead of aborting the
transaction.
It is however harder to have the constraint customized by different
modules/localization because it is now done directly in the database and
not in python. Changing the constraint means deleting/recreating the
index. For now, this only happens for Latin America l10n, so a simple
hardcoded approach is implemented.
In order to achieve this, the business code is trying to use the
sequence incrementally until it gets a number it can use for when
multiple transactions are concurrent.

closes odoo/odoo#104606

Related: odoo/enterprise#34236
Signed-off-by: Quentin De Paoli <qdp@odoo.com>

2 fixes are made:
* We use a FOR NO KEY UPDATE instead of FOR UPDATE because we don't want
  to prevent the insertion of lines referencing the partner as a foreign
  key (i.e. new invoices).
  The data is purely informative and the exact value isn't too important
  anyways.
* We catch SerializationFailure on top of the previously catched
  LockNotAvailable. It can happen in this use case
  - T1 and T2 start
  - T1 acquires the lock and updates
  - T1 commits
  - T2 acquires the lock: it gets it because T1 released it
  - T2 updates: T1 did it as well so there is a serialization failure.

Part-of: odoo/odoo#104606

Sometimes a constraint is too complex to be expressed in the general
`_sql_contraint`.
This allows to hook on a constraint if it matches the name in order to
display a user friendly error message.

Part-of: odoo/odoo#104606

**Issue:**

When at the first page of the list, and the user deleted all/or some
of the records, the next page is not automatically displayed.

**Solution:**

This is because the first page (offset=0) is exempted from offset
adjustment (_adjustOffset) which is responsible in reloading the
records in the list.

In this commit, we propose to reload the list if the call to
`_adjustOffset` didn't call `load` and there are actually deleted
records.

closes odoo/odoo#106176

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

**Issue:**

- Open a list view and group the records. Notice the count per group.
- BUG: When deleting a record under a group, the count in the group
  is not updated.

**Solution:**

When calling `deleteRecords` in the `DynamicGroupList`, we call
`deleteRecords` on each group's `list`. This "list" can be
`DynamicGroupList` or `DynamicRecordsList`. Regardless which instance
calls the `deleteRecords` method, we should take the number of the
deleted records and subtract it from the group's current count.

If it turned out that the calling object is a `DynamicGroupList`,
we should make sure that it returns the ids of the deleted records
so that the parent group can update its count as well, that's why
we are collecting the deleted record ids.

It's not so easy to follow but we can roughly imagine the structure
this way:

DynamicGroupList
-> DynamicGroupList[]
   -> DynamicRecordsList[]

Deleting items from the inner dynamic records list should result to
update of the parent group list, and eventually, to the update of the
root group list.

Part-of: odoo/odoo#106176

When creating a record, if a value is related to a monetary field and if
the currency field is a non-stored related one, the value will not be
rounding: when writing the monetary value in the database, we first call
`convert_to_column`. In the parameter, `record` is empty (it is not yet
created) and `values` only contains the stored values (so the currency
value is not present). As a result, `currency` will not be defined and
the value will not be rounded.

OPW-2955202

closes odoo/odoo#106278

X-original-commit: 28196693b50b9d424887391ad13db69c5f5dfe4f
Related: odoo/enterprise#34255
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

Detailed Reason field in hr_departure_wizard view is now wrapped in a group for better organization.

task-3002105

closes odoo/odoo#101743

Related: odoo/enterprise#32087
Signed-off-by: Kevin Baptiste <kba@odoo.com>

Steps to reproduce:
    - install the "Subscriptions" module;
    - create a subscription;
    - got to the portal of the customer of the subscription;
    - click on the "Set/Manage Payment Method" buton;
    - add a new payment method.

Issue:
    An invoice is generated and therefore the next invoice date is incremented.

Cause:
    We do not check the type of operation when we finalize the payment process.
    And so a subscription renewal invoice is created.

Solution:
    Transactions with "operation" which is equal to "validation" are for tokenizer only (without payment).
    If "operation" is equal to "online_token", it is a payement which must be invoiced.
    Detect payment token change, if this is the case to not generate an invoice.

opw-3061621

closes odoo/odoo#106279

X-original-commit: 0213083478022939eeca3bc385b146296e2bbf23
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>

**Before this commit**
Various issues are present in the calendar filter autocomplete:
- typing a character in the input would close the autocomplete dropdown
- search for a term yielding to no results would not display the
  "No records" entry
- click on the "Search more..." entry yields to a validation error
  message: "a mandatory field is not set". [1]

**After this commit**
The FilterAutoComplete component has been removed as it was useless.
It was a kind of higher order component trying to manage the
AutoComplete component's input state, leading to unwanted complexity.

We decided to remove this component despite being in a stable branch
for the following reasons:
- it was not exported and only used by the CalendarFilterPanel
- it brought unnecessary complexity
- it was not working properly
- the branch is still a bit young
- the diff in the CalendarFilterPanel template is minimal

Now that the CalendarFilterPanel directly make use of the
AutoComplete component, the first listed issue has been solved.
The two other issues were simple fixes addressed in the mean time.

[1] this issue comes from opw-3031045, more infos below:
Steps to reproduce:
- Go to calendar basic view
- Click on "+ Add attendees" and then on "Search more ..."

Current behavior:
Validation error on partner_id in calendar_filter create

Expected behavior:
You can look for a partner with advanced research options

Explanation:
The code treated the "Search more ..." option like a partner
option instead off calling the onSearchMore method that creates
the advanced research dialogue.

opw-3031045

closes odoo/odoo#103532

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Martin Fockedey <mafo@odoo.com>
Co-authored-by: Hubert Van de Walle <huvw@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>

closes odoo/odoo#106280

X-original-commit: b09b8ef9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

closes odoo/odoo#105917

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Commit [1] actually "repair" the test theme installation that was
actually not calling `_post_copy()` for the website/themes created
through the `_post_init` hook of the `test_themes` module.
By doing so, the Nano theme now correctly activated the
`footer_language_selector` view, meaning that the tour would fail as
this Nano view would mess up with the tour (that Nano view was returned
on top of the Theme custo view).

Those website standalone tests should really be part of the regular
testing suite and not in the nightly build only:
1. This is getting really annoying to fix it again and again, we
   wouldn't have to do that if it was in the regular testing base as it
   could not be broken. This is a waste of time for no reason, as we
   need to investigate, understand and find a fix.
2. For now it only broke due to no real bug, most of the time it is
   because the test need to be adapted to a theme change or something,
   but one day someone will be able to break the website core mechanisms
   (COW, theme install etc) and this will be problematic.
   Note that if this was to happen, the runbot team will be handling the
   issue and the fix with the people that broke it, as it was promised
   when we discussed about moving those tests in the regular testing
   suite. It was the conscensus for us to accept to leave those tests in
   the nightly only (we didn't really had a choice tho).

[1]: https://github.com/odoo/design-themes/commit/fea847977d8bd4b0c0ddfc7685e3d3dc0933759c



closes odoo/odoo#106202

X-original-commit: 17a182fb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Some missing aria attributes from 14.0 are reintroduced.

They are required for screen reader users to be able to know if menus
are opened and if menuitems are checked (e.g. if a filter is applied).

closes odoo/odoo#106186

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: Luis González <lgonzalez@vauxoo.com>

Dropdown menus/items were refactored and moved to OWL when migrating to
15.0. Now, the focus is always on the dropdown button, which captures
and handles all keyboard events, to be able to move over the menus.
Currently-selected item is highlighted by toggling classes.

However, since the focus is always on the dropdown button, screen
reader users are  no longer able to know what menu item is being
selected, as it's only a visual change (in previous versions, the focus
actually moved to the selected element).

The above is fixed by making the activeElement follow the visual change.

Part-of: odoo/odoo#106186
Co-authored-by: Luis González <lgonzalez@vauxoo.com>

Graphs were not aligned depending on data. They will now stick to bottom of the card and fill consistently the space above.

closes odoo/odoo#106056

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

Before commit, clicking on the "App Store" and "Updates" menus in Apps
in debug mode causes a crash.

Why:
Since owl 2, rejecting a promise in onWillStat is considered an error
and so we have a crash. In our case, the error is already handled
(Display a notification and do a doAction). So we can resolve the promise.

The two menus ("App Store" and "Updates") will be removed in master.

closes odoo/odoo#106235

X-original-commit: 08c8d64eedb509cdeafa1cecceb28f00a3bd98f0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>

Since the conversion in OWL of the `many2one_barcode` widget, on Mobile
when we open the search more a filter value is added automatically in
the filter and so when we want to change the value we need an additional
step to remove the filter to see all records.

This commit, use a 'custom event' to open the barcode search and restore
the normal behaviour on the `click` event.

Steps to reproduce:
* Go to Timesheet
* Add a new line
* Select a project
* Try to change the project => BUG show only the selected project

closes odoo/odoo#106158

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Co-authored-by: Romain Estievenart <res@odoo.com>

It is not possible to post the journal entries related to an expense
paid by the company

Steps to reproduce:
1. Install Expense
2. Create an expense payable to company
3. Set an amount
4. Create report
5. Submit report
6. Approve report
7. Attempt to post
8. An error is thrown

Solution:
Relax the constraint on account.move.line linked to an expense paid by
the company

Problem:
The constraint `_check_payable_receivable` in the account module forbids
to post the journal entries even though they are correct

opw-3038648

closes odoo/odoo#105850

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

Steps to reproduce:
    - install sale_management module;
    - go to settings of sale_management and check "Automatic invoice" parameter;
    - in debug mode, we can see the template selected (do not change it);
    - save the settings;
    (This is just one example)

Issue:
    The parameter is not added to the "ir_config_parameter" table.

Cause:
    The improvement which consists in comparing the settings which one wishes to record with those which already exist in order to set the parameters which are different creates a problem.
    Indeed, the current settings are retrieved directly from the model with their default value if there is one.
    These are the values that will be used for the comparison.
    Because of this, when we want to save a parameter which is set to its default value (on first save), the logic will not notice a difference.
    Therefore, the parameter will not be saved in the "ir_config_parameter" table.

Consequence:
    In the code, when we wanted to look up the value of a parameter, if it is not saved, we use its default value instead of saving it with its default value.
    Example:
    ```
    field_example = fields.Integer(string='Example', default=1000, config_parameter='model.field_example')
    value_field_example = params.get_param('model.field_example', default=1000)

    ```
    The default value is repeated.

Solution:
    To know whether or not we add a new parameter in the "ir_config_parameter" table, we must look at what already exists in the table and not in the settings defined in the model.

opw-3057306

closes odoo/odoo#106184

X-original-commit: d881dfaaa163b409a94494e35afa2cbda7cf2aa2
Related: odoo/enterprise#34233
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Before this commit, new model term translations cannot be saved if it has been
translated before.
The reason is while translating fr_FR
the backend needs the mapping {old_term_fr: new_term_fr} to update old_value_fr
However the UI sent {old_term_en: new_term_fr} which was wrong

This commit fixes the bug by changing the key of the mapping from the
old_term_en to the old_term_fr

opw-3074712

closes odoo/odoo#106174

Signed-off-by: Samuel Degueldre <sad@odoo.com>

closes odoo/odoo#106051

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>

Change class="oe-blackbox" to data-oe-protected="true" (same purpose), because
the name was decided in a rush before 16.0

When the editor history management and sanitization (sanitize.js) handle nodes
of an embedded view, OWL can become corrupted, which will lead to a traceback.

This commit uses the attribute data-oe-protected="true" to prevent
historyRollbacks or sanitization, and ensure that protected elements children
are removed during the cleanForSave operation.

The collaborative DOMPurify sanitization is untouched, for security reasons. To
properly use `data-oe-protected` in collaborative mode, a more complex
mechanism should be put in place to ensure that the protected element children
are properly reconstructed for each client, and that it is not part of the
collaboration. (i.e.: embedded view in knowledge do not support the
collaborative mode currently).

This commit also blocks the selection handling in tables which would be in a
data-oe-protected="true" node.

Task-3012552

closes odoo/odoo#102887

Related: odoo/enterprise#32627
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>

Steps to reproduce:
    - go to Contacts app;
    - add a reporting view (Graph, Pivot or Dashboard) (with studio for example)
    - tape any character in the search bar;
    - on "search related company for" field either use the arrow keys to go down to this and then click the right arrow key or click on the triangle to the left of this field.

Issue:
    An error occurs.

Cause:
    There is a mismatch between the parameters that are sent by the rpc call and those processed by the logic part.
    Specifically, the domain must be part of the kwargs and not the args of the params key in the rpc call.
    The problem occurs with a filter that looks like: `<field name="parent_id" domain="[('is_company', '=', True)]" operator="child_of"/>`

Solution:
    Move domain in kwargs under key named args in the params of the rpc call.

opw-3031096

closes odoo/odoo#106069

X-original-commit: 8a9b418b27dcc9b904413f14cd0443f9a5b10d17
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>

add missing neutralization scripts for modules introduced in Odoo 16

closes odoo/odoo#104355

Related: odoo/enterprise#33328
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

add missing neutralization script for modules introduced in Odoo 16

Part-of: odoo/odoo#104355

The job_title field was too narrow and misaligned on mobile.
Removed the help text for the Contacts smartbutton.

task-3070980

closes odoo/odoo#106223

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

Issue :
- Liechtenstein adapted the same QR-Invoice as Switzerland.
However, Odoo only allows the issuance of QR-Invoices to
swiss customers

https://www.llb.li/en/private/paying-and-saving/payment-services/qr-bill#:~:text=Standing%20orders%20based%20on%20orange%20payment%20slips%20can%20no%20longer%20be%20processed%20after%2030%20September%202022.%20Therefore%2C%20these%20standing%20orders%20need%20to%20be%20newly%20set%20up%20on%20the%20basis%20of%20QR%20bills

.

Fix:
- Allow LI users to be issued QR-Invoices

OPW-2977644

closes odoo/odoo#106207

X-original-commit: e7704303
Related: odoo/enterprise#34219
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>

This commit aims to solve the reported issue where printers are switching states from "connected" to "disconnected" and stay unreachable for 2 minutes. Now theavailable printers will be searched for multiple times before disconnecting them
task 2891909

Fixes 2687380
Fixes 2856101

closes odoo/odoo#106173

X-original-commit: ac0ca14c
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

**Issue:**

- Open a list view with `expand="1"` and `limit=<arbitrary small number, say 5>`.
- BUG: The pager shows that it's displaying the limited records, but in reality,
  it's displaying all records under each group.

**Solution:**

This is because we are *not* limiting the number of records being fetch in the first
read_group rpc. We are now specifying the expand_limit in this commit.

closes odoo/odoo#106126

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

Currently, in mass mailing, the user cannot be redirected to the next
page after clicking "upload a file" in the import mailing list.

This is because the contact list field is mandatory, so when the user
clicks "upload a file" with an empty contact list, it is unable to
be redirected to the next page, as it saves the wizard before executing the
action.

This commit fixes the above issue by making the contact list field
not mandatory anymore in the wizard view.

Oversight of: aa183fa2

taks-3070829

closes odoo/odoo#106119

Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

This PR

Reverts the change in #105425 as the code is redundant see Discussion
Fixes the issue and explain the details as it doesn't get triggered from
inventory adjustment view but from current stock view in location X.

Steps to reproduce:
- Install inventory
- Activate storage locations
- Allow import in Locations/WH/Stock/Current Stock
- Export the current stock of WH/Stock
- Change the Location in the file to WH/Output
- Import the modified file

In the Location/Current stock view,  the _load_records_write/create methods are bypassing the allowed_fields checks in the def create/write since this check only occurs when _is_inventory_mode() = True. This can cause inconsistencies if there are quants reserved. To solve the problem we set inventory_mode to True so that the method returns True and the checks are triggered (and prevent these inconsistencies).

Task id: 3007499

closes odoo/odoo#106068

X-original-commit: 7240c5b19e9c06fe22a929ca3ec83115c29a5c7f
Related: odoo/enterprise#34144
Signed-off-by: Tiffany Chang <tic@odoo.com>

**Steps to reproduce:**

- go to a product page
- replace image (=> image is shown)
- click on "Save manually" (the cloud upload icon)
- BUG: previous image is displayed.

But it was saved: if you move to another record and return then it
shows the correct one.

**Solution:**

Basically, in an image_field: If its props.value is a "binary size",
then the image source is a url pointing to a server endpoint and
this url is based on the rawCacheKey, otherwise, we use the "base64"
of the uploaded image.

The proposed solution for the said issue is to invalidate the
rawCacheKey during upload. Then, during the calculation of image url
(at `getUrl`), we reassign the rawCacheKey with the newest
"__last_update" value of the record when needed (if the props.value
is a "binary size").

closes odoo/odoo#105672

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Field tooltip lacks domain information because of a small mistake in
`getTooltipInfo` function.

To reproduce: open a form in debug mode and hover any many2one field that has
domain in its configuration. Example: ``hr.expense:sale_order_id``

opw-3049554

closes odoo/odoo#105290

Signed-off-by: Samuel Degueldre <sad@odoo.com>

Steps to reproduce the issue (see opw):
- Add a form to a page
- Add a checkbox
- Add a second checkbox that is required and visible only if the first
  checkbox is not checked
- Save
- Do not check anything and try to send => Good, you can't, the required
  checkbox is not set
- Check the second checkbox and try to send => Good, you can, the
  required checkbox is set
- Go back to the empty form, check the first checkbox and try to send
=> Bad, you can't but you should: the required checkbox is hidden, it
   is not supposed to be required anymore.

(Not that arguably, that two checkboxes setup should be replaced by a
required selection field but the issue of the OPW would remain as there
is another required conditionally-hidden field (a file upload) when the
second checkbox is checked.)

Conditionally-hidden fields should not require validation while they are
hidden. Indeed, their purpose is to be able to enter additional data
when some condition is fulfilled. If such a field is required, it is
only required when visible. The problem only occurred with checkboxes,
the other fields were already working in that case. Although there could
be issues with dates too, this commit added a series of FIXME and TODO
comments as well as some things need to be investigated.

opw-3003952

closes odoo/odoo#106102

X-original-commit: ec09033634ee9710ce1bd774d088699fa372c356
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit, when submitting a website form which has invalid
radio buttons, checkboxes or file upload elements, they had no visual
difference. Now they will have red labels as intended with bootstrap.

For alone checkboxes, a warning label will appear after the checkboxes.
This will only take effects for newly added checkboxes.

Related to opw-3003952

X-original-commit: d0049cfefb3496661a578af8003af1d71ed34c4c
Part-of: odoo/odoo#106102

With [1], checkboxes in website forms were wrapped in a <div/> with the
"form-check" bootstrap class (as they should). That forgot to mark the
checkboxes themselves with the class "form-check-input". Without it they
are misaligned.

This fixes the error for newly added checkboxes in forms. Old ones will
stay "broken".

[1]: https://github.com/odoo/odoo/commit/9ea276ae2f00c3a5ba4e10af313085947e70e265

Related to opw-3003952

X-original-commit: 080e497e80209d7b6500d088ed36b821ccc19605
Part-of: odoo/odoo#106102

Before this commit, if the user tried to setup a required selection
field whose first value is empty, it was possible but the empty value
appeared as a 0px-height div in the DOM preview. That empty value also
shows up when trying to use the conditionally-hidden fields feature: if
another field's visibility depends on such selection field, the editor
UI was visually broken as the first choice was an empty option element.

Now, we show "<no value>" in both cases.

Note: this is not done in earlier versions than 15.0 although the
problem exists, but it was decided that the real problem was about the
visibility select being visually broken and that feature only appeared
in 15.0.

Related to opw-3003952

X-original-commit: 003ecc6a560f5b284b4bd3b864007a1c4ccf8f47
Part-of: odoo/odoo#106102

The `comment` field was not properly displayed since the move to grid display.

closes odoo/odoo#106175

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

Steps to reproduce:
1. Create a membership product for a period of time in the past,
 and one including the current day
2. Create a member, make him non-free
3. Create an invoice for the member for the past membership, cancel
 the invoice
4. Note that membership state is not updated to `cancelled` (Problem 1)
5. Change the `date_cancel` on membership.membership.line
 to a date in the past
6. Add an invoice for the current membership, note that the state is
 updated to `cancelled`
7. confirm the invoice and register payment, note that the state is
 not update to `paid` (Problem 2)

This line in `_compute_membership_state` causes the bug to appear:
```
if partner.membership_cancel and today > partner.membership_cancel:
    partner.membership_state = 'free' if partner.free_member else 'canceled'
    continue
```

To solve the issue, we remove the lines of code that made the state
to be stuck and use the membership lines only to calculate the correct
state.

opw-2978902

closes odoo/odoo#106169

X-original-commit: addd3fbf
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Khanalizadeh Ahmad (khah) <khah@odoo.com>