closes odoo/odoo#133066

X-original-commit: 854923b8
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>

X-original-commit: b9de6fc2
Part-of: odoo/odoo#133066

Bug
===
The labels of the properties and their names are always required,
the check was wrongly done and still used the historical name "id"
instead of "name".

If a property value is missing, the color of the label is marked in red.
But the datepicker and dropdown are also in read which we don't want
(only the label).

Task-3188915

closes odoo/odoo#123640

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

After this commit, we prevent the slideshow from appearing when clicking
on an "Images Wall" snippet image that has been set as a link.

Steps to reproduce the bug:

- Drag and drop an "Images Wall" snippet onto the page.
- Add some images in the snippet.
- Click on an image within the snippet.
- In the editor text toolbar, click on the "Link" button.
- Set the URL of the link to "/contactus".
- Click on the "Save" button in the modal.
- Save the page.
- Click on the image with the link.
- Bug: The slideshow briefly appears before redirecting to the "contact
us" page.

task-3425624

closes odoo/odoo#133347

X-original-commit: 8b29eabb
Signed-off-by: Colin Louis (loco) <loco@odoo.com>

A customer has a gift card product linked to a specific income account.
When sold, the income account associated with the gift card product is
credited correctly. The issue arises when the gift card is consumed
within a sales order. An order line is added using a "dummy product" to
indicate the gift card's usage (one dummy product is created for each
loyalty program). Due to this, when an account move is created from the
sale order, the income account defined on the dummy product is used
instead of the one on the gift card product. This leads to the wrong
income account being debited, causing unbalanced accounting entries.

There's currently no way to link back to the original gift card product
from a `loyalty.card` record. Because of this, the system cannot
identify the correct income account to debit. Fixing this would require
adding a new field, which we can't do in stable.

A potential workaround is to find the dummy product and set the income
account to the same as the gift card product. However, with one dummy
product for each `loyalty.program`, all named "Gift Card", finding the
right dummy product is difficult.

This commit aims to simplify the workaround by adding a link to the
associated dummy product on the `loyalty.program` form view. This change
should ease the process of finding and modifying the correct dummy
product, thus mitigating the issue in the current stable version.

opw-3239720
opw-3373287

closes odoo/odoo#132857

Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>

A check was added to prevent importing records with prefixes of existing
modules: https://github.com/odoo/odoo/pull/130825

 . This queries the
known modules, but non-admin users don't have access to that by default,
causing the import to fail for them. Allow the module query regardless
of access rights.

closes odoo/odoo#133351

X-original-commit: e1dcf886
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Merel Geens <mege@odoo.com>

Issue :
When you try to import a big file it will display a blank error.

Steps to reproduce the error :
1-install inventory and e-commerce
2-go to products and import records
3-upload the file attached the ticket

Reason :
Before, there was a type included in the `reason` but now
it seems that the error has no type neither a message.

Fix:
I tried to just output a general error.

opw-3410954

closes odoo/odoo#133329

X-original-commit: 26a1c91e
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>

This commit fixes the behavior of those customized buttons, used in
form view footers, aiming at saving/discarding the changes. The expected
behavior is that the dialog closes itself when those buttons are pressed,
which was no longer applied since the rewrite of views in Owl.

Also, the newly created value was not selected after saving the record.
Now, it selects it immediately if a button with special="save" has been
pressed.

A test has been added to verify that dialogs behaves correctly and close
themselves when clicking such buttons.

task-3254368

closes odoo/odoo#128244

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

This traceback arises when a user tries to make a payment on the website.

To reproduce this issue:

1) Install 'website_sale'
2) open invoicing/configuration/journals
3) Change the journal type if it is 'sales'
4) Install and enable 'Wire Transfer' payment provider in
   invocing/configuration/Payment Providers
5) Now open 'website/shop' add any product to cart and proceed to checkout
6) Make a payment with 'Wire Transfer'

Error: 'ValueError Expected singleton: account.journal()'

On '_compute_sale_order_reference' method, 'invoice_journal' variable
is getting values with the reference of 'type=sale'.
See:-
https://github.com/odoo/odoo/blob/ebc4ed6c4fb11b01be28cf417b27de83d5361cef/addons/sale/models/payment_transaction.py#L20-L30



Because of user changed the type of journal, 'invoice_journal'
value will be empty recordset and it is referenced to call
'_process_reference_for_sale_order' method.

