Syncing from upstream odoo/odoo (saas-18.2) #34241

bt-admin · 2025-07-12T03:02:01Z

bt_gitbot

Before this commit, tour "discuss_channel_public_tour" was failing non-deterministically at the following step: ``` .o-mail-Message:not(:has(.o-mail-MessageReaction)) ``` This happens because prio steps added a new reaction and asserted it was shown. It clicks on reaction to remove it and then page reload to see the reaction is gone. Problem is that it can reload page too fast and the RPC to remove the reaction did not have time to occurs. This commit fixes the issue by awaiting message no longer has reaction before page reload. Fixes runbot-error-227769 closes #218228 X-original-commit: ba94227 Signed-off-by: Alexandre Kühn (aku) <[email protected]>

Step to reproduce 1. Createdb with account and contact module install in 18.0 version. 2. create 2 company A and B 3. create partner with both company A and B seperate 4. create a user that have only rights of company B and rights of Accounting/setting groups 5. create a Bank account(Contact->Configuration->Bank Account) with partner A in company A 6. Now login with user B and create a bank account number with same account number. Access error will come. For resolve the access error fetching the correct result according to company so it won't fetch other company result the changes merged last week ad6c900#diff-22e97cf61c6826e67cd9a3276bdb292e997cb1117ca44c1749c69d5d01931787R69 ``` Access Error Uh-oh! Looks like you have stumbled upon some top-secret records. Sorry, Test B (id=7) doesn't have 'read' access to: - Contact, A (res.partner: 8) Blame the following rules: - res.partner company If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. This seems to be a multi-company issue, but you do not have access to the proper company to access the record anyhow. ``` upg-2986193 opw-4876839 tbg-2093 closes #218087 X-original-commit: 333fcb9 Signed-off-by: Ruben Gomes (rugo) <[email protected]> Signed-off-by: Sanchit Gupta (sagu) <[email protected]>

This commit will add the amount residual in text in the note of the xml we sent to nilvera. The text need to be in uppercase. If the invoice is in another currency than Turkish Lira, we have to add two notes one for the amount in turkish lira and one in the other currency Also when the integer part or fractional part is zero it should be zero in turkish. task-4518269 closes #218505 X-original-commit: 0f733e1 Signed-off-by: Maximilien La Barre (malb) <[email protected]> Signed-off-by: Florian Gilbert (flg) <[email protected]>

Currently these problems can appear when an invoice is cash rounded. 1. In case we use the "Modify tax amount" (`biggest_tax`) cash rounding strategy: The rounding amount is added to the taxes in Odoo but not in the UBL XML - This affects everything that uses `_prepare_invoice_aggregated_taxes` (and not just UBL XML) 2. The generated UBL XML is invalid (for any rounding strategy). See below for details. 3. The import of the exported UBL XML does not yield back the same invoice (even after fixing the export / the previous 2 problems). Also there are some problems with the correction of tax values of imported UBL XML (`correct_invoice_tax_amount`). (They probably do not cause issues in practice but would after this fix. We adapt the correction as part of the fix for (3).) #### Runbot: How to generate problematic XML 1. Select BE Company CoA 2. Enable Cash Rounding in the settings 3. Create a cash rounding method (in the settings where cash rounding can be enabled): - precision `1.00` - strategy: any - profit / loss account: any 4. Create an invoice - Set a Belgian partner (e.g. "BE Company CoA" is okay) - Set the the cash rounding method from step 2 - Single Line with price=70.00€ and a 21% tax 5. The total should be 85.00 € (84.70 € w/o the rounding) In the journal items there should be the following non payment term items: - 70.00€ base - 14.70€ tax - 0.30€ rounding (depending on the cash rounding strategy the tax is set or not) 6. Confirm & Send (with BIS Billing 3.0) 7. Look at the UBL BIS 3 XML in the `Invoice` element - `TaxTotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€ - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€ - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€ - `LegalMonetaryTotal/TaxInclusiveAmount`: 85.00€ - `LegalMonetaryTotal/PayableAmount`: 85.00€ 8. This fails validation `BR-CO-15`: ``` Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110). ``` (`LegalMonetaryTotal/TaxInclusiveAmount` = `LegalMonetaryTotal/TaxExclusiveAmount` + `TaxTotal/TaxAmount`) Since the cash rounding is included in `LegalMonetaryTotal/TaxInclusiveAmount` but not in `TaxTotal/TaxAmount` (or `LegalMonetaryTotal/TaxExclusiveAmount`) #### Tax value correction details (with examples) Currently we try to fix the tax amounts after importing an invoice. The function we use for that (`_correct_invoice_tax_amount`) has the following issues: - We look for `TaxTotal/TaxSubtotal` elements anywhere. But i.e. such elements can also exist inside `InvoiceLine` elements. Example: - module `l10n_dk_oioubl` file `test_xml_oioubl_dk.py` - function `test_oioubl_import_exemple_file_4` / XML file 'external/BASPRO_01_01_00_Invoice_v2p1.xml' - The tax total parsed from the document may need to be inverted. E.g. credit notes can be given as an invoice with negative amounts. See function `_get_import_document_amount_sign`. Example: - module `l10n_account_edi_ubl_cii` file `test_xml_ubl_be.py` - function `test_import_invoice_xml_open_peppol_examples` / XML file 'bis3_invoice_negative_amounts.xml' - We compare the tax total from the document only with a single line of that tax. But there can be multiple lines for a single tax. We have to use the sum of all those lines for the comparison. Example: - module `l10n_account_edi_ubl_cii` file `test_xml_ubl_au.py` - function `test_export_import_invoice` / XML file 'from_odoo/a_nz_out_invoice.xml' #### The fix This commit does the following to fix that 1. We include cash rounding lines belonging to a tax in the tax computation for the UBL XML export (or rather everything any tax computation done with `_prepare_invoice_aggregated_taxes`). 2. After fixing (1) we only have to fix the "Add a rounding line" (`add_invoice_line`) strategy. This is as follows - Subtract the cash rounding from the `LegalMonetaryTotal/TaxInclusiveAmount` - Add node `LegalMonetaryTotal/PayableRoundingAmount` with the value of the cash rounding 3. Cases - `add_invoice_line`: We create a dedicated invoice line with the amount found in node `LegalMonetaryTotal/PayableRoundingAmount` (if it is present). - `biggest_tax`: We update the amount on the tax line to match the value found in the XML. (Currently we only do this if the difference is not greater than '0.05') The fixes for the tax value correction on import are also needed for 3./`biggest_tax`. #### Runbot: example XML after the fix The export in the example then looks like this for the different cash rounding strategies - `add_invoice_line` - `TaxTotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€ - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€ - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€ - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€ - `LegalMonetaryTotal/PayableRoundingAmount`: 0.30€ - `LegalMonetaryTotal/PayableAmount`: 85.00€ The validation for the `LegalMonetaryTotal/PayableAmount` is still okay since (in the example) it is just `LegalMonetaryTotal/TaxInclusiveAmount` + `LegalMonetaryTotal/PayableRoundingAmount`. - `biggest_tax` - `TaxTotal/TaxAmount`: 15.00€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€ - `TaxTotal/TaxSubtotal/TaxAmount`: 15.00€ - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€ - `LegalMonetaryTotal/TaxInclusiveAmount`: 85.00€ - `LegalMonetaryTotal/PayableRoundingAmount`: (not exported) - `LegalMonetaryTotal/PayableAmount`: 85.00€ #### References Also see - https://docs.peppol.eu/poacc/billing/3.0/bis/#_rounding - https://docs.peppol.eu/poacc/billing/3.0/bis/#_calculation_of_totals task-4854592 X-original-commit: b033a87 Part-of: #218480 Related: odoo/enterprise#90008 Signed-off-by: Antoine Dupuis (andu) <[email protected]> Signed-off-by: Sven Führ (svfu) <[email protected]>

