Daily updates from Odoo
Friday, January 31, 2025
50 changes · 18.0
New functionality added to Odoo
Brazilian NF-e invoices can now include package and transport information from related stock operations. This helps teams prepare EDI invoices before delivery by recording packaging during an earlier picking step and linking those packages directly to the invoice.
Original PR description
NF-e invoices can optionally include sent packages. This integrates with the stock module to provide a way for users to specify packages on invoices. Typically EDI is done before products are sent…
NF-e invoices can optionally include sent packages. This integrates with the stock module to provide a way for users to specify packages on invoices.
Typically EDI is done before products are sent out ("ordered quantity" invoicing policy). To handle this the user can enable 2-step picking. In the first step they can record how they will package the products. After that, the packages can be included on the invoice for EDI. At a later time products can be delivered to the customer in the last step. We provide a picking smart button in the invoice form view to easily navigate to the related pickings to sort out the packaging. This is typically done by a dedicated person who handles everything related to EDI.
Note that for products to be included in packages they must be storable (is_storable). The stock module allows to package
non-storable products as well, but in those cases the resulting stock.quant.package's are empty (no quant_ids).
task-4298921
## TODO
- [ ] translationsEnhancements to existing features
This change adds a development-only way to load Point of Sale tour tests so teams can run synchronization scenarios across multiple browser sessions. It helps validate order, payment, and restaurant workflow synchronization more reliably without affecting normal users, since the test tools load only when explicitly enabled in the POS URL.
Original PR description
Before we had no solution to test the synchronisation of the pos. In classic tours websocket are not supported. And we cannot launch two tours in parallel. This commit add the possibility to load test assets in the PoS during our development. That's allow us to launch tour in loop in two different browser and test the synchronisation by creating orders, payment etc. Tour assets are only added by adding `&tours=True` in the URL of the PoS interface.
This change updates the Dutch SBR tax report wizard, which is used to prepare statutory tax submissions in the Netherlands. The available information is limited because the pull request is still marked as work in progress, but the impact appears focused on improving or correcting that reporting flow.
Original PR description
[WIP]
Resolved issues and error corrections
Event proposal forms now exclude tags that are meant to stay hidden on the public website. This keeps the tag list cleaner and helps visitors choose only relevant, intended options.
Original PR description
Colorless tags are always hidden in the frontend interface, this allows to manage them in backend without showing them. Since there's no filter on the `websiteEventTrackProposalFormTags` widget, those tags were still selectable from the website, resulting in the following issues: - Adding useless noise in the selection. - Letting users select tags that are not intended to be selected. - Users could also wrongly select a tag instead of the intended one.
This update makes several automated user journeys more dependable by adding checks that keep each test on the intended path. It reduces inconsistent test results across website, events, CRM, and point of sale areas, helping teams validate changes with more confidence.
Original PR description
In this commit, we fix multiple tours on step that can cause non deterministic behaviors by adding additionnal steps to ensure tour is well on the way to taking the right path. 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
Point of Sale now keeps its order tracking sequence from resetting when the browser is refreshed during the same device session. This reduces the risk of duplicate tracking numbers and helps staff avoid confusion when managing new orders.
Original PR description
Before this commit, refreshing the browser and creating a new order could yield a duplicate tracking number, causing confusion. This commit addresses the issue by preventing the sequence from resetting within the same session on a single device. opw-4501048 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Settling an unconfirmed sales quotation through Point of Sale now correctly updates the delivered quantity on the quotation. This keeps sales records accurate even when the quotation was not confirmed before payment in the POS.
Original PR description
When settling a quotation (unconfirmed sale order) from the POS, the delivered quantity was not updated in the quotation. Steps to reproduce: ------------------- * Make a sale order but don't confirm it * Go to the POS and settle the quotation > Observation: The delivered quantity is not updated in the quotation Why the fix: ------------ If the quotation was not confirmed no move lines were created, so the `has_valued_moves` was False and no move lines were created for the PoS order. And because the pos order has no move lines the quotation was not updated with the delivered quantity. opw-4479862
This fixes an internal test validation issue so JavaScript test failures are detected more reliably. It reduces false failures caused by wording changes in error messages, helping keep development and release checks stable.
Original PR description
Before this commit, the error_checker asserting that a JS unit test run failed performed a strict equality with an outdated string on error logs. Now, the message has been changed, flagged explicitly as something that shouldn't be changed and the presence of that message is checked accross the entire message for robustness. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Point of Sale sessions from crashing when orders are created and receipts are printed while offline, then synchronized after reconnecting. It also shows a clear connection-lost message for kitchen order sending while offline, helping staff understand what went wrong instead of encountering a traceback.
Original PR description
Steps to Reproduce: =================== - Open a POS session and go offline. - Create orders and print receipts at the receipt screen. - Restore the internet connection and bring the POS online. - A…
Steps to Reproduce: =================== - Open a POS session and go offline. - Create orders and print receipts at the receipt screen. - Restore the internet connection and bring the POS online. - A traceback occurs during synchronization. Before this commit: ===================== A traceback occurred when making a POS order, printing a receipt in offline mode, and later going online. The issue arose because the nb_print field was updated via a backend write call to restrict payment method edits. However, during offline mode, the order_id was a string, causing the traceback. After this commit: =================== - The backend write call for nb_print is bypassed in offline mode. Instead, the `nb_print` count is updated on the frontend. When the order syncs after going online, the increased `nb_print` value prevents payment method edits as expected. - Removed the nb_print validation constrains from payment lines. Validation is already handled in the write method of pos.order. This change avoids validation errors when syncing orders from offline to online, where nb_print = 1 and payment lines exist. The write method ensures proper handling during order creation. - A `Connection Lost` error message is displayed when attempting to send orders to the kitchen while in offline mode. Task-4504625
The spreadsheet tool was updated to a newer version with fixes that make formulas faster and improve everyday editing behavior. It also corrects number parsing for certain locales and improves pivot table calculations, reducing errors for users working with spreadsheets in Odoo.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f505971d4 [REL] 18.0.13 Task: 0 https://github.com/odoo/o-spreadsheet/commit/9d5251d0d [PERF] formulas: add a cache on…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f505971d4 [REL] 18.0.13 Task: 0 https://github.com/odoo/o-spreadsheet/commit/9d5251d0d [PERF] formulas: add a cache on linear search functions Task: 4080146 https://github.com/odoo/o-spreadsheet/commit/4ef9f2da1 [FIX] auto-complete: hide auto-complete when selecting a cell Task: 4022927 https://github.com/odoo/o-spreadsheet/commit/d131f1585 [FIX] locale: wrong parsing with "." thousand separator Task: 4525746 https://github.com/odoo/o-spreadsheet/commit/7793d0931 [FIX] ui_sheet: batch resize commands in `AUTORESIZE_ROWS` Task: 4504918 https://github.com/odoo/o-spreadsheet/commit/07ee8ab47 [FIX] pivot: use displayed value in computed measure Task: 4517312 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fix lets the recruitment app create separate candidate records for the same email address when applications are for jobs at different companies. It prevents erroneous duplicate-candidate errors and supports multi-company hiring workflows.
Original PR description
In version 18.0, due to this PR: https://github.com/odoo/odoo/pull/190334/commits/b28dbc7faeac1095fe01d75e1783d7395, applying to jobs in different companies using the same email will not create separate candidates. This behavior raises the following error: https://github.com/odoo/odoo/blob/75571a661c5fa1dd80299bb110d9297219b7f465/addons/hr_recruitment/models/hr_applicant.py#L351. This PR aims to fix the issue by ensuring that candidates are unique per company. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes two unrelated steps from an automated web test that had been copied in by mistake. It helps keep the test suite clearer and easier to maintain, with no expected change for end users.
Original PR description
Commit https://github.com/odoo/odoo/commit/98218629f88b619ca9c8013ecbffaa221d82531c introduced a test with two non-related steps (these steps were certainly copy-pasted from another test, in spreadsheet). This commit removes these steps. 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
This fix prevents businesses from enabling lot-based valuation on products that still have valued stock without a lot number. It avoids unusable stock records and accounting discrepancies, and also clarifies an error message related to negative lot quantities.
Original PR description
When Lot valuation is enabled on a product, it is not longer possible to create a move without lot. Hence, if you had a valued quantity without lot before enabling lot valuation, it was impossible to…
When Lot valuation is enabled on a product, it is not longer possible to create a move without lot. Hence, if you had a valued quantity without lot before enabling lot valuation, it was impossible to update or empty this quantity in any way. Leaving you with an unusable StockQuant. Furthermore, when enabling the lot valuation, no layer was created for the quants without lot, creating a permanent discrepancy between the stock and valuation. This discrepancy was still present even after disabling the lot valuation. To fix this issue, we do not allow the lot valuation if there is a quant without lot in a valued location.  + Fix negative lot error message PREV:  NOW:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restaurant point-of-sale users can now create a new floor plan by clicking anywhere on the create button, not just the plus icon. This removes a small usability frustration and makes setup more intuitive.
Original PR description
Before this commit: ========== - To create a new floor plan, the user must click the plus icon on the floor plan's create button; clicking anywhere else on the floor plan's create button was not working. After this commit: ========== - Users can click anywhere on the floor plan's create button to create a floor plan. task-4517219
Point of Sale reports now avoid showing duplicate order lines when a sold product belongs to multiple POS categories. This keeps sales reporting clearer and prevents inflated or confusing report details for affected products.
Original PR description
If you sell a product that has multiple pos categories, the report would contain as many lines as the number of categories. Steps to reproduce: ------------------- * Create product A with atleast 2 pos categories * Make a sale in PoS with this product * Go to PoS order report and click on the graph * This will open a view containing all the lines of the report > Observation: You have multiple lines for the same order Why the fix: ------------ To avoid this issue, we select only the first category of the product. opw-4451101
This fix prevents Odoo spreadsheets from unnecessarily reloading pivot data when a global filter is changed. Users get a smoother spreadsheet experience with fewer interruptions while working with filtered business data.
Original PR description
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
Email unsubscribe links now require an extra confirmation step, preventing automated security scans by email clients from unsubscribing recipients by mistake. The unsubscribe confirmation experience is also clearer, so users can easily see when they have been unsubscribed and still manage their subscription settings if needed.
Original PR description
## Do not merge; commit will be cherry-picked into fw-port PRs 16.0 PR: https://github.com/odoo/odoo/pull/189561 Email clients have begun implementing security measures to protect users from phishing…
## Do not merge; commit will be cherry-picked into fw-port PRs 16.0 PR: https://github.com/odoo/odoo/pull/189561 Email clients have begun implementing security measures to protect users from phishing by analyzing email links, and interacting with them (see task-3972953). This has the side effect of automatically unsubscribing email recipients from mailing lists by clicking the link in the footer of the emails. This commit adds an intermediate step to the process, by requiring users to click on a button before they are unsubscribed. task-4364446 -- The current unsubscription destination page for emails makes it unclear for the user whether they've been unsubscribed or not. This is because the "unsubscription confirmed" box is placed below the "manage subscription settings" box on the confirmation page. To avoid confusion, while ensuring current Studio customizations to stable instances are not impacted, a new intercalate page is added to clarify that the user is unsubscribed, and offer the option to manage unsubscriptions by reaching the previous page. task-4364446
The Point of Sale sample setup no longer triggers an error when users reopen the Clothes section after deleting the Clothes Shop. This prevents confusing log errors and keeps the POS setup flow working smoothly.
Original PR description
Currently a `Parseerror` appears when the user clicks 'Clothes' in POS. ### Error: ``` ParseError while parsing /home/odoo/src/odoo/18.0/addons/point_of_sale/data/scenarios/clothes_data.xml:337 A combo choice can't contain duplicate products. View error context: '-no context-' ``` ### Steps to reproduce above error :- - Install 'Point of Sale' (without demo data). - Open POS and click 'Clothes', then delete 'Clothes Shop'. - Click again 'Clothes'. - The error appears in the log. This commit resolves the issue by using `Command.clear()`, to clear the link before creating the combo products. sentry-6191520798
This update corrects inconsistent Profit and Loss report data that could cause the report to fail when loading lines. Users can now open the report more reliably without encountering an unexpected error.
Original PR description
The aim of this commit is to avoid having inconsistent data leading to a Traceback while loading the lines of the Profit and Loss report. Context: cbe74884b937f630cf1d2ccf475a04e70b6f4669 changed the structure hierachy. It wasn't a big issue until e96e8d4aa663a4a5305214f2124243070fa797bb resequenced the lines and changed the order of computation in `<account.report>._get_line`. This method assumes the parent lines are going to be computed first and then cached in a dict. Leaving `parent_id` made this assumption wrong leading to a KeyError exception throwing a traceback. Before the commit: The data kept the previous `parent_id` which could lead to a traceback due to inconsistent data. After the commit: `parent_id` not being set, the code doesn't try to get it from the cached lines and computes it correctly. task-id: None
The dashboard no longer shows the bank selection prompt when a journal is already linked to a bank account. This avoids confusing users with an unnecessary setup option and keeps the banking dashboard clearer.
Original PR description
The aim of this commit is making sure that we don't display the bank selection in the dashboard if the journal is already connected to a bank account. no task id
This fix addresses two recurring nightly test failures in the Kenya OSCU localization and its Point of Sale integration. It removes an unnecessary dependency trigger and adjusts access handling so validation information can be read reliably by the right users.
Original PR description
This commit fix 2 tests who nightly fails on runbot: Test 1, `test_01_orders_no_invoiced` (https://runbot.odoo.com/odoo/runbot.build.error/111519): This test failed because of a `flush_all()`, who raised an error because of an `api.depends_context` on a computed field in `product_template` Solution: remove the `api.depends_context` as he's useless (the compute still trigger as it should) Test 2, `test_read_purchase_order` (https://runbot.odoo.com/odoo/runbot.build.error/111518): This test failed because of access right error Solution: add a compute_sudo on `l10n_ke_validation_message` field and add a `groups="point_of_sale.group_pos_user"` on account_move view. no-task
Subscription totals are now calculated more accurately when orders include multiple lines with tax-included prices. This prevents small rounding discrepancies, especially in certain foreign currencies, so recurring and non-recurring amounts shown to users match the expected billed values.
Original PR description
Subscriptions with multiple lines and tax-included prices introduced a rounding error in some cases. This commit fixes the _compute_recurring_total method by using the same rounding method as _compute_amounts in the sale/ module, based on AccountTax helper methods. opw-[4460812](https://www.odoo.com/odoo/all-tasks/4460812)
The Documents app now correctly highlights the Info & Tags button when users open it from the cog wheel menu. This makes the interface clearer and keeps the button state consistent across the document view.
Original PR description
Steps to reproduce: 1. Click the 'Info & Tags' button from the cog wheel dropdown menu next to the breadcrumb. 2. The info button on the right side (near the view switch button) is not getting the 'active' class as it should be. Technical Reason: `this.documentsState.isChatterVisible` in `documents_control_panel` couldn't be updated through the cog menu component directly. This commit adds a reactive object which can be modified and observed by several components. After this Commit: The Button will get the 'active' class accordingly to the state. This commit also removes duplicate code by using an existing mixin. Task-4427575
Miscellaneous changes
Before this commit, the resource_ref field of a server action can disappear when the action is saved. This is due to the following: - the update_related_model_id is a computed stored READONLY field which leads to it not being included in the web_save rpc and is therefore not saved on the record The fix consists to ensure the update_related_model_id is saved by making it readonly=False, which is usually what we want when we have a computed stored field. Task: opw-4513803 Forward-Port-O
Original PR description
Before this commit, the resource_ref field of a server action can disappear when the action is saved. This is due to the following: - the update_related_model_id is a computed stored READONLY field which leads to it not being included in the web_save rpc and is therefore not saved on the record The fix consists to ensure the update_related_model_id is saved by making it readonly=False, which is usually what we want when we have a computed stored field. Task: opw-4513803 Forward-Port-Of: odoo/odoo#195124
This commit fixes an issue where if the user applies a group by on an aggregatable field (an integer like color_index for example), this field is also registered as an aggregator in the webReadGroup call and this leads to nonsensical results by the orm. After this commit, the group by field is automatically excluded from aggregators so the issue cannot happen. task-4491839 Forward-Port-Of: odoo/odoo#195733 Forward-Port-Of: odoo/odoo#195623
Original PR description
This commit fixes an issue where if the user applies a group by on an aggregatable field (an integer like color_index for example), this field is also registered as an aggregator in the webReadGroup call and this leads to nonsensical results by the orm. After this commit, the group by field is automatically excluded from aggregators so the issue cannot happen. task-4491839 Forward-Port-Of: odoo/odoo#195733 Forward-Port-Of: odoo/odoo#195623
This commit fixes the width of not available items inside the search results list and the search result dropdown. We achieve the fix by using the same approach used in this commit: https://github.com/odoo/odoo/commit/9ffbc8720b84f51d5d03a7e11c74c19b62cf46c0 opw-4444222 task-4517564 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195316
Original PR description
This commit fixes the width of not available items inside the search results list and the search result dropdown. We achieve the fix by using the same approach used in this commit: https://github.com/odoo/odoo/commit/9ffbc8720b84f51d5d03a7e11c74c19b62cf46c0 opw-4444222 task-4517564 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195316
Issue: When using the enterprise version, and configuring an accounting report with the report builder, issues might arise when changing the sequence of lines (using the drag and drop feature). Combined with the enterprise PR, this commit solves the issue by returning the lines ordered by sequence. Enterprise PR: https://github.com/odoo/odoo/pull/187907#pullrequestreview-2581564549 task-4328098 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-p
Original PR description
Issue: When using the enterprise version, and configuring an accounting report with the report builder, issues might arise when changing the sequence of lines (using the drag and drop feature). Combined with the enterprise PR, this commit solves the issue by returning the lines ordered by sequence. Enterprise PR: https://github.com/odoo/odoo/pull/187907#pullrequestreview-2581564549 task-4328098 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187907
Versions -------- - 16.0 Backport of https://github.com/odoo/odoo/pull/195266 Issue ----- Use `float_compare` to compare floating point amounts on reward validation. Forward-Port-Of: odoo/odoo#195793 Forward-Port-Of: odoo/odoo#195637
Original PR description
Versions -------- - 16.0 Backport of https://github.com/odoo/odoo/pull/195266 Issue ----- Use `float_compare` to compare floating point amounts on reward validation. Forward-Port-Of: odoo/odoo#195793 Forward-Port-Of: odoo/odoo#195637
Versions -------- - saas-17.4+ Steps ----- 1. Create a `next_order_coupons` loyalty program; 2. go to eCommerce as Public User; 3. add products to cart so that the program gets applied; 4. on checkout, log in as Portal User during delivery step; 5. finalize payment. Issue ----- Two coupons were created: one for Public User with 0 points, one with no partner and 1 point. There should only be one coupon, and it should be linked to the logged in user. Cause ----- PR https://
Original PR description
Versions -------- - saas-17.4+ Steps ----- 1. Create a `next_order_coupons` loyalty program; 2. go to eCommerce as Public User; 3. add products to cart so that the program gets applied; 4. on…
Versions -------- - saas-17.4+ Steps ----- 1. Create a `next_order_coupons` loyalty program; 2. go to eCommerce as Public User; 3. add products to cart so that the program gets applied; 4. on checkout, log in as Portal User during delivery step; 5. finalize payment. Issue ----- Two coupons were created: one for Public User with 0 points, one with no partner and 1 point. There should only be one coupon, and it should be linked to the logged in user. Cause ----- PR https://github.com/odoo/odoo/pull/163545 changed `next_order_coupons` programs to set a partner when created. Issue is when they get created as Public user, the next call to `_update_programs_and_rewards` when logged in will remove the point entries for that coupon, as it's linked to partner that doesn't match the sale order's: https://github.com/odoo/odoo/blob/278ce01fe1882ea424032dcf97c4d345816be96e/addons/sale_loyalty/models/sale_order.py#L867-L870 Solution -------- Before checking whether to unlink the point entries, update the coupon's `partner_id` if it was created for Public User and the sale order itself is no longer linked to Public User. Also when generating new coupons in `_update_programs_and_rewards`, link `next_order_coupons` to the customer to make it behave identical to coupons created via `__try_apply_program` (relevant when changing the SO customer from a one specific partner to another specific partner). opw-4397753 Forward-Port-Of: odoo/odoo#194936
Email clients have begun implementing security measures to protect users from phishing by analyzing email links, and interacting with them (see task-3972953). This has the side effect of automatically unsubscribing email recipients from mailing lists by clicking the link in the footer of the emails. This commit adds an intermediate step to the process, by requiring users to click on a button before they are unsubscribed. task-4364446 Forward-Port-Of: odoo/odoo#195643 Forward-Port-Of: o
Original PR description
Email clients have begun implementing security measures to protect users from phishing by analyzing email links, and interacting with them (see task-3972953). This has the side effect of automatically unsubscribing email recipients from mailing lists by clicking the link in the footer of the emails. This commit adds an intermediate step to the process, by requiring users to click on a button before they are unsubscribed. task-4364446 Forward-Port-Of: odoo/odoo#195643 Forward-Port-Of: odoo/odoo#189561
Fixes two bugs on carry over amount: reset accrual carryover to lost state: steps: - set the carry over to "carry over with maximum" - set a number of days to carry over and save - set the carry over type back to "None" -> You still carry over the amount of days you typed in instead of 0 always carryover the cap: steps: - create an accrual plan with: - 21 days per year alloc - start immediate - 28 days cap - carryover with max 7 days - create
Original PR description
Fixes two bugs on carry over amount:
reset accrual carryover to lost state:
steps:
- set the carry over to "carry over with maximum"
- set a number of days to carry over and save
- set the carry over type back to "None"
-> You still carry over the amount of days you typed in instead of 0
always carryover the cap:
steps:
- create an accrual plan with:
- 21 days per year alloc
- start immediate
- 28 days cap
- carryover with max 7 days
- create allocation for the current year (1/1/XXXX)
- take 15 days holidays -> 6 days left on the alloc
- check the leaves left for next year -> 28 days, should be 27 (21 + 6)
This happened because the carry-over calculation didn't take into account
the number of days left on the allocation and always carried over the cap.
Forward-Port-Of: odoo/odoo#190140
Forward-Port-Of: odoo/odoo#188621The b2b fields are still required in the portal form even if the "Show b2b fields" is deactivated Steps: - From the website editor, on the checkout form, unselect the "Show b2b fields" setting - Log out and go to ecommerce - Add a product to card and checkout - Fill the address form with a Brazilian address -> Error: "Some required fields are empty." With this commit, we add the field `vat` to the mandatory fields only if the option "Show b2b" fields is activated. opw-4403161 Forward-Port
Original PR description
The b2b fields are still required in the portal form even if the "Show b2b fields" is deactivated Steps: - From the website editor, on the checkout form, unselect the "Show b2b fields" setting - Log out and go to ecommerce - Add a product to card and checkout - Fill the address form with a Brazilian address -> Error: "Some required fields are empty." With this commit, we add the field `vat` to the mandatory fields only if the option "Show b2b" fields is activated. opw-4403161 Forward-Port-Of: odoo/odoo#195792 Forward-Port-Of: odoo/odoo#194110
Upon zooming in on the elearning slides view from the mobile by finger pinch, the whole page zooms in and not just the content, which causes the content quality to be still blurry. To Reproduce on Runbot: 1.Go to eLearning module. 2.Go to "Edit" on any of the courses. 3.Add a pdf content. 4.From the phone, go to the website elearning for the same course. 4.Click on the pdf content we uploaded. 5.Try finger pinch zooming in, the document gets still blurry. 6.The issue seems to be that
Original PR description
Upon zooming in on the elearning slides view from the mobile by finger pinch, the whole page zooms in and not just the content, which causes the content quality to be still blurry. To Reproduce on Runbot: 1.Go to eLearning module. 2.Go to "Edit" on any of the courses. 3.Add a pdf content. 4.From the phone, go to the website elearning for the same course. 4.Click on the pdf content we uploaded. 5.Try finger pinch zooming in, the document gets still blurry. 6.The issue seems to be that there's no finger pinch zoom in and out, and when you try doing that the whole page zooms in and out, not changing the quality of the document. So, the solution was to make zoom in and out icon available on small screen devices as well. opw-3893275 Forward-Port-Of: odoo/odoo#178655
In https://github.com/odoo/odoo/pull/127877, the active field was removed and replaced with state: cancel. This domain was modified but removed the check for the cancelled state. opw-4420347 Forward-Port-Of: odoo/odoo#195078 Forward-Port-Of: odoo/odoo#194600
Original PR description
In https://github.com/odoo/odoo/pull/127877, the active field was removed and replaced with state: cancel. This domain was modified but removed the check for the cancelled state. opw-4420347 Forward-Port-Of: odoo/odoo#195078 Forward-Port-Of: odoo/odoo#194600
Steps to reproduce: 1. Go to Website -> Edit -> Theme section. 2. Choose a predefined font family for the paragraph, such as "Arvo". 4. Return to the font family dropdown and click on "Add a Custom Font". Notice that the selected font reverts to the "default/system" font. Issue: The issue occurs because when a predefined "we-button" is selected from the dropdown menu(we-button with value i.e. data attributes defined), its value is passed to widgetValue. However, when the "Add a Custom
Original PR description
Steps to reproduce: 1. Go to Website -> Edit -> Theme section. 2. Choose a predefined font family for the paragraph, such as "Arvo". 4. Return to the font family dropdown and click on "Add a Custom…
Steps to reproduce: 1. Go to Website -> Edit -> Theme section. 2. Choose a predefined font family for the paragraph, such as "Arvo". 4. Return to the font family dropdown and click on "Add a Custom Font". Notice that the selected font reverts to the "default/system" font. Issue: The issue occurs because when a predefined "we-button" is selected from the dropdown menu(we-button with value i.e. data attributes defined), its value is passed to widgetValue. However, when the "Add a Custom Font" button is clicked(which does not have value i.e. data attributes are not defined), the "we-button" value changes to an empty string, which is then passed into widgetValue. As a result, it triggers refreshBundle with the empty string and resets to the default value. Solution: This PR ensures that `_refreshBundles` is not triggered until the widgetValue has a valid (non-empty) value. This prevents the font from being reverted to the default. task-4373983 Forward-Port-Of: odoo/odoo#190329
The $0 placeholder in templates is highly useful, but it is not considered when saving a view. For instance, the search icon in the shop search bar has an incorrect xpath: `/data/xpath[3]/form/t[1]/div[1]/button[1]/i[1]`, where the inner `t[1]` actually points to another view through a `<t>$0</t>` containing the inherited view. The method responsible for handling this replacement fails when the element is editable, causing a crash. This commit ensures that when an xpath jumps to another t
Original PR description
The $0 placeholder in templates is highly useful, but it is not considered when saving a view. For instance, the search icon in the shop search bar has an incorrect xpath: `/data/xpath[3]/form/t[1]/div[1]/button[1]/i[1]`, where the inner `t[1]` actually points to another view through a `<t>$0</t>` containing the inherited view. The method responsible for handling this replacement fails when the element is editable, causing a crash. This commit ensures that when an xpath jumps to another template, it disallows the branding. task-3609835 Forward-Port-Of: odoo/odoo#187760
**Problem**: `this.state.showCodeView` cannot be relied upon because `toggleCodeView` of `HtmlField` is never called in cases like mass mailing. Instead, `MassMailingSnippetsMenu` forces code view without using the `HtmlField` mechanism. **Solution**: Instead of checking `this.state.showCodeView`, directly check the return value of `this._getCodeViewEl()` in `MassMailingHtmlField`. **Steps to Reproduce**: 1. Add an Image-Text snippet. 2. Save the snippet. 3. Resize the image. 4.
Original PR description
**Problem**: `this.state.showCodeView` cannot be relied upon because `toggleCodeView` of `HtmlField` is never called in cases like mass mailing. Instead, `MassMailingSnippetsMenu` forces code view without using the `HtmlField` mechanism. **Solution**: Instead of checking `this.state.showCodeView`, directly check the return value of `this._getCodeViewEl()` in `MassMailingHtmlField`. **Steps to Reproduce**: 1. Add an Image-Text snippet. 2. Save the snippet. 3. Resize the image. 4. Switch to code view. 5. Save. 6. Observe that the class `o_modified_image_to_save` is not removed from the image. opw-4406195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195587 Forward-Port-Of: odoo/odoo#195539
Before this commit, with a slow internet connection, if a user added an item to the order and pressed the pay button very quickly (before completing the price loading), it would bypass the payment step and directly give the receipt. opw-4305214 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186960
Original PR description
Before this commit, with a slow internet connection, if a user added an item to the order and pressed the pay button very quickly (before completing the price loading), it would bypass the payment step and directly give the receipt. opw-4305214 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186960
If Projects plan is removed we cannot let it be recreated in a module upgrade. If we allow so the new plan will create an unnecessary column in `account_analytic_line`. This would repeat each time the user upgrades the module in case the plan is removed before the upgrade. In principle this is not an issue, unless account_budget is also installed. In such case the new column for `budget_line` won't be created and that would cause errors. Steps to reproduce 1. Install `account_budget` 2. Cre
Original PR description
If Projects plan is removed we cannot let it be recreated in a module upgrade. If we allow so the new plan will create an unnecessary column in `account_analytic_line`. This would repeat each time…
If Projects plan is removed we cannot let it be recreated in a module upgrade. If we allow so the new plan will create an unnecessary column in `account_analytic_line`. This would repeat each time the user upgrades the module in case the plan is removed before the upgrade. In principle this is not an issue, unless account_budget is also installed. In such case the new column for `budget_line` won't be created and that would cause errors. Steps to reproduce 1. Install `account_budget` 2. Create a new Plan 3. Set the config parameter to the id of the new plan 4. Remove Projects plan 5. Upgrade analytic module 6. Try to create a new analytic account. There is an error in the frontend ``` OwlError: The following error occurred in onWillStart: ""budget.line"."x_plan3_id" field is undefined." ``` The problem is that since the new plan was created via an upgrade the post init hook of `account_budget` didn't run. Therefore the new column in `budget_line` was not created. Notes: * In step 4 above the column `x_plan2_id` in analytic line is left unused. This is not a problem per-se besides extra data dangling in the DB. * We may argue that we should ensure that the column plan is created in a register_hook in `account_budget` but conceptually the relevant setting is the config parameter, recreating a plan that has no reason to exist could cause more issues down the line. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195710
This commit will update some taxes: - Update the purchase tax accounts - Add new 0% EX tax - Delete EX RS 20% & EX RS -20% In the tax report: - Change the name of the report - Add a new record task: 4244715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185947
Original PR description
This commit will update some taxes: - Update the purchase tax accounts - Add new 0% EX tax - Delete EX RS 20% & EX RS -20% In the tax report: - Change the name of the report - Add a new record task: 4244715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185947
This PR is backporting of these commits: [1] Commit https://github.com/odoo/odoo/commit/a1b7d8aba255ec477a030d44897b8ea73d1f37e7 [2] Commit https://github.com/odoo/odoo/commit/3653131d32997392b2170ce542bfc544fd96bef2 These commits introduce the computation of fiscal positions for sales and purchase documents based on the place of supply. While these changes are already merged into version 18.1, they are now required in version 17.0. --- I confirm I have signed the CLA and read
Original PR description
This PR is backporting of these commits: [1] Commit https://github.com/odoo/odoo/commit/a1b7d8aba255ec477a030d44897b8ea73d1f37e7 [2] Commit https://github.com/odoo/odoo/commit/3653131d32997392b2170ce542bfc544fd96bef2 These commits introduce the computation of fiscal positions for sales and purchase documents based on the place of supply. While these changes are already merged into version 18.1, they are now required in version 17.0. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195703 Forward-Port-Of: odoo/odoo#195399
Before this commit, the test was relying in "today's" date for creating the recurring invoices. Since the time period for generating them was too short, the expected deliveries were not being generated. After this commit, we give a fixed date to the start date of the subscriptions and then generate the recurring invoices with a time distance of a month, solving the issue. Issue-from: OPW-4166852 Related PR: odoo/enterprise#73397 Forward-Port-Of: odoo/enterprise#76336
Original PR description
Before this commit, the test was relying in "today's" date for creating the recurring invoices. Since the time period for generating them was too short, the expected deliveries were not being generated. After this commit, we give a fixed date to the start date of the subscriptions and then generate the recurring invoices with a time distance of a month, solving the issue. Issue-from: OPW-4166852 Related PR: odoo/enterprise#73397 Forward-Port-Of: odoo/enterprise#76336
Solves 2 issues related to the report builders. Also cleans the onWillUpdateProps as advised by the Framework JS team. Issue 1: Steps to reproduce: - Go to Accounting -> Configuration -> Accounting Reports - Create a new report with 2 lines - drag the bottom line on top of the first one -> The list order is properly handled - Press the save button -> The list order is back to its original form. Cause of the issue: When saving, the list.props.list.records is equal to it
Original PR description
Solves 2 issues related to the report builders. Also cleans the onWillUpdateProps as advised by the Framework JS team. Issue 1: Steps to reproduce: - Go to Accounting -> Configuration -> Accounting Reports - Create a new report with 2 lines - drag the bottom line on top of the first one -> The list order is properly handled - Press the save button -> The list order is back to its original form. Cause of the issue: When saving, the list.props.list.records is equal to its original order and therefore needs to be ordered based on the sequence. Issue 2: -> solved in related community PR - Create a report with 2 lines, line 2 being a child of line 1 - Drag line 2 above line 1 -> Validation error Cause of the issue: - The backend constraint receives line not ordered by sequence task-4328098 Forward-Port-Of: odoo/enterprise#74177
This commit will authorize to delete an online synchronization from the cog menu even if the connection is in error. Previously, we added a check that if the connection throws a user error or a redirect warning we can't delete it. We will remove this. Backport of odoo/enterprise#72902 task-4526918 Forward-Port-Of: odoo/enterprise#78198
Original PR description
This commit will authorize to delete an online synchronization from the cog menu even if the connection is in error. Previously, we added a check that if the connection throws a user error or a redirect warning we can't delete it. We will remove this. Backport of odoo/enterprise#72902 task-4526918 Forward-Port-Of: odoo/enterprise#78198
Whatsapp API doesn't allow to send captions with audio anymore, therefore we should modify the way we handle captions. After this commit audio will be sent first while text message will stay in a composer, it will only be sent after the audio is sent. task-4007616 Forward-Port-Of: odoo/enterprise#77885 Forward-Port-Of: odoo/enterprise#66818
Original PR description
Whatsapp API doesn't allow to send captions with audio anymore, therefore we should modify the way we handle captions. After this commit audio will be sent first while text message will stay in a composer, it will only be sent after the audio is sent. task-4007616 Forward-Port-Of: odoo/enterprise#77885 Forward-Port-Of: odoo/enterprise#66818
When trying to print invoice before reveiving etims details by the gouvernment, we get an error because we're trying to access some attributes of those fields, such as `strftime` or `len()` With this commit, we replace non set fields by empty strings either for display purpose or methods calls. opw-4480304 Forward-Port-Of: odoo/enterprise#78176
Original PR description
When trying to print invoice before reveiving etims details by the gouvernment, we get an error because we're trying to access some attributes of those fields, such as `strftime` or `len()` With this commit, we replace non set fields by empty strings either for display purpose or methods calls. opw-4480304 Forward-Port-Of: odoo/enterprise#78176
StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted for in the future period. To reproduce, you can: - Create a subscription with a start_date in the past, so that today's date is in the SECOND period: Ex: Today = "2024-11-01" * Recurring plan: Monthly * Start Date: "2024-10-01" - Trigger the cron to invoice & deliver the FIRST period ("2
Original PR description
StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted…
StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted for in the future period.
To reproduce, you can:
- Create a subscription with a start_date in the past, so that today's date is in the SECOND period: Ex: Today = "2024-11-01"
* Recurring plan: Monthly
* Start Date: "2024-10-01"
- Trigger the cron to invoice & deliver the FIRST period ("2024-10-01" -> "2024-10-31").
- Validate the first period picking => "Scheduled Date" becomes the done date: "2024-11-01"
- Trigger the cron to invoice & deliver the SECOND period ("2024-11-01" -> "2024-11-30"). => Second period picking is NOT generated, because the first period picking was interpreted as belonging to the second period.
---
Test result before fix:
```
2024-11-07 13:44:54,695 34298 ERROR oes_17_test_sss odoo.addons.sale_subscription_stock.tests.test_sale_subscription_stock_order: FAIL: TestSubscriptionStockOnOrder.test_picking_done_in_another_period
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/enterprise/sale_subscription_stock/tests/test_sale_subscription_stock_order.py", line 543, in test_picking_done_in_another_period
self.assertTrue(bool(second_picking))
AssertionError: False is not true
```
OPW-4280155
Forward-Port-Of: odoo/enterprise#73741
Forward-Port-Of: odoo/enterprise#73484We already support the non-SEPA ISO 20022 method in the `account_sepa` module. However, we were still requiring the origin bank account to be an IBAN account, according to SEPA rules. However, since ISO 20022 can be used outside of the SEPA zone, we don't need to check for an IBAN in that case. This commit fixes that, so non IBAN bank accounts can use ISO 20022 payments. Forward-Port-Of: odoo/enterprise#78171 Forward-Port-Of: odoo/enterprise#77873
Original PR description
We already support the non-SEPA ISO 20022 method in the `account_sepa` module. However, we were still requiring the origin bank account to be an IBAN account, according to SEPA rules. However, since ISO 20022 can be used outside of the SEPA zone, we don't need to check for an IBAN in that case. This commit fixes that, so non IBAN bank accounts can use ISO 20022 payments. Forward-Port-Of: odoo/enterprise#78171 Forward-Port-Of: odoo/enterprise#77873
Version: - 17.0 Steps to reproduce: - Install the Sign module. - Try to open a sample document. Issue: - An access error occurs when a "Sign User" tries to access a demo sign template. Solution: - Allow internal users to access sample data. task- 4390945 Forward-Port-Of: odoo/enterprise#75522
Original PR description
Version: - 17.0 Steps to reproduce: - Install the Sign module. - Try to open a sample document. Issue: - An access error occurs when a "Sign User" tries to access a demo sign template. Solution: - Allow internal users to access sample data. task- 4390945 Forward-Port-Of: odoo/enterprise#75522
When the user tries to forward a Google Maps location in a message, a traceback will appear. Steps to reproduce the error: - Go to WhatsApp > Templates > Create a new template A > Header Type: Location - Set a Body message > In Variables, Set the sample values for all the variables - Create a new Contact with a Mobile number > Send a Whatsapp message with template A - User will receive a message with a link of location > Forward that message back to that number Traceback: ``` File "
Original PR description
When the user tries to forward a Google Maps location in a message, a traceback will appear. Steps to reproduce the error: - Go to WhatsApp > Templates > Create a new template A > Header Type:…
When the user tries to forward a Google Maps location in a message,
a traceback will appear.
Steps to reproduce the error:
- Go to WhatsApp > Templates > Create a new template A > Header Type: Location
- Set a Body message > In Variables, Set the sample values for all the variables
- Create a new Contact with a Mobile number > Send a Whatsapp message with template A
- User will receive a message with a link of location > Forward that message back to that number
Traceback:
```
File "/home/odoo/odoo/enterprise/whatsapp/controller/main.py", line 42, in webhookpost
wa_account_id._process_messages(value)
File "/home/odoo/odoo/enterprise/whatsapp/models/whatsapp_account.py", line 225, in _process_messages
body += Markup("<br/>{location_address}").format(location_name=messages['location']['address'])
File "/home/odoo/.local/lib/python3.10/site-packages/markupsafe/__init__.py", line 213, in format
return self.__class__(formatter.vformat(self, args, kwargs))
File "/usr/lib/python3.10/string.py", line 165, in vformat
result, _ = self._vformat(format_string, args, kwargs, used_args, 2)
File "/usr/lib/python3.10/string.py", line 205, in _vformat
obj, arg_used = self.get_field(field_name, args, kwargs)
File "/usr/lib/python3.10/string.py", line 270, in get_field
obj = self.get_value(first, args, kwargs)
File "/usr/lib/python3.10/string.py", line 227, in get_value
return kwargs[key]
File "/home/odoo/.local/lib/python3.10/site-packages/markupsafe/__init__.py", line 249, in __getitem__
return self._kwargs[key]
KeyError: 'location_address'
```
https://github.com/odoo/enterprise/blob/2b4acb4c82a7374d45f25a7d8eebdc53b7f6e140/whatsapp/models/whatsapp_account.py#L225
Here, ``location_name`` is used instead of ``location_address``,
So, It will lead to the above traceback.
sentry-6206183097
Forward-Port-Of: odoo/enterprise#76883