In '_process_reference_for_sale_order' method ensure_one() is used,
which leads to above traceback.

sentry-4392496618

closes odoo/odoo#131934

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

closes odoo/odoo#133290

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

For some localization, an invoice is created automatically when creating
a pos_order. This leads to a PDF being donwloaded for every pos_order
done during a session which might be annoying for the cashier.

This commit adds a method that is meant to be overriden by those
localizations so that this invoice is not printed everytime.

closes odoo/odoo#133171

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

Interac is the most popular Canadian debit card system [1]. To support
Interac payments in Stripe two changes were made [2]:

- "interac_present" was added as a payment_method_type when creating
  the payment intent, and
- Interac payments are never captured

interact_present should only be added if the Stripe account being used
is Canadian [3] and transactions take place in CAD [4]. If either of
these is not true Stripe will return an error when creating the
payment intent. Stripe Terminal doesn't support non-native currencies
[5], so checking the currency should be enough, but to be extra
defensive we also check the country on the company before adding the
payment_method_type. [6]

To stop capturing we check the type on the payment_method and bypass
captureAfterPayment. We also add a check on canBeAdjusted because
these payments cannot be adjusted later on.

A known limitation is that it won't be possible to refund customers
via Interac. This requires an API call (not possible via Stripe
Dashboard) and isn't feasible in a stable release. Refunding needs to
happen with cash.

Testing this is not possible with a physical reader since Stripe
refuses to send Interac test cards to non-Canadian addresses. Instead
a simulated reader was used [7]. When developing this simulated reader
discovery was explicitly enabled in the code:

await this.terminal.discoverReaders({simulated: true})

Afterwards Stripe Terminal can be configured so that the next
transaction it simulates is an Interac one. To do so the following was
executed in a browser console:

posmodel.payment_methods[{ID}].payment_terminal.terminal.setSimulatorConfiguration({testPaymentMethod: 'interac'})

This only affects the next transaction, subsequent transactions will
use the default card_present again.

[1] https://www.interac.ca/en/content/business/interac-by-the-numbers/
[2] https://stripe.com/docs/terminal/payments/regional?integration-country=CA#create-a-paymentintent
[3] {'error': {'code': 'card_present_type_not_supported',
           'message': 'The interac_present source type is not supported in US.',
           'request_log_url': 'https://dashboard.stripe.com/test/logs/xxx',
           'type': 'invalid_request_error'}}
[4] {'error': {'code': 'card_present_currency_not_supported',
           'message': 'The interac_present source type with currency usd is '
                      'not supported in CA.',
           'request_log_url': 'https://dashboard.stripe.com/test/logs/xxx',
           'type': 'invalid_request_error'}}
[5] https://support.stripe.com/questions/stripe-terminal-country-and-currency-availability
[6] Ideally the supported payment type should be determined by the
payment_icon_ids m2m on payment.provider. But since pos_stripe
currently doesn't use that field this approach was chosen.
[7] https://stripe.com/docs/terminal/payments/connect-reader



opw-3376103

closes odoo/odoo#128491

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

Before this commit when we login as a user having project rights and open the
form view then 'project status' stat button isn't clickable. So in this commit
we have fixed that issue by giving group project user groups to stat button .

task-3432384

closes odoo/odoo#132962

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

It's possible to specify an existing module as the xml id prefix when
importing records from a file. This will result in `ir_module_data`
records being created with `noupdate` set to False. When the module is
upgraded, these records will be deleted.

This can lead to undesired side effects like journal items for
accounts imported this way being deleted.

This change prevents creating new records linked to existing modules
when importing from a file. Instead, the user should either use no
prefix or the name of a non-existent module, like `__import__`.

opw-3231987

closes odoo/odoo#133237

X-original-commit: 8f12d14c4c4354a63c94f14e7a89abc6048525f9
Signed-off-by: Merel Geens <mege@odoo.com>

Steps to reproduce:
-------------------
- create a job position without specifying the company;
- being in the first company, create an application for this job position;
- being in the second company, create an other application;
- go to the job position kanban view;

Issue:
------
Despite the selected company, the count for this job application is still two.

Solution:
---------
Include the allowed companies in the query to count the number of applicants.

opw-3453348

closes odoo/odoo#133236

X-original-commit: 8bce129a
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>

When the user tries to import the invoice file with space on both sides
of the date value the error will be generated.