Currently rounding lines (with taxes) are not included in the tax lines in multiple places. This is fixed in this commit. See the previous commit for motivation. part of task-4854592 closes #218480 X-original-commit: 6fd5b89 Related: odoo/enterprise#90008 Signed-off-by: Antoine Dupuis (andu) <[email protected]> Signed-off-by: Sven Führ (svfu) <[email protected]>

Steps to reproduce: 1. Enable the cookie bar. 2. Edit the cookie bar to have a link/button at the center. 3. Go to /shop. 4. Click the "compare" button on one product. 5. Scroll down and click "compare" on another product. Issue 1: Product animation goes to the top-left corner. Issue 2: After accepting the cookie bar, the compare button appears but overlaps with the popover. Reason: To cover bottom fixed elements when any modal is open, we added the `o_bottom_fixed_element_hidden` class with the `d-none` property to hide those elements, making them visible once the modal closes. As a result, the compare button hides when scrolled, leading it to redirect to the top-left corner. Additionally, adding a product triggers the applyStyles function of popper.js to handle popover styles. When the cookie bar is accepted and the modal closes, this method doesn't trigger until scroll. This commit aims to resolve animation of product comparison when modal is open by remove the `o_bottom_fixed_element_hidden` class when added to compare products. Additionally, we add debounce leading and trailing params to the `_hideBottomFixedElements` to call function accordingly. task-3877807 X-original-commit: d3d87b3 Part-of: #214776 Signed-off-by: Benjamin Vray (bvr) <[email protected]>

