Friday, January 17, 2025
55 changes · 18.0
Enhancements to existing features
When an invoice report is misconfigured, users now see a clear error message instead of a technical crash. This helps administrators quickly identify that no invoice report is configured in the database and resolve the setup issue.
Original PR description
Problem --------- When you use a Invoice report with the checkbox "Invoice report" unselected (misconfiguration), you get a traceback. Objective --------- Replace it with an error message instead, saying there's no invoice report configured in the database. Solution --------- Turn the asserts into a if condition that raises a user error. task-4421065 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Leaving a Discuss call now also exits full-screen mode if it was active. This prevents users from being stuck in full-screen view after ending a call, making the call experience smoother and less confusing.
Original PR description
Before this commit, leaving call while the call view is full screen would keep the fullscreen mode. This commit fixes the issue by exiting the full screen when leaving the call. Task-4476568
Code cleanup and technical improvements
This update removes leftover unused code from the Restaurant Point of Sale area. It does not change business workflows, but helps keep the system easier to maintain and reduces the chance of confusion in future updates.
Original PR description
Remove dead code forgotten in previous commit
Miscellaneous changes
Problem: When a manufacturing order with a work order that was not planned is completed, a resource.calendar.leave is created for the work order. During this process the work order’s date_finished field is recalculated. This means that this work order reserves a slot in the work center to be finished in the future even though it has already been completed. Purpose: If the work order already has a date_finished value, then that value should be used instead of it being recalculated based on the
Original PR description
Problem: When a manufacturing order with a work order that was not planned is completed, a resource.calendar.leave is created for the work order. During this process the work order’s date_finished…
Problem: When a manufacturing order with a work order that was not planned is completed, a resource.calendar.leave is created for the work order. During this process the work order’s date_finished field is recalculated. This means that this work order reserves a slot in the work center to be finished in the future even though it has already been completed. Purpose: If the work order already has a date_finished value, then that value should be used instead of it being recalculated based on the availability of the work center. This will help ensure that completed work orders are not reserving time in a work center when it has already been completed. Steps to Reproduce on Runbot: 1. Create a new storable product. 2. Create a BoM for this product and navigate to the Operations tab and add an operation. 3. Create a manufacturing order, confirm it, and then produce all without planning it. 4. Navigate to the completed work order and observe the finished date is in the future. 5. Navigate to the work centers working hours’ time off and find the record associated with the work order. 6. Observe that the end date is in the future. opw-4393301 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193705 Forward-Port-Of: odoo/odoo#192393
This fixes an internal website test so its media dialog checks are actually executed. It helps ensure website media features are tested as intended, reducing the chance of unnoticed issues reaching users.
Original PR description
This PR adds the missing run methods in the media dialog tour steps **merged** in [commit](https://github.com/odoo/odoo/commit/bee295f). The run methods are necessary to execute the tour steps Without these methods, the tour steps were not executed properly, and the functionality was not tested as intended. task-4246644
On small screens, a button menu with only one item now displays cleanly without leaving an empty space beside it. This improves the visual polish and usability of forms on mobile devices.
Original PR description
On smaller screen, the statbuttons are grouped in a dropdown (the "lightning" icon) and displayed in two columns. But when only one button is present, it leaves a weird empty cell next to it. This commit fixes it by adding an exception in CSS when only one button is present to remove the useless column and center it. Note: this change doesn't affect the empty cell when an odd number of buttons are displayed. task-4491705
The document layout setup now correctly shows the A4 paper format when Belgian payroll is installed. This prevents confusion during document configuration and helps businesses select the right format for payroll-related reports.
Original PR description
In the document layout configurator, the paper format A4 would not be there if the module l10n_be_hr_payroll is installed. This is because in Belgium, some reports need A4 but in the configurator, we only get paperformat not linked to any report. The solution is to remove the domain for this field in the configurator. Since there will be more paper formats, I renamed the newly created formats in the Belgian payroll to differentiate them.
The website mega menu now handles links that were saved without a URL instead of crashing. This prevents visitors and editors from seeing an error when navigating to pages that are not part of the menu.
Original PR description
Steps to reproduce: - Open the "Menu Editor" dialog. - Add a "Mega Menu Item". - Save the "Menu Editor" dialog. - Enter "Edit Mode". - Open the "Mega Menu". - Select "Images Subtitles" as the "Mega Menu" template option. - Click on the largest image on the right side of the "Mega Menu". - Click the "Create Link" button in the image options. - Leave the input URL empty for this new link. - Save the page. - A link without an "href" attribute is now present in the "Mega Menu". - Edit the browser URL to redirect to a page that is not present in the menu; for example, add "/test" to the current URL. It does not matter whether the page exists or not. - Bug: A traceback occurs. The bug occurred because the function "_updateActiveMenuLinks" (introduced by this commit [1]) called "new URL" on an empty string, as it attempted to process a link without an href attribute. [1]: https://github.com/odoo/odoo/commit/5be12800a59e912997fff39cec57ab70914f2485 opw-4480958
This fixes an issue in Discuss calls on mobile where moving participant cards could make them disappear off screen. Participant cards can now only be dragged when they are in the intended movable state, improving call usability on phones and tablets.
Original PR description
Before this commit, when dragging participant cards on mobile they will get dragged off screen. 1. Open discuss on mobile 2. Get into a call 3. Move the participant cards -> they will disappear This happens because the `drag` function gets called without checking if the participant card is in the inset state (the state in which it can be moved around). This commit fixes the issue by checking that the component is in that state before being able to drag it. task-4491597
Users can now use Escape or Enter when confirming whether to close a live chat. This makes the close confirmation behave as expected and helps operators handle chats more smoothly without relying only on mouse clicks.
Original PR description
Before this commit, the Escape and Enter hotkeys did not work to cancel and confirm the `CloseConfirmation` in livechat. This happened because: - The `keydown' event is not captured without the focused element. - `useAutofocus` doesn't detect the element properly because the active element in the ui service is set by the main tree DOM root, not the shadow root. This PR makes sure that the close confirmation element is focusable on mounting and also puts the focus on the chat window composer on cancel so it's more effective in case the user needs to type or use Esc to reopen close confirmation.
The public sharing page for live spreadsheets no longer shows a download button that led visitors to a 404 error. This avoids a confusing broken action for external viewers when spreadsheets are shared by link.
Original PR description
Steps to reproduce: - install Documents - create a new spreadsheet - hit the Share button - change the sharing settings to "Anyone with the link: Viewer / Musty have the link to access" - open the…
Steps to reproduce: - install Documents - create a new spreadsheet - hit the Share button - change the sharing settings to "Anyone with the link: Viewer / Musty have the link to access" - open the sharing link in an incognito window - hit the download button => 404 not found A public user cannot convert a spreadsheet to an excel file and downlaod it because a route needs to be called to create the excel file. This route is currently not allowed for public users. For frozen spreadsheet, we generate the excel file before-hand (when the internal user shares the spreadsheet). For a regular "live" share though, we cannot pre-generate the excel file since the spreadsheet continues to live and evolve. The `spreadsheet` module needs to be updated for this bug fix to take effect. (otherwise the download button won't do anything, which is not worse than facing a 404 response) See also Enterprise PR. Task: 4440241 opw: 4417519 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The upload button shortcut in Accounting has been changed from Alt+B to Alt+Shift+I. This prevents it from interfering with Odoo's standard back navigation shortcut, making keyboard use smoother and more predictable.
Original PR description
Before this PR: - The Upload Button was assigned the shortcut Alt+B. - This caused a conflict with Odoo's default shortcut for navigating backward. After this PR: - The shortcut for the Upload Button is now updated to Alt+Shift+I. - This resolves the conflict and ensures smooth navigation and functionality. Task ID:-4417310
Invoices sent for a contact linked to a company now use the company's configured EDI format instead of the individual contact's format. This ensures customers receive electronic invoices in the expected company-level format and avoids incorrect document generation.
Original PR description
The invoice edi format should be take from the parent of the partner instead of the partner himself. Steps: - Create an individual partner X and set an edi format - Create a company partner Y and set a different edi format - Make X child of Y - Create an invoice for X, confirm and click on 'Send and print' button -> The edi file is in the format set on X instead of the format set on Y opw-4480527
The portal user welcome email template has been renamed to avoid sharing the same name as another user invitation template. This makes the email template list clearer for administrators and reduces the chance of selecting the wrong template.
Original PR description
Currently, there are two mail templates named "Settings: New User Invite" in the records. To avoid duplication, we will rename the template used to welcome portal users who register as internal users to "Settings: New Portal Sign Up". Follow up of #188391 Task-4481862 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes several issues in Odoo’s frontend testing framework and related test helpers, making automated tests more reliable and less prone to false failures or timeouts. It improves how test timing, progress display, mock server defaults, and protected error reporting work, helping teams catch real issues faster during development.
Original PR description
This commit handles various fixes for the Hoot testing framework & other frontend unit test helpers. Enterprise: https://github.com/odoo/enterprise/pull/77245 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes invoice name generation for companies whose fiscal year ends on February 29. It prevents incorrect sequence selection in non-leap years, helping invoices keep consistent and compliant numbering.
Original PR description
When computing an invoice name placeholder dynamically the sequence used depends on the fiscal year end date but it does not account for february 29 on non-leap years, which is a [valid](https://github.com/odoo/odoo/blob/893b253644159a70d1916e3eaf25d1c8af4e92c3/addons/account/models/company.py#L294-L298) date. Here an adjustment for the day is added to safely compare a date with the fiscalyear end. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The document layout setup now correctly shows the A4 paper format when Belgian payroll is installed. This prevents confusion when configuring payroll-related documents and makes similarly named Belgian payroll formats easier to tell apart.
Original PR description
In the document layout configurator, the paper format A4 would not be there if the module l10n_be_hr_payroll is installed. This is because in Belgium, some reports need A4 but in the configurator, we only get paperformat not linked to any report. The solution is to remove the domain for this field in the configurator. Since there will be more paper formats, I renamed the newly created formats in the Belgian payroll to differentiate them.
The Shopee sales app was added to the translation setup after being missed in an earlier merge. This helps ensure its text can be translated properly for users in different languages, with no expected change to day-to-day workflows.
Original PR description
File was forgotten during the merge of 6845ca19567577f70910ed269f91232453c93b20
This fixes an issue in Documents where using Shift + Down Arrow after selecting a record did not extend the selection to the next record. Users can now select multiple documents with the keyboard as expected, improving day-to-day list navigation.
Original PR description
Reproduce: 1. Go to documents list view 2. Select any not-the-last record 3. Hold Shift and hit down arrow 4. The record below is not selected as it should Task-4432914
Payslip PDF reports now display the employee's actual pay schedule, such as bi-weekly, instead of always showing monthly for monthly wage contracts. This helps payroll documents better match contract settings and reduces confusion for employees and payroll teams.
Original PR description
Steps: - Install the hr_payroll module - Open the payslip form view - click on print --- Description of the issue/feature this PR addresses: When the schedule pay on a contract is set to anything other than `Monthly` (e.g., bi-weekly), the PDF report incorrectly displays `Monthly`. This happens because the report only considers the wage type (monthly or hourly) and does not take the schedule pay into account. --- Fix: This PR addresses the issue by including the schedule pay type in the PDF report when the wage type is set to `Monthly`. task-4332531
Public viewers of live shared spreadsheets no longer see a download button that leads to a 404 error. This avoids confusion for external recipients while keeping frozen spreadsheet downloads available when they can be prepared in advance.
Original PR description
Steps to reproduce: - install Documents - create a new spreadsheet - hit the Share button - change the sharing settings to "Anyone with the link: Viewer / Musty have the link to access" - open the sharing link in an incognito window - hit the download button => 404 not found A public user cannot convert a spreadsheet to an excel file and downlaod it because a route needs to be called to create the excel file. This route is currently not allowed for public users. For frozen spreadsheet, we generate the excel file before-hand (when the internal user shares the spreadsheet). For a regular "live" share though, we cannot pre-generate the excel file since the spreadsheet continues to live and evolve. The `spreadsheet` module needs to be updated for this bug fix to take effect. (otherwise the download button won't do anything, which is not worse than facing a 404 response) See also community PR. Task: 4440241 opw: 4417519
This update improves the internal automated test setup used for Odoo's frontend features. It helps test data behave more like real system records, reducing false failures and making future updates safer across affected apps.
Original PR description
This commit handles various fixes for the Hoot testing framework & other frontend unit test helpers. Community: https://github.com/odoo/odoo/pull/193937
For Belgium, combination of taxes and their deductibility are many. While our system of Distribution lines can be used in many cases, it's not easy or intuitive to configure, even for advanced accountants. This commit aims at making sure: - The most useful taxes are active by default - We provide a few examples of the most commonly used Deductible taxes as well as examples of specific cases (Deductible IntraCom taxes). task-id 4417039 Forward-Port-Of: odoo/odoo#193860 Forward-Port-Of: o
Original PR description
For Belgium, combination of taxes and their deductibility are many. While our system of Distribution lines can be used in many cases, it's not easy or intuitive to configure, even for advanced accountants. This commit aims at making sure: - The most useful taxes are active by default - We provide a few examples of the most commonly used Deductible taxes as well as examples of specific cases (Deductible IntraCom taxes). task-id 4417039 Forward-Port-Of: odoo/odoo#193860 Forward-Port-Of: odoo/odoo#191350
Issue: * Accrued Expense Entry shows wrong currency symbol for 'Total in Currency' for multicurrency POs. Steps To Reproduce: * In a multicurrency environmentcreate a PO with a currency different than the one of the company and confirm it. * Receive the product and validate it. * On the PO action wheel, create `Accrued Expense Entry`. * Notice 'Total in Currency' is set to the wrong currency. Solution: * In `_compute_move_vals` I set the move's `currency_id` of the accrual move to t
Original PR description
Issue: * Accrued Expense Entry shows wrong currency symbol for 'Total in Currency' for multicurrency POs. Steps To Reproduce: * In a multicurrency environmentcreate a PO with a currency different than the one of the company and confirm it. * Receive the product and validate it. * On the PO action wheel, create `Accrued Expense Entry`. * Notice 'Total in Currency' is set to the wrong currency. Solution: * In `_compute_move_vals` I set the move's `currency_id` of the accrual move to that of the order's currency. * in `create_entries` I prevent the creation of the accrual move if orders have different currencies. * Please note that there were no issues with currency conversions. opw-4072932 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194050 Forward-Port-Of: odoo/odoo#177929
Before this commit: Once receveiving Mercado Pago callback, a JS traceback would occur: ```js TypeError: Cannot read properties of undefined (reading 'payment_method') at Proxy.get_payment ``` opw-4349957 Forward-Port-Of: odoo/odoo#194112
Original PR description
Before this commit: Once receveiving Mercado Pago callback, a JS traceback would occur: ```js TypeError: Cannot read properties of undefined (reading 'payment_method') at Proxy.get_payment ``` opw-4349957 Forward-Port-Of: odoo/odoo#194112
**Current behavior:** The rounding applied during the cost split of a landed cost's cost computation can yield undesirable/unexpected results. **Expected behavior:** Sensible rounding. **Steps to reproduce:** 1. Create some product with arbitrary cost, with avg and real_time costing and valuation, respectively 2. Create a purchase order with 6 lines, all for that product 3. Confirm order & receive products, create bill and add a landed cost line with cost=6.85 4. Post bill a
Original PR description
**Current behavior:** The rounding applied during the cost split of a landed cost's cost computation can yield undesirable/unexpected results. **Expected behavior:** Sensible rounding. **Steps to…
**Current behavior:**
The rounding applied during the cost split of a landed cost's
cost computation can yield undesirable/unexpected results.
**Expected behavior:**
Sensible rounding.
**Steps to reproduce:**
1. Create some product with arbitrary cost, with avg and
real_time costing and valuation, respectively
2. Create a purchase order with 6 lines, all for that product
3. Confirm order & receive products, create bill and add a
landed cost line with cost=6.85
4. Post bill and create the landed cost:
* link to the receipt
* set split method to `equal`
5. Validate the LC, see that the val adjustment lines are
rounded unexpectedly- *specifically all the lines are rounded up
(beyond the per-adjustment-line value) which means the final
adjustment line cost-split share will reflect the cumulative
rounding loss of every adjustment line rounded prior*
E.g.,
<pre>
[ 1.15, 1.15, 1.15, 1.15, 1.15, 1.11 ]
^
</pre>
**Cause of the issue:**
We currently use `rounding_method='UP'`.
**Fix:**
Round HALF-UP. This will minimize the difference between the
true, unrounded split-value and the post-rounding value.
Semi-related fix: try to use consistent `ResCurrency.round()`
methods between `compute_landed_cost()` and `_check_sum()`.
opw-4200916
Forward-Port-Of: odoo/odoo#193861
Forward-Port-Of: odoo/odoo#190449### Before When creating a new vendor bill through Vendors > 'Example Vendor 1'> Vendor Bills (magic button), if the vendor was changed to 'Example Vendor 2' and the draft saved then it would show up under the 'Example Vendor 1' in the Partner Ledger instead of under the correct 'Example Vendor 2'. This is due to the partner_id being defined in the context when going through the 'Example Vendor 1' view. ### Now During the creation of the account move lines we use a context without the
Original PR description
### Before When creating a new vendor bill through Vendors > 'Example Vendor 1'> Vendor Bills (magic button), if the vendor was changed to 'Example Vendor 2' and the draft saved then it would show up under the 'Example Vendor 1' in the Partner Ledger instead of under the correct 'Example Vendor 2'. This is due to the partner_id being defined in the context when going through the 'Example Vendor 1' view. ### Now During the creation of the account move lines we use a context without the default_partner_id. The Partner Ledger now shows the draft bill entry under the right vendor. opw-4407709 Forward-Port-Of: odoo/odoo#193842 Forward-Port-Of: odoo/odoo#192567
Before this commit, markers on the location selector map were misaligned. The misalignment was proportional to the zoom level, as the marker incorrectly used the top-left corner of the anchor as its reference. This commit resolves the issue by defining the correct icon anchor position for markers. Forward-Port-Of: odoo/odoo#193982
Original PR description
Before this commit, markers on the location selector map were misaligned. The misalignment was proportional to the zoom level, as the marker incorrectly used the top-left corner of the anchor as its reference. This commit resolves the issue by defining the correct icon anchor position for markers. Forward-Port-Of: odoo/odoo#193982
Apparently in normal mode (and thus the new headless mode) Chrome does not focus the document. The `activeElement` is correctly set, but `document.hasFocus()` always returns `false` and per-element focus events are suppressed. That makes tests testing or needing focus fail in the new headless mode as well as well as impossible (or at least frustrating) to `debug`. Enabling "focus emulation", which corresponds to the "Emulate a focused page" UI option, seems to resolve the issue. Fixes r
Original PR description
Apparently in normal mode (and thus the new headless mode) Chrome does not focus the document. The `activeElement` is correctly set, but `document.hasFocus()` always returns `false` and per-element focus events are suppressed. That makes tests testing or needing focus fail in the new headless mode as well as well as impossible (or at least frustrating) to `debug`. Enabling "focus emulation", which corresponds to the "Emulate a focused page" UI option, seems to resolve the issue. Fixes reliably failing tests - `/im_livechat:ExternalTestSuite.test_external_livechat` - `/account:TestUI.test_01_account_tax_groups_tour` - `/account_accountant:TestBankRecWidget.test_tour_bank_rec_widget` - `/web_editor:TestOdooEditor.test_odoo_editor_suite` Backport of: odoo/odoo@0aaf98b77feaa15f5eb30e1c251f5765e8afbfa5 Forward-Port-Of: odoo/odoo#193993
When we go to the website preview in the Odoo backend, if the current domain used (to access the backend) is not the same as the one of the previewed website, we redirect the user, and he might have to reconnect. The same is done when using the website switcher. Note: in the first case, the user is warned. We should probably do the same for the second case (?). This is a problem for the Odoo support team. When they connect to a customer database upon user request, the <customer_db_name>.odoo
Original PR description
When we go to the website preview in the Odoo backend, if the current domain used (to access the backend) is not the same as the one of the previewed website, we redirect the user, and he might have…
When we go to the website preview in the Odoo backend, if the current domain used (to access the backend) is not the same as the one of the previewed website, we redirect the user, and he might have to reconnect. The same is done when using the website switcher. Note: in the first case, the user is warned. We should probably do the same for the second case (?). This is a problem for the Odoo support team. When they connect to a customer database upon user request, the <customer_db_name>.odoo.com address is used. But as soon as they are using the website app, they are redirected to the real website domains... where they are disconnected and cannot connect themselves. To fix this issue, we allow setting up a session info parameter to bypass those website redirections. This is not to be done by real users: this will come with bugs (for the support team). Indeed, we are normally redirecting for a reason: many flows rely on using the right domain when visiting a specific website. Depending on what users have in their page, this could also simply make the website preview iframe crash. task-4069779 Forward-Port-Of: odoo/odoo#193648 Forward-Port-Of: odoo/odoo#193122
We now also delete `lib/` directory before deleting/downloading new IoT handlers. In community, this directory does not exist, resulting in Path error while trying to `iterdir()` on it. We now look for files recursively inside `iot_handlers/`, and provide the list to the updated method `unlink_file` that now accepts multiple arguments to avoid excessively switching between rw/ro filesystem modes. Forward-Port-Of: odoo/odoo#193990
Original PR description
We now also delete `lib/` directory before deleting/downloading new IoT handlers. In community, this directory does not exist, resulting in Path error while trying to `iterdir()` on it. We now look for files recursively inside `iot_handlers/`, and provide the list to the updated method `unlink_file` that now accepts multiple arguments to avoid excessively switching between rw/ro filesystem modes. Forward-Port-Of: odoo/odoo#193990
The example of values in the description are translated in other languages. It should not because only the technical values are accepted (which are never translated) It's not needed to backport to 16.0 because function description were not translated at that time. Task: 4471424 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/
Original PR description
The example of values in the description are translated in other languages. It should not because only the technical values are accepted (which are never translated) It's not needed to backport to 16.0 because function description were not translated at that time. Task: 4471424 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193350 Forward-Port-Of: odoo/odoo#193205
Versions -------- - saas-17.4+ Steps ----- 1. Create a new quotation template; 2. add a header which uses the `date_order` field; 3. configure the mapping from this form field to the record field; 4. print the quotation template. Issue ----- The datetime is formatted as "Jan 16, 2025, 5:59:26 PM", which is different from how dates are formatted, or how datetimes are usually formatted elsewhere in Odoo. Additionally, it may also be too long to fit in the form field. Cause --
Original PR description
Versions -------- - saas-17.4+ Steps ----- 1. Create a new quotation template; 2. add a header which uses the `date_order` field; 3. configure the mapping from this form field to the record field; 4.…
Versions -------- - saas-17.4+ Steps ----- 1. Create a new quotation template; 2. add a header which uses the `date_order` field; 3. configure the mapping from this form field to the record field; 4. print the quotation template. Issue ----- The datetime is formatted as "Jan 16, 2025, 5:59:26 PM", which is different from how dates are formatted, or how datetimes are usually formatted elsewhere in Odoo. Additionally, it may also be too long to fit in the form field. Cause ----- The `format_datetime` function is used without a `dt_format` specified, falling back on the default `'medium'`: https://github.com/odoo/odoo/blob/cbd5531697954ec62d79e0eec2c00bd61cd8b0e4/odoo/tools/misc.py#L1399 Solution -------- In order to get the format defined for the relevant locale in Odoo, `dt_format=False` should be specified in the `format_datetime` call: https://github.com/odoo/odoo/blob/cbd5531697954ec62d79e0eec2c00bd61cd8b0e4/odoo/tools/misc.py#L1427-L1430 opw-4414688 Forward-Port-Of: odoo/odoo#194016
Issue: when the website has a domain `get_base_url` return the domain if the record calling it has a company set on it - call the function with an empty object to get the database url instead Task: 3903743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193182
Original PR description
Issue: when the website has a domain `get_base_url` return the domain if the record calling it has a company set on it - call the function with an empty object to get the database url instead Task: 3903743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193182
In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice). This commit aims to give a single and unified way to display them. ticket-4440711 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193305 Forward-Port-Of: odoo/odoo#192463
Original PR description
In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice). This commit aims to give a single and unified way to display them. ticket-4440711 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193305 Forward-Port-Of: odoo/odoo#192463
When receiving an ubl file by mail, we need to ensure that the company from where we retrieve the product is the same as the invoice company, otherwise we end up with an UserError ("Incompatible companies on records"). Steps: - Have 2 company (X being id == 1 and Y being id == 2) - Create a product "Locations et leasing opérationnel" with X setas company_id - Create an alias on company Y vendor bills journals - Sent the `bis3_bill_example.xml` located in `addons/account_edi_ubl_cii/tests/tes
Original PR description
When receiving an ubl file by mail, we need to ensure
that the company from where we retrieve the product is the same as
the invoice company, otherwise we end up with an UserError ("Incompatible companies on records").
Steps:
- Have 2 company (X being id == 1 and Y being id == 2)
- Create a product "Locations et leasing opérationnel" with X setas
company_id
- Create an alias on company Y vendor bills journals
- Sent the `bis3_bill_example.xml` located in `addons/account_edi_ubl_cii/tests/test_files/`
to the email alias
- Open the created bill
-> Error in the chatter: "Error importing attachment ... as invoice
(decoder=_import_invoice_ubl_cii)
opw-4444747
Forward-Port-Of: odoo/odoo#193984
Forward-Port-Of: odoo/odoo#193786Before this commit: Nothing would happen after a mercado pago webhook notification received. Since 17.4, `payment_method` attribute have been changed to `payment_method_id`. Thus it was returning `undefined` and silently fail to update the line After this commit: Call `handleMercadoPagoWebhook` on notification received as intended opw-4349957 Forward-Port-Of: odoo/odoo#193784
Original PR description
Before this commit: Nothing would happen after a mercado pago webhook notification received. Since 17.4, `payment_method` attribute have been changed to `payment_method_id`. Thus it was returning `undefined` and silently fail to update the line After this commit: Call `handleMercadoPagoWebhook` on notification received as intended opw-4349957 Forward-Port-Of: odoo/odoo#193784
…wnload Current behavior before PR: When using the "Download logs" button, from the IoT box form view, an Internal Server Error is raised every time. ```py Internal Server Error : Log file configuration is not set ``` Description of the issue/feature this PR addresses: New IoT Box images are missing the default `logfile` parameter in their config. This parameter is required for log downloading, and cannot be left empty. The `logfile` parameter has been removed from the `odoo.conf`
Original PR description
…wnload Current behavior before PR: When using the "Download logs" button, from the IoT box form view, an Internal Server Error is raised every time. ```py Internal Server Error : Log file…
…wnload Current behavior before PR: When using the "Download logs" button, from the IoT box form view, an Internal Server Error is raised every time. ```py Internal Server Error : Log file configuration is not set ``` Description of the issue/feature this PR addresses: New IoT Box images are missing the default `logfile` parameter in their config. This parameter is required for log downloading, and cannot be left empty. The `logfile` parameter has been removed from the `odoo.conf` config file in PR #169633. However, it is still explicitly mentioned as `/var/log/odoo/odoo-server.log` in two other files: https://github.com/odoo/odoo/blob/451a956a22015034b8c35bd0d9a860b78442af7f/addons/hw_posbox_homepage/controllers/homepage.py#L74 and https://github.com/odoo/odoo/blob/451a956a22015034b8c35bd0d9a860b78442af7f/addons/point_of_sale/tools/posbox/overwrite_before_init/etc/init_posbox_image.sh#L28 As such, a fallback to the default `/var/log/odoo/odoo-server.log` is added. Desired behavior after PR is merged: The Logs can be downloaded from the IoT box form view without receiving an Internal Server Error. opw-4443593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192922 Forward-Port-Of: odoo/odoo#192867
In odoo/odoo#192449, we removed the only code patch we had on the IoT Box. We can then remove the patching logic. Forward-Port-Of: odoo/odoo#193935
Original PR description
In odoo/odoo#192449, we removed the only code patch we had on the IoT Box. We can then remove the patching logic. Forward-Port-Of: odoo/odoo#193935
**Current behavior:** Having some product with a subcontract BoM and using the unarchived 'Subcontract' picking type and creating a purchase order to the subcontractor for that product: changing the `scheduled_date` of the generated receipt will improperly set the start/end date on the subcontracting MO which was generated alongside the receipt. Specifically, the `scheduled_date` of the receipt should correspond to the `date_finished` of the MO- however currently it is incorrectly modifying
Original PR description
**Current behavior:** Having some product with a subcontract BoM and using the unarchived 'Subcontract' picking type and creating a purchase order to the subcontractor for that product: changing the…
**Current behavior:** Having some product with a subcontract BoM and using the unarchived 'Subcontract' picking type and creating a purchase order to the subcontractor for that product: changing the `scheduled_date` of the generated receipt will improperly set the start/end date on the subcontracting MO which was generated alongside the receipt. Specifically, the `scheduled_date` of the receipt should correspond to the `date_finished` of the MO- however currently it is incorrectly modifying the MO `date_start` instead. **Expected behavior:** Modifying `scheduled_date` on the receipt will in turn modify the `date_finished` of the MO. **Steps to reproduce:** *Unarchive the Subcontract picking type operation* 1. Create a final product with a subcontract type BoM, on the BoM set some positive value for Manuf. Lead Time (in miscellaneous tab) 2. Create a purchase order to the subcontractor for that product 3. Confirm the PO -> observe that on creation, the scheduled date of the receipt matches the end date of the MO 4. Change the scheduled date of the receipt (for example, 10 days in the future) -> observe that after saving, the MO date correspondence is inverted (end date = scheduled date + lead time) instead of the start date being set with respect to the end time (like on creation), the end date gets set with respect to the start date **Cause of the issue:** It's an inconsistency with how the fields (start, end) are calculated and when. **Fix:** Make this case behave the same as the creation does- that is, end date is informed by the receipt's scheduled date and the start date of the MO is set by subtracting the lead time from there. opw-4231548 Forward-Port-Of: odoo/odoo#188389
Steps to reproduce: 1. In elearning get a current course or create a new one. 2. Add or just reorder some of the slides/sections. 3. Duplicate the course. After the changes applied to improve the batch call of copy in https://github.com/odoo/odoo/commit/4ac2702c31f0e95f33f9ad554e7350bef9dab8bd the values that we get after the copy are ordered by id instead of preserving the original order, so for this case we can make sure to reorder the values and mantain the proper sequence when duplic
Original PR description
Steps to reproduce: 1. In elearning get a current course or create a new one. 2. Add or just reorder some of the slides/sections. 3. Duplicate the course. After the changes applied to improve the batch call of copy in https://github.com/odoo/odoo/commit/4ac2702c31f0e95f33f9ad554e7350bef9dab8bd the values that we get after the copy are ordered by id instead of preserving the original order, so for this case we can make sure to reorder the values and mantain the proper sequence when duplicating inside copy_data(). opw-4240873 Forward-Port-Of: odoo/odoo#188333
Steps to reproduce: - Start a Viva wallet payment - Immediately cancel and remove the payment line - After a few seconds, a traceback occurs This commit fixes the issue by ensuring that the Viva Wallet status polling only runs if it is still the current payment line. task-4472269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193571 Forward-Port-Of: odoo/odoo#193358
Original PR description
Steps to reproduce: - Start a Viva wallet payment - Immediately cancel and remove the payment line - After a few seconds, a traceback occurs This commit fixes the issue by ensuring that the Viva Wallet status polling only runs if it is still the current payment line. task-4472269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193571 Forward-Port-Of: odoo/odoo#193358
## Issue: - Child contacts of followers were unable to access the tasks menu in the portal home, despite having access according to the access rules. ## Steps to reproduce: 1. Create a parent contact with a child contact. 2. Grant the child contact portal access. 3. Create a task with the parent contact as the customer. 4. Add the parent contact as a follower or send a message in the task chatter. 5. Log in as the child contact in the portal. 6. Notice the tasks menu is unavailable.
Original PR description
## Issue: - Child contacts of followers were unable to access the tasks menu in the portal home, despite having access according to the access rules. ## Steps to reproduce: 1. Create a parent contact with a child contact. 2. Grant the child contact portal access. 3. Create a task with the parent contact as the customer. 4. Add the parent contact as a follower or send a message in the task chatter. 5. Log in as the child contact in the portal. 6. Notice the tasks menu is unavailable. ## Solution: - The issue originated in `_prepare_home_portal_values`, where the task count was computed with a restrictive domain and sudo instead of relying on the access rules. - Removed the unnecessary domain filter to let the access rules handle it. opw-4306834 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191601
Before this commit, selecting an order from the order list and attempting to load it would result in an error. opw-4251717 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184754
Original PR description
Before this commit, selecting an order from the order list and attempting to load it would result in an error. opw-4251717 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184754
* = stock * PROPBLEM: when viewing purchase or vendor dashboard (under logistic section) , viewing the scoreboard for purchased or order it calculate all record from purchase.report but when clicking on it, redirect to view of 'purchase order' only which is wrong compare to the number display on the scoreboard * SOLUTION: This commit fix by edit the domain of related pivot which the scoreboard use to display data to the domain having state in either Purchase or Done Description of the iss
Original PR description
* = stock * PROPBLEM: when viewing purchase or vendor dashboard (under logistic section) , viewing the scoreboard for purchased or order it calculate all record from purchase.report but when clicking on it, redirect to view of 'purchase order' only which is wrong compare to the number display on the scoreboard * SOLUTION: This commit fix by edit the domain of related pivot which the scoreboard use to display data to the domain having state in either Purchase or Done Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193640 Forward-Port-Of: odoo/odoo#191985
Under Japan’s Qualified Invoice System, which took effect in October 2023, the consumption tax amount should be calculated and rounded based on the total invoice amount for each tax rate, rather than on an item-by-item basis. See https://www.pwc.com/jp/en/taxnews/pdf/jtu-20221111-en.pdf @qrtl --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193522
Original PR description
Under Japan’s Qualified Invoice System, which took effect in October 2023, the consumption tax amount should be calculated and rounded based on the total invoice amount for each tax rate, rather than on an item-by-item basis. See https://www.pwc.com/jp/en/taxnews/pdf/jtu-20221111-en.pdf @qrtl --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193522
Steps to reproduce ================== - Install account_accountant,contacts,web_studio - Go to contacts - Open any record - Open studio - Switch to the Accounting notebook - Edit the subview form - Add a smart button => It crashes Cause of the issue ================== The button_box operation is not made to work inside a subview. We should not be able to add buttons inside subviews as they are not displayed outside studio anyways. opw-4379868 Forward-Port-Of: odoo/enterprise
Original PR description
Steps to reproduce ================== - Install account_accountant,contacts,web_studio - Go to contacts - Open any record - Open studio - Switch to the Accounting notebook - Edit the subview form - Add a smart button => It crashes Cause of the issue ================== The button_box operation is not made to work inside a subview. We should not be able to add buttons inside subviews as they are not displayed outside studio anyways. opw-4379868 Forward-Port-Of: odoo/enterprise#77085 Forward-Port-Of: odoo/enterprise#76297
This commit's purpose is to clean up the graph view of the sla report analysis model. Some fields were added on the view by a generic improvement task to handle the widget 'float_time' with grap view. In this case, those fields are a nuisance for readability, so we're getting rid of them. target version 17.0 - master task - 4351830 Forward-Port-Of: odoo/enterprise#76237
Original PR description
This commit's purpose is to clean up the graph view of the sla report analysis model. Some fields were added on the view by a generic improvement task to handle the widget 'float_time' with grap view. In this case, those fields are a nuisance for readability, so we're getting rid of them. target version 17.0 - master task - 4351830 Forward-Port-Of: odoo/enterprise#76237
*: frontdesk, hr_contract_salary, hr_referral Issue: when the website has a domain `get_base_url` return the domain if the record calling it has a company set on it - call the function with an empty object to get the database url instead Task: 3903743 Forward-Port-Of: odoo/enterprise#76888
Original PR description
*: frontdesk, hr_contract_salary, hr_referral Issue: when the website has a domain `get_base_url` return the domain if the record calling it has a company set on it - call the function with an empty object to get the database url instead Task: 3903743 Forward-Port-Of: odoo/enterprise#76888
Steps: • Install the Employee referral App. • Open the app for the first time. You will see buttons labeled Skip, and Start Now. When you click on any of these buttons, there is a noticeable blank screen for a moment during the transition. • Tap on the User Icon within the app interface. A blank screen appears momentarily before the next screen is displayed. • When you select an icon for a friend, the same issue occurs: a blank screen is displayed for a moment during the transiti
Original PR description
Steps: • Install the Employee referral App. • Open the app for the first time. You will see buttons labeled Skip, and Start Now. When you click on any of these buttons, there is a noticeable blank screen for a moment during the transition. • Tap on the User Icon within the app interface. A blank screen appears momentarily before the next screen is displayed. • When you select an icon for a friend, the same issue occurs: a blank screen is displayed for a moment during the transition. Cause: • The issue occurred because, for all the above actions, the target was set to 'main,' which caused a blank component to appear for a moment during transitions. Fix: • If we do not want to show the blank component then either the clearBreadcrumbs set to false or noEmptyTransition should be true.(refer the action_service.js) • Here i have set noEmptyTransition to true. task-4320099 Forward-Port-Of: odoo/enterprise#74955
In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice). This commit aims to give a single and unified way to display them. ticket-4440711 Forward-Port-Of: odoo/enterprise#76977 Forward-Port-Of: odoo/enterprise#76522
Original PR description
In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice). This commit aims to give a single and unified way to display them. ticket-4440711 Forward-Port-Of: odoo/enterprise#76977 Forward-Port-Of: odoo/enterprise#76522
When validating the payment CFDI in multicurrency scenario (invoice in USD, payment in MXN), we should provide the official convertion rate in the equivalenciaDR xml attribute. However, this is not always possible due to rounding: PACs with lower error tolerance (Quadrum) will not validate the payment Steps to reproduce: - With an MX company setup - Set the following rates for USD - Date 1: 0.049905678268 - Date 2: 0.049073733284 - Create an invoice in date1 of 6368.40 USD (5490.00 w
Original PR description
When validating the payment CFDI in multicurrency scenario (invoice in USD, payment in MXN), we should provide the official convertion rate in the equivalenciaDR xml attribute. However, this is not…
When validating the payment CFDI in multicurrency scenario (invoice in USD, payment in MXN), we should provide the official convertion rate in the equivalenciaDR xml attribute. However, this is not always possible due to rounding: PACs with lower error tolerance (Quadrum) will not validate the payment Steps to reproduce: - With an MX company setup - Set the following rates for USD - Date 1: 0.049905678268 - Date 2: 0.049073733284 - Create an invoice in date1 of 6368.40 USD (5490.00 with 16% tax) - Register a full payment in date 2 in company currency (129772.07 MXN) Issue: Payment CFDI will not validate when using Quadrum PAC with error ``` Code : CRP20268 Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de los importes de las bases registrados en los documentos relacionados donde el impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de este elemento. ``` This occurs because when computing cfdi values we take the invoice (rounded) amounts and recompute the amount in mxn using the official currency rate. While doing so, due to rounding, we accumulate imprecision, the final computation might be off by a cent or two and PACs with a lower error tolerance (Quadrum) will not be able to validate the cfdi. A solution is to internally use the computed rate, while we provide the official currency rate in the xml opw-4357985 Forward-Port-Of: odoo/enterprise#76333
2 Bugs: When using grouped mode in the intrastat report, the load more would load the same result everytime because no offset or limit were provided. Another bug is that when you used the non grouped mode, the would be no load more at all. opw-4342518 Forward-Port-Of: odoo/enterprise#77090 Forward-Port-Of: odoo/enterprise#76543
Original PR description
2 Bugs: When using grouped mode in the intrastat report, the load more would load the same result everytime because no offset or limit were provided. Another bug is that when you used the non grouped mode, the would be no load more at all. opw-4342518 Forward-Port-Of: odoo/enterprise#77090 Forward-Port-Of: odoo/enterprise#76543
The commit fixes the commit[[1]] that optimizes the cron activation logic. Before this fix, only admin users could run the manual fetch, it was wrong and we need to authorize all the users that have access to the bank sync to active/deactivate this cron by using the manual fetch. opw-4477366 [1]: https://github.com/odoo/enterprise/commit/bc3b9136d4d62fbc1d09267f73cac7ca29f1ba3a Forward-Port-Of: odoo/enterprise#77148
Original PR description
The commit fixes the commit[[1]] that optimizes the cron activation logic. Before this fix, only admin users could run the manual fetch, it was wrong and we need to authorize all the users that have access to the bank sync to active/deactivate this cron by using the manual fetch. opw-4477366 [1]: https://github.com/odoo/enterprise/commit/bc3b9136d4d62fbc1d09267f73cac7ca29f1ba3a Forward-Port-Of: odoo/enterprise#77148
Versions: ------------- 16.0 Steps to Reproduce: ---------------------------- 1. Open the Sign app. 2. Switch to the kanban view of sign templates. 3. Upload a document without adding any sign items. 4. Switch to the list view and open the template. 5. In the form view, go to the "Fields" notebook tab. 6. Add 2-3 sign items, then go back to the kanban view. 7. Reopen the template. Issue: --------- An error occurs when trying to sign the template. Cause: ---------- When a
Original PR description
Versions: ------------- 16.0 Steps to Reproduce: ---------------------------- 1. Open the Sign app. 2. Switch to the kanban view of sign templates. 3. Upload a document without adding any sign items. 4. Switch to the list view and open the template. 5. In the form view, go to the "Fields" notebook tab. 6. Add 2-3 sign items, then go back to the kanban view. 7. Reopen the template. Issue: --------- An error occurs when trying to sign the template. Cause: ---------- When adding sign items in the form view, other required fields are left empty. These missing values are needed to properly render the items in the PDF iframe. Solution: ------------ Make the sign items in the "Fields" notebook read-only. task-4212762 Forward-Port-Of: odoo/enterprise#71017