Steps to reproduce:
1. Install the `account_edi_ubl_cii` module.
2. Generate one `factur-x.xml` file or import this file
https://drive.google.com/file/d/1RCqLT37j2g6LPkauf75LpOzZt64XHd_L/view?usp=drive_link
3. Go to the invoice app and click the `upload` button.
4. Select the `factur-x.xml` file and an error will be generated at the backend
and nothing to be imported.

This commit fixes the issue by removing the extra spaces in the date value,
if user gives the spaces in the invoice file.

see-
https://github.com/odoo/odoo/blob/a0ea6302a574624604cad7d0903711b30a4802a6/addons/account_edi_ubl_cii/models/account_edi_xml_cii_facturx.py#L315



sentry-4331059603

closes odoo/odoo#132617

X-original-commit: 1f32b5ec
Signed-off-by: Laurent Smet (las) <las@odoo.com>

Since Odoo 16 [1] account module uses some non-storable computed Binary fields
to compute and access structured data. Those data is not transformed into binary
data and is not supposed to be used outside of server environment. There are
still use cases when ORM tries to process such fields as normal Binary fields.
For example, on using export wizard [2].

This commit fixes similar problem on reading `account.move{.line}` records via
rpc.

STEPS: create `account.move` record and read it via an RPC call [3]

```
account_move_id = 666
models.execute_kw(db, uid, password, 'account.move', 'read', [account_move_id])
```

SOLUTION

1. Add missing `exportable=False` to the fake Binary fields
2. Block access to such fields via method `check_field_access_rights`

[1]:
https://github.com/odoo/odoo/commit/d8d47f9ff8554f4b39487fd2f13c153c7d6f958d
[2]: https://github.com/odoo/odoo/commit/c925ecb2a22750524020f0d111888fd76eedb0cb
[3]: https://www.odoo.com/documentation/16.0/developer/api/external_api.html



opw-3099975

closes odoo/odoo#110699

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

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

- Login as a user with no rights
- Use a mobile viewport
- Create a new Maintenance Request
- Edit the Created By field

-> A traceback occurs because the user has no rights

Solution
========

We extend the Many2OneField to accept a relation option and Depending on
whether the user has the rights, use the correct one.

This is similar to 41eaff0f

opw-3430105

closes odoo/odoo#132197

Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>

Before this commit:
When printing a receipt with an epson printers models TM-U2X0 (like
TM-U220), random characters will be printed instead of the receipt.

This happened as a picture of the receipt is sent to the IoT box, but
the TM-U2X0 models does not support all "Bit Image commands". We
currently use the GS v 0 one which is not supported by this printer
models. See:
https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=94

In addition, of that, the command itself is obsolete.

After this commit:
The support for another command "ESC *" is added which is not obsolete
and supported by TM-U2X0 models.

Notes:
 - Compared to "GS v 0", the receipt printed with "ESC *" is worst:
  - It take longer to print (5 seconds vs 1 second)
  - There is consistently some thin "empty white lines"
 - Most of the code is inspired from `python-escpos`:
 https://github.com/python-escpos/python-escpos/blob/master/src/escpos/escpos.py



Due to the drawbacks, making it the default way to print would be a bad
idea. As such, we can configure the mode (with other parameters) using
particular name for the printer (which can be done by adding it manually
 with cups)

opw-3351084,3341907

closes odoo/odoo#131301

X-original-commit: f30085bf
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Loan Sens (lse) <lse@odoo.com>

Steps to reproduce:

- Install an app like Sales, Purchase, etc. (any app where we can get
many lines)
- For example, get a sale order and add at least 10 lines.
- Then we try to delete this lines as fast as we can, spamming the
thrash can icon.

Issue:

A one2many contains a record, and when the user clicks on the trash icon
to remove it, and it clicks a second time precisely when the model has
been updated (so the record no longer exists there), but before the
x2many field is re-rendered (so the icon is still present).

Solution:

We can avoid this behavior but just making sure we have still access to
the (it exists) `record` and its `__bm_handle__` and then we can proceed
afterwards.

opw-3299395

closes odoo/odoo#122315

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

Prior to this commit, when limited product loading was enabled,
scanning a product that had not been loaded yet would trigger a search
for the product without taking into account the available_in_pos field,
and it would also set available_in_pos to true.

This commit ensures that when a product is loaded using its barcode,
the behavior aligns with the changes introduced in this
commit: https://github.com/odoo/odoo/pull/87329/commits/a83c7aea37b06e8b1f04f1f02982ff577d7058e9