Before version `saas-18.1`, we were using `publicWidget`, where `bottomFixedElement` was bound to the scrollable target returned by the `getScrollingTarget` function. This function (implemented with `jQuery`) was used to detect the appropriate scrollable container. The same `getScrollingTarget` function was also used in the `sharePopup widget`, specifically in the `onModalHidden` method, which triggers a scroll event when the modal becomes hidden. However, starting from version `saas-18.2`, we migrated to using `interaction` instead. In this new setup, we use `scrolling.js` from `web`, which does not include a `getScrollingTarget` function. As a result, the `bottomFixedElement` interaction is now bound directly to the `document scroll`. Additionally, when closing the `sharePopup`, we now trigger the scroll method on the current scrollingElement using `getScrollingElement` instead of `getScrollingTarget`. The key difference is: - `getScrollingElement` returns `document.scrollingElement` - `getScrollingTarget` used to return `window` if the default scrolling element was used Going forward, both `getScrollingTarget` and `getScrollingElement` will be deprecated. New implementations should rely directly on `window` or `documentElement` as appropriate. From this commit, we now pass the `defaultView` of the `scrollingElement` directly and bind the scroll method to it. task-3877807 closes #214776 Signed-off-by: Benjamin Vray (bvr) <[email protected]>

Chatbot rating tours can sometimes fail. They all share the same steps: start a chat, close the chat, then rate the agent. Before closing the chat, the tours check that the message is present in the DOM, assuming it has been posted, then close the chat window. However, this is not enough to guarantee the thread was properly created. Initially, a temporary thread is shown. When the user sends the first message, a temporary message is posted on that thread while the real thread is created asynchronously. As a result, closing the chat after checking the message in the DOM doesn’t guarantee the window belongs to the persisted thread. If it doesn’t (due to slow network or high CPU load), the rating panel never shows because the real thread was never closed. This commit fixes the issue by waiting for the persisted thread to be created before closing the chat. fixes runbot-159683 closes #218407 X-original-commit: cc79ad8 Signed-off-by: Sébastien Theys (seb) <[email protected]> Signed-off-by: Matthieu Stockbauer (tsm) <[email protected]>

In order to ease development/debugging lonpolling=>websocket fallback we added the possibility to disable longpolling calls in order to force the communication via websocket. closes #218567 Task: 4929877 X-original-commit: b89b9f7 Signed-off-by: Louis Travaux (lotr) <[email protected]>

