Daily updates from Odoo
Navigate
Branch
Thursday, September 19, 2024
70 changes
13 changes
Resolved issues and error corrections
The stock forecast report now correctly identifies customer-bound moves when multi-step delivery routes use push rules. This helps businesses see more reliable outgoing stock quantities and avoid misleading inventory forecasts.
Original PR description
Following #156437, the new default setup for multi-step deliveries is through the new push rules. This means that when you trigger a delivery to a customer, it will first create the PICK before creating the delivery. This means that now we need to check on the `location_final_id` if it exists before checking the `location_dest_id`, as it holds the real destination of the move to consider it as an 'out' move or not. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the ability to choose a specific journal when creating a debit note from an invoice. It ensures the debit note wizard correctly determines the journal type, so valid journals are shown instead of an empty selection.
Original PR description
Steps to reproduce: - Install Accounting and account_debit_note - Accounting > Customers > Invoices > Select any - Gear Icon > Debit note - Try to select an entry in 'Use Specific Journal' No journal…
Steps to reproduce:
- Install Accounting and account_debit_note
- Accounting > Customers > Invoices > Select any
- Gear Icon > Debit note
- Try to select an entry in 'Use Specific Journal'
No journal is available to pick from, this happens because 'Use specific journal' filters journal_id with the domain [('type', '=', journal_type)], and journal_type mistakenly has the value False.
The root cause of this issue is the strengthened recompuation protection added in 20c2e5996651168db3a6d75ace6a8907c1661792. The ORM will no longer allow recomputation of fields without a default if they share a compute method with another field which has a default value. (In an onchange flow).
At the time of the wizard's creation we update the cache in onchange() to contain False for each value without a default. In 17.0 and earlier we used to invalidate that cached value, leading to the computation of journal_type, but that behavior has changed since.
To avoid uncessary recomputation of 'move_type' (which is given a default value) we protect its compute method. However 'move_type' shares its compute method with journal_type, so we also prevent the computation of journal_type in the process.
We end up with our debit note wizard which has never made a call to _compute_from_moves (meaning is has no journal_type) and thus filter journal_id by [('type', '=', False)], which is forbidden as journal_id.type is a required field, preventing us from selecting a journal.
opw-4124278
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue where loading Argentine localization demo data after database setup could fail because some sample products received duplicate default taxes. The affected demo products are now tied to the correct company, preventing errors when sample invoices or accounting entries are created.
Original PR description
### Steps to reproduce: - Create a db with `l10n_ar` but without demo data - In dev move at the bottom of the settings page: Load Demo data #### > UserError > load aborted. ### Cause of the issue:…
### Steps to reproduce: - Create a db with `l10n_ar` but without demo data - In dev move at the bottom of the settings page: Load Demo data #### > UserError > load aborted. ### Cause of the issue: Since commit 051d43dbef390de171307fe0e493d651c9ad7b4b (17.0), during the create of products, if the product is not associated to a given company, we add a default tax for each company that is not in the context (and hence should not have defined a tax yet): https://github.com/odoo/odoo/blob/b32fc0f715e41f6795972f2f8a2c3e4826357aa1/addons/account/models/product.py#L138-L146 However, if you were to create a DB without demo data and if you were loading the demo data from the UI, you will create demo datas product for companies that had already set a tax for that product (e.g. `company_ri` on the product `product_product_telefonia`) and since the current company is in the context the override of the create will add a second tax on these products for that companies. As such, if the product is later used in account moves it will raise a user error: https://github.com/odoo/odoo/blob/b32fc0f715e41f6795972f2f8a2c3e4826357aa1/addons/l10n_ar/models/account_move.py#L141-L144 and the installation of the all the demo datas will then be aborted. ### Fix: Since the demo data's products used in the account moves raising user errors are only expected to be used in the the company for which we have associated a tax eg: https://github.com/odoo/odoo/blob/b32fc0f715e41f6795972f2f8a2c3e4826357aa1/addons/l10n_ar/demo/account_supplier_invoice_demo.xml#L136 we simply add a company_id on these products. Note that the test datas had to be updated in somewhat a similar way in commit 051d43dbef390de171307fe0e493d651c9ad7b4b. opw-4180872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix keeps the connection between sales orders and their related purchase orders when products are received through multiple warehouse steps. It helps ensure make-to-order purchases remain traceable and correctly linked throughout the receipt process.
Original PR description
With the old pull rules, pickings were created up to the last step before reception (i.e. Input in multi-step reception) which would be all in the procurement group. Then, once the purchase order is validated, then reception move would be the orig of that last step move. In this case, the link would work properly. However, with the new push rules, the move that trigget the creation of the purchase order is no longer Input -> Stock, but the first step of delivery. This still works correctly until the first reception step is completed, but then the move_orig of the Stock -> Output is no longer Vendor -> Input, but Input -> Stock, which doesn't contain the link to the purchase order. This means we have to rollup the orig of the move to get to the actual purchase order, regardless of the number of extra steps in between. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
In Factur-X, it is sometimes required to specify the SIRET (using the node `SpecifiedLegalOrganization`). The SIRET is a field appearing when l10n_fr is installed. In addition, in 17.0, it only appears if the current company has the French CoA installed. Hence, it is not possible to specify a SIRET on a French partner if the company is Belgian, for instance. To fix this, we also use the company_registry to fill the SIRET node in the xml. In master, we intend to remove the SIRET field, as w
Original PR description
In Factur-X, it is sometimes required to specify the SIRET (using the node `SpecifiedLegalOrganization`). The SIRET is a field appearing when l10n_fr is installed. In addition, in 17.0, it only appears if the current company has the French CoA installed. Hence, it is not possible to specify a SIRET on a French partner if the company is Belgian, for instance. To fix this, we also use the company_registry to fill the SIRET node in the xml. In master, we intend to remove the SIRET field, as we should have used the company_registry from the beginning instead. opw-4174309 Forward-Port-Of: odoo/odoo#180321
Forward-Port-Of: odoo/odoo#180663
Original PR description
Forward-Port-Of: odoo/odoo#180663
This error occurs when attempting to add a payment using the ``Quick Add`` feature in the Kanban view. Steps to reproduce: - Install the ``pos_online_payment`` module - Point of Sale > Orders > Payments > Go to Kanban view - Click on the ``Quick Add`` button and ``Add`` Traceback: ``KeyError: 'payment_method_id'`` The error in [1] occurred because the ``payment_method_id`` was not found in the vals. This commit will fix the above error by removing the Kanban view from payments be
Original PR description
This error occurs when attempting to add a payment using the ``Quick Add`` feature in the Kanban view. Steps to reproduce: - Install the ``pos_online_payment`` module - Point of Sale > Orders > Payments > Go to Kanban view - Click on the ``Quick Add`` button and ``Add`` Traceback: ``KeyError: 'payment_method_id'`` The error in [1] occurred because the ``payment_method_id`` was not found in the vals. This commit will fix the above error by removing the Kanban view from payments because we never allow payment creation. [1]- https://github.com/odoo/odoo/blob/42ab53925b140508e2aa837ce09c914b8f243b21/addons/pos_online_payment/models/pos_payment.py#L20 sentry-5750182450 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180557
* PROPBLEM: When duplicating a picking, the creation date is not updated to latest date (fields.datetime.now) instead it was taken from the copy value. This will be a problem if user try to search for it, they do not know 'creation_date' actually is because it is not present on picking view * SOLUTION: this commit add copy=False to update 'creation_date' when duplicating picking Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is
Original PR description
* PROPBLEM: When duplicating a picking, the creation date is not updated to latest date (fields.datetime.now) instead it was taken from the copy value. This will be a problem if user try to search for it, they do not know 'creation_date' actually is because it is not present on picking view * SOLUTION: this commit add copy=False to update 'creation_date' when duplicating picking 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#180580 Forward-Port-Of: odoo/odoo#179718
This commit adds default fiscal positions for the UK, and postponed / reverse charge VAT. The (sales) reverse charge tax is labeled "Reverse Charge 20%" because of a legal requirement (Chapter 7.6.1 on the gov website: https://www.gov.uk/guidance/the-vat-domestic-reverse-charge-procedure-notice-735) Two purchase reverse charge taxes are added, one for the domestic reverse charge scheme, and one for the international reverse charge scheme. (More details on the gov website: https://www.go
Original PR description
This commit adds default fiscal positions for the UK, and postponed / reverse charge VAT. The (sales) reverse charge tax is labeled "Reverse Charge 20%" because of a legal requirement (Chapter 7.6.1…
This commit adds default fiscal positions for the UK, and postponed / reverse charge VAT. The (sales) reverse charge tax is labeled "Reverse Charge 20%" because of a legal requirement (Chapter 7.6.1 on the gov website: https://www.gov.uk/guidance/the-vat-domestic-reverse-charge-procedure-notice-735) Two purchase reverse charge taxes are added, one for the domestic reverse charge scheme, and one for the international reverse charge scheme. (More details on the gov website: https://www.gov.uk/guidance/how-to-fill-in-and-submit-your-vat-return-vat-notice-70012) The existing 20% purchase VAT is split into two new taxes, one for services and one for goods. This is so that they may be appropriately mapped in the "Rest of the World" fiscal position. If the company is situated in Northern Ireland, certain taxes and fiscal positions should be activated. This commit sets the (by default) inactive Northern Irish taxes and fiscal position to active after loading the chart template when the company has a state_id set as one belonging to Northern Ireland. task-id: 3260002 Forward-Port-Of: odoo/odoo#178185
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180639
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180639
In this commit, we fix undeterministic bugs in tour add_to_cart_snippet_tour. To fix this behavior, we add few additionnal steps to check the state of DOM before continuing the tour. Forward-Port-Of: odoo/odoo#179360 Forward-Port-Of: odoo/odoo#178788
Original PR description
In this commit, we fix undeterministic bugs in tour add_to_cart_snippet_tour. To fix this behavior, we add few additionnal steps to check the state of DOM before continuing the tour. Forward-Port-Of: odoo/odoo#179360 Forward-Port-Of: odoo/odoo#178788
You should not be able to archive a journal used in a payment method. Steps to reproduce: ------------------- * Go on any journal used in a payment method (e.g. Cash) * Archive the journal > Observation: You are still able to use the payment method without the journal being active Note: --------------- Similar fix was done for the point of sale here : https://github.com/odoo/odoo/pull/177751 opw-4070620 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo
Original PR description
You should not be able to archive a journal used in a payment method. Steps to reproduce: ------------------- * Go on any journal used in a payment method (e.g. Cash) * Archive the journal > Observation: You are still able to use the payment method without the journal being active Note: --------------- Similar fix was done for the point of sale here : https://github.com/odoo/odoo/pull/177751 opw-4070620 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180689 Forward-Port-Of: odoo/odoo#180487
Version: 16.0+ Issue: A vendor bill paid with an existing check remains paid although the check has been removed. This is because the vendor payment is made with the check and the payment is still reconciled with the vendor bill. This will lead to inconsistent/erroneous display of the payment status of the vendor bill. Purpose of this PR: Prevent the check payments with other operations from being reset to draft or removed. Instead raise an error to notify the user that the payment is us
Original PR description
Version: 16.0+ Issue: A vendor bill paid with an existing check remains paid although the check has been removed. This is because the vendor payment is made with the check and the payment is still reconciled with the vendor bill. This will lead to inconsistent/erroneous display of the payment status of the vendor bill. Purpose of this PR: Prevent the check payments with other operations from being reset to draft or removed. Instead raise an error to notify the user that the payment is used for other account moves. Steps to reproduce in runbot: 1) set up latam checks in database 2) make an invoice and use a check as payment 3) make a bill and use the existing check to pay for the bill 4) go back to the invoice and reset the payment to draft and delete the payment 5) the vendor payment will remain and be marked as paid/partial paid opw-4189731 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180522
48 changes
New functionality added to Odoo
Adds ready-made marketing automation templates for online sales follow-ups. Businesses can now more easily ask for feedback after a purchase and re-engage repeat customers with thank-you messages and product suggestions.
Original PR description
Add sales templates for marketing_automation. - purchase followup: Request feedback about a recent purchase - repeat customer: Thank customers and suggest new products task-3640536
Odoo adds shared tools to manage digital certificates and keys, reducing duplicated work across country-specific features. This should make certificate-based processes easier to maintain and more consistent for localizations such as Argentinian e-invoicing and Belgian payroll reporting.
Original PR description
Problem --------- All localisations dealing with certificates do it their own way. However, these have a lot of common usages and there is lot of redundant work done there. Furthermore, it makes maintenance harder is case of failure. Objective --------- Create common models to manage keys and certificates. Solution --------- We create 2 models: 1 - For certificates, `certificate.certificate` 2 - For keys, `certificate.key` Each model makes use of the cryptography library to extract data from the certificate file. odoo/odoo/pull/168834 odoo/upgrade/pull/6142 task-3806683
Adds the ability for Indian localization users to retrieve GSTR-2A tax data from the government portal, including B2B and credit/debit note details. This helps businesses keep tax reporting data more aligned with Indian GST compliance requirements and reduces manual data collection.
Original PR description
This update adds a new feature to the Indian localization module (l10n_in). Now, the system can fetch GSTR-2A data from the portal, including details from the B2B and CDN sections. This enhancement ensures that the module stays in sync with India's specific tax reporting needs. Task Id: 3551097
Businesses in India can now fetch e-invoice IRN data from the GST portal and use it to match or create vendor bills more efficiently. The update also adds manual IRN entry and QR-based workflows, reducing manual billing effort and improving GST compliance accuracy.
Original PR description
This pull request introduces a new module, `l10n_in_reports_gstr_irn_sync`, and implements an API for better integration with the GST portal. #### Key Features: - **Module Addition:** - Fetches and processes IRN data from the GST portal. - Automatically creates draft bills if no related IRN bill exists. - Improves GST compliance and billing efficiency. - **API Implementation:** - Adds an endpoint to get bill details using IRN. - Ensures IRN is a 64-character alphanumeric string. - Allows setting IRN via QR scanning or GST report. #### Impact: - Enhances billing accuracy and compliance. - Reduces manual work. - Streamlines billing processes. Task ID: 3551097
Adds the ability for Indian localization users to retrieve GSTR-2A data from the GST portal, covering B2B, credit/debit notes, imports, and SEZ import sections. This helps businesses keep purchase tax reporting data aligned with Indian compliance requirements directly in Odoo.
Original PR description
This update adds a new feature to the Indian localization module (l10n_in). Now, the system can fetch GSTR-2A data from the portal, including details from B2B, CDN, IMPG, and IMPGSEZ sections. This enhancement ensures that the module stays in sync with the specific tax reporting needs in India. Task Id: 3551097
Enhancements to existing features
Contact records now show a WhatsApp chat count when conversations exist, making it easier for users to find past customer WhatsApp interactions. Clicking the count opens the related conversations in newest-first order and lets users open each chat directly.
Original PR description
**PURPOSE:** As more and more WhatsApp conversations with customers happen, one needs to be able to easily retrieve what said in those, just as we do with the chatter for emails. **SPECIFICATIONS:** - Add a stat button on the Contact form showing WA chat count and hidden if 0 - The counter should display the number of WA chats linked with that partner - Clicking on stat button should open a list view of the conversations which were counted in the stat button counter. - Conversations should be ordered by newest to oldest (last message received goes first) - Clicking on each row should open the conversation in chat window **Upgrade:** https://github.com/odoo/upgrade/pull/6161 **task**-[3658331](https://www.odoo.com/web#id=3658331&cids=2&menu_id=6478&action=4043&model=project.task&view_type=form)
Studio exports are easier to configure and now include important app details such as custom stage behavior and app icons. Export errors are also shown inside Odoo instead of taking users away from their session, making the process clearer and less disruptive.
Original PR description
Specs: https://app.excalidraw.com/l/65VNwvy7c4X/7zj4XOg5eLg Task: https://www.odoo.com/odoo/project/133/tasks/3446301 ### [FIX] web_studio: pointer for home_menu_customizer - Before: no pointer…
Specs: https://app.excalidraw.com/l/65VNwvy7c4X/7zj4XOg5eLg
Task: https://www.odoo.com/odoo/project/133/tasks/3446301
### [FIX] web_studio: pointer for home_menu_customizer
- Before: no pointer cursor on home_menu_customizer entries
- After: fixed
### [FIX] web_studio: show traceback on export failure
- Before this commit
If an error occur server side while generating an export archive, the
browser will leave the Odoo webclient to display the received server
error page.
- After this commit
The server error is now displayed in an error dialog, without leaving
the Odoo webclient.
### [FIX] web_studio: add missing info in export
- Before:
When exporting a new app with custom stages, the stage field is not
marked as group_expand, leading to the imported app to only show
grouped stages having at least a record, leaving the empty stages not
shown.
Also, apply a custom icon to a new app and its icon will not get
exported.
- After:
Fixed by simply adding the proper fields in the export
-> [ir.model.fields] group_expand
-> [ir.ui.menu] web_icon_data
### [IMP] {test_}web_studio: exports v2
**Changes**
- simplification of the wizard's UX
- autofill renamed preset and logic changed a bit: only preset models
that have modified records (from the hardcoded list of preset models +
custom models "x_...")
- simplify xmlids for records from the generated module (no module name
needed for those records)
- no more filter out unmodified records for chosen studio.export.model
This means that you now need to filter out manually the records you do
not want to export by narrowing the studio.export.model's domain.SEPA direct debit mandate handling has been redesigned to reduce manual work and make customer communications clearer. The update removes unnecessary journal-based restrictions, adds required pre-notification handling, improves mandate status tracking, and introduces better send-and-print flows for signature requests.
Original PR description
### **[IMP] {account,payment}_sepa_direct_debit: SDD mandatalypse** The aim of this commit is to rework the sepa mandate models to improve the user experience Context (non-exhaustive): Prior to this…
### **[IMP] {account,payment}_sepa_direct_debit: SDD mandatalypse**
The aim of this commit is to rework the sepa mandate models
to improve the user experience
Context (non-exhaustive):
Prior to this changes a few frustration points were present:
- The obligation to make a new mandate if another journal was used
- The selection of the right mandate upon payment creation
- Redundant buttons
- Lack of SEPA norm required elements e.g.:
- the pre-notification period and pre-notification mail
(account_sepa_direct_debit)
- the automatic expiration of a mandate for inactivity
- A proper send & print wizard when sending the signature request
- Lots of small UI/UX issues
After this commit (non-exhaustive):
- A lot of constraints removal/displacement further in the flow
- Removal of journal-related fields
and adding the missing pre-notification period
- A new state when canceling a draft mandate
- New mail templates for the different interactions with the customer
- New Send & Print wizard with a mail composer
- Required collection date computation overhaul
- Mandates state computation overhaul
see task for more details
### **[IMP] l10n_uk_bacs: Change permission groups**
The permission group for the BACS Direct debit Instruction
was deemed too high and it was decided to lower
it to the basic account group.
As an employee able to see/use bank statement feature
is considered trustworthy enough to validate mandates
### **[LINT] {account,payment}_sepa_direct_debit: apply ruff style to module**
The new rules of the ruff linter makes any changes in this module
impossible without correcting the style issues first.
This applies the required changes in a separate commit for
more clarity
task-id: 3722517Manufacturing teams can now configure accounts used to track work in progress and related overheads. Work order costs can also be calculated up to a chosen date, supporting more accurate period-based accounting for unfinished production.
Original PR description
Enterprise support of WIP accounting: - adds fields to settings to configure accounts (only needed in Enterprise due to only expecting it to be needed when Accounting is installed, i.e. not only invoicing) - adapt the WO cost calculation to be flexible with only calculating up to a specific date of recorded times
The generic Balance Sheet report now presents equity information more clearly, making financial statements easier to understand and review. This helps businesses interpret their financial position with greater confidence and consistency.
Original PR description
Clarification of the generic Balance Sheet Task [link](https://www.odoo.com/odoo/project/967/tasks/4057538) task-4057538
Companies can now set a tax closing start date that differs from January 1, helping support country-specific tax periods. Tax reports also get a dedicated tax period date filter so reporting and closing periods stay aligned and reduce filing mistakes.
The appointment validation page now shows a cleaner, better aligned card with rounded images and fewer visual separators. Resource details are presented more clearly, and simple resource-only cases avoid showing an unnecessary card.
Original PR description
Purpose ======= Improve the card display on the right of the validation page. Specification ============= - Remove the card border - Round the 4 corners of the image - Align the staff user/resource name with their details - Remove the separators that were set between each details line, and only display one below the staff user/resource name. Task-4141399
Manufacturing work order Gantt labels now show the final product name at the beginning. This makes production schedules easier to read and helps teams quickly identify what each planned work order contributes to.
Original PR description
Show the name of the final product at the beginning of the gantt labels task: 3977697 See odoo/odoo#168432
Adds a dedicated tool to help users find potential duplicate online bank transactions in a journal, using matching details such as amount, date, account number, or transaction ID. This helps accounting teams clean up duplicated imports from online synchronization and keeps reconciliation records more reliable.
Original PR description
Remove fetch missing transactions cog menu from jounal view (as it's only pertitnent on bank journals).
Add wizard to find duplicate online transactions in a journal.
This tool finds all transaction with
- same amount &
- same date &
- same account number
or
- same transaction id
where at least one of the transactions is an online sync transaction.
Task: 3648519Loyalty features have been improved for customers using the online portal, with related sales and point-of-sale flows aligned. This helps make loyalty benefits more visible and consistent across customer-facing sales channels.
Original PR description
_* : sale_loyalty, pos_loyalty, sale
Studio approval rules now support both individual approvers and approver groups, with clearer step-based approval flows. Approvers and notified users receive activity alerts at the right time, and approvers can delegate approval rights when needed.
Original PR description
This commit improves the Studio approval models and flow. A rule can now have Users that can approve or a Group, users of which can approve too. Approvers are pinged with a Mail Activity when a rule…
This commit improves the Studio approval models and flow. A rule can now have Users that can approve or a Group, users of which can approve too. Approvers are pinged with a Mail Activity when a rule is up next in the approval flow. Users to notify are pinged whenever an entry has been created or changed. As before, approval rules are ordered by their "Step" field (notification_order). Same order rules are of equal importance, higher order rules have higher importance. Together they compose an approval flow, which is made explicit with a Kanban view where rules are grouped by their notification order by default. A "Delegate" feature has been implemented: - if a user is an approver on a rule, they can add other users permanently or temporarily as approvers on that rule. They can only remove approvers if they themselves added them. They can do that via the button "Delegate" on the rule's form view. Generally speaking, they are not supposed to have create/write access on rules, and must delegate via the wizard. - If a user has write access on rules (in the admin group), modifying approvers on the form view will wipe every delegation previously done. Technically, it is not necessary anylonger to put `studio_approval="1"` as an attribute on the button itself to fetch its approvals. The information that tells buttons to fetch approvals is now part of the get_views. *: test_web_studio task-4123107 Co-authored-by: Aaron Bohy <aab@odoo.com> Co-authored-by: Adrien Dieudonné <adr@odoo.com> Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com> Co-authored-by: Lucas Perais <lpe@odoo.com>
Subscriptions can now be invoiced on the first day of the relevant billing period, giving businesses more control over billing timing. Generic subscriptions also handle partial-period invoicing only when a subscription ends, helping make final invoices clearer and more accurate.
Original PR description
Allow the invoicing of sale_subscription to be on the 1st day of the given billing period. This commit also change the behaviour of generic subscription to only invoice the partial period on subscription end. task-id: 4077820
Brazilian eCommerce orders can now automatically use the required EDI defaults for payment and delivery, reducing manual setup for consumer sales. The update also improves customer defaults, relocates Brazilian city data to the core Brazil localization, and refreshes translations for better consistency.
Original PR description
This adds default values for some EDI-specific fields on payment.method and delivery.carrier. They will be used automatically in the eCommerce flow. This also sets the appropriate default EDI values for B2C customers that create an account through eCommerce. B2B customers are supported but their EDI fields have to be manually configured in the backend. This is ok for now because in most cases B2B account creation is handled manually anyway. Brazilian cities are moved from l10n_br_avatax to l10n_br. The translations changed a lot because they were out of date and poorly maintained. Translations were generated from scratch. New terms were merged in properly with msgmerge (based on advice from TIC who redid the l10n_br translations in odoo/enterprise#67955). task-4061540
The Documents kanban view now loads spreadsheet thumbnails using a lightweight thumbnail checksum instead of reading large spreadsheet snapshot files. This noticeably speeds up opening folders with large spreadsheets, reducing wait times from around 1.4 seconds to about 35 milliseconds in the tested case.
Original PR description
In the Documents app, the `checksum` field can't be used has a "unique" value to invalidate browser cache when it changes. The reason is that the document attachment isn't actually changed when a new…
In the Documents app, the `checksum` field can't be used has a "unique" value to invalidate browser cache when it changes. The reason is that the document attachment isn't actually changed when a new spreadsheet revision is created The fix was to use the last revision uuid as this unique value. It has one major drawback though: if there is no active revision, the revision uuid is read from the snapshot, which is a json file which can be very large (tens or even hundreds of Mb). (see https://github.com/odoo/enterprise/commit/a055dfeb84abc34015b269422264534d97a83d8f) This is very slow. Before this commit, we use the checksum of the thumbnail. Open the Documents kanban with 8 relatively larges spreadsheets: - before: ~1.4s - after: ~35ms (5ms to compute `spreadsheet_thumbnail_checksum`) An alternative to the proposed solution here is to make `current_revision_uuid` faster by looking at inactive revisions instead of loading the json. But - the time complexity would grow linearly with the number of revisions - if there's no revisions at all (which happens when uploading a new spreadsheet file), the json still needs to be loaded. This idea is valid on its own, but is left for another commit, the field `current_revision_uuid` is not used in many situations anyway. Let's make the Documents kanban view faster in all cases. Task: 4193350
The purchase and vendor dashboards are now combined into a single clearer view, making it easier to review supplier-related performance in one place. The stock reporting experience is also improved by replacing Inventory Flow with a more useful Operation Analysis dashboard for monitoring operations.
Original PR description
Task: [4138346](https://www.odoo.com/web#id=4138346&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Project dashboard cards have been simplified across related apps to make them easier to read and maintain. The update uses newer standard interface components, improving consistency without changing core business workflows.
Original PR description
*hr_timesheet,sale_timesheet,documents_project,industry_fsm_report, project_account_budget In this commit we have simplified the kanban arch for the project module dashboard. the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of `<field/>` tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use `<field name=... widget=image/>` instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color=color_field_name on root node Task-3992107
The generic Profit and Loss report was updated to match Odoo's accounting cheat sheet and make totals easier to understand. This reduces confusion where some lines looked like summaries but did not add up their visible child lines.
Original PR description
Turns out that the previous version wasn't super intuitive, as a lot of feedback was pointing out: some of the report lines weren't summing their children, although it visually looked like they were (nonetheless the naming of these lines was accurate to what they were computing, as for the total). The old version was also different to what's in our own doc (at https://www.odoo.com/documentation/17.0/applications/finance/accounting/get_started/cheat_sheet.html). So to fix these, we adopted the same version as shown in our accounting cheat sheet.
The developer debug menu has been reorganized into clearer sections, with updated labels and ordering to make tools easier to find. The Data option now opens the JSON view for the current page, improving access to record details for troubleshooting.
Original PR description
This commit reworks the debug menu by organising the items by section, renaming some items and reordering them. The menu "Data" (previously "View Raw Record Data") now redirects to the /json route of the current view. task-4055746
WhatsApp setup menus and manual template-sending options are moved into a separate app, keeping the main WhatsApp module cleaner for users who only need simple invoice sending. Message replies and Discuss integration remain in the base WhatsApp module so incoming responses continue to work as before.
Original PR description
Users using our SAAS may want to simply send whatsapp invoices through whatsapp and not use their own account for anything fancy. We move the menus and views specific to setting up whatsapp and sending templates manually to a new module so that users won't have a bunch of menus they do not care about on SAAS. The discuss/replies integration remains in the base module as discuss is how responses are stored at all, and the technical module should still take care of responses. task-3645815
The manufacturing PLM and work order dashboards have been simplified to make their cards easier to read and maintain. This update modernizes the underlying layout components without changing core business workflows.
Original PR description
In this commit we have simplified the kanban arch for the mrp_plm and mrp_workorder module dashboard. the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of `<field/>` tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use `<field name=... widget=image/>` instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color=color_field_name on root node Task-3992107
The Planning-related kanban screens have been simplified to use newer, standard card layouts and styling. This should make the dashboard views easier to maintain and more consistent for users across Planning, Project Forecast, and Sales Planning.
Original PR description
In this commit we have simplified the kanban arch for the planning module dashboard. the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of `<field/>` tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use `<field name=... widget=image/>` instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color=color_field_name on root node Task-3992107
Avatar tag lists now show the remaining person’s avatar when only one item is hidden, rather than displaying a “+1” counter. This makes resource and user lists clearer at a glance and avoids unnecessary extra counting in the interface.
Original PR description
Before this commit, the user avatar tag list displayed the counter with +1 when there was only 1 tag left to display. Now, the last tag is displayed instead of the counter. This commit also renames the property `itemsVisible` to `visibleItemsLimit` to better reflect the purpose of this property. task-4134018
Cashiers can now leave the payment screen while a payment is still being processed, and the payment will continue in the background. This reduces interruptions at the point of sale and supports smoother handling of due settlements and Chilean electronic invoice payments.
Original PR description
Before it was not possible to leave the payment_screen during a payment. Now it is possible to leave the payment_screen and continue the payment in the background. taskId: 4128663
Indian tax reports now warn users when invoices with TDS or TCS taxes involve vendors or customers without a valid PAN. This helps businesses spot cases where higher withholding or collection rates may apply under Income Tax Act rules and quickly open the affected invoices.
Original PR description
Under Section 206AA/206AB of the Income Tax Act, 1961, if the PAN of a Vendor/Customer is unavailable, TDS/TCS should be at a higher rate. With this PR, if any invoices have TDS/TCS tax and their partner has empty/invalid PAN then a warning will be displayed with the action above report which redirects to all those invoices list view. **task**-4037680 related community PR: https://github.com/odoo/odoo/pull/172091
Enterprise accounting and localization features were updated to stay aligned with recent core changes for electronic document exchange between purchases and sales. This improves compatibility and performance for invoice and bill processing, with small related test updates for subscriptions.
Original PR description
This PR adapts the existing enterprise code to the community changes in `account` & `sale` made to introduce EDI from PO to SO. Community: odoo/odoo#172450 task-3791197
Customers can now pay subscriptions using payment methods that do not support saved payment details when online payment is required. If a subscription has no saved payment token for renewal, the system sends a payment reminder instead of creating an invoice automatically, helping avoid failed renewal flows and improving customer flexibility.
Original PR description
*= test_sale_subscription Before this commit, we only allow to pay subscription with payment methods which allow tokenization which can be used while auto renewal of subscription. after this commit, allow user to pay with non tokenize method if online payment is required. if no token on subscription then send user a payment reminder instead of creating invoice. task-3471687 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
Manufacturing planning now includes a ready-to-use spreadsheet template for importing Master Production Schedule data. This helps users test or prepare planning data more quickly using products that fit the standard demo setup, while avoiding conflicts with existing demo entries.
Original PR description
An XLSX import template for MPS that works with the default demo product data and doesn't clash with the MPS demo data. Partly relies on #68419 (f9989c3). Task ID: [4129558](https://www.odoo.com/odoo/project/966/tasks/4129558)
The Point of Sale flow now supports printing a basic receipt for gift transactions. This gives store staff more flexibility when handling gifts and improves the customer experience by providing an appropriate receipt format.
Original PR description
Enhanced the POS system by introducing a basic receipt option specifically for gift transactions. This allows users to easily print receipts for gift items, improving user experience and providing greater flexibility in handling various types of sales. Task ID: 4081593 related: https://github.com/odoo/odoo/pull/180459
The spreadsheet dashboard tests now verify that the correct first day of the week is used for each locale. This helps ensure date-based dashboard calculations remain consistent for users in different regions.
Original PR description
This commit is the counterpart of https://github.com/odoo/odoo/pull/180619 and updates the test to check the weekstart of the locale. Task: 4194152
Accounting users can now set dedicated accounts for inventory adjustments and scrap valuation from the Accounting configuration page. This helps businesses track these inventory movements more clearly and report their financial impact in the right accounts.
Original PR description
This commit enables users to specify two new accounts for inventory adjustment and scrap purposes. These accounts can be specified from the configuration page of the Accounting app. Task-4013809
Brazilian eCommerce orders can now use default electronic invoicing settings for payment and delivery, reducing manual setup for consumer sales. The update also improves Brazil localization data by moving city records into the core Brazil module and refreshing translations.
Original PR description
This adds default values for some EDI-specific fields on payment.method and delivery.carrier. They will be used automatically in the eCommerce flow. This also sets the appropriate default EDI values for B2C customers that create an account through eCommerce. B2B customers are supported but their EDI fields have to be manually configured in the backend. This is ok for now because in most cases B2B account creation is handled manually anyway. Brazilian cities are moved from l10n_br_avatax to l10n_br. The translations changed a lot because they were out of date and poorly maintained. Translations were generated from scratch. New terms were merged in properly with msgmerge (based on advice from TIC who redid the l10n_br translations in odoo/enterprise#67955). task-4061540 Part of the alternative "no zip ranges" approach. Alternative to https://github.com/odoo/enterprise/pull/68584, but unchanged from it.
Resolved issues and error corrections
Tax closing entries will no longer automatically receive default taxes from accounts marked for tax closing. This prevents validation errors in special accounting setups and helps tax closing proceed reliably.
Original PR description
Some special cases may require to have an account set as "used in tax closing" and at the same time having a default tax to improve usability. This would cause issues as the tax would be set on the line and trigger the _check_taxes_on_closing_entries constrains. This fix aim to mitigate that by ensure that _compute_tax_ids is not done on tax closing lines. task id # 3903331
This update improves Australian Single Touch Payroll finalisation and year-to-date zeroing so businesses can correctly update key employee or company reporting indicators. It helps ensure compliant submissions when prior payroll reporting needs to be reset or corrected.
Original PR description
This commit is a follow up to the previous PR# 65395. This commit updates the Finalisation and Zeoring of the YTD for a number of cases. This will allow users to submit a zeroed YTD to change the key indicators for the employee or the company.
Marketing automation activity relationships now display correctly in hierarchy views. This restores needed parent relationship information so users can understand how campaign activities connect to each other.
Original PR description
Since [1] the hierarchy kanban is missing the necessary parent data to be able to properly display hierarchies We add it back with a comment specifying it needs to remain task-4195978 1: d07574d2a286543c22072fa4ea338ff756242f21
This fix prevents errors when multiple attachments are processed together for Indian GSTR reporting. It improves reliability in setups that use Indian localization alongside accounting features, helping reports and related PDF attachments work as expected.
Original PR description
The method `_unwrap_edi_attachments` previously failed when `self` contained more than one record. This caused issues, particularly in the test `test_extend_with_attachments_multi_pdf` when both `l10n_in` and `account_accountant` modules were installed. The issue has been fixed by adding a loop to process each record in `self` individually and checking the `res_model` for each attachment within the file data. Fixes: https://runbot.odoo.com/web/#id=98056&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form
This fixes an error that could occur when Monster recruitment integration credentials are missing. Users will no longer be blocked by a data comparison issue in that situation, making the recruitment posting flow more reliable.
Original PR description
consteq needs to compare the same type of data so bool and str can't be compared FIX convert the bool to str before comparing task-4196102
The Knowledge app’s automated cover selection test was corrected after it checked for a button that was no longer relevant. This helps keep quality checks stable and makes future issues in this area easier to diagnose.
Original PR description
In this commit, we fix the knowledge_cover_selector_tour tour.
Actually, the step 41 makes no sense.
{
// Make the add cover button visible
trigger: '.o_knowledge_edit_cover_buttons',
},
We check for edit cover buttons but the cover was removed in previous
steps.
we take advantage of the commit to transform the comments into "content"
to make it easier to debug the tour.
We take advantage of this commit to lint the file.The Knowledge permission panel was updated so it no longer depends on jQuery, which may not always be available. This prevents errors when managing permissions and helps keep the feature compatible with newer platform standards.
Original PR description
This commit removes the soon-to-be deprecated JQuery from the PermissionPanel component. JQuery triggered errors inside the permission panel when it is not loaded, which can happen. This commit replaces all JQuery calls to a standard JS alternative. task-4193620
Miscellaneous changes
Steps to Reproduce the Bug: - Create two storable products, "P1" and "P2". - Create a Quality Point: - Product: P1 - Type: Manufacturing - Create a Quality Check: - Product: P2 - Select the Quality Point of P1 Problem: The product is updated to P1 instead of triggering a user error. opw-4030133 Forward-Port-Of: odoo/enterprise#69695 Forward-Port-Of: odoo/enterprise#69362
Original PR description
Steps to Reproduce the Bug: - Create two storable products, "P1" and "P2". - Create a Quality Point: - Product: P1 - Type: Manufacturing - Create a Quality Check: - Product: P2 - Select the Quality Point of P1 Problem: The product is updated to P1 instead of triggering a user error. opw-4030133 Forward-Port-Of: odoo/enterprise#69695 Forward-Port-Of: odoo/enterprise#69362
When the Appraisal of employee is archived and a user clicks on the Ongoing Appraisal button, a traceback will appear. Steps to reproduce the error: - Install ```hr_appraisal``` module - Create new employee > Click Request Appraisal > Save Appraisal > Archive that Appraisal - Go back to employee > Click on ```Ongoing Appraisal``` button Traceback: ``` Traceback (most recent call last): File "/home/odoo/odoo/community/odoo/http.py", line 2267, in __call__ response = request
Original PR description
When the Appraisal of employee is archived and a user clicks on the Ongoing Appraisal button, a traceback will appear. Steps to reproduce the error: - Install ```hr_appraisal``` module - Create new…
When the Appraisal of employee is archived and a user clicks on
the Ongoing Appraisal button, a traceback will appear.
Steps to reproduce the error:
- Install ```hr_appraisal``` module
- Create new employee > Click Request Appraisal > Save Appraisal >
Archive that Appraisal
- Go back to employee > Click on ```Ongoing Appraisal``` button
Traceback:
```
Traceback (most recent call last):
File "/home/odoo/odoo/community/odoo/http.py", line 2267, in __call__
response = request._serve_db()
File "/home/odoo/odoo/community/odoo/http.py", line 1842, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "/home/odoo/odoo/community/odoo/http.py", line 1862, in _transactioning
return service_model.retrying(func, env=self.env)
File "/home/odoo/odoo/community/odoo/service/model.py", line 134, in retrying
result = func()
File "/home/odoo/odoo/community/odoo/http.py", line 1840, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "/home/odoo/odoo/community/odoo/http.py", line 1847, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/odoo/community/odoo/http.py", line 2072, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/odoo/community/odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/odoo/community/odoo/http.py", line 774, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/odoo/community/addons/web/controllers/dataset.py", line 42, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/home/odoo/odoo/community/addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/odoo/community/odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "/home/odoo/odoo/enterprise/hr_appraisal/models/hr_employee_base.py", line 39, in action_open_last_appraisal
if len(relevant_appraisals) == 1:
UnboundLocalError: local variable 'relevant_appraisals' referenced before assignment
```
https://github.com/odoo/enterprise/blob/a9a3ece5c8ae5fa0b2fa117acb5dbedc69689478/hr_appraisal/models/hr_employee_base.py#L30-L37
When appraisal is archived, ```employee_appraisals``` will be empty,
So, eventually ```relevant_appraisals``` will be Empty.
So, it will lead to the above traceback.
sentry-5830582533
Forward-Port-Of: odoo/enterprise#69893**Steps to reproduce:** - Install Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Configure external trade according to: https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade - Make sure that USD has up-to-date rates - Create an external trade invoice: * Customer: [a US customer] (e.g. Deco Addict) * Currency: USD * Usage: Without fiscal effects * Incoterm: EX WORKS * Exter
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Configure external trade according to: https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade - Make sure that USD has up-to-date rates - Create an external trade invoice: * Customer: [a US customer] (e.g. Deco Addict) * Currency: USD * Usage: Without fiscal effects * Incoterm: EX WORKS * External Trade: Definitive - Confirm the invoice - Print the invoice **Issue:** In the external trade section of the invoice, there are 2 empty cells: "Operation Type" and "Subdivision". According to https://facture.com.mx/nuevo-complemento-comercio-exterior-2-0/ they both have been removed. opw-4078535 Forward-Port-Of: odoo/enterprise#70206 Forward-Port-Of: odoo/enterprise#70178
Patch the voip.ringtone service in all voip tests to avoid playing ringtones while tests are running. Forward-Port-Of: odoo/enterprise#70041
Original PR description
Patch the voip.ringtone service in all voip tests to avoid playing ringtones while tests are running. Forward-Port-Of: odoo/enterprise#70041
Before this PR: There are two problems: first, if you have a line discount like this: <img width="350" alt="Captura de pantalla 2024-03-27 a la(s) 09 48 55" src="https://github.com/odoo/enterprise/assets/382893/7564b133-c6e9-4bab-97f3-d8a0a2634fe5"> The calculation made by Odoo is: 319319 * 21.35 / 100 = 68175 which does not match the amount placed in "DescuentoMonto". In this case, it is 68173 (difference of 2 CLP) which is why it is better to prioritize the discount amount instead of the
Original PR description
Before this PR: There are two problems: first, if you have a line discount like this: <img width="350" alt="Captura de pantalla 2024-03-27 a la(s) 09 48 55"…
Before this PR: There are two problems: first, if you have a line discount like this: <img width="350" alt="Captura de pantalla 2024-03-27 a la(s) 09 48 55" src="https://github.com/odoo/enterprise/assets/382893/7564b133-c6e9-4bab-97f3-d8a0a2634fe5"> The calculation made by Odoo is: 319319 * 21.35 / 100 = 68175 which does not match the amount placed in "DescuentoMonto". In this case, it is 68173 (difference of 2 CLP) which is why it is better to prioritize the discount amount instead of the percentage in the XML, which is already rounding, leading to a problem. The second: if you have a surcharge in the line, like this: <img width="354" alt="Captura de pantalla 2024-03-27 a la(s) 09 52 40" src="https://github.com/odoo/enterprise/assets/382893/5a7ffa96-a2d9-498f-acf3-7003c95aa789"> Odoo ignores it. After the PR: The first issue is fixed by giving priority to the "DescuentoMonto" tag. The second issue is added as an improvement. Since Odoo does not have a column to show the surcharge separated in the line, we are taking advantage of the feature that supports negative discounts in the line to put that surcharge as negative. Forward-Port-Of: odoo/enterprise#65842 Forward-Port-Of: odoo/enterprise#59532
9 changes
New functionality added to Odoo
This update introduces a new feature to calculate and account for corporate tax obligations for UAE corporations. When a company's profits exceed a defined threshold, this system automatically generates the necessary tax reports, streamlining compliance processes. This addition ensures accurate tax reporting and adherence to local regulations.
Original PR description
When a corporation's annual net profits exceeds a certain limit, a corporate tax has to be paid. This commit implements the calculation and accounting of this corporate tax. task: 3690934
Enhancements to existing features
The subscription refresh button on the database expiration panel is now displayed as a clear text button instead of just an icon. This makes it easier for users to find and use the refresh action when their subscription has been renewed but the system hasn't updated yet, helping them quickly unblock their database without confusion.
Original PR description
For on premise instances, when the database expire and user renew its subscription, the update is not immediate; on the expiration panel there is a already a button to forcefully refresh the…
For on premise instances, when the database expire and user renew its subscription, the update is not immediate; on the expiration panel there is a already a button to forcefully refresh the subscription status and unblock the database, but it's not really visible (its not clear that the 'refresh' icon right next to "Renew your subscription" / "Upgrade your subscription" buttons is just to refresh the subscription status and not to re-do that action again). This commit now shows the 'Refresh subscription status' action as a textual button to make it more visible to users. [opw-3942907](https://www.odoo.com/odoo/project.task/3942907) Note: the goal is to introduce a slight [wording change](https://github.com/odoo/enterprise/compare/16.0...odoo-dev:enterprise:16.0-opw-3942907-exp-panel-increase-sub-refresh-act-visibility-xal#diff-915475ae004db6256f7efc2757edfead13697a1581ee8c609251b1bafdcf9d06R24) (cf ticket) in 16.0 and later forward port, we're not doing it for 15.0 as the translation is still loaded in db Forward-Port-Of: odoo/enterprise#70238 Forward-Port-Of: odoo/enterprise#65768
This update removes the "Create" and "Create and Edit" options from the Tax Grids list view within Journal Items. This streamlines the user interface by preventing accidental creation of tax grids from this view, ensuring tax grid management follows a more controlled workflow.
Original PR description
Remove "Create" and "Create and Edit" of Tax Grids in the list view of Journal Items. task: 4179612
Resolved issues and error corrections
This fix resolves an issue where the postage cost calculation for SnailMail follow-up letters was not being computed correctly. Previously, when sending follow-up notices to customers with multiple contacts, the system would incorrectly show only 1 stamp regardless of the actual number of letters being sent. This update ensures the cost calculation properly reflects the actual number of follow-up letters being processed.
Original PR description
Problem: The `snailmail_cost` field was not being computed because the compute method was not being called. Steps to reproduce: - Enable "SnailMail" in Settings. - Navigate to Accounting > Follow-up Reports. - Open a report. - Follow up on the report. - Observe that the stamps count is 1, even if the partner has multiple follow-up contacts. opw-4160083 Forward-Port-Of: odoo/enterprise#70236
Fixed a technical error that occurred when generating bank reconciliation reports for accounts with zero balances. The system was attempting an invalid mathematical calculation that caused the report to fail. This fix ensures the report generates successfully in all scenarios.
Original PR description
The issue: When we have entries that are linked to a bank statement with a balance of 0, this will lead to a division by zero error when generating a reconciliation report The Fix: check for the suspense balance value, if it is zero, then there is no need to compute the rate since zero divided by anything = 0 opw-3990116 Forward-Port-Of: odoo/enterprise#66603 Forward-Port-Of: odoo/enterprise#65095
This fix resolves an issue where manually changing a line's parent category in Account Reports would not update its position in the report display. The parent_id field has been removed from the editing interface since the hierarchy is already properly managed by the system's display widget, preventing confusion and incorrect report layouts.
Original PR description
### Steps to reproduce issue: 1. Go to _Accounting > Configuration > Account Reports_ 2. Select Balance Sheet and Add a line in it 3. Select the new line and give it ASSETS as parent_id 4. Go to Reporting > Balance Sheet 5. The new line is still at the end of the report ### Explanation: Lines have a `sequence` to sort them in the report. It is not computed to change along with `parent_id`, since the lines are supposed to be arranged through the `AccountReportListRenderer` widget. Because of it a line whose `parent_id` changes will not be placed correctly. ### Fix reasoning: The `parent_id` field will be removed from the view, the hierarchy is already shown in the widget. opw-4101282
Users were unable to upload image files when creating invoices in the Kenya EDI system due to a technical error. This fix resolves the issue by properly handling image file uploads, allowing users to attach images to invoices without encountering errors.
Original PR description
Currently, an exception is generated when the user tries to upload an image file for creating an invoice. error: `UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 0: invalid start byte` This is because below code line tries to load image context of uploaded image file. https://github.com/odoo/enterprise/blob/799b80d12680153a5ba42ee97501723ba38052b1/l10n_ke_edi_oscu/models/account_move.py#L567 This commit fixes the above issue by handling `UnicodeDecodeError` in `contextlib.suppress.` sentry-5757745777
Users with restricted access permissions were unable to download planning reports due to permission errors when accessing related sales order and project information. This fix grants the system temporary elevated access to retrieve the necessary data for report generation, allowing all authorized users to successfully download their planning reports.
Original PR description
- 17.0 ### Steps to reproduce: - Install sale_planning and project_forecast app. - Create a sale order with the planning product (e.g. Developer (Plan services)) and confirm it. - Create planning for that sale order and set resource (e.g. Marc demo) to it. - Click 'Publish & Send' button. - Set 'User: Own Documents Only' rights for the sales and 'User' or 'none' for the project and planning for Marc demo. - Login from that user and open the planning app. - Open assigned planning form view. - Print planning. ### Issue: - Traceback occurs of access right. ### Cause: - While downloading the report, it goes to access the "display_name" and "name" field of sale order line and project respectively that is computed in the _compute_display_name, but the user cannot access "sale.order.line" and "project" due to record rule. ### Solution: - Give access to the record by using sudo(). task-3978552
This fix prevents users from accidentally mismatching products when creating quality checks. Previously, if a user selected a quality point from a different product, the system would silently change the product instead of alerting them to the error. Now the system properly validates that the quality point and quality check must belong to the same product, protecting data integrity.
Original PR description
Steps to Reproduce the Bug: - Create two storable products, "P1" and "P2". - Create a Quality Point: - Product: P1 - Type: Manufacturing - Create a Quality Check: - Product: P2 - Select the Quality Point of P1 Problem: The product is updated to P1 instead of triggering a user error. opw-4030133 Forward-Port-Of: odoo/enterprise#69362