opw-3463427

closes odoo/odoo#132851

X-original-commit: 3a1ed26a
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>

With Python 3.11, PyPDF2 2.12.1 is used and the exception raised when
the encryption type is not supported is now `NotImplementedError`
instead of `PdfReadError` in previous version.

In order to support both version, this commit adds a catche for the
`NotImplementedError` too.

closes odoo/odoo#133149

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Issue:
Two services which difference is that one is expensable with an
expense policy different of none, the expensable service is not
included in the project profitability as revenue from a service,
even it's not actually an expense, just a service that "could be"
expensed. The other service which is not marked as "can be expensed"
is correctly computed in the project profitability.

Steps to reproduce:
- Install Project, Accounting, Sales, Expenses
- Settings > activate analytic accounting
- Create a service, invoiced on milestones, creates a project on SO
  confirmation, can be expensed with an expense policy of Sales price.
- Create an SO, confirm the SO
- Set the milestone to 50% reached, invoice the SO, post it
- Go to the project profitability of the project, notice there is no
  revenue section for the service.
- If you follow these same steps for a service which is not set "can
  be expensed", the service is correctly included as revenue from
  service billable milestone.

Cause:
When computing the profitability items from services, we first get
the `sale_line_ids` (whose domain excludes the expenses), then we get
the product that are linked to those sale_line_ids, but we exclude
products that have an expense_policy different than 'no'. This
domain may not be necessary, because `sale_line_ids` already exclude
expenses.

Fix:
Remove the particular domain leaf.

Affected versions:
16 up to master

Reference:
opw-3430020

closes odoo/odoo#133141

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

When sending an email from a multi-company environment, the automatic
email signature is not corresponding to the company from which the email
is sent.

This is because the user context is not properly forwarded, in
particular the `allowed_company_ids` key.

The issue comes from the new rpc service not autmatically adding the
user context to the request, whereas the legacy rpc service did.

opw-3394780

closes odoo/odoo#132899

X-original-commit: 058736a0433dbf09dc413789d68942f1c550e45a
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Some companies require their clients to pay them always for the 10th day
of the month (for instance), and if we're the 15th already, then pay the
10th of the next month.

However, with the changes in the payment terms, we can now only ask the
client to pay for the 10th of the next month, which is not satisfying.

Therefore, we now allow negative days/months to meet this demand.

task-id 3127965

closes odoo/odoo#133148

Signed-off-by: Laurent Smet (las) <las@odoo.com>

Commit [1] does not include the amazing feature "apply on variants".
As a result, a legit configuration could lead to a `ValidationError`
(see the new test `test_cycle_on_legit_apply_variants`)

Note about the modifications of `test_11_multi_level_variants`:
because of an ORM limitation, if we create a BoM line directly:
```py
self.env['mrp.bom.line'].create({...})
```
the constraint will not be triggered... We need to write the line
creation directly on the BoM

[1] 4a4f92c5

opw-3200969

closes odoo/odoo#133089

X-original-commit: 31120a53
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

When creating a reconciliation model line on
a new record, by activate the boolean toggle on
`force_tax_included` field, the line is save
but as the reco model is not, `check_company`
will raise an error.

Steps:

- Create a new model
- Before saving, create a line, set a tax and
  click on Tax included toggle button
-> Error is raised

opw-3473189

closes odoo/odoo#132942

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

The Mail Debug tab is confusing for users and should only be used by
people who know what can or cannot be expected from it. It is not
providing a good preview of the e-mail's rendering since the HTML it
displays is not meant to be rendered by a browser but by all sorts of
e-mail clients. This means that some things that render properly in it
won't necessarily render properly in some e-mail clients, but also
likewise that some things that don't render properly in it will in fact
render as expected in e-mail clients. This is why it's only available in
debug mode but since many users routinely enable debug mode to get
access to hidden features, this is not enough to prevent them from
reporting issues that are not issues.

closes odoo/odoo#132284

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

When a model selection record is going to be deleted, a _process_ondelete method is called in order to delete all the records of the corresponding model that have that selection. These records are obtained by calling _get_records, which uses a query that needs a table. Thus, we should avoid cases for non-abstract models that have _auto = False.

closes odoo/odoo#133082

X-original-commit: 408175a7
Signed-off-by: Raphael Collet <rco@odoo.com>