Versions -------- - 18.0+ Steps ----- 1. Enable debugging mode; 2. go to Settings / Technical / Database Structure / Attachments; 3. search for a PDF attachement; 4. open developer tools; 5. click on Record / Data. Issue ----- > Connection lost. Trying to reconnect... Traceback in logger: > `UnicodeDecodeError: 'utf-8' codec can't decode byte ...` Cause ----- Commit 5ef4c07 moved the `json_default` function from `date_utils` to `json`, with the purpose of letting it serialize objects besides `date` & `datetime`. When used for raw data of binary files like PDF, it encounters values that cannot be represented in UTF-8, and because `decode` defaults to strict error handling, an exception is thrown. Solution -------- When sending the `read` request to the ORM, only request fields of that aren't of type `binary` to ensure they're serializable. opw-4717657 closes #218552 X-original-commit: 21e517c Signed-off-by: Aaron Bohy (aab) <[email protected]>

…uidelines Steps to reproduce: 1. Install the `Contacts` module. 2. Go to Contacts > Create a new contact. 3. Select country "India", then open the State dropdown. 4. Observe that "Orissa" appears instead of the updated name "Odisha". Issue: As per Government of India guidelines, the state name was officially changed from "Orissa" to "Odisha" in 2011. However, Odoo still uses the outdated name in the state selection. Solution: Update the name of the state from "Orissa" to "Odisha" in state records. opw-4935633 closes #218524 X-original-commit: 4767737 Related: odoo/enterprise#90024 Signed-off-by: Nicolas Lempereur (nle) <[email protected]> Signed-off-by: Khushi Srivastava (khsr) <[email protected]>

**Issue** The auto check out cron was using the check in time in UTC to determine the excepted working hours and the previous attendances. For example: - have an employee with a working schedule using a UTC+8 timezone. - check-in on a monday before 8am (0:00 UTC) in the employee's tz. - the auto check-out cron closes the attendance immediately because there are no working hours for the attendance's check in day in UTC (Sunday). **Change** Use the date of the check-in localized in the tz of the calendar used by the attendance's employee to determine the previous worked hours for that day and the expected worked hours. opw-4654847 closes #218478 X-original-commit: f140c73 Signed-off-by: Bertrand Dossogne (bedo) <[email protected]> Signed-off-by: Tanguy Quéguineur (taqu) <[email protected]>

Before this commit, if multiple documents were sent to print at exactly the same time, some of them could end up erroring because the Windows printing API requires us to send one document at a time. After this commit, we use a lock similar to the Linux driver, to ensure that only one document is sent to the printer at once. opw-4829908 closes #218532 X-original-commit: 78c1c47 Related: odoo/enterprise#90030 Signed-off-by: Max Whale (mawh) <[email protected]>

Before the commit, when a 'pick up in store' was published, the out-of-stock message was hidden to avoid confusion. However, customers want to benefit from it, and now we reintroduce it. opw-4791969 closes #218434 X-original-commit: 1d06520 Signed-off-by: Valeriya Chuprina (vchu) <[email protected]>

We now ensure that the certificate data returned by odoo.com is not empty, to avoid nginx not restarting. closes #218432 Task: 4926102 X-original-commit: cfd47c4 Signed-off-by: Max Whale (mawh) <[email protected]> Signed-off-by: Louis Travaux (lotr) <[email protected]>

The `test_add_new_line_in_detailled_op` fails in 18.0+ since clicking on the head of the modal content will trigger a web_read before the records has been updated in db. So that the last applied change disappear. This commit attempt to clean the tour to be more reliable. runbot-113534 closes #218405 X-original-commit: 5a49e92 Signed-off-by: William Henrotin (whe) <[email protected]> Signed-off-by: Lancelot Semal (lase) <[email protected]>

PR#135607 breaks support of image types other than `png` for menu icons. This puts back the support for previously supported image types. closes #218358 X-original-commit: 9facf18 Signed-off-by: Martin Trigaux (mat) <[email protected]>

Before this commit: - Visually empty <div> elements could be inserted during paste. - These empty blocks created invisible spacing in the editor. - External styles inside pasted <div> elements were not removed. - The placeholder (`Type '/' for commands`) could not render correctly in those areas. This regression was introduced in commit `#196481`, which stopped replacing blacklisted tags like <div> with <p>. As a result, cleanForPaste no longer stripped inline styles from <div> elements. After this commit: - Non-empty <div> elements are now replaced with a valid baseContainer element. - Empty <div> elements are automatically removed from pasted content. - This restores the expected cleaning behavior and removes unwanted styles. task-4805536 closes #217992 X-original-commit: 0c66222 Signed-off-by: David Monjoie (dmo) <[email protected]>

