Cascade removal of account.report.expression records to corresponding
account.report.external.value, avoiding the following issue when upgrading:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1302, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 536, in load_modules
env['ir.model.data']._process_end(processed_modules)
File "/tmp/tmpwrjjshgf/migrations/base/0.0.0/pre-models-no-model-data-delete.py", line 103, in _process_end
return super(IrModelData, self)._process_end(modules)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2562, in _process_end
self._process_end_unlink_record(record)
File "/home/odoo/src/odoo/17.0/addons/website/models/ir_model_data.py", line 36, in _process_end_unlink_record
return super()._process_end_unlink_record(record)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2491, in _process_end_unlink_record
record.unlink()
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4218, in unlink
cr.execute(SQL(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.ForeignKeyViolation: update or delete on table "account_report_expression" violates foreign key constraint "account_report_external_value_target_report_expression_id_fkey" on table "account_report_external_value"
DETAIL: Key (id)=(94) is still referenced from table "account_report_external_value".
```
closesodoo/odoo#155242
X-original-commit: d28ae22e08c86392f3d772d3d7564b1b8e70e7e0
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
This commit backports the test introduced in odoo/odoo#155154, as
it is relevant to have it in every versions to ensure that dropdown
menu (i.e. submenus) are correctly tested.
closesodoo/odoo#155218
X-original-commit: 8915c8db63d2ebc697bbfc073e3504589a26b4b8
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The following combinations of payment methods and providers are removed:
- Amazon Pay - Adyen: The payment method cannot be activated because it
requires saving a public key in Odoo, and no field was made available
for that. Also, a custom configuration is necessary and the public key
must be generated through a lengthy process that is too cumbersome for
the added value of the payment method anyway.
- BLIK - Stripe: The payment method is not supported by Stripe when the
PaymentIntent object is created after collecting the payment details.
See https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=payment#enable-payment-methods
opw-3736511
closesodoo/odoo#153481
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When creating a SOL on the fly, if the name entered matches an existing service product, selecting 'Create' should create the SOL without opening a form view modal.
We do that by fetching the `default_name` from the context.
However, from the Many2one field, since the name will already be present in the create vals, in will not be in the default values in the context.
To fix this, this commit adds a new context key when calling `name_create` that allows us to retrieve the name from the `default_get`
Task-3553151
closesodoo/odoo#155191
Related: odoo/enterprise#57344
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Vincent Larcin (vila) <vila@odoo.com>
When creating SOLs on the fly in the employee mapping on projects, only the "Create and Edit" option is available.
This commit enables the quick create for SOLs in the mapping.
Task-3553151
Part-of: odoo/odoo#155191
When the user creates a new record having a property field, the system
fetches the property definition of the parent record to retrieve the
field's default values (see: `_add_default_values`). If the user lacks
read access on the parent record, the user gets an access error when
retrieving the property definition of the parent record.
To prevent this error, we will perform a sudo call on the parent record
before reading the property definition of the parent record. This allow
the user to create a new record, even if they do not have access to the
parent record.
task-3594814
closesodoo/odoo#155178
X-original-commit: 6f0fb8579d8230f91b7eefc5d29f8d61390dacc4
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Julien Banken (jbn) <jbn@odoo.com>
Before this commit, validation transactions would send an email when the
token is assigned to the order.
closesodoo/odoo#155167
Taskid: 3675875
X-original-commit: f70967e240058d8a6b095fc58c591249e517bd31
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
When a message is posted, the server sends a `mail.record/insert`
notification to update the related channel pin state. In order to
recognize the thread, the client needs its id and its model.
Currently, only the id is passed so the thread pin state is not
updated. This PR adds the model to the notification.
closesodoo/odoo#155150
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This value is accessed often during sort of messaging menu, so it's
better to not compute it each time on the fly.
- make it a compute
- access correspondent2 to avoid extra indirection
- store in variable in sort instead of accessing twice (less proxy get)
The performance impact is more visible for subsequent sorting, as the
first one benefits less from the cache (when it still has to be built).
Part-of: odoo/odoo#155068
Avoid doing this process every time the datetime is accessed.
It looks like it is already cached with `_datetime`, but it's not
efficient because there are still many proxy get access (which are
costly).
3 proxy access before: getter itself, reading _datetime twice
1 proxy access after: the field itself
Part-of: odoo/odoo#155068
Before this PR, after having imported a module, a warning appears in the
log, because it tries to update the graph which does not make sense for
an imported module.
This commit makes sure the warning is skipped if the module was
imported.
closesodoo/odoo#155096
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
decided to add the domain condition in the project.task user_ids field definition,
which means we can remove identical domains in views
Task-3698867
closesodoo/odoo#155044
X-original-commit: c6978c3fc4f828d970d45ebdaa4a35b44f3d09ce
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*de,din5008,din5008_purchase,din5008_repair,din5008_sale,din5008_stock
After 15.0, part of the German localization modules have been moved to
the DIN5008 modules to be shared with other countries.
We migrate the translations here to the correct modules in the versions
after 15.0 and complete missing ones.
opw-3669388
closesodoo/odoo#155035
X-original-commit: 3c97b4aa3ecd0dc6f0208fd0dcdf05217748bfd6
Related: odoo/enterprise#57247
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
If payment_custom or payment_demo is installed 'Secured by' element is
overriden and becomes hidden for all payment providers.
We removed xpath as it is more convenient for the users to see which
provider is behind a payment method. After this commit 'Secured by'
element is shown for all providers except for custom.
closesodoo/odoo#155014
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit fixes summing list of dicts returned by
_prepare_analytic_lines.
closesodoo/odoo#154937
Nb: This code is not yet covered by a test use case.
X-original-commit: 0e91af415ece2f87b95a81a3f7bfdaae5113a840
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
__getitem__() of BaseModel, reset the prefetch set of the recordset.
Fix _compute_activity_date_deadline, to batched the reading of
activity's deadline.
closesodoo/odoo#154860
X-original-commit: ef7226aaa2f0ad135133fe27bdf1414b7ebf2a92
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
This refactoring of action_unbuild() enhances its extensibility for stock_move_line creation.
Previously, passing additional values to the unbuild move lines necessitated a complete override
of the method due to its rigid design. With this refactoring, it is now possible to extend
the respective methods for preparing move line values, allowing for the addition of new values
or modification of existing ones.
closesodoo/odoo#154667
X-original-commit: 9716c3116dec9d3463123914b73d0556ccd07816
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Have a SA company
In Accounting settings activate invoice terms
Add a payment terms string in english, add the arabic translation
Create an invoice
Click preview
Issue: Payment terms will be shown in english twice
This occurs because, even if `narration` field is translatable the
translation is not automatically copied when the field is copied from
the company `invoice_terms`.
opw-3530811
closesodoo/odoo#153966
X-original-commit: b49198d42db0cbc90db54f8509eae0ebbbf7b894
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Steps to reproduce
------------------
* install `account_peppol`
* open a partner's list view
* select a contact
* on the top middle, click Actions > Verify Peppol
You should be met with a traceback:
`AttributeError: 'bool' object has no attribute 'setdefault'`
Cause
-----
`button_account_peppol_check_partner_endpoint` is expected to return an
action or a falsy value (no action to perform).
opw-3683612
closesodoo/odoo#152817
Signed-off-by: William André (wan) <wan@odoo.com>
**Current behavior:**
Creating a promo type loyalty program and editing the
'products' field in the 'Among' section of the rule created by
default at the bottom of the form view before saving the
program will cause the products selected in this field to be
cleared upon saving the program.
**Expected behavior:**
Filling out this field of the default rule before saving the
overarching loyalty program should result in the same behavior
as doing so after saving the program. That is, the field should
save the user's input.
**Steps to reproduce:**
1. Create a new loyalty program in the Discount & Loyalty tab
2. Give it a name and, before saving the program, edit the
'Products' field of the default rule that is created at
the bottom of the form to have at least one value
3. Now save the program and observe that the 'Products' field
has been cleared of the previously selected values
**Cause of the issue:**
In the form view for the loyalty.program there are two
instances of the field trigger_product_ids which are set to be
invisible unless creating a specific program type. This field
is set to be related to rule_ids.product_ids in its definition
within the loyalty.program class definition. Thus, when the
user saves the program and rule concurrently, the empty
trigger_product_ids field overwrites the product_ids field
and whatever the user had populated it with is cleared.
The reason it only happens to the default rule and not ones
which are manually added before saving the program is because
in the traverse_related() method in fields.py, only the first
record of the related field is returned to be modified. In this
case, it means only the first rule's product_ids field is
overwritten.
**Fix:**
Overwrite the create() method in program.loyalty and check if
the program being created is of type 'gift_card' or 'ewallet'
then, if so, delete the trigger_product_ids key,val from the
dictionary so it will not later override the products specified
in the loyalty rule.
opw-3669953
closesodoo/odoo#155093
X-original-commit: 7ed0a773b6e0711b127f236ce665c35202d973bc
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Current behaviour:
500: Internal Server Error
Error while rendering the template account.report_invoice_document
Steps to reproduce:
Accounting > Configuration > invoicing > Payment Terms
New > Create and save a payment term with 2 lines
For example :
- name 80/20 test
- line_1 : 80% after 0 days
- line_2 : 20% after 30 days
Sales > Orders > Quotations
Chose any > use payment terms 80/20 test
Save and create associated invoice > chose regular invoice
> create draft invoice > preview > 500: Internal Server Error
Cause of the issue:
The method _get_amount_due_after_discount() called during the rendering
of the template does not return a value in case self.early_discount is
False.
Fix:
Return total_amount by default since no discount is applied.
opw-3683708
closesodoo/odoo#155080
X-original-commit: c8154b6aa57cc42e352260c7f75e52cd29a2d52d
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
Before this commit:
When using the removeFormat button, the backgroundColor and
foregroundColor were not completely removed.
After this commit:
The removeFormat button will completely remove all the styles applied to it.
task-3344762
closesodoo/odoo#155146
X-original-commit: 9c4194ad3387c55d39ec7bbef1c6414893098c6e
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Steps to reproduce:
- Install Accounting
- Create a fiscal position with a legal note
- Create an invoice with the created fiscal position
- Preview the invoice
=> The legal note from the fiscal position appears on the invoice as expected
- Install l10n_it
- Preview the invoice
=> The legal note from the fiscal position doesn't appear anymore
Cause:
The condition to display the legal note from the fiscal position is overridden
by l10n_it module to only display it for Italian companies, which is not correct.
Solution:
Remove the condition about the Italian companies.
By removing that condition, the inherited view becomes useless as the overridden
condition is the same as the original one.
The inherited view will have to be removed in master.
opw-3709443
closesodoo/odoo#155072
X-original-commit: aa8646281885167698e9f8b3b549b2c4e17dc2cc
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Commit [1] introduced default images changes for the website library.
The problem is that the ir.attachment definitions are in a non-updatable
environment by mistake (apparently since forever)... so they are not
updated after update/upgrade.
This commit moves the definitions to its own updatable file, in 17.0 and
above only (ignoring potential other changes that were made in 15.0/16.0
at the time but apparently led to no issue). But this is not enough:
upgraded users will still have those ir.attachment records marked as non
updatable and will thus not be updated. Meaning that the ir.attachment
record will still reference path to images that do not exist anymore
(since [1]) and thus not display anything in related snippets, or worse:
crash on some non-robust-to-404-images options (This will be made more
robust in another update).
Note that, at the moment, we cannot solve this issue by making the
/web/image route not return a 404 but a placeholder image in that case,
for technical reasons (even though it would be consistent as this is
what is done if you try to reach `/web/image/something_with_a_typo`).
It would also be annoying to solve this problem by adding a migration
script inside the Odoo repo itself:
- It would only work if upgraded users do a -u again (unlikely).
- That would mean an upgrade script rotting in the main repo forever.
Instead, this commit chose to restore the removed images so that
upgraded users will be able to use the outdated paths. In master, an
upgrade script will be made (in the upgrade repo) to properly update all
those attachment records and be able to finally remove those outdated
images. Note that this may also be fixed without upgrade script if
non-updatable records whose XML declaration is moved out a non-updatable
area become updatable (under discussion with the framework team... we
will see when this lands in master).
Steps to reproduce:
- Install a 16.0 with the website module
- Upgrade to 17.0
- Drag a "Blockquote" snippet on a page
=> Crash and the image is missing (in the DOM but invisible and
impossible to edit). Note that the crash itself will also be fixed by
the later update that will be done to make editor options more robust
to 404 images.
[1]: https://github.com/odoo/odoo/commit/a4377bfa85b19be29a430573e0f42fff4da52757
opw-3693055
opw-3723895
opw-3744257
opw-3747348
opw-3749764
...
closesodoo/odoo#155015
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Part 1: _search_is_member
-------------------------
Separate query to fetch candidate channels because the sub-select that
`_search` would generate leads psql query plan to take bad decisions.
When candidate ids are explicitly given it doesn't need to make
(incorrect) guess, at the cost of one extra but fast query.
It is expected to return hundreds of channels, a thousand at most, which
is acceptable.
A "join" would be ideal, but the ORM is currently not able to generate
it from the domain.
`sudo` is added as well because the rules for the member don't need to
be checked as no information is leaked.
Part 2: clean rules
-------------------
The rule for reading "self" is included in the rule for reading other
members. It can be disabled for "read" to avoid duplicate.
It also checked is_member again, but is_self necessarily implies it.
Part 3: clean tests
-------------------
The opportunity is taken to fix the tests. The tests where considering
as "access error" when there was an assert error inside the test (for
example not finding the channel or the member), but those needed to be
considered as failure regardless of expected outcome of access check.
Extra mute loggers are added to clean the test output.
closesodoo/odoo#153697
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Usecase to reproduce:
- Create a picking with available quantity and another without
- Confirm both picking
- In list view, select the two picking and use the validate action
Expected behavior:
The first picking is validated and the second has been untouched
Current behavior:
The second picking is picked. That will prevent any further reservation
It happens because on multiple records the error message for empty
picking is bypassed and the picked is applied on it.
Close#153983closesodoo/odoo#155039
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Previously, exporting BIS3 when there is a 0% tax in the invoice will
results in the XML showing warning of UBL-CR-601. But if we do not
include any TaxExemptionReason reason at all, a fatal error BR-E-10 will
pop up.
Here is the details of those 2 rules:
```xml
(with context: /*/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory
[normalize-space(cbc:ID) = 'E'][cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT'])
<assert id="BR-E-10" flag="fatal" test="exists(cbc:TaxExemptionReason) or
exists(cbc:TaxExemptionReasonCode)">
[BR-E-10]-A VAT breakdown (BG-23) with VAT Category code (BT-118)
"Exempt from VAT" shall have a VAT exemption reason code (BT-121)
or a VAT exemption reason text (BT-120). </assert>
and
(no context)
<assert id="UBL-CR-601" flag="warning" test="
not((cac:InvoiceLine|cac:CreditNoteLine)/cac:Item/
cac:ClassifiedTaxCategory/cbc:TaxExemptionReason)">
[UBL-CR-601]-A UBL invoice should not include the InvoiceLine
Item ClassifiedTaxCategory TaxExemptionReason </assert>
```
Based on these rules, we can conclude that:
- TaxExemptionReason must not appear in InvoiceLine/Item/ClassifiedTaxCategory
- TaxExemptionReason must appear (when some line in invoice has exempt tax)
in TaxTotal/TaxSubtotal/TaxCategory
Previously, the TaxExemptionReason will appear on both places.
This commit fixes that and adds a test to ensure that when a 0% tax is
present, TaxExemptionReason only appear in TaxTotal/TaxSubtotal/TaxCategory
closesodoo/odoo#155022
Task-id: 3703206
X-original-commit: 6c2f098f46c5d90d2384c596f4cef8fa874adbd5
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Yosua Nicolaus (yoni) <yoni@odoo.com>
Since [1] when the mega menu were first introduced, to make their
edition possible, the bootstrap dropdown behavior was neutralized by
removing the `data-[bs-]toggle` attribute.
In [2] when Bootstrap was upgraded to version 5.1.3, the
`dataApiKeydownHandler` event handler that is called when up, down or
escape are pressed raises an error if `data-bs-toggle` cannot be found
on a previous sibling of the dropdown. This makes the approach chosen
in [1] incomplete.
This commit avoids this issue by temporarily adding a class that
is excluded from the event handler selector.
The patch must unfortunately be applied within bootstrap itself because
the event handler is registered right after the method is defined and
we have no way to access the registered event handlers afterwards.
This makes it impossible to patch the called method from outside, nor
its associated selector.
We cannot simply update the selector that was already patched by [3]
because it is also used by other methods.
A test is included which should mitigate the risk of accidentally losing
this patch upon bootstrap upgrades.
Steps to reproduce:
- Create a mega menu.
- Edit the page.
- Open the mega menu.
- Click inside the mega menu content to have a cursor selection.
- Press the arrow up key, the arrow down key or the escape key.
=> An error dialog was displayed.
The same issue happened with a nested menu instead of a mega menu.
[1]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
[2]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[3]: https://github.com/odoo/odoo/commit/daca8fe4e3da4a5ad5fabf3730496a3919af8abc
task-3614926
opw-3741670
closesodoo/odoo#155019
X-original-commit: 48f0c4203ceb5e770fed6193bd6382690b1b62fe
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Have a base user with no access to Accounting, Expenses, Employee
Create an expense, input an amount
Save and Create Report
Access Error will raise
You are not allowed to access 'Journal Entry' (account.move) records.
This occurs because of a remaining field in the hr.expense.sheet form
view after refactoring the model
opw-3690493
closesodoo/odoo#154798
X-original-commit: f274e7087adffa05e8ec753cb75a87d474e2f305
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
*: mail.
This PR removes the live chat sidebar category. From now on, each
channel will have its own category. This is a first step towards
providing an efficient way for operators to join/leave a live chat
channel.
part of task-3640730
closesodoo/odoo#154755
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In #138387 we modified the expense lines tree in expense reports so that the user can click on the lines to see an attached receipt in the viewer at the side of the webpage. The tree was made to be readonly to make clicking the lines easier and to make it harder for the user to change a field by mistake. This commit reverts the lines to being editable again while leaving some fields as readonly like quantity and taxes as those can invalidate the expense.
task-3685651
closesodoo/odoo#149588
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Currently, when adding a product to a quotation with the catalog, no warning message will appear when adding a poduct that has a warning or blocking message.
Steps to reproduce:
-------------------
* Go to **Sales** app -> Configuration -> Settings
* Enable **Sale Warnings**
* Go to **Products** -> Products
* Create a new product
* Under **Sales** tab:
* For warning, select either warning or blocking message
* Write a message
* Go to **Orders** -> Quotations
* Create a new quotation
* Select the **Catalog** to add products
* Add the newly created product
Why the fix:
------------
The first version of this fix was a python exclusive change. It was a bit hacky; it was raising an error when the product had a blocking warning and sending a message on the bus when the product had a non-blocking warning.
The second version was changing the return value of `_update_order_line_info` to return the price and the warning if any. The warning was shown inside JS with `_updateQuantity`. This change was not good for a stable verion as it was changing the signature of a public method.
This fix automatically changes the data that is loaded to the catalog. It adds the warning message if any and changes the `readOnly` field accordingly.
Warning/blocking messages will be automatically displayed in the catalog, on the product informations. Products with blocking messages will me marked as readonly to avoid being able to add the product to the sale order (this is the original behavior for blocking messages).
Regarding the field `readOnly` and ẁarning`:
* We can't write `res[product.id]['readOnly'] = product.sale_line_warn == "block"' because readOnly is set to True by default if the sale order is cancelled and doing this would overide that value later. See:
https://github.com/odoo/odoo/blob/21c25a7ccd0ba2d6574ddbcfbcf50dbbc03a1e6c/addons/product/models/product_catalog_mixin.py#L97-L99
* We're also sending the warning only if there is one because of this:
```python
<span t-elif="props.readOnly" class="my-2 pt-3 border-top" t-out="props.warning">
You can't edit this product in the catalog.
</span>
```
Because in the case where readOnly is True for another reason than the product having a blocking warning, the initial message will be displyed.
Since the module purchase also uses the warning on products, this fix is extended to include it.
opw-3631511
closesodoo/odoo#149155
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Co-authored-by: Valentin Chevalier <vcr@odoo.com>
Steps to reproduce:
-------------------
- create an accrual plan;
- create an accrual level;
- save;
- create a second accrual level;
- save the form;
Issue:
------
We trigger an error with an invalid `added_value_type` field.
Cause:
------
The `added_value_type` is a compute stored field without inverse.
As it is not inversible, this field will be readonly by default [^1].
When the dialog window is opened, we trigger a specific logic
which will trigger an onchange [^2].
During this onchange, we work with a virtual record from the `hr.leave.accrual.level`
model (the one corresponding to the first level) which has an origin.
Unfortunately, we are using the cached value for the virtual record, i.e. `None`.
The latter will have been set as if it is a record without origin.
As the `added_value_type` field is readonly on the dialog form view,
we have to save the record with this value.
Since this field is required, the error occurs.
Solution:
---------
In order to use the value on the original record,
the field must be forced with `readonly=False`.
Note:
-----
Commit which introduced the issue: 0a9e83dfd8
The fix allows you not to use `_origin`
(which normally shouldn't be used in this case).
[^1]: https://github.com/odoo/odoo/blob/e89ed59269974f148c2285446dcd60e871df1a01/odoo/fields.py#L451
[^2]: https://github.com/odoo/odoo/blob/25cda065dccaae5edd861114c29157c7abb68533/addons/web/static/src/model/relational_model/static_list.js#L194-L299
opw-3745463
closesodoo/odoo#155033
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
-Move menu options to have 'Close session' and 'Backend' at the bottom of the list
task id: 3759943
closesodoo/odoo#154998
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
- In this commit, we make some requests in js to get a list of HSN codes to
match with the input entered by the user in the field.
- And for the options attribute in hsn_autocomplete widget, when a user selects
an option from the list, the hsn_decription will be stored in the field
specified by the user.
task-3646598
closesodoo/odoo#151507
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Steps to reproduce:
===================
- Open any app (sales for example)
- Toggle studio
- select reports tab
- Select any report
- Select some text and open any dropdown (font size or color)
- Click somewhere else on the document
- Select some text again
- The dropdown stayed open from the first select
Origin of the issue:
====================
Clicking somewhere on the document in studio doesn't trigger the events
`defined in bootstrap/js/dist/dropdown.js` because of the iframe.
Solution:
=========
Trigger click event on toggle button for the opened dropdown when hiding
the toolbar to close them
task-3674736
closesodoo/odoo#154969
X-original-commit: 878f3b27966a278a9332ef43e827eb2006911583
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
As of the first of March 2024, the SST tax
will increase from 6% to 8%.
To that end, the current 6% tax will be set
to inactive by default, and we will add
a new 8% service tax to replace it.
Task id # 3748127
closesodoo/odoo#154966
X-original-commit: 772d16bc6da7a696681805be42ca48e8cfd13db2
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Order name rather than ID so that the user has more control on documents
published in eCommerce and quote builder. Minor CSS cleanup.
closesodoo/odoo#154961
Signed-off-by: Fabien Pinckaers (fp) <fp@odoo.com>
Issue:
Articles were erroneously marked as changed,
leading to unnecessary autosaves. Part of this was
caused by the inclusion of history IDs in the
content comparison process, which differ even
without substantive content changes.
Solution:
Applied `stripHistoryIds` to the content obtained
from the WYSIWYG editor before performing the
dirty check. This ensures that comparisons focus
solely on actual content changes, eliminating
history IDs as a factor in the dirty state
determination.
opw-3707380
closesodoo/odoo#154068
Related: odoo/enterprise#56626
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Description:
In a multi-company environment, `payment.provider` records are specific to each company. After activating Stripe on Company 1,
you can set a Website for the record if you wish. If you wish to activate Stripe for Company 2, Odoo will use `.copy()`
to create a new `payment.provider` record for Company 2. However, this will lead to differing incorrect behavior depending
on the version.
On 16, a new `payment.provider` record will be created, but will be connected to the Website set on Company 1's provider.
On 17, Odoo will throw an error after a `check_company` call reveals that the Website set on the new record is for the
wrong company, preventing the record from being created.
In both cases, the `.copy()` grabs the optional Website set on the existing `payment.provider` record to be used incorrectly
for the new record.
Desired behavior after PR is merged:
The Website relation is always neutralized when Odoo creates a new Stripe `payment.provider` record using the `.copy()` method
opw-3683338
closesodoo/odoo#154521
X-original-commit: 76cf4221b332c924c243e19f911131431c041bc6
Signed-off-by: Joel Bluemel (jobl) <jobl@odoo.com>
*account,hr_expense,purchase,repair,sale,spreadsheet_dashboard_*,web
In Chile, "Untaxed Amount" has its own special term that isn't used in
Spain/LATAM spanish: ~~"Total neto"~~ "Monto neto" [Chilean customer
changed what term should be once fw-port was at v17]. Therefore
everywhere that it appears (in a .pot file), we ensure that the es_CL
localization uses this term.
Also untranslated terms from the es_CL.po files that were edited have
been removed since they add no benefit and make it harder to read the
file (we expect to only add terms to the file, not translate every
term for Chile).
opw-3670297
closesodoo/odoo#154473
X-original-commit: d1d4d30ef402ce835cba892459fdceadfc9944e1
Related: odoo/enterprise#56853
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Move compute of `imStatusTrackedPersonas` to its inverse field. Doing
the compute on the "One" side of the relation prevents from looping and
computing all values whenever there is a change in any of them.
In practice, this reduces the "compute" time of the message fetch (which
also fetch persona as authors of messages), reducing by approximately
half the time it takes to insert these messages (depending on the number
of persona it had to loop through).
For example from 60ms to 30ms on my machine for message insert in
"partner_1_125" (populate medium).
closesodoo/odoo#154918
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In commit[1] an improvement was made to increase the scrollbar height
on hover to make it easier to scroll. However chromium updated the way
::webkit-scrollbar works breaking the behavior on recent browser. On
firefox the margin was applied without the change of height on the
scrollbar creating a visual glitch on hover.
On chromium >121 the `scrollbar` property takes priority over the
`::webkit`-x to keep the scrollbar styling with height change on webkit
browser we have to apply the `scrollbar` property only on Firefox.
The mixin was used only on `website_sale` filter offcanvas and category
horizontal scrollbar, this commit removes the mixin and customization on
the offcanvas vertical scroll to make it consistent with the other
offcanvas across website.
This commit also disables the scrollbar hover effect on touchscreens.
The transform was causing an issue on some devices displaying the
scrollbar behind the items, thus it's now applied on the container.
Note: We use not `.o_wsale_filmstip_fancy_disabled` to avoid the
`scrollbar` property being set when the Javascript is not loaded yet.
Otherwise the scrollbar would be invisible until a hover from the user.
[1]: odoo/odoo@bdede43e1e
task-3718501
closesodoo/odoo#152456
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
When checking a partner's validity on Peppol network, we should always check the `commercial_partner_id` to get the right eas & endpoint. Also, the Peppol verification check should not occur if the current company does not have an active peppol registration.
Currently, if a user wants to send an invoice to a specific contact of a partner, they cannot as `_need_ubl_cii_xml` evaluates to False because the contact is not a valid Peppol participant.
opw-3748720
closesodoo/odoo#152654closesodoo/odoo#154823
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Edoardo Piroli