Thursday, October 31, 2024
49 changes · 18.0
Resolved issues and error corrections
This update adds missing internal labels to a website building block used in the numbers list section. It helps the website editor correctly identify and handle that element, reducing small editing inconsistencies without changing the visible page design.
Original PR description
This commit adds missing `data-snippet` and `data-name` attributes to the `s_hr` snippet used in the structure. task-4223179 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Links to uploaded web addresses are no longer treated like downloadable documents in the editor. This keeps the link options consistent, while real document links continue to open in a new window as intended.
Original PR description
Since [1] documents can be uploaded in links. All these attachments are considered as documents, even if they are URLs. The "Open in New Window" option is available for any link, while it should be forced to a new window for documents. This commit introduces the distinction between URL and non-URL attachments: only the non-URL attachments are now considered as documents. In order to make that information available when switching between links: - missing steps of `start` are now included when updating props - sequence of updating props is forced by putting it in a method The "Open in New Window" option is only visible for non-documents. Upon link update, documents are always open in new window and non-document are never download links. [1]: https://github.com/odoo/odoo/commit/cec6ee74de4b904b590d41140d99ae844ed1f15d task-4208243
This fix removes an editor option that could break the layout of the website numbers snippet when changing its column count. It helps website editors avoid accidentally creating a visually broken section.
Original PR description
Changing the amount of columns of this snippet from the dropdown in the editor makes the layout break. This commit prevent the user from doing that. task-4223179 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a flaky automated test for the website slides fullscreen editor by making it wait until the slide link is ready before clicking it. The change helps keep validation runs stable and reduces false failures during development.
Original PR description
The tour "full_screen_web_editor" is failing randomly on the runbot because the step that clicks on the "Home Gardening" slide doesn't open it in fullscreen (as seen in a screenshot of a failing runbot). It is very likely because the fullscreen parameter on the "Home Gardening" link is added afterward in javascript and is not yet present when it is clicked in the test (see function _updateHref of websiteSlidesCourseSlidesList widget). To solve the problem we change the selector that clicks on the "Home Gardening" link to ensure the fullscreen parameter is present in the link. Task-4222573
This fix prevents Point of Sale test tours from failing when a tour is not available in its specific asset bundle. It helps keep automated checks stable without changing day-to-day user behavior.
Original PR description
In Point of Sale module we didn't load all the javascript tour because this module use specific assets bundle. This commit fix the issue by verifying if the tour exist in the registry before trying to get it.
This update fixes an internal automated checkout test for Ecuador website sales after a recent platform change made one test setting invalid. It helps keep quality checks running correctly without changing the customer-facing shopping experience.
Original PR description
After odoo/odoo@45b90b8b7ce252e1558728f4fc03e52459817565 `test: true` is not a valid tour key anymore 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
When users add a link to an image while editing content inside a dialog, the link options now appear in front instead of being hidden behind the dialog. This prevents confusion and makes document layout editing smoother.
Original PR description
Problem: If a dialog is open and the link popover is triggered, it remains behind the dialog, creating further usability issues. Probem: The overlay items are displayed according to their `sequence` attribute, which determines their display order: https://github.com/odoo/odoo/blob/bb20a6d0b3c3a70edbc1f68f560be1f333379ede/addons/web/static/src/core/overlay/overlay_container.js#L65-L67 Solution: Increase the `sequence` value for the `LinkPopover` overlay, ensuring it appears on top of other overlays, including dialogs. Steps to reproduce: 1. Insert an image in the editor in Settings/Configure your document layout/Footer. 2. Click on the image and try to add a link. 3. Observe that the link popover is not visible. opw-4244308
Applying the stretch option to an image in the website editor no longer briefly shows an intermediate image. This creates a smoother editing experience and avoids visual distraction while content is being adjusted.
Original PR description
Before this PR: - An intermediate image was briefly visible when the stretch option was applied, causing a flickering effect. After this PR: - The intermediate image is no longer visible, eliminating the flickering issue. - A cloned image element is used during the processing of the actual image, ensuring that the intermediate image is hidden. task-4206947 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Documents app now keeps a display-layering rule limited to Documents screens instead of letting it affect other areas of Odoo. This prevents visual overlap issues elsewhere while preserving the intended dropdown behavior in Documents.
Original PR description
This PR fixes an issue about a `z-index` CSS property defined in Documents that is affecting the whole back-end and front-end environment as it is not scoped within a Documents related selector. While this CSS is actually needed if you have a dropdown with a `+ X` item at the end to prevent the button from being rendered under the view, it needs to be scoped to Documents only. We also take that opportunity to use the `SCSS` variable related to that `z-index` value. | 18.0 | This PR | |--------|--------| |  |  | task-4270185
The payment form now hides the journal entry shortcut from invoicing-only users. This avoids showing a confusing option that leads to limited accounting details they are not meant to use, while keeping it available for accounting users.
Original PR description
Steps to reproduce: - Install invoicing enterprise (but not accounting) - Register a payment on an invoice - open the form view of the payment When opening the payment form view, if the payment is associated with a journal entry, which can be accessed with the smart button. However, with invoicing enterprise, this button doesn't make sense because the user will only see the "other info" tab of the journal entry. We therefore limit the access to the button only for accounting users. task-4224553
An unused invoice data field was removed from the invoice screen because it could trigger access errors for users with sales permissions but without invoice rights. This prevents those users from being blocked by a field that was not needed for the interface or related behavior.
Original PR description
The field extract_word_ids is in the account move view but raises an access error when someone without invoice rights open the invoice (rights you have when you have some sales rights). As this field is not used in the view or in the associated JS, we can remove it and fix the access rights issues.
The Gantt view now displays the total row title centered as intended. This minor visual correction improves readability and gives users a more polished planning view.
Original PR description
This commit fixes a position issue with the total row title which should be center aligned. task-4251407
The Luxembourg payroll screens now better distinguish which employee information can be edited and which cannot. Contract index values are also shown correctly as non-monetary amounts, reducing confusion during payroll administration.
Original PR description
On the employee, we should clarify the view to tell what is editable or not. On the contract, the index is monetary but shouldn't.
This update fixes user assignment in Quality Point kanban cards and adds clearer help text in the manufacturing planning wizard. It helps teams assign quality responsibilities correctly and better understand planning fields when adding products.
Original PR description
Draft for a mixed bag of MRP bugfixes for post-freeze 18.0. 1. Fixed the responsible assignment button for Quality Points in the kanban view. 2. Added tooltips to the BoM and indirect demand fields of MPS wizard. Task ID: [4154879](https://www.odoo.com/odoo/966/tasks/4154879)
This fixes an internal automated test for the German POS certification module after a related platform change made the old test setting invalid. It helps keep quality checks reliable without changing day-to-day user functionality.
Original PR description
After odoo/odoo@45b90b8b7ce252e1558728f4fc03e52459817565 `test: true` is not a valid tour key anymore
The personal documents section now displays the “Existing file” label correctly beneath the related upload field. This prevents the label from blocking required document uploads and makes the form clearer for employees completing salary contract paperwork.
Original PR description
Before this commit there was an overlap between the "Existing file" label in the "Personal documents" section. The user was not able to click on these required inputs to upload his documents. Visually there was also a problem: the label was aligned weirdly. By replacing the "px-10" and "py-10" by "form-text", there is no overlap anymore, the user can click on the input file field and the label is nicely displayed under the related field with a relevant style (as intended in Bootstrap). <img width="1701" alt="Screenshot 2024-10-18 at 09 46 12" src="https://github.com/user-attachments/assets/fb70f99f-5524-4642-895d-30d515a07405"> 
Code cleanup and technical improvements
This update reorganizes how automated web tours handle their steps so the underlying automation system is easier to maintain. It also improves completion, error, and timeout handling, which should make automated guided flows and tests more reliable.
Original PR description
In this commit, we move the methods from tour_step_automatic to tour_automatique so that it better responds to the macro.js API. In the latter, we add an onComplete method and use the onError and onTimeout methods to handle errors that could occur in a tour. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
*l10n_din5008, l10n_din5008_purchase, l10n_din5008_repair, l10n_din5008_sale, l10n_din5008_stock Related to: https://github.com/odoo/enterprise/pull/71710 Forward-Port-Of: odoo/odoo#184790 Forward-Port-Of: odoo/odoo#183268
Original PR description
*l10n_din5008, l10n_din5008_purchase, l10n_din5008_repair, l10n_din5008_sale, l10n_din5008_stock Related to: https://github.com/odoo/enterprise/pull/71710 Forward-Port-Of: odoo/odoo#184790 Forward-Port-Of: odoo/odoo#183268
Before this PR, pressing the `Escape` key in an open thread action within the chat window would close the entire chat window rather than just the thread action. This PR fixes the issue by ensuring `Escape` closes only the active thread action. task-4290661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185874 Forward-Port-Of: odoo/odoo#185503
Original PR description
Before this PR, pressing the `Escape` key in an open thread action within the chat window would close the entire chat window rather than just the thread action. This PR fixes the issue by ensuring `Escape` closes only the active thread action. task-4290661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185874 Forward-Port-Of: odoo/odoo#185503
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.4.1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185965
Original PR description
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.4.1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185965
On small images, the actions to delete image is barely usable. In mobile, these actions are always shown, so they could even prevent clicking on attachment to view in dialog. Also on big a image the 2 actions are far away, which is can be exhausting. This commit fixes the issue by using a dropdown when there is more than 1 action or when the image is considered very small. Images visual is at most 75px width and height, so smaller images now show a background, which ensures image actions and
Original PR description
On small images, the actions to delete image is barely usable. In mobile, these actions are always shown, so they could even prevent clicking on attachment to view in dialog. Also on big a image the 2 actions are far away, which is can be exhausting. This commit fixes the issue by using a dropdown when there is more than 1 action or when the image is considered very small. Images visual is at most 75px width and height, so smaller images now show a background, which ensures image actions and clicking on image for preview are both reachable with ease, also added the required changes accordingly. task-3563828 Backport of: https://github.com/odoo/odoo/pull/180671 Forward-Port-Of: odoo/odoo#185605 Forward-Port-Of: odoo/odoo#185219
*product, event_product, event_booth_sale In the Appointment app, when trying to select an "Up-front payment product," products configured to create a task in a project are not available in the dropdown list. Cause of the issue: In the `appointment_type` model definition within the `appointment_account_payment` module, a domain was applied on the `product_id` field, restricting the selectable products. The domain filtered out products with the `service_tracking` field set to values other
Original PR description
*product, event_product, event_booth_sale In the Appointment app, when trying to select an "Up-front payment product," products configured to create a task in a project are not available in the…
*product, event_product, event_booth_sale In the Appointment app, when trying to select an "Up-front payment product," products configured to create a task in a project are not available in the dropdown list. Cause of the issue: In the `appointment_type` model definition within the `appointment_account_payment` module, a domain was applied on the `product_id` field, restricting the selectable products. The domain filtered out products with the `service_tracking` field set to values other than `"no"`. As a result, products that create tasks in projects (which have `service_tracking` set to `"task_global_project"`) were excluded. The commit https://github.com/odoo/enterprise/commit/ff54ff6cbdf79b1c24c468b5238d8eeb91e85cb9 aim was to prevent `event` and `event_booth` product to be selectable. This commit allows other product whose `service_tracking != 'no'` to be selectable while not allowing `event` and `event_booth`. opw-4146731 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185123
Currently, sending a Bis 3 xml on Peppol raises errors if an early payment discount is set on the invoice (the Belgian one: "Always (upon invoice)", for instance: "2/7 Net 30"). An example xml can be found in the attachments. It raises the error: ``` [BR-E-01]-An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is "Exempt from VAT" shall contain exactly one VAT breakdo
Original PR description
Currently, sending a Bis 3 xml on Peppol raises errors if an early payment discount is set on the invoice (the Belgian one: "Always (upon invoice)", for instance: "2/7 Net 30"). An example xml can be found in the attachments. It raises the error: ``` [BR-E-01]-An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is "Exempt from VAT" shall contain exactly one VAT breakdown (BG-23) with the VAT category code (BT-118) equal to "Exempt from VAT" ``` Looking at the documentation on [1], we realize we lack an additional VAT breakdown in the xml. [1] https://einvoice.belgium.be/en/article/business-expert-group-overview task-4283933 Forward-Port-Of: odoo/odoo#185138
…creating accrued revenue entries Problem: When using the generate accrued revenue entries action on a sale/purchase order where the first order line is a section or note leads to an invalid account move being created. The move contains a line with not account set. Purpose of this PR: To make sure only product lines are taken into account when generating these entries How to reproduce: 1) Create and confirm a sale order where the first order line is a section or note and the next con
Original PR description
…creating accrued revenue entries Problem: When using the generate accrued revenue entries action on a sale/purchase order where the first order line is a section or note leads to an invalid account move being created. The move contains a line with not account set. Purpose of this PR: To make sure only product lines are taken into account when generating these entries How to reproduce: 1) Create and confirm a sale order where the first order line is a section or note and the next contains a product 2) Run the Accrued Revenue Entry contextual action 3) Fill the Accrual Account and Amount fields with arbitrary data and hit Create Entry 4) Error appears, a move line is generated with no account --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183230
Currently, the invisible fields are considered in the export default fields. It doesn't make sense from a user perspective as those are generally technical fields used for computation. This wasn't the case prior to v17. The fix is to filter the invisible fields. task-4277023 Forward-Port-Of: odoo/odoo#185791 Forward-Port-Of: odoo/odoo#184719
Original PR description
Currently, the invisible fields are considered in the export default fields. It doesn't make sense from a user perspective as those are generally technical fields used for computation. This wasn't the case prior to v17. The fix is to filter the invisible fields. task-4277023 Forward-Port-Of: odoo/odoo#185791 Forward-Port-Of: odoo/odoo#184719
opw-3971513 Forward-Port-Of: odoo/odoo#181103
Original PR description
opw-3971513 Forward-Port-Of: odoo/odoo#181103
Have a parent company [PARENT] Create an invoice [INV1] Create a branch company [BRANCH] Create an invoice [INV2] for [BRANCH] company Go to invoice list view Select both companies Select both invoices Click 'Register Payment' Traceback ``` File "[...]/odoo/addons/base/models/res_company.py", line 405, in _accessible_branches return self.browse(self.__accessible_branches()) File "<decorator-gen-107>", line 2, in __accessible_branches File "[...]/odoo/tools/cache.py", lin
Original PR description
Have a parent company [PARENT]
Create an invoice [INV1]
Create a branch company [BRANCH]
Create an invoice [INV2] for [BRANCH] company
Go to invoice list view
Select both companies
Select both invoices
Click 'Register Payment'
Traceback
```
File "[...]/odoo/addons/base/models/res_company.py", line 405, in _accessible_branches
return self.browse(self.__accessible_branches())
File "<decorator-gen-107>", line 2, in __accessible_branches
File "[...]/odoo/tools/cache.py", line 97, in lookup
key = key0 + self.key(*args, **kwargs)
File "<string>", line 1, in <lambda>
File "[...]/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.company(2, 1)
```
opw-4027692
Forward-Port-Of: odoo/odoo#172792**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For example: * Unit per CLP: 0.001057876419 * CLP per Unit:945.29 - Create an invoice in USD with 2 lines having different amount: * 15.80 * 15.00 - Save the invoice - Print the invoice **Issue:** On the printed invoice, a slightly different currency rate is displayed for each invoice l
Original PR description
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For…
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For example: * Unit per CLP: 0.001057876419 * CLP per Unit:945.29 - Create an invoice in USD with 2 lines having different amount: * 15.80 * 15.00 - Save the invoice - Print the invoice **Issue:** On the printed invoice, a slightly different currency rate is displayed for each invoice line. **Cause:** The currency rate to display is computed for each invoice line, based on the following formula: `abs(self.balance) / self.price_subtotal` However, the value of balance is rounded to the unit because of the CLP currency and therefore it generates a different rate when trying to compute it. **Solution:** Compute the rate from the total values instead of the subtotal of each line. The real rate configured on the currency cannot be used because it can be modified after the creation of the invoice. opw-4242448 Linked enterprise PR: https://github.com/odoo/enterprise/pull/73035 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185230
Steps to reproduce (on runbot): 1. enable "extra hours" and add extra hours to an employee 2. as an admin go to management > time off 3. make a new time off and choose "extra hours" as the time off type 4. The duration of extra hours is duplicated The issue happens because the form view inherits two identical views. This commit removes the unnecessary view. task-4102491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o
Original PR description
Steps to reproduce (on runbot): 1. enable "extra hours" and add extra hours to an employee 2. as an admin go to management > time off 3. make a new time off and choose "extra hours" as the time off type 4. The duration of extra hours is duplicated The issue happens because the form view inherits two identical views. This commit removes the unnecessary view. task-4102491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185070 Forward-Port-Of: odoo/odoo#176929
Problem: Certain `ir.actions.act_window` actions contain a context with `active_id`, which causes issues when set as home actions, as `active_id` will not be defined in that context. Solution: Prevent the selection of actions that include `active_id` in their context from being set as home actions. Steps to reproduce: 1. Enable debug mode. 2. Navigate to `Settings / Users & Companies / Users`. 3. Select the current user from the list. 4. Under Preferences / Menus Customization set "H
Original PR description
Problem: Certain `ir.actions.act_window` actions contain a context with `active_id`, which causes issues when set as home actions, as `active_id` will not be defined in that context. Solution: Prevent the selection of actions that include `active_id` in their context from being set as home actions. Steps to reproduce: 1. Enable debug mode. 2. Navigate to `Settings / Users & Companies / Users`. 3. Select the current user from the list. 4. Under Preferences / Menus Customization set "Home Action" to "Quotations and Sales." 5. After that: each time you go to backend homepage (/) you get a traceback error instead of the app dashboard opw-4283156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185867 Forward-Port-Of: odoo/odoo#185319
**Description of the issue/feature this PR addresses:** It is needed to be able to create Factura B for a foreign customer. Legal reference: Here is some useful documentation : https://servicioscf.afip.gob.ar/publico/abc/ABCpaso2.aspx?id=8555970 https://www.afip.gob.ar/EspaciosdeDialogoInstitucional/documentos/Acta-15-Espacio-de-Dialogo-AFIP-Camaras-Empresariales-14-11.pdf **Current behavior before PR:** It is not possible to create Factura B for a foreign customer. **Desired b
Original PR description
**Description of the issue/feature this PR addresses:** It is needed to be able to create Factura B for a foreign customer. Legal reference: Here is some useful documentation : https://servicioscf.afip.gob.ar/publico/abc/ABCpaso2.aspx?id=8555970 https://www.afip.gob.ar/EspaciosdeDialogoInstitucional/documentos/Acta-15-Espacio-de-Dialogo-AFIP-Camaras-Empresariales-14-11.pdf **Current behavior before PR:** It is not possible to create Factura B for a foreign customer. **Desired behavior after PR is merged:** It is possible to create Factura B for a foreign customer. Task Adhoc side: 30008 Task latam side: 913 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185160 Forward-Port-Of: odoo/odoo#176604
The bus service uses a shared worker to reduce the number of connections to the server. However, debugging the worker state can be challenging. If the shared worker is opened later, the WebSocket does not appear in the network tab. Additionally, the worker manages multiple tab and network states, which are not easy to visualize. This commit adds debug logs to the WebSocket worker to track communication between the client and worker, as well as between the worker and server. The log i
Original PR description
The bus service uses a shared worker to reduce the number of connections to the server. However, debugging the worker state can be challenging. If the shared worker is opened later, the WebSocket does not appear in the network tab. Additionally, the worker manages multiple tab and network states, which are not easy to visualize. This commit adds debug logs to the WebSocket worker to track communication between the client and worker, as well as between the worker and server. The log is done by each tab because Safari does not provide devtools for the shared worker. As a result, logs would be unreachable. It's easier to access the logs from the tab devtools. Forward-Port-Of: odoo/odoo#185801
In Mexican (or Colombian) e-commerce websites, a customer may face an issue where they are unable to confirm an order because no delivery method is selected. ### Steps to reproduce - Install `l10n_mx_edi_website_sale` - Ensure the website is configured with a Mexican company - Enable 'Automatic Invoice' in website settings - As a public user, proceed through checkout and try to confirm the order The issue occurs if the user is prompted to fill in delivery information and hasn't previ
Original PR description
In Mexican (or Colombian) e-commerce websites, a customer may face an issue where they are unable to confirm an order because no delivery method is selected. ### Steps to reproduce - Install…
In Mexican (or Colombian) e-commerce websites, a customer may face an issue where they are unable to confirm an order because no delivery method is selected. ### Steps to reproduce - Install `l10n_mx_edi_website_sale` - Ensure the website is configured with a Mexican company - Enable 'Automatic Invoice' in website settings - As a public user, proceed through checkout and try to confirm the order The issue occurs if the user is prompted to fill in delivery information and hasn't previously provided an address. This can be consistently reproduced using a new incognito session. Upon attempting to confirm the order, the following error is shown: "No shipping method is selected." ### Cause The delivery information form (`/shop/address/submit`) normally redirects to `/shop/checkout`, where the user selects a delivery method. However, the `_get_extra_billing_info_route` hook can alter the redirect, bypassing the checkout step and causing the delivery method to remain unset. opw-4205135 opw-4222398 Forward-Port-Of: odoo/odoo#184098
When guessing the language at install (or upgrade) we cannot trigger a pre-fetch of all fields of `res.company` because some of its columns may be not initialized yet. One way to trigger this behaviour is to add a stored field whose default value uses translations, while at the same time adding any other stored field. If the translation is fetched in a sudo environment we can get an error when the System partner has `NULL` language. Steps to reproduce: 1. On a cleanly initialized DB (only `b
Original PR description
When guessing the language at install (or upgrade) we cannot trigger a pre-fetch of all fields of `res.company` because some of its columns may be not initialized yet. One way to trigger this…
When guessing the language at install (or upgrade) we cannot trigger a pre-fetch of all fields of `res.company` because some of its columns may be not initialized yet. One way to trigger this behaviour is to add a stored field whose default value uses translations, while at the same time adding any other stored field. If the translation is fetched in a sudo environment we can get an error when the System partner has `NULL` language.
Steps to reproduce:
1. On a cleanly initialized DB (only `base`) add any extra language (en_GB would do).
2. Open Users & Companies (show inactive users) open System user.
3. Open Related Partner.
3. In the form view of the System partner set the language to None.
4. Try to install via the command line a module with the fields as described above (see below for a code example).
We get an error like:
```
2024-10-30 08:48:40,831 41180 INFO test_16 odoo.modules.registry: module mymodule: creating or updating database tables
2024-10-30 08:48:40,839 41180 ERROR test_16 odoo.sql_db: bad query: SELECT "res_company"."id" AS "id", "res_company"."name" AS "name"
... <many more fields, redacted> ... "res_company"."bar" AS "bar", "res_company"."foo" AS "foo" FROM "res_company" WHERE "res_company".id IN (1)
ERROR: column res_company.foo does not exist
LINE 1: ...e" AS "write_date", "res_company"."bar" AS "bar", "res_compa...
```
The solution we propose is to skip the prefetch of `res.company` fields when we are in the process of guessing the language. In this case the language is correctly picked from the System partner's company.
This issue has been observed in many upgrades to 18, but it's present in older Odoo versions as well. The language field in `res.partner` is not required, thus it is also possible to set the language to `NULL` via code.
Example data observed in upgrades:
```
> select id,name,active,lang from res_partner where lang is null
+----+-----------------------+--------+--------+
| id | name | active | lang |
|----+-----------------------+--------+--------|
| 4 | Public user | False | <null> |
| 5 | Default User Template | False | <null> |
| 6 | Portal User Template | False | <null> |
| 2 | System | False | <null> |
+----+-----------------------+--------+--------+
```
There may be other standard flows that lead to such setup where System partner has no language set.
Example inherit of `res.company` that triggers the issue:
```py
class A(models.Model):
_inherit = "res.company"
bar = fields.Many2one(
comodel_name="ir.sequence",
default=lambda self: self.env["ir.sequence"].sudo().create({"name": _("Dummy")}),
required=True,
)
foo = fields.Integer()
```
Standard example of this code pattern that triggers the issue during upgrades to 18:
https://github.com/odoo/odoo/blob/dd71d998/addons/account/models/company.py#L140-L152
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#185810There was a typo in the test, which was breaking tests when they ran without demo data. This commit fixes it. [broken test builds](https://runbot.odoo.com/web#id=56563&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) Forward-Port-Of: odoo/odoo#185659
Original PR description
There was a typo in the test, which was breaking tests when they ran without demo data. This commit fixes it. [broken test builds](https://runbot.odoo.com/web#id=56563&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) Forward-Port-Of: odoo/odoo#185659
Steps to reproduce: - New Project > New Task > Timesheet 10h on task - New subtask on task > Timesheet 5h on subtask - Reporting > Tasks Analysis Remaining hours are computed incorrectly, when no allocated hours are set on a task, we have null values in database that prevent the computation of allocated_hours and remaining_hours which also messes up the project totals. The computation of remaining hours is also only supposed to occur when we have a non zero amount of allocated hours,
Original PR description
Steps to reproduce: - New Project > New Task > Timesheet 10h on task - New subtask on task > Timesheet 5h on subtask - Reporting > Tasks Analysis Remaining hours are computed incorrectly, when no…
Steps to reproduce: - New Project > New Task > Timesheet 10h on task - New subtask on task > Timesheet 5h on subtask - Reporting > Tasks Analysis Remaining hours are computed incorrectly, when no allocated hours are set on a task, we have null values in database that prevent the computation of allocated_hours and remaining_hours which also messes up the project totals. The computation of remaining hours is also only supposed to occur when we have a non zero amount of allocated hours, otherwise the remaining hours are always 0. Additionally, the 'Total Hours' column is confusing for customers as it is meant to compute the total hours spent on a task (subtasks included) but is enabled by default when looking at the projects as a whole which does not make sense. For instance, with 'Task' parent of 'Subtask': | Name | Allocated | Hours spent | Remaining | Total Hours | | -------- | --------- | ----------- | ---------- | ----------- | | Project | 0 | 15 | -15 (-> 0) | 20 | | Task | 0 | 10 | -10 (-> 0) | 15 | | Subtask | 0 | 5 | -5 (-> 0) | 5 | The sum of total hours on project is meaningless and confusing so it is preferable not to have it enabled by default (Subtask is counted twice, once in Task and once itself). opw-4236984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185733 Forward-Port-Of: odoo/odoo#184291
When downloading a url type attachment, it will not open in a new tab and breaks the activity of the current tab,such as rtc call and breadcrumbs. To reproduce the error: Project > Task > click on the url attachment > open in the current tab, the breadcrumbs (previous filters) will be lost This commit fixes the issue by opening the url attachment in a new tab. And "downloading" a url does not make sense, so the download button is replaced by an open button. --- I confirm I have signed
Original PR description
When downloading a url type attachment, it will not open in a new tab and breaks the activity of the current tab,such as rtc call and breadcrumbs. To reproduce the error: Project > Task > click on the url attachment > open in the current tab, the breadcrumbs (previous filters) will be lost This commit fixes the issue by opening the url attachment in a new tab. And "downloading" a url does not make sense, so the download button is replaced by an open button. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185636 Forward-Port-Of: odoo/odoo#184264
The invoice prints the "Shipping address" instead of the "Invoicing and shipping address." Commit 6d36b38 moved `l10n_din5008` formatting logic from Python to XML, but the values were not set properly. Setting the `t-value` will resolve this issue. To reproduce: 1. Create an invoice. 2. Assign an individual customer that has its company set. 3. Print it. <details> <summary>Click here to see</summary> Before: <img src="https://github.com/user-attachments/assets/4eb54685
Original PR description
The invoice prints the "Shipping address" instead of the "Invoicing and shipping address."
Commit 6d36b38 moved `l10n_din5008` formatting logic from Python to XML, but the values were not set properly. Setting the `t-value` will resolve this issue.
To reproduce:
1. Create an invoice.
2. Assign an individual customer that has its company set.
3. Print it.
<details>
<summary>Click here to see</summary>
Before:
<img src="https://github.com/user-attachments/assets/4eb54685-f906-4c29-87b3-70015ca84b9a"/>
After:
<img src="https://github.com/user-attachments/assets/1889a202-420f-4128-aeb6-a47fc9cd3a2e"/>
</details>
upg-2092611
opw-4209922
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#182538*l10n_din5008_account_followup,l10n_din5008_industry_fsm, l10n_din5008_sale_renting Related to https://github.com/odoo/odoo/pull/184790 Forward-Port-Of: odoo/enterprise#72707
Original PR description
*l10n_din5008_account_followup,l10n_din5008_industry_fsm, l10n_din5008_sale_renting Related to https://github.com/odoo/odoo/pull/184790 Forward-Port-Of: odoo/enterprise#72707
In the Appointment app, when trying to select an "Up-front payment product," products configured to create a task in a project are not available in the dropdown list. Cause of the issue: In the `appointment_type` model definition within the `appointment_account_payment` module, a domain was applied on the `product_id` field, restricting the selectable products. The domain filtered out products with the `service_tracking` field set to values other than `"no"`. As a result, products that creat
Original PR description
In the Appointment app, when trying to select an "Up-front payment product," products configured to create a task in a project are not available in the dropdown list. Cause of the issue: In the `appointment_type` model definition within the `appointment_account_payment` module, a domain was applied on the `product_id` field, restricting the selectable products. The domain filtered out products with the `service_tracking` field set to values other than `"no"`. As a result, products that create tasks in projects (which have `service_tracking` set to `"task_global_project"`) were excluded. The commit https://github.com/odoo/enterprise/commit/ff54ff6cbdf79b1c24c468b5238d8eeb91e85cb9 aim was to prevent `event` and `event_booth` product to be selectable. This commit allows other product whose `service_tracking != 'no'` to be selectable while not allowing `event` and `event_booth`. opw-4146731 Forward-Port-Of: odoo/enterprise#71166
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For example: * Unit per CLP: 0.001057876419 * CLP per Unit:945.29 - Create an invoice in USD with 2 lines having different amount: * 15.80 * 15.00 - Save the invoice - Print the invoice **Issue:** On the printed invoice, a slightly different currency rate is displayed for each invoice l
Original PR description
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For…
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For example: * Unit per CLP: 0.001057876419 * CLP per Unit:945.29 - Create an invoice in USD with 2 lines having different amount: * 15.80 * 15.00 - Save the invoice - Print the invoice **Issue:** On the printed invoice, a slightly different currency rate is displayed for each invoice line. **Cause:** The currency rate to display is computed for each invoice line, based on the following formula: abs(self.balance) / self.price_subtotal However, the value of balance is rounded to the unit because of the CLP currency and therefore it generates a different rate when trying to compute it. **Solution:** Compute the rate from the total values instead of the subtotal of each line. The real rate configured on the currency cannot be used because it can be modified after the creation of the invoice. opw-4242448 Linked community PR: https://github.com/odoo/odoo/pull/185230 Forward-Port-Of: odoo/enterprise#73035
This partially redoes odoo/enterprise#64900. Copying tax_ids from the sale order lines to the down payment line on the invoice doesn't work for external tax calculators. Tax percentages returned by tax calculators are only informational. When they return e.g. 5% tax, the actual amount can be different from 5% because of differences in rounding or (partial) exemptions. The authoritative tax is returned as a value amount (e.g. $10). Because of this, we cannot rely on Odoo to calculate the tax from
Original PR description
This partially redoes odoo/enterprise#64900. Copying tax_ids from the sale order lines to the down payment line on the invoice doesn't work for external tax calculators. Tax percentages returned by…
This partially redoes odoo/enterprise#64900. Copying tax_ids from the sale order lines to the down payment line on the invoice doesn't work for external tax calculators. Tax percentages returned by tax calculators are only informational. When they return e.g. 5% tax, the actual amount can be different from 5% because of differences in rounding or (partial) exemptions. The authoritative tax is returned as a value amount (e.g. $10). Because of this, we cannot rely on Odoo to calculate the tax from account.tax records. It's not always going to match. It's not possible to fix this by externally calculating taxes on the down payment invoice. The single down payment line cannot accomodate all different tax categories. Creating a down payment line per tax category (e.g. avatax_category_id) was considered, but a specific down payment product would need to be created per used tax category which would clutter the database. On top of that, down payment products are removed in later versions [1] which would complicate this approach even further. This solves the issue by not calculating taxes on down payments at all. The down payment invoice will not be sent to external tax calculators. The resulting down payment lines on the SO won't have taxes set, and those lines will be excluded from the request to the external tax calculator. The final, "regular invoice" transaction will happen as if no down payments were made. The down payment lines won't be sent, so this will look like a regular invoice from the external calculator's view. By default, the downpayment lines equal the subtotal of the selected down payment amount. We remove tax_ids from the lines because we cannot count on calculating tax locally (see above). To keep the behavior analogous we override the downpayment wizard to create a single down payment line with a total equal to the entered total in the wizard. [1] odoo/odoo@9aa52dd6418e5881adc2d96d15d062b55d6150c5 opw-3971513 Forward-Port-Of: odoo/enterprise#73027 Forward-Port-Of: odoo/enterprise#70517
To reproduce: 1) Activate storno accounting in the settings 2) Create a new partner 3) Create a Vendor Credit Note for that partner, post it 4) Register a full payment for the credit note 5) Open the Aged Payable report ====> The partner appears in the report, even though it has an amount of 0. It shouldn't, since there is no open amount for it. This was due to the way we checked the amount of the credit note was zero. In storno, the payable line of the refund is a negative credit inst
Original PR description
To reproduce: 1) Activate storno accounting in the settings 2) Create a new partner 3) Create a Vendor Credit Note for that partner, post it 4) Register a full payment for the credit note 5) Open the Aged Payable report ====> The partner appears in the report, even though it has an amount of 0. It shouldn't, since there is no open amount for it. This was due to the way we checked the amount of the credit note was zero. In storno, the payable line of the refund is a negative credit instead of being a debit. Still, it's linked through the debit_move_id field to the partial reconcile. So, removing the debit from the debit or credit from the credit wasn't enough in that setup. opw-4166891 Forward-Port-Of: odoo/enterprise#72827 Forward-Port-Of: odoo/enterprise#72422
Collection of small shop floor fixes for v17. Please refer to the individual feature commits for details. Forward-Port-Of: odoo/enterprise#73062 Forward-Port-Of: odoo/enterprise#70704
Original PR description
Collection of small shop floor fixes for v17. Please refer to the individual feature commits for details. Forward-Port-Of: odoo/enterprise#73062 Forward-Port-Of: odoo/enterprise#70704
Steps ----- - Install timesheet_grid - Set monday as the first day of the week in the language settings - Set the timezone of the user's working schedule to a more advanced timezone, e.g. UTC+10 - Go to Timesheets and add some hours on monday -> The under/over time is calculated relative to a lower number of hours than the real number of working hours for that day. Cause ----- `get_daily_working_hours` uses UTC's start/end of day for the start and end of the period, causing some workin
Original PR description
Steps ----- - Install timesheet_grid - Set monday as the first day of the week in the language settings - Set the timezone of the user's working schedule to a more advanced timezone, e.g. UTC+10 - Go to Timesheets and add some hours on monday -> The under/over time is calculated relative to a lower number of hours than the real number of working hours for that day. Cause ----- `get_daily_working_hours` uses UTC's start/end of day for the start and end of the period, causing some working hours near the start/end of the period to be missed. opw-4163183 Forward-Port-Of: odoo/enterprise#73010 Forward-Port-Of: odoo/enterprise#72526
Versions: ------------ 17.0 Steps to Reproduce: ----------------------------- 1. go to sign document 2. add sign item in document 3. click on sign document now 4. click on start seems be not working properly 5. video link: https://nimb.ws/WKMlFjB Issue: ------- stacking order of sign item navigator seems to be low Solution: ------------ increase z-index value of `o_sign_sign_item_navigator`. task-4191542 Forward-Port-Of: odoo/enterprise#70170
Original PR description
Versions: ------------ 17.0 Steps to Reproduce: ----------------------------- 1. go to sign document 2. add sign item in document 3. click on sign document now 4. click on start seems be not working properly 5. video link: https://nimb.ws/WKMlFjB Issue: ------- stacking order of sign item navigator seems to be low Solution: ------------ increase z-index value of `o_sign_sign_item_navigator`. task-4191542 Forward-Port-Of: odoo/enterprise#70170
The SLA success rate was previously being computed using the entire history of closed tickets as the domain. This is contrary to the expected behavior, given the helper text on Odoo and the list view of tickets that opens up if you click the percentage. This commit changes the domain to only consider tickets that were closed in the last 7 days. To reproduce on Runbot, follow the steps laid out here, as the process involves forcing tickets to fail and be older than 7 days closed: htt
Original PR description
The SLA success rate was previously being computed using the entire history of closed tickets as the domain. This is contrary to the expected behavior, given the helper text on Odoo and the list view of tickets that opens up if you click the percentage. This commit changes the domain to only consider tickets that were closed in the last 7 days. To reproduce on Runbot, follow the steps laid out here, as the process involves forcing tickets to fail and be older than 7 days closed: https://www.odoo.com/odoo/49/tasks/4206255 opw-4206255 Forward-Port-Of: odoo/enterprise#71600
Steps: Create a ticket with no partner. Click on 'Plan Intervention'. The modal opens. Issue: See that a partner "@" has been created and set. Cause: Clicking on the button calls `action_generate_fsm_task`, which calls `_find_or_create_partner`, but the args, `self.partner_name` and `self.partner_email`, are empty. Solution: Not try to create a partner when the fields both empty. task-4265584 Forward-Port-Of: odoo/enterprise#72304
Original PR description
Steps: Create a ticket with no partner. Click on 'Plan Intervention'. The modal opens. Issue: See that a partner "@" has been created and set. Cause: Clicking on the button calls `action_generate_fsm_task`, which calls `_find_or_create_partner`, but the args, `self.partner_name` and `self.partner_email`, are empty. Solution: Not try to create a partner when the fields both empty. task-4265584 Forward-Port-Of: odoo/enterprise#72304
### Description of the issue/feature this PR addresses: It is needed to be able to create Factura B for a foreign customer. Legal reference: Here is some useful documentation : https://servicioscf.afip.gob.ar/publico/abc/ABCpaso2.aspx?id=8555970 https://www.afip.gob.ar/EspaciosdeDialogoInstitucional/documentos/Acta-15-Espacio-de-Dialogo-AFIP-Camaras-Empresariales-14-11.pdf ### Current behavior before PR: It is not possible to create Factura B for a foreign customer. ### Desired
Original PR description
### Description of the issue/feature this PR addresses: It is needed to be able to create Factura B for a foreign customer. Legal reference: Here is some useful documentation : https://servicioscf.afip.gob.ar/publico/abc/ABCpaso2.aspx?id=8555970 https://www.afip.gob.ar/EspaciosdeDialogoInstitucional/documentos/Acta-15-Espacio-de-Dialogo-AFIP-Camaras-Empresariales-14-11.pdf ### Current behavior before PR: It is not possible to create Factura B for a foreign customer. ### Desired behavior after PR is merged: It is possible to create Factura B for a foreign customer. Task Adhoc side: 30008 Task latam side: 913 Forward-Port-Of: odoo/enterprise#72728 Forward-Port-Of: odoo/enterprise#71562