The tests: - `test_report_stock_quantity` - `test_report_stock_quantity_with_product_qty_filter` can fail if the test class was instantiate at midnight and the tests launched at 00:01. The issue has been explained extensively in d1e11dc Here is a modest retranscription of its holy analysis: The Test class `TestReportStockQuantity` inherit from `TransactionCase`. So, once initialized, a SQL transaction is started and is the same for all the tests of the class: https://github.com/odoo/odoo/blob/d86409d93e096126b32cbb35f442db332628375d/odoo/tests/common.py#L775-L778 Also, in a SQL request, the method `now()` does not really return the current date: > Notice that NOW() and its related functions return the start time of the current transaction. In other words, the return values of the function calls are the same within a transaction. (https://www.postgresqltutorial.com/postgresql-date-functions/postgresql-now/) So, if we we start all the tests of the class `TestReportStockQuantity` at the end of D01. The SQL transaction is created and the tests are executed one by one with a NOW() corresponding to D01. However, certain indiviual tests might be launched on the following day D02 because it takes time to run the rest of the tests of the class: In particular, the python "today()" will notgive the same date as the SQL NOW and the queries of the test will simply not perform the expected. E.g: https://github.com/odoo/odoo/blob/d86409d93e096126b32cbb35f442db332628375d/addons/stock/tests/test_report_stock_quantity.py#L105-L110 runbot-226726 closes #216984 X-original-commit: 9c5e08a Signed-off-by: William Henrotin (whe) <[email protected]> Signed-off-by: Lancelot Semal (lase) <[email protected]>

### Contains the following commits: odoo/o-spreadsheet@1c3230398 [REL] 18.2.21 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) odoo/o-spreadsheet@1e355511c [PERF] pivot: don't invalidate cache needlessly [Task: 4933971](https://www.odoo.com/odoo/2328/tasks/4933971) odoo/o-spreadsheet@07a58438c [FIX] pivot: don't aggregate calculated missing value [Task: 4933818](https://www.odoo.com/odoo/2328/tasks/4933818) odoo/o-spreadsheet@002b11602 [FIX] Cells: newline is not a valid date separator [Task: 4910327](https://www.odoo.com/odoo/2328/tasks/4910327) odoo/o-spreadsheet@1b3219a0a [FIX] error_tooltip: Do not show cause position in dashboard [Task: 4926129](https://www.odoo.com/odoo/2328/tasks/4926129) odoo/o-spreadsheet@faa6fec36 [PERF] import xlsx: avoid reading all cells multiple times during table_conversion [Task: 4699860](https://www.odoo.com/odoo/2328/tasks/4699860) odoo/o-spreadsheet@ec190f3e9 [FIX] Config: remove eslint [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) odoo/o-spreadsheet@c3e2db80d [IMP] config: ignore .DS_Store file from mac os [](https://www.odoo.com/odoo/2328/tasks/) odoo/o-spreadsheet@816b89552 [FIX] header_size: resize row based on link label instead of full link [Task: 4886598](https://www.odoo.com/odoo/2328/tasks/4886598) odoo/o-spreadsheet@ac707d69a [FIX] pivot: allow to group by error [Task: 4886041](https://www.odoo.com/odoo/2328/tasks/4886041) odoo/o-spreadsheet@a392fa056 [FIX] demo: fix `clear` action again [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) odoo/o-spreadsheet@4526c9747 [FIX] demo: Fix new `clear` action [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) closes #218594 Signed-off-by: Vincent Schippefilt (vsc) <[email protected]> Co-authored-by: Anthony Hendrickx (anhe) <[email protected]> Co-authored-by: Alexis Lacroix (laa) <[email protected]> Co-authored-by: Lucas Lefèvre (lul) <[email protected]> Co-authored-by: Dhrutik Patel (dhrp) <[email protected]> Co-authored-by: Adrien Minne (adrm) <[email protected]> Co-authored-by: Mehdi Rachico (mera) <[email protected]> Co-authored-by: Florian Damhaut (flda) <[email protected]> Co-authored-by: Rémi Rahir (rar) <[email protected]> Co-authored-by: Pierre Rousseau (pro) <[email protected]> Co-authored-by: Vincent Schippefilt (vsc) <[email protected]>

