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>
Peppol endpoint must not contain special characters. This commit adds
an onchange, where the input is being sanitized.
If the endpoint is not filled in, we already throw an error when
creating an edi user, so that should be fine.
task-3718573
Part-of: odoo/odoo#154823
Turn your odoo user's language to "French (BE) / Français (BE)".
Now, let's say you have a pivot function returning an amount in the one million
(e.g. 1 230 000). It's formatted to "1.230.000,00"
Reference that cell with `FORMAT.LARGE.NUMBER`. The result is "1.230k"
Now hit the share button and open the share link in an incognito tab.
=> the cell is now "123m"
That's because the string "1.230.000,00" is wrongly parsed to 123000000
(to fix in o-spreadsheet).
Besides that, the formatted value may not necessarily be parsable.
With this commit, we export the raw value, stringified.
opw 3720586
closesodoo/odoo#154712
X-original-commit: 7f8d705b216b392ce1249793a0b44dcec0ac536c
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Before this commit, calling _applyCommands with a lot of commands
DELETE or UNLINK on a StaticList already containing a lot of
commands was very slow. This happened for instance in the Automated
Rule form view, click on "Add an action", and in the dialog form
view, select a "mail" type, e.g. "Add followers". In that form view
there's a many2many field "available_model_ids" which contains at
first almost all models of the database (LINK commands). Switching
to a "mail" model restricts those models to the ones inheriting
from the thread mixin, i.e. it generates a lot of UNLINK commands.
On runbot, in represents 1000+ LINK and UNLINK commands. This
could take several seconds.
With this commit, we no longer iterate over all commands when
applying UPDATE, DELETE or UNLINK commands. Instead, we generate
at first a mapping of record ids to their own commands, and we
then have a quick access, given a record id, to the list of his
commands, which is small in comparison to the whole list of
commands. After iterating over all commands, we generate the new
list of commands and we update this.records and this._currentIds
to do the necessary cleanups (i.e. removing records and ids for
which we received DELETE/UNLINK commands).
task 3599674
closesodoo/odoo#154568
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Steps to Reproduce
- Install E-Commerce app
- Add Demo payment provider in Test mode
- Go to Settings > Website > Invoicing and activate Automatic Invoice
- Go to Settings > Website and set the domain for:
- My Website -we'll refer to it as website_1- as http://[IP_address]:[port] such as http://127.0.0.1:8069
- My Website 2 -we'll refer to it as website_2- as http://[IP_address]:[port] such as http://127.0.0.2:8069
- Create a new product with Invoicing Policy as Ordered quantities
- Go to website_2 and add the new product to the cart and checkout
- With Debug mode on, Check the Emails sent via Settings > Technical > Email > Emails
Current Behavior
Two emails are automatically sent:
- An SO email that opens website_2 when clicking on View Sales Order button which is correct as we purchased the product through website_2
- An Invoice email that opens website_1 when clicking one View Invoice button which is WRONG as it should follow its originating SO and opens website_2 as well
Expected Behavior
Both SO and invoice emails should refer to the website where the SO was created -website_2 in our use case-
Observations
The automatic invoice always refer to website_1 regardless of the website where the SO was originally created.
Investigation
The website_id of the invoice is decided by the corresponding field https://github.com/odoo/odoo/blob/322889ea0a24c5eff2e3289502a2f606cb4048d0/addons/website_sale/models/account_move.py#L10-L13
- As noticed it's a related field to the partner_id.website_id which is False
- That's why the invoice website_id is also False leading to the preview button to fall back to website_1
- The partner_id.website_id is always False unless you manually added the field to the view and then set the website_id. Our case will work correctly if you set the website_id for the user/customer to website_2
- I also tried to sign up at website_2 to see if the website_id will be set accordingly but it stayed as False
Proposed Solution
make the invoice website_id relates to the originating SO instead of the partner
opw-3685742
closesodoo/odoo#154376
X-original-commit: 361e8f68af9c9656764906c8a44d22e1fed090a8
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
ZATCA changed the demo VAT code used with Sandbox, this commit aims to update the demo data in the l10n_sa_edi module
closesodoo/odoo#154309
X-original-commit: 54628c497322b9afb506d9d2437cce90c3262b08
Signed-off-by: Josse Colpaert <jco@odoo.com>
When installing a new module, the access of the Default Template User
is propagated to any existing employee (introduced at
aefb05eb497a8a16a). This can be problematic in companies that don't
want all their employees to become manager by default. Allow to
disable this behaviour in a settings.
This is the version of the patch targetting stable version that is not
configurable through the interface, manually creating an ICP
base_setup.default_user_rights_minimal=True as the way to change the
behaviour.
Closesodoo/odoo#149224
Task-id 3685856
closesodoo/odoo#154816
X-original-commit: 70f66f147bb0c133be6ae3fd2b11438afe2366a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Antoine Vandevenne (anv)