When neutralizing the database we should disactivate all
fetchmail servers to prevent data loss (ex. when using POP)

opw-2758998

closes odoo/odoo#132379

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Scenario:
- edit the current document layout and use is_html_empty method in it
- it works in Preview Document, when printing any report, ...

=> it breaks when opening document layout wizard by clicking on
   "Configure Document Layout"

Reason: is_html_empty was added to _get_rendering_context, but the
preview instead the document layout wizard doesn't use this method.

Fix: add is_html_empty in the context

opw-3433583

closes odoo/odoo#133029

X-original-commit: c56942e8
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

in commit 5316c903 paypal button was badly placed due to width limit

closes odoo/odoo#133028

X-original-commit: 3282afc9
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Valeriya Chuprina (vchu) <vchu@odoo.com>

Current behavior:
When you settle an order in the PoS and completely validate it, the
remaining moves from the original sales should be cancelled.
However, it was not the case because we were not adding all the picking
in the `waiting_picking_ids` list. And so when we were checking this
list we were not cancelling all the moves.

Steps to reproduce:
- Setup multi-step routes (Inventory > Settings > Multi-Step Routes)
- Change the configuration of the warehouse to use the multi-step routes
- Create a sale order for any product and confirm it
- Open the PoS, and settle the order you just created
- Validate the order
- Go back to the sale order, and check the state of the delivery
- Only one picking has been cancelled

opw-3390529

closes odoo/odoo#132850

X-original-commit: 22d53075
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>

Task Adhoc: 33137
Task Latam: 1073

Description of the issue/feature this PR addresses:
Check number is not required for payments when payment method "New Third Party Checks" but is needed to be required.

Current behavior before PR:
Check number is not required for payments when payment method "New Third Party Checks".

Desired behavior after PR is merged:
Check number is required for payments when payment method "New Third Party Checks".

closes odoo/odoo#132204

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

Steps to reproduce:
1. Go to a blog post
2. Add a header
3. Hide the element on desktop and save
4. Click the button to translate the page

When translating a page, `getScrollOptions` is not initialized, which
throws an error when updating invisible DOM, as it could require the
function to be loaded.

This is because `_updateInvisibleDOM` needs this property to be set.

Similar fix: https://github.com/odoo/odoo/commit/62cc16dae74729a805a08f17db8ba75d9c51d096



opw-3430581

closes odoo/odoo#130080

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

Before this commit, when a regular barcode, like '3700000000370', which
could be interpreted using GS1 rules, was scanned in PoS, it was
incorrectly identified as a GS1 barcode even though it didn't contain
a product reference. This commit addresses this issue by implementing
a validation check during barcode scanning. The system now verifies
whether a scanned barcode conforms to GS1 rules and contains a product
reference. This ensures accurate barcode recognition.

opw-3468158

closes odoo/odoo#132709

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

Description of the issue/feature this PR addresses:
in task form view, when assignees field contains too long name, due to which
form view of task is broken.

Current behavior before PR:
task form view is broken due to assignees long name.

Desired behavior after PR is merged:
task form view is fixed even when name is long.

Fix:
- o_badge_text has property which fix the form view when assignees name is long.
- o_tag_badge_text class is added with o_badge_text class so that all the
property of o_badge_text class can access by o_tag_badge_text.

task-3217427

closes odoo/odoo#116805

Related: odoo/enterprise#38875
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

This PR odoo/odoo#125747 missed the account 973, which is still not in Ukrainian.
This account should be translated as well.

closes odoo/odoo#132921

X-original-commit: 6acb5660
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>

When the editor is displayed in a modal, the floating toolbar needs a
higher z-index than the modal in order to be visible. This is due to the
fact that the toolbar is mounted on the 'body' element (therefore, behind
the modal in terms of z-index).

The mobile toolbar, on the other hand, is mounted as a sibling of the
editable's element, which means it is always visible when the html field
is in a modal, without the need for a z-index. In fact, the mobile
toolbar, being fixed (no auto-hide) and having a z-index higher than
modals, leads to the undersired effect of being visible over modals that
are displayed on top of the html field. An example can be seen in the
Project app, where the editor is inside the task's description tab and a
modal can be opened for the customer.

This commit fixes such undesired visibility of the mobile toolbar over
modals by not applying the z-index to the toolbar when it's not
necessary (when not a direct child of the 'body' element).

task-3263463

closes odoo/odoo#132714

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