…data In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect types linked to business code that should not be unlinked or changed from model. Introduce a generic way to mark some activity types as master data * model is fixed and should not be modified, because it is linked to specific flows e.g. todo should be generic; * data should not be unlinked, because it is used in automated flows like plans, business code, ... and cannot easily be replaced; Mail: make "Call", "Meeting" and "Todo" activity types master data users cannot remove as they are required in various flows: fleet, plans, voip, ... Also force their model to be False (aka be cross model). Mail: make "Warning" and "Upload document" activity types in addition to "Call" and "Todo", always cross model. As they are used in various apps it should not be specific to a model. Hr holidays: prevent from modifying leave activity types, as they are used in business flows and in automated code. Fleet: prevent from modifying contract activity type (same reason). Task-3777606 X-original-commit: e1db22f Part-of: #218184 Related: odoo/enterprise#89881 Signed-off-by: Thibault Delavallee (tde) <[email protected]>

When creating several activities linked to the same record you may encouter a crash due to several followers being inserted for the same record. Indeed everything is done at the same time and all data is not already flushed. It is actually better to uniquify list of records to subscribe, so that subscription is done once / user. Task-3777606 X-original-commit: fe16eae Part-of: #218184 Related: odoo/enterprise#89881 Signed-off-by: Thibault Delavallee (tde) <[email protected]>

When model does not match, raise a warning and fallback on default activity type. Task-3777606 X-original-commit: 17a4203 Part-of: #218184 Related: odoo/enterprise#89881 Signed-off-by: Thibault Delavallee (tde) <[email protected]>

Just make tests from 00f2a6a a bit clearer about expected behavior when creating with default activities in context. Task-3777606 X-original-commit: d517308 Part-of: #218184 Related: odoo/enterprise#89881 Signed-off-by: Thibault Delavallee (tde) <[email protected]>

Current event creation tries to create activities. However code coming from #72043 seems quite broken: it tries to find if the target model accepts activities, but does not by browsing the wrong model with wrong ids ... which globally turns off activity creation. This fix rewrites a bit code creating activities when creating an event so that * check activity support on the right model; * it uses the right model on activity type: otherwise you may end up with models that do not match between record and activity type; * remove useless (or wrong) code trying to browse 'model ids' on a given model; * we now correctly check for activity inheritance using 'is_mail_activity' field on IrModel; Task-3777606 X-original-commit: f4954b4 Part-of: #218184 Related: odoo/enterprise#89881 Signed-off-by: Thibault Delavallee (tde) <[email protected]>

Avoid calling '_sync_activities' when activities are anyway created directly from event itself. Task-3777606 X-original-commit: 38529c0 Part-of: #218184 Related: odoo/enterprise#89881 Signed-off-by: Thibault Delavallee (tde) <[email protected]>

Master data protection ====================== In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect types linked to business code that should not be unlinked or changed from model. Introduce a generic way to mark some activity types as master data * model is fixed and should not be modified, because it is linked to specific flows e.g. todo should be generic; * data should not be unlinked, because it is used in automated flows like plans, business code, ... and cannot easily be replaced; Mail: make "Call", "Meeting" and "Todo" activity types master data users cannot remove as they are required in various flows: fleet, plans, voip, ... Also force their model to be False (aka be cross model). Mail: make "Warning" and "Upload document" activity types in addition to "Call" and "Todo", always cross model. As they are used in various apps it should not be specific to a model. Hr holidays: prevent from modifying leave activity types, as they are used in business flows and in automated code. Fleet: prevent from modifying contract activity type (same reason). Account Online Synchornization: make "Bank Synchronization" master data as business behavior dependso on it. Also fix model used for the type. Account reports: make "Tax Closing" master data as business flow depends on it. Approvals: make "Approval" master data as business flow depends on it and it is not easy to remove it in their usage. Hr Payroll: make "Leaves to defer" master data as business flow depends on it. Voip: make "Call" activity type master data users cannot remove as it is required in various flows of VOIP. Also force its model to be False as it is used in various models and should not suddenly be limited to a given model. Done in community, as activity is defined in 'mail'. Studio: make "Approval" master data as approval flow depends on it. Calendar: fix activities creation ========================= Current event creation tries to create activities. However code coming from #72043 seems quite broken: it tries to find if the target model accepts activities, but does not by browsing the wrong model with wrong ids ... which globally turns off activity creation. This fix rewrites a bit code creating activities when creating an event so that * check activity support on the right model; * it uses the right model on activity type: otherwise you may end up with models that do not match between record and activity type; * remove useless (or wrong) code trying to browse 'model ids' on a given model; * we now correctly check for activity inheritance using 'is_mail_activity' field on IrModel; Task-3777606 closes #218184 Forward-port-of: #218001 Forward-port-of: #156731 Related: odoo/enterprise#89881 Signed-off-by: Thibault Delavallee (tde) <[email protected]>

