Thursday, October 24, 2024
47 changes · 18.0
Enhancements to existing features
Technical users can now import attachments while preserving their links to related records and fields. This makes controlled attachment data migrations easier from the debug-only technical menu.
Original PR description
readonly=True on `res_model`/`res_field`/`res_id` of ir_attachment making these fields not importable. Attachment menu is only accessible in debug mode in the technical menu anyway. Then we suppose that user in attachment views understand what he does (hopefully). task-4252555
The mail search panel was cleaned up by removing an unused setting that had no effect on how it appeared or behaved. This keeps the code simpler and easier to maintain without changing the user experience.
Original PR description
Purpose of this commit: This commit removes the unused `className` prop from the SearchMessagePanel, as it was never utilized in the component's template.
Resolved issues and error corrections
The table picker in the HTML editor now closes when users press most keys, instead of staying open while they type. This makes table insertion feel more predictable and avoids the picker lingering over the editing area.
Original PR description
**Current behavior before PR:** - After opening the table picker, it does not close when typing, unless Escape key was pressed **Desired behavior after PR is merged:** - Now, the table picker will close when any key is pressed except for arrow keys.
Miscellaneous changes
Follow-up of https://github.com/odoo/odoo/pull/182347 PR above improved out-of-focus counter, one of such improvements is to take new inbox messages into account. However, doing so had to unintended side-effect to make them play sound, open chat bubble, and display more than 1 notification. This happens because the inbox notification were treated like new message in chat notifications. This commit fixes the issue by limiting PR above of inbox new messages to contribute for the out-of
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/182347 PR above improved out-of-focus counter, one of such improvements is to take new inbox messages into account. However, doing so had to unintended side-effect to make them play sound, open chat bubble, and display more than 1 notification. This happens because the inbox notification were treated like new message in chat notifications. This commit fixes the issue by limiting PR above of inbox new messages to contribute for the out-of-focus counter. In other words, the following behaviors have been fixed: - new inbox messages from chatter no longer open a chat bubble - new inbox messages from chatter no longer play sound - new inbox messages from chatter only show 1 notification at most Forward-Port-Of: odoo/odoo#184620
This fix ensures mobile users can create stock move records when required details are filled automatically in the background. It prevents situations where warehouse staff could be blocked from recording stock movements on mobile devices.
Original PR description
Since the `name` field is set via onchange, we need it here. Currently on mobile, a user may be prevented altogether from creating a stock move record in some situations. opw-4278098
Restores a previously removed action so customers with older analytic views can still use the view button without hitting an error. This prevents a user-facing crash and keeps existing custom or not-yet-updated screens working as expected.
Original PR description
The `action_read_distribution_model` method was removed from the following commit. https://github.com/odoo/odoo/pull/182278/commits/777dea298fd74f2349ca22d05fe7f48596216dfe Since the client's non-updated views still call it, but get a traceback as it doesn't exist anymore. Error:- ``` AttributeError: The method 'action_read_distribution_model' does not exist on the model 'account.analytic.distribution.model' ``` We add it again to fix the issue. sentry-5804153543
Sharing a project without adding collaborators no longer sends an unnecessary notification. This prevents confusing messages and makes the sharing flow clearer for users.
Original PR description
Previously, when a project was shared without adding collaborators, an incorrect notification was sent, potentially confusing for the user. this commit ensures no notification is triggered if the collaborator's O2M field is empty,thereby avoiding misleading messages. task-3956252
Changing a user's tour setting from the form now correctly stops any running guided tour when tours are disabled. This prevents unwanted onboarding or help tours from continuing after a user or administrator turns them off.
Original PR description
Before this commit, changing tour_enabled on the form view of the user was not deactivating the running tour. After this commit, the running tour is deactivated if the tour_enabled is false when loading the tour service. TASK-ID: 4276412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix keeps the work order button column in manufacturing orders sized correctly when start, pause, or stop buttons appear or disappear. Users should see a cleaner, more reliable layout without needing to resize the page to refresh the view.
Original PR description
The column containing the buttons start/pause/stop does not recompute it's size when one of the button appears/disappears, but it does when the column/the page is resized. In this fix, we revert https://github.com/odoo/odoo/pull/169177 which was not relevant anymore and we ensure to recompute the width every time if we're not using the magic column width.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Pivot titles used only in dashboard editing screens will no longer be sent for translation. This reduces unnecessary translation work without changing what end users see in standard dashboards.
Original PR description
In standards dashboards, pivot titles are currently extracted from the json files to be translated. But those titles are not visible in dashboard mode (only in edit mode, in the side panels and menus). The cost of translating those titles is not worth it. .pot files will be re-exported later, when TIC is back. She already warned the translators to skip those translation anyway. Task 4239967 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The analytic distribution model list now relies on Odoo's built-in form-opening button instead of a duplicate custom button. This keeps the interface consistent and avoids redundant controls for users when opening records.
Original PR description
In this commit: https://github.com/odoo/odoo/commit/43027a34a6e51901ff869beec2bba74218b29356 They added a new button to open the form view directly. If the view has an attribute open_form_view to True or being in debug mode. Since we manually added a button to do the exact same thing, let's use the button from the list view. task: 4204366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Creating a new Link Tracker record no longer triggers an error when required URL details are not yet filled in. This prevents an interruption for users setting up tracked links from Link Tracker or related apps like mass mailing.
Original PR description
After the new `_monkeypatches` of `url_join`/`_check_str_tuple` we're getting TypeError traceback on creating a Link Tracker. Steps ===== Install Link Tracker and an associate module(i.e., mass mailing) Turn on developer mode Open Link Tracker app and try to create a new record Traceback: `TypeError: Cannot mix str and bytes arguments (got (False, 'False'))` Technical: ========== When creating a new we don't have `short_url_host` or `code`, thus its giving False. Also, code was in in `""`, means False , "False", its unnecessary. After this commit: =================== There will be no traceback on creating a Link Tracker. Task-4279725
The payroll accounting test suite for Switzerland was adjusted to match a recent internal payslip validation change. This helps keep automated checks reliable and reduces the risk of payroll-related regressions reaching users.
The balance sheet report now handles companies that have no journals configured instead of showing an error. This prevents users from hitting a traceback when opening financial reports in empty or newly configured databases.
Original PR description
When there are no journals and the user tries to open the balance sheet report, a traceback will appear. Steps to reproduce the error: - Install ``account_reports`` module without demo data - Remove…
When there are no journals and the user tries to open the balance sheet report,
a traceback will appear.
Steps to reproduce the error:
- Install ``account_reports`` module without demo data
- Remove all journals
- Go Reporting > Open Balance sheet
Traceback:
```
StopIteration: null
File "odoo/http.py", line 2364, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 728, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/18.0/account_reports/models/account_report.py", line 1914, in get_options
initializer(options, previous_options=previous_options)
File "home/odoo/src/enterprise/18.0/account_reports/models/account_report.py", line 379, in _init_options_journals
options['journals'].extend(next(iter(company_journals_map.values())))
```
https://github.com/odoo/enterprise/blob/302eb1052609462fe607f77fcc934690f9abbe5a/account_reports/models/account_report.py#L379
When there are no journals ``company_journals_map`` will be empty,
So, it will lead to the above traceback.
sentry-5993507281Spreadsheet side panels now use a consistent bold style for their titles and labels. This fixes a visual inconsistency, making the interface feel more polished and easier to scan for users.
Original PR description
## Description The font weight of this side panel was previously inconsistent with other side panels. This commit ensures that the font weight is now uniform across all side panels. Task: 4194259
A test was added to ensure spreadsheet pivot autocomplete works correctly when using positional pivot arguments in Odoo. This helps prevent a previously fixed issue from returning and supports more reliable spreadsheet behavior for users.
Original PR description
This commit adds a test for a bug fix merged in o-spreadsheet, but the behavior can actually only be triggered in odoo, with positional pivot arguments. Task: 4235329
Problem: When a user is on a branch, they are unable to view the parent company's discounts and are unable to apply it to the sales orders. Purpose: The branch should have access to the discounts & loyalty programs from the parent company. Steps to Reproduce on Runbot: 1. Install sale_loyalty 2. Create a branch 3. On the branch company, observe that no discounts & loyalty programs from the parennt company are displayed 4. Attempt to apply a coupon code from a discount belonging to the
Original PR description
Problem: When a user is on a branch, they are unable to view the parent company's discounts and are unable to apply it to the sales orders. Purpose: The branch should have access to the discounts & loyalty programs from the parent company. Steps to Reproduce on Runbot: 1. Install sale_loyalty 2. Create a branch 3. On the branch company, observe that no discounts & loyalty programs from the parennt company are displayed 4. Attempt to apply a coupon code from a discount belonging to the parent company on a sales order and receive a ValidationError opw-4079487 closes odoo/odoo#182392 X-original-commit: 85d130302e88deb4ee8d1172d847d7ab78918418 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184807
Fixes a rounding issue where the cost of kit components is rounded too early in the stock valuation process, leading to discrepancies in the final stock valuation layer values. The kit's total cost was being calculated with an early rounding step, which caused a small mismatch between the expected and actual values. This fix ensures that the correct unit cost is used in the stock valuation layer without affecting the product's standard price. Example: 1.) Create Product A: Storable Product
Original PR description
Fixes a rounding issue where the cost of kit components is rounded too early in the stock valuation process, leading to discrepancies in the final stock valuation layer values. The kit's total cost…
Fixes a rounding issue where the cost of kit components is rounded too early in the stock valuation process, leading to discrepancies in the final stock valuation layer values. The kit's total cost was being calculated with an early rounding step, which caused a small mismatch between the expected and actual values. This fix ensures that the correct unit cost is used in the stock valuation layer without affecting the product's standard price. Example: 1.) Create Product A: Storable Product Type Route = Manufacturing Category = AVCO or FIFO 2.) Create Product B: Storable Product Type Routes = Buy Category = AVCO or FIFO 3.) Make a BOM Product A Quantity = 1 Kit Components: 12 units of Product B 4.) Create a Purchase Order: Buy 1 unit of Product A at $100 5.) Confirm PO -> this will generate a receipt 6.) Validate receipt 7.) Note the valuation is 12 units @ a value of 99.96 where it should be 100 Current behavior before PR: svl.value = 99.96 Desired behavior after PR is merged: svl.value = 100 opw-4208554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184805 Forward-Port-Of: odoo/odoo#183267
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 task-3794536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185027
Original PR description
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 task-3794536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185027
- Add new tax groups, fiscal positions and taxes for retentions of not residents. - Add configuration to send SII in new taxes. https://sede.agenciatributaria.gob.es/Sede/nuevasede.html @rafaelbn @arantxasudon @moduon MT-5974 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183901 Forward-Port-Of: odoo/odoo#166499
Original PR description
- Add new tax groups, fiscal positions and taxes for retentions of not residents. - Add configuration to send SII in new taxes. https://sede.agenciatributaria.gob.es/Sede/nuevasede.html @rafaelbn @arantxasudon @moduon MT-5974 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183901 Forward-Port-Of: odoo/odoo#166499
A traceback occurs from version 18.0 when the user creates a new link tracker. To reproduce this issue in 18.0: 1) Install website, link tracker and enable debug mode 2) Tries to create a new link tracker record from the link tracker Error:- ``` TypeError: Cannot mix str and bytes arguments (got (False, 'False')) ``` The onchange sets computes to False by default when they're requested, and apparently does not recompute them if they don't depend on anything. Because of that
Original PR description
A traceback occurs from version 18.0 when the user creates a new link tracker. To reproduce this issue in 18.0: 1) Install website, link tracker and enable debug mode 2) Tries to create a new link tracker record from the link tracker Error:- ``` TypeError: Cannot mix str and bytes arguments (got (False, 'False')) ``` The onchange sets computes to False by default when they're requested, and apparently does not recompute them if they don't depend on anything. Because of that the `short_url_host` value will be False and this leads to a traceback when the compute method of `short_url` triggers. Ref of the breaking commit:- https://github.com/odoo/odoo/pull/170548/commits/20d2f122568feead98df18706ca0a4691c8393c5 sentry-5969318187 Forward-Port-Of: odoo/odoo#182898
An error message was missing a space in between "a" and "hamburger" in "ahamburger". This commit fixes this typo. Task-4173938 Forward-Port-Of: odoo/odoo#184791 Forward-Port-Of: odoo/odoo#184584
Original PR description
An error message was missing a space in between "a" and "hamburger" in "ahamburger". This commit fixes this typo. Task-4173938 Forward-Port-Of: odoo/odoo#184791 Forward-Port-Of: odoo/odoo#184584
e-Resguardo document type must not have internal type **Current behavior before PR**: e-Resguardo document type has "invoice" internal type  **Desired behavior after PR is merged**: e-Resguardo document type do not have internal type **Task Adhoc side**: 43467 **Task Latam side**: 1280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port
Original PR description
e-Resguardo document type must not have internal type **Current behavior before PR**: e-Resguardo document type has "invoice" internal type  **Desired behavior after PR is merged**: e-Resguardo document type do not have internal type **Task Adhoc side**: 43467 **Task Latam side**: 1280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184810
Problem: When creating a purchase order (PO) for a company with branches, products from all branches are shown in the product list, even if only the main company is selected. However, users are not allowed to create POs for products belonging to other branches, leading to confusion. Steps to reproduce: - Create a company with branches. - Configure some products for the main company and others for the branches. - In the company selector, choose the main company, keeping branches selected.
Original PR description
Problem: When creating a purchase order (PO) for a company with branches, products from all branches are shown in the product list, even if only the main company is selected. However, users are not allowed to create POs for products belonging to other branches, leading to confusion. Steps to reproduce: - Create a company with branches. - Configure some products for the main company and others for the branches. - In the company selector, choose the main company, keeping branches selected. - While creating a PO, products from the branches appear in the product list. opw-4116680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184757 Forward-Port-Of: odoo/odoo#180623
Adhoc-task: 40503 Description of the issue/feature this PR addresses: 1- We removed the following taxes to avoid duplication: "ex_tax_retencion_suss_sufrida", "WTH SUSS I", which is already located here(https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R2) "ex_tax_retencion_ganancias_sufrida", "WTH Earnings I", which is already located here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06
Original PR description
Adhoc-task: 40503 Description of the issue/feature this PR addresses: 1- We removed the following taxes to avoid duplication: "ex_tax_retencion_suss_sufrida", "WTH SUSS I", which is already located…
Adhoc-task: 40503 Description of the issue/feature this PR addresses: 1- We removed the following taxes to avoid duplication: "ex_tax_retencion_suss_sufrida", "WTH SUSS I", which is already located here(https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R2) "ex_tax_retencion_ganancias_sufrida", "WTH Earnings I", which is already located here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R7) and here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R12) 2- We moved the taxes from files to match the same structure as l10n_ar Current behavior before PR: After downloading l10n_ar_withholding and checking the taxes, we realized there were some duplicates. [[FIX]l10n_ar_withholding: repeated taxes in chart of accounts.webm](https://github.com/odoo/odoo/assets/109111493/56776d61-86f1-4632-98a4-c9e192cc5f3a) Desired behavior after PR is merged: The taxes are no longer duplicated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168945
When upgrading a module where a model has been removed entirely, the ORM does a clean up for 'ir.model.fields.selection' records. However, in this case it doesn't work, because the records reference a model that no longer belongs to the registry (if there are no migration scripts). This commit simply makes the cleanup ignore such a case. It makes sense, because the whole table will be deleted anyway (if there are no migration scripts). STEPS - install a module that defines a model with
Original PR description
When upgrading a module where a model has been removed entirely, the ORM does a clean up for 'ir.model.fields.selection' records. However, in this case it doesn't work, because the records reference a model that no longer belongs to the registry (if there are no migration scripts). This commit simply makes the cleanup ignore such a case. It makes sense, because the whole table will be deleted anyway (if there are no migration scripts). STEPS - install a module that defines a model with a selection field - rename or remove the model - upgrade the module This commit fixes #179392. It was inspired by #104624. opw-3024537 Forward-Port-Of: odoo/odoo#184764
A known issue in Brave (https://github.com/brave/brave-browser/issues/2362#issuecomment-571775236) prevents push notifications unless "Use Google Services for Push Messaging" is enabled in settings. Before this commit, attempting to enable desktop notifications in Brave resulted in a traceback. This commit handles the failure by displaying a more helpful message, suggesting enabling Google Services when using Brave, or showing a generic error for other browsers. task-4191214 Forward-
Original PR description
A known issue in Brave (https://github.com/brave/brave-browser/issues/2362#issuecomment-571775236) prevents push notifications unless "Use Google Services for Push Messaging" is enabled in settings. Before this commit, attempting to enable desktop notifications in Brave resulted in a traceback. This commit handles the failure by displaying a more helpful message, suggesting enabling Google Services when using Brave, or showing a generic error for other browsers. task-4191214 Forward-Port-Of: odoo/odoo#184394 Forward-Port-Of: odoo/odoo#183968
Prior to this commit, splitting an order would create a new order, causing it to appear again on the preparation display. This could lead to the kitchen preparing the same order twice. The sequence of events was as follows: 1. The order is placed. 2. The kitchen receives and prepares the order. 3. The waiter delivers the order to the table. 4. The client receives the bill and requests a split. At the point of splitting, a new order is created. This duplicate order should not be sent to
Original PR description
Prior to this commit, splitting an order would create a new order, causing it to appear again on the preparation display. This could lead to the kitchen preparing the same order twice. The sequence of events was as follows: 1. The order is placed. 2. The kitchen receives and prepares the order. 3. The waiter delivers the order to the table. 4. The client receives the bill and requests a split. At the point of splitting, a new order is created. This duplicate order should not be sent to the kitchen as it represents a meal that has already been prepared and consumed. This commit resolves this issue by preventing display of duplicate orders to the kitchen during order splitting. opw-4247067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184679
This commit allows uninvited admins to edit non-private events (public, confidential). It was a needed change since administrators might have to change the event information of these types of events day to day. A re-work of the compute methods will be made on master followed by the addition of the proper ACL rules for handling calendar events. task-4182649 Forward-Port-Of: odoo/odoo#180051
Original PR description
This commit allows uninvited admins to edit non-private events (public, confidential). It was a needed change since administrators might have to change the event information of these types of events day to day. A re-work of the compute methods will be made on master followed by the addition of the proper ACL rules for handling calendar events. task-4182649 Forward-Port-Of: odoo/odoo#180051
Before this commit we are not able to move expense to a reconciled account in a future period because posting future entries are delayed so we can't reconciled journal items on the fly. * create new company 'test' * switch on it * install French accounting (l10n_fr) * check 'Show Full Accounting Features' to gives access to accounting feature on your user access tab * create vendor bill and post it * go to the 'Journal Items' tab and click on cut-off button and set following fields in
Original PR description
Before this commit we are not able to move expense to a reconciled account in a future period because posting future entries are delayed so we can't reconciled journal items on the fly. * create new company 'test' * switch on it * install French accounting (l10n_fr) * check 'Show Full Accounting Features' to gives access to accounting feature on your user access tab * create vendor bill and post it * go to the 'Journal Items' tab and click on cut-off button and set following fields in the wizard: * *Recognition Date*: next month * *Accrued Account*: '486000 Charges constatées d'avance' * Adjusting Amount: as you want 50% for example * *Journal* : Miscellaneous Operations * click on create journal entries button Journal entries should be created. Fixes #94390 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184962 Forward-Port-Of: odoo/odoo#94395
Prior to this PR, the layout of the Twitter section in the email template was distorted (see reference image: https://tinyurl.com/29meoh6o). With this PR, the layout issue will be fixed to ensure it displays correctly. Task-4210376 Forward-Port-Of: odoo/odoo#184045
Original PR description
Prior to this PR, the layout of the Twitter section in the email template was distorted (see reference image: https://tinyurl.com/29meoh6o). With this PR, the layout issue will be fixed to ensure it displays correctly. Task-4210376 Forward-Port-Of: odoo/odoo#184045
This commit adds a constraint on the availability_condition, checking that if the availability_condition is set to country, the field country_id is set. task-4160643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184686 Forward-Port-Of: odoo/odoo#182509
Original PR description
This commit adds a constraint on the availability_condition, checking that if the availability_condition is set to country, the field country_id is set. task-4160643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184686 Forward-Port-Of: odoo/odoo#182509
Steps to reproduce: - Install `l10n_ec_website_sale` - Change the company of the first website to 'EC Company' - Change company of demo user to 'EC Company' - Connect as demo - Make a purchase - Checkout and fill the address - Create a new billing address Issues: A traceback appears, the reason is that `show_vat` is false here as we are editing a new billing address as such `partner_sudo != order_sudo.partner_id`. https://github.com/odoo/odoo/blob/4c025f91d4a13c9a150c4c16ac9754da0b
Original PR description
Steps to reproduce: - Install `l10n_ec_website_sale` - Change the company of the first website to 'EC Company' - Change company of demo user to 'EC Company' - Connect as demo - Make a purchase -…
Steps to reproduce: - Install `l10n_ec_website_sale` - Change the company of the first website to 'EC Company' - Change company of demo user to 'EC Company' - Connect as demo - Make a purchase - Checkout and fill the address - Create a new billing address Issues: A traceback appears, the reason is that `show_vat` is false here as we are editing a new billing address as such `partner_sudo != order_sudo.partner_id`. https://github.com/odoo/odoo/blob/4c025f91d4a13c9a150c4c16ac9754da0b2c79e4/addons/website_sale/controllers/main.py#L1159-L1168 Since `show_vat` is False the VAT fields will not be shown. https://github.com/odoo/odoo/blob/d61a8212ca795009ca4f39462991614a42e41700/addons/website_sale/views/templates.xml#L1990 However for ecuadorian company for example `vat` and `l10n_latam_identification_type_id` is set as mandatory. https://github.com/odoo/odoo/blob/4c025f91d4a13c9a150c4c16ac9754da0b2c79e4/addons/l10n_ec_website_sale/controllers/main.py#L17-L18 This discrepancy causes a traceback later on as we are requiring a field which is not visible in the view. https://github.com/odoo/odoo/blob/d61a8212ca795009ca4f39462991614a42e41700/addons/website_sale/static/src/js/address.js#L127-L135 opw-4139919 Forward-Port-Of: odoo/odoo#183705
Use Case : Argentinian Company (pesos) Invoice in USD Payment received in USD, with withholding tax on it The current logic will convert the withholding values from USD (payment currency) to USD (invoice currency) instead of converting to ARS (company currency) and set this value as balance. This is of course incorrect. opw-4150317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183726
Original PR description
Use Case : Argentinian Company (pesos) Invoice in USD Payment received in USD, with withholding tax on it The current logic will convert the withholding values from USD (payment currency) to USD (invoice currency) instead of converting to ARS (company currency) and set this value as balance. This is of course incorrect. opw-4150317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183726
**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will reusult in a traceback when MRP is installed. **Expected behavior:** No traceback. **Steps to reproduce:** *install mrp,purchase* *enable reception report in settings* 1. Open a purchase order with a product that is used in another order 2. Click on the forecast report on the order lin
Original PR description
**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will…
**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will reusult in a traceback when MRP is installed. **Expected behavior:** No traceback. **Steps to reproduce:** *install mrp,purchase* *enable reception report in settings* 1. Open a purchase order with a product that is used in another order 2. Click on the forecast report on the order line 3. Click on a linked record in the "Used by" column in the report table 4. Click the browser back button -> traceback **Cause of the issue:** When trying to rebuild context, we get the actual model name provided by this.props.action.res_model. This was invariably treated as a stringified number in a read call to `ir.model` to try to get the model name -> result of the read is nonsense and when it is later used in an RPC, it tries to read fields from a nonexistent model. **Fix:** Get rid of the String -> Number conversion, directly use the value in `res_model` as the new `this.resModel`. opw-4181590 Forward-Port-Of: odoo/odoo#183742
The test depended on a module that was not in the depends. Forward-Port-Of: odoo/odoo#184578
Original PR description
The test depended on a module that was not in the depends. Forward-Port-Of: odoo/odoo#184578
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However since this view is cached (by [this line][2]) it happens that the livechat bubble appears without any operators available and vice versa. __Description of the fix:__ Add a t-nocache to prevent `info` from being cached and always be up-to-date. __Steps to reproduce the issue:__ On runbot this b
Original PR description
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However…
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However since this view is cached (by [this line][2]) it happens that the livechat bubble appears without any operators available and vice versa. __Description of the fix:__ Add a t-nocache to prevent `info` from being cached and always be up-to-date. __Steps to reproduce the issue:__ On runbot this behavior is inconsistent since each worker has its own cache. It is however consistent in local with only one worker. Make sure you are **not** in debug mode 1. Set a livechat channel on the website, make sure there is no chatbot on it 2. Enter the livechat channel with the admin 3. Open the website on an incognito window (the chat bubble should be there) 4. Leave the livechat channel with the admin 4. Refresh the incognito window The chat bubble is still there. Note that the chat bubble might not appear at all even when the admin enter the livechat if the opposite has been cached before. opw-4233744 [1]: https://github.com/odoo/odoo/blob/837a6a8/addons/im_livechat/views/im_livechat_channel_templates.xml#L100 [2]: https://github.com/odoo/odoo/blob/2997afa/addons/website/views/website_templates.xml#L86 Forward-Port-Of: odoo/odoo#184644
As part of the removing `Dead Batteries` pep 594, the usage of the `cgi` module is deprecated and it will be removed the standard library in python 3.13. See https://peps.python.org/pep-0594/#cgi Here the cgi module was used to parse the `Content-Type` of a response and separate the mime part from the parameters. But as the mime part was only used to verify the beginning of the string this separation is not nedeed. While at it, this commit removes the unused zlib import. Forward-Port-Of:
Original PR description
As part of the removing `Dead Batteries` pep 594, the usage of the `cgi` module is deprecated and it will be removed the standard library in python 3.13. See https://peps.python.org/pep-0594/#cgi Here the cgi module was used to parse the `Content-Type` of a response and separate the mime part from the parameters. But as the mime part was only used to verify the beginning of the string this separation is not nedeed. While at it, this commit removes the unused zlib import. Forward-Port-Of: odoo/odoo#184845
Steps to reproduce: - install Documents and CRM - login as Marc Demo - go to any pivot view - click on "Insert in spreadsheet" - select the Dashboards tab and confirm => boom Task: 4273554 Forward-Port-Of: odoo/enterprise#72395
Original PR description
Steps to reproduce: - install Documents and CRM - login as Marc Demo - go to any pivot view - click on "Insert in spreadsheet" - select the Dashboards tab and confirm => boom Task: 4273554 Forward-Port-Of: odoo/enterprise#72395
Forward-Port-Of: odoo/enterprise#72336 Forward-Port-Of: odoo/enterprise#72260
Original PR description
Forward-Port-Of: odoo/enterprise#72336 Forward-Port-Of: odoo/enterprise#72260
CAF is based on the AVS Salary and not the GROSS Forward-Port-Of: odoo/enterprise#72550 Forward-Port-Of: odoo/enterprise#72534
Original PR description
CAF is based on the AVS Salary and not the GROSS Forward-Port-Of: odoo/enterprise#72550 Forward-Port-Of: odoo/enterprise#72534
Problem: The issue occurs when trying to select a different plan for a recurring product with variants in the e-commerce view. We are not refreshing the list of plans when we select another combination. Steps to reproduce: - Create a recurring product with variants. - Add multiple subscription plans with variants. - Go to the website and view the product page. - The selection of alternative plans is unavailable. opw-4179086 Forward-Port-Of: odoo/enterprise#72480 Forward-Port-Of: odoo
Original PR description
Problem: The issue occurs when trying to select a different plan for a recurring product with variants in the e-commerce view. We are not refreshing the list of plans when we select another combination. Steps to reproduce: - Create a recurring product with variants. - Add multiple subscription plans with variants. - Go to the website and view the product page. - The selection of alternative plans is unavailable. opw-4179086 Forward-Port-Of: odoo/enterprise#72480 Forward-Port-Of: odoo/enterprise#71347
Steps to reproduce the issue: 1. Install the MRP module 2. Go to Production Analysis 3. Click on the pivot table 4. Select the `Expected component cost / unit` field 5. The miscalculation will be show for `expected_component_cost_unit`. It is dividing by the MO quantity produced rather than the BOM quantity. Explanation: The issue lies in the SQL query, where the expected cost is divided by `prod_qty.product_quantity`, meaning we are using the quantity produced by a MO. instead,
Original PR description
Steps to reproduce the issue: 1. Install the MRP module 2. Go to Production Analysis 3. Click on the pivot table 4. Select the `Expected component cost / unit` field 5. The miscalculation will be show for `expected_component_cost_unit`. It is dividing by the MO quantity produced rather than the BOM quantity. Explanation: The issue lies in the SQL query, where the expected cost is divided by `prod_qty.product_quantity`, meaning we are using the quantity produced by a MO. instead, it should be divided by the BOM quantity. Fix reasoning: With this commit, the issue is resolved by dividing the expected cost by the BOM `product_qty`. Forward-Port-Of: odoo/enterprise#69905
Before this commit: The lock date error message was hard-coded to the MM/DD/YYYY format, regardless of the user's language, which causing inconsistency and confusion in date format. After this commit: The lock date error message now dynamically follows the date format set to the user's language, which improve consistency and reduce confusion. task-3925185 Forward-Port-Of: odoo/enterprise#72579 Forward-Port-Of: odoo/enterprise#70405
Original PR description
Before this commit: The lock date error message was hard-coded to the MM/DD/YYYY format, regardless of the user's language, which causing inconsistency and confusion in date format. After this commit: The lock date error message now dynamically follows the date format set to the user's language, which improve consistency and reduce confusion. task-3925185 Forward-Port-Of: odoo/enterprise#72579 Forward-Port-Of: odoo/enterprise#70405
Problem: When changing a variant in the rental product page, the availability is not updated because the `/rental/product/availabilities` endpoint is not called. This results in situations where users can attempt to rent unavailable variants without being warned. Steps to reproduce: - Create a rental product with two variants. - Try to rent the second variant when it is unavailable. - The `/rental/product/availabilities` endpoint is not called, so availabilities are not updated, and no wa
Original PR description
Problem: When changing a variant in the rental product page, the availability is not updated because the `/rental/product/availabilities` endpoint is not called. This results in situations where users can attempt to rent unavailable variants without being warned. Steps to reproduce: - Create a rental product with two variants. - Try to rent the second variant when it is unavailable. - The `/rental/product/availabilities` endpoint is not called, so availabilities are not updated, and no warning is displayed. opw-4130172 Forward-Port-Of: odoo/enterprise#72503 Forward-Port-Of: odoo/enterprise#71851
… partners This enhancement introduces an XLSX export variant for the trial balance, specifically tailored for Colombian companies under the report name "BALANCE DE PRUEBA POR TERCERO." The requirement is to provide a detailed breakdown per partner for each account. The initial trial balance lines are primarily derived from the general ledger report, which originally focused on grouping by accounts. Inspired by the structure of the general ledger accounts, this implementation now extends t
Original PR description
… partners This enhancement introduces an XLSX export variant for the trial balance, specifically tailored for Colombian companies under the report name "BALANCE DE PRUEBA POR TERCERO." The requirement is to provide a detailed breakdown per partner for each account. The initial trial balance lines are primarily derived from the general ledger report, which originally focused on grouping by accounts. Inspired by the structure of the general ledger accounts, this implementation now extends the grouping to include both accounts and partners. While initially designed for the Colombian localization, the code is flexible and can be easily adapted for use in other localizations as needed. Co-authored-by: Brice Bartoletti <bib@odoo.com> task-3594546 Forward-Port-Of: odoo/enterprise#72404 Forward-Port-Of: odoo/enterprise#70110
In odoo/odoo#182509, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643 Forward-Port-Of: odoo/enterprise#72523
Original PR description
In odoo/odoo#182509, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643 Forward-Port-Of: odoo/enterprise#72523