This commit makes a small change to move the code that calls the weighing dialog into its own function. This is so it can more easily be overridden. task-4910716 closes #218603 X-original-commit: 1d12dd1 Related: odoo/enterprise#90065 Signed-off-by: Yaroslav Soroko (yaso) <[email protected]> Signed-off-by: Max Whale (mawh) <[email protected]>

The language used in the DIOT documentation was confusing and even though we had the exact same description for two columns it turns out they were different, so we need to change the logic of a few columns to make it work as needed. - Behavior prior to this PR: In the DIOT, the columns Paid 8% N, Paid 8% s, Paid 16%, Importation 16% and Intangible imports 16% are sums of taxes paid with this type of tax. And all the tax columns are based in the base not in the tax part. - Behavior after this PR. Taxes now have a correction in their tags so that the columns in the DIOT report are calculated correctly, Tax columns only contains tax values, not base values. opw-4920577 "I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr" closes #218414 X-original-commit: 1180c80 Related: odoo/enterprise#89984 Signed-off-by: Antoine Dupuis (andu) <[email protected]> Signed-off-by: Hector Mauricio Perez Barajas (hmpb) <[email protected]>

…tInvoicingCommon closes #217978 X-original-commit: 0ca692f Related: odoo/enterprise#89773 Signed-off-by: Claire Bretton (clbr) <[email protected]> Signed-off-by: Laurent Smet (las) <[email protected]>

`is_storable` is defined in `stock`. This test is located in `purchase`, that do not depend on `stock`. We use type='consu' instead. This change ensures that the product is created with the correct type. build_error-229762 closes #218677 Forward-port-of: #218403 Signed-off-by: William Henrotin (whe) <[email protected]> Signed-off-by: Omar Sherif Ali Hassan (osah) <[email protected]>

alexkuhn and others added 30 commits July 11, 2025 01:58

[FIX] base: menu icon image support

86670d2

PR#135607 breaks support of image types other than `png` for menu icons. This puts back the support for previously supported image types. closes #218358 X-original-commit: 9facf18 Signed-off-by: Martin Trigaux (mat) <[email protected]>

[IMP] account, account_tax_python: Move taxes helpers into AccountTes…

9f75f6d

…tInvoicingCommon closes #217978 X-original-commit: 0ca692f Related: odoo/enterprise#89773 Signed-off-by: Claire Bretton (clbr) <[email protected]> Signed-off-by: Laurent Smet (las) <[email protected]>

bt-admin added the saas-18.2 label Jul 12, 2025

bt-admin merged commit be0d718 into brain-tec:saas-18.2 Jul 12, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Syncing from upstream odoo/odoo (saas-18.2) #34241

Syncing from upstream odoo/odoo (saas-18.2) #34241

Uh oh!

bt-admin commented Jul 12, 2025

Uh oh!

Uh oh!

Syncing from upstream odoo/odoo (saas-18.2) #34241

Syncing from upstream odoo/odoo (saas-18.2) #34241

Uh oh!

Conversation

bt-admin commented Jul 12, 2025

Uh oh!

Uh oh!