Daily updates from Odoo
Friday, May 17, 2024
19 changes · master
Enhancements to existing features
This update adds clearer internal labels to the Mexican electronic invoicing report fields for product code and unit code. It helps teams and implementers customize invoice layouts more reliably without changing the visible invoice content.
Original PR description
Inside the `l10n_mx_edi.report_invoice_document` report, it is difficult to locate the `<th/>` and `<td/>` tags associated with "Unit code" and "Product code" headers and values using xpaths. This fix aims to make this easier by adding name attributes to both
Bank statement CSV files can now be imported when their transactions are ordered from newest to oldest. This helps businesses use files from banks that export statements in descending date order without manually reordering them first.
Original PR description
This commit added the option to import bank lines ordered by dates in descending order. Before that, only ascending order of lines by dates was accepted. Some banks provide csv files that are sorted by date descendingly. task-3839831
The deferred entries list has been simplified by removing unnecessary columns, making it easier for accounting users to focus on the information they need. This improves day-to-day navigation and reduces visual clutter without changing accounting behavior.
Original PR description
The current tree view is polluted with useless columns. This commit cleans it up. task-id 3928442
Inventory reporting labels and menus were adjusted to make them clearer and better organized. The recurring product filter now uses simpler wording, and the Performance report menu is placed under technical features so business users see a cleaner reporting menu.
Original PR description
In this commit: ================== - Rephrased 'Can be Recurring' to 'Recurring' in product views filters. - Under Reporting/Performance : - Moved the 'Performance' menu to technical features for better categorization. task-3721429
The appointment leave management wizard no longer uses a separate resource calendar field. This streamlines the leave setup flow and reduces confusion for users managing appointment availability.
Original PR description
Remove and clean the use of a resource calendar in the appointment manage leaves wizard. Follow-up of odoo/enterprise#56617 task-3773104
Documentation links in several Odoo Enterprise screens now use a version-aware link widget instead of fixed links to a specific documentation version. This reduces maintenance work across releases and helps users land on the correct documentation for the Odoo version they are using.
Original PR description
Before this commit, in many views the links to the documentation was a absolute link to a given version of the documentation. Because of that, the links had to be changed for each version of Odoo. After this commit, most of the link to the documentation use a widget with a relative link that will be adpted with the current version odoo running on the server. task-id: 3605445
Miscellaneous changes
Before this commit: We restrict the user to delete GST Return Period record once the transaction has been initiated with the government server to maintain the consistency After this commit: In some special case i.e. for demo/bad record we might want to delete the GST Return Period with help of `force_delete` context it can be easily done in the special cases task-3930638 Forward-Port-Of: odoo/enterprise#62562
Original PR description
Before this commit: We restrict the user to delete GST Return Period record once the transaction has been initiated with the government server to maintain the consistency After this commit: In some special case i.e. for demo/bad record we might want to delete the GST Return Period with help of `force_delete` context it can be easily done in the special cases task-3930638 Forward-Port-Of: odoo/enterprise#62562
Issue: - Previously, the `_getDefaultFilterLabel()` method overridden, but mistakenly called the `_getEmptyGroupLabel()` method from the superclass, causing traceback errors. Fix: - This commit fixes the issue by calling the correct superclass method, `_getDefaultFilterLabel()`. Effect of the commit:https://github.com/odoo/enterprise/commit/8382bf4dc94139bd9eb44eb0907bb1b991a0e3b2# Forward-Port-Of: odoo/enterprise#62714
Original PR description
Issue: - Previously, the `_getDefaultFilterLabel()` method overridden, but mistakenly called the `_getEmptyGroupLabel()` method from the superclass, causing traceback errors. Fix: - This commit fixes the issue by calling the correct superclass method, `_getDefaultFilterLabel()`. Effect of the commit:https://github.com/odoo/enterprise/commit/8382bf4dc94139bd9eb44eb0907bb1b991a0e3b2# Forward-Port-Of: odoo/enterprise#62714
The tests were failing because the TPAR report was working correctly beause all TPAR taxes were inactive. They need to be set active before using. Task# 3782518 Forward-Port-Of: odoo/enterprise#62702 Forward-Port-Of: odoo/enterprise#62697
Original PR description
The tests were failing because the TPAR report was working correctly beause all TPAR taxes were inactive. They need to be set active before using. Task# 3782518 Forward-Port-Of: odoo/enterprise#62702 Forward-Port-Of: odoo/enterprise#62697
When typing in the softphone's search bar, the search result doesn't appear immediately; the user has to press Enter to make it happen. This is because the input field uses the t-model directive with the trim modifier. The trim modifier silently switches the directive to lazy mode, meaning that the content of the field is updated whenever the onchange event is fired instead of oninput. This commit removes the trim modifier to fix the problem. opw-3890028 Forward-Port-Of: odoo/enterprise#6
Original PR description
When typing in the softphone's search bar, the search result doesn't appear immediately; the user has to press Enter to make it happen. This is because the input field uses the t-model directive with the trim modifier. The trim modifier silently switches the directive to lazy mode, meaning that the content of the field is updated whenever the onchange event is fired instead of oninput. This commit removes the trim modifier to fix the problem. opw-3890028 Forward-Port-Of: odoo/enterprise#62379 Forward-Port-Of: odoo/enterprise#62125
**Steps** [website_sale_subscription] - Settings > Website, set "Add to Cart" behaviour to "Go to cart" - Create a recurring product with only one recurring price. - Go to shop, choose the recurring product and try to add it to the cart ** Error 500 ** **Issue** In case there's only one plan, no menu to select a plan is displayed and plan_id is NaN in that case. https://github.com/odoo/enterprise/blob/7d160198be779095660e7f6fb68ae231e4621972/website_sale_subscription/static/src/js/websi
Original PR description
**Steps** [website_sale_subscription] - Settings > Website, set "Add to Cart" behaviour to "Go to cart" - Create a recurring product with only one recurring price. - Go to shop, choose the recurring product and try to add it to the cart ** Error 500 ** **Issue** In case there's only one plan, no menu to select a plan is displayed and plan_id is NaN in that case. https://github.com/odoo/enterprise/blob/7d160198be779095660e7f6fb68ae231e4621972/website_sale_subscription/static/src/js/website_sale_subscription.js#L15 Which is going to be problematic later https://github.com/odoo/enterprise/blob/7d160198be779095660e7f6fb68ae231e4621972/website_sale_subscription/models/sale_order.py#L21 introduced by 7d160198be779095660e7f6fb68ae231e4621972 **Fix** We do not pass a plan_id if there's only one existing plan and use the fallback. opw-3891366 Forward-Port-Of: odoo/enterprise#62038
When the user quits a unfinished picking, the reservation on the move lines are lost. To avoid that, uncompleted moves will be split in such case. For example: - Assume we have a move of 0/15; - The user picks 4 qty (4/15) then exit the picking: => Before this commit, we're left with only one `stock.move.line` with 4 qty and already picked (not knowing what its reservation was since this information is on the `stock.move` and not on the `stock.move.line`.) => After this commit, the lin
Original PR description
When the user quits a unfinished picking, the reservation on the move lines are lost. To avoid that, uncompleted moves will be split in such case. For example: - Assume we have a move of 0/15; - The user picks 4 qty (4/15) then exit the picking: => Before this commit, we're left with only one `stock.move.line` with 4 qty and already picked (not knowing what its reservation was since this information is on the `stock.move` and not on the `stock.move.line`.) => After this commit, the line's move will be split and we'll be left with two `stock.move` and thus `stock.move.line`: - One with 4 qty, already picked (4/4); - One with 11 qty, waiting to be picked (0/11); So, the user will always know what the remaining qty they still have to pick. task-3821067 Forward-Port-Of: odoo/enterprise#59212
## Analysis Since this commit https://github.com/odoo/enterprise/commit/16ba33cd77413948308dd09326021a14f52f51f6, a domain is used to filter which preparation displays should be refreshed when an order arrives. The current domain only filters the preparation displays that are linked to one or more PoS (`pos_config_ids`). If no specific PoS are linked to the preparation display, the domain will filter out the preparation display and the user will have to **manually refresh** the preparation di
Original PR description
## Analysis Since this commit https://github.com/odoo/enterprise/commit/16ba33cd77413948308dd09326021a14f52f51f6, a domain is used to filter which preparation displays should be refreshed when an order arrives. The current domain only filters the preparation displays that are linked to one or more PoS (`pos_config_ids`). If no specific PoS are linked to the preparation display, the domain will filter out the preparation display and the user will have to **manually refresh** the preparation display to see a new order. ## Solution The domain should also check if a preparation display is linked to all PoS. ## References opw-3756416 Forward-Port-Of: odoo/enterprise#62430
The SellerSupplierParty data was initially included for transport reason '13', but recent validations show it is only necessary for transport reasons '02' and '07', which we do not support. Removed these fields to prevent data redundancy and potential errors. Before: - Included SellerSupplierParty data for transport reason '13'. After: - Removed SellerSupplierParty data from DespatchAdvice template. This change ensures compliance with the latest validation rules and reduces unnecessar
Original PR description
The SellerSupplierParty data was initially included for transport reason '13', but recent validations show it is only necessary for transport reasons '02' and '07', which we do not support. Removed these fields to prevent data redundancy and potential errors. Before: - Included SellerSupplierParty data for transport reason '13'. After: - Removed SellerSupplierParty data from DespatchAdvice template. This change ensures compliance with the latest validation rules and reduces unnecessary XML data. Legal Reference:  https://cpe.sunat.gob.pe/sites/default/files/inline-files/ValidacionesGREv20221020_publicacion.xlsx Latam Task: https://latam-localizations.odoo.com/web#id=1203&menu_id=142&cids=1&action=188&model=project.task&view_type=form Forward-Port-Of: odoo/enterprise#62651
### Steps to reproduce the issue: 1. Go to _Planning > My Planning_ and switch to the Weekly Calendar view 2. Plan a new Event from 5.30 AM to 7 PM in the Calendar 3. When the creation Form opens, the Date does not reflect the slot you were creating - Also happens in Gantt view: 1. Make sure the company's schedule starts or ends between two hours (e.g.: 8.15 am) 2. Click on the '+' button of the corresponding cell in the Daily Gantt view 3. The Date will be cut to the start or e
Original PR description
### Steps to reproduce the issue: 1. Go to _Planning > My Planning_ and switch to the Weekly Calendar view 2. Plan a new Event from 5.30 AM to 7 PM in the Calendar 3. When the creation Form opens,…
### Steps to reproduce the issue: 1. Go to _Planning > My Planning_ and switch to the Weekly Calendar view 2. Plan a new Event from 5.30 AM to 7 PM in the Calendar 3. When the creation Form opens, the Date does not reflect the slot you were creating - Also happens in Gantt view: 1. Make sure the company's schedule starts or ends between two hours (e.g.: 8.15 am) 2. Click on the '+' button of the corresponding cell in the Daily Gantt view 3. The Date will be cut to the start or end of the schedule. ### Explanation: Before opening `planning.planning_view_form`, the client calls for `onchange` which will then call for `default_get` that will align `start_datetime` and `end_datetime` with the work hours of `res.company.resource_calendar_id` in every situation where no resource is specified. https://github.com/odoo/enterprise/blob/ff4e39a09399f46790c0ad45bc9f9af4e4cd44d1/planning/models/planning.py#L625-L635 ### Suggested fix: `start_datetime` and `end_datetime` should not change only in Weekly and Daily Calendar views and in Daily Gantt View. The key should not remain in the Context of the Action to avoid unintended behaviours, adding it in the Context of the Event instead. opw-3829635 Forward-Port-Of: odoo/enterprise#62601 Forward-Port-Of: odoo/enterprise#61152
Currently, when validating an order, an error appears. Steps to reproduce: ------------------- * Install **l10n_de_pos_cert** and set up **fiskaly** * Set up **PoS** in German company * Open a store session * Validate an order > Unknown Error: An unknown error has occured! Please, contact Odoo. Why the fix: ------------ https://github.com/odoo/enterprise/blob/a8bd649f7b4c5c3af64edaca19b9c8ca9999cd9e/l10n_de_pos_cert/static/src/overrides/models/models.js#L184-L186 Function `get_t
Original PR description
Currently, when validating an order, an error appears. Steps to reproduce: ------------------- * Install **l10n_de_pos_cert** and set up **fiskaly** * Set up **PoS** in German company * Open a store…
Currently, when validating an order, an error appears.
Steps to reproduce:
-------------------
* Install **l10n_de_pos_cert** and set up **fiskaly**
* Set up **PoS** in German company
* Open a store session
* Validate an order
> Unknown Error: An unknown error has occured! Please, contact Odoo.
Why the fix:
------------
https://github.com/odoo/enterprise/blob/a8bd649f7b4c5c3af64edaca19b9c8ca9999cd9e/l10n_de_pos_cert/static/src/overrides/models/models.js#L184-L186
Function `get_tax_details()` was changed with
https://github.com/odoo/odoo/commit/ab0bdf0192120671010634978f202da35ddfc79f
It was previously returning an object of the form
```js
amount: 56.050000000000004
base: 295
name: "19%"
tax: Proxy(AccountTax)
amount: 19
amount_type: "percent"
children_tax_ids: []
company_id: Base {models: {…}, records: Proxy(Object), model: {…}, _raw: {…}, id: 3, …}
id: 16
include_base_amount: false
is_base_affected: true
model: {…}
models: {pos.config: {…}, pos.order: {…}, pos.order.line: {…}, pos.session: {…}, pos.payment.method: {…}, …}
name: "19%"
price_include: false
```
And now returns
```js
amount: 56.050000000000004
amount_type: "percent"
base: 295
batch_indexes: [0]
display_base: 295
evaluation_context: {multiplicator: 0.19}
extra_base_for_base: []
extra_base_for_tax: []
id: 16
include_base_amount: false
index: 0
is_base_affected: true
name: "19%"
price_include: false
sequence: 10
tag_ids: []
tax_amount: 56.05
tax_amount_factorized: 56.050000000000004
tax_exigibility: "on_invoice"
tax_ids: []
tax_percentage: 19
```
`details.tax.id` is now simply `details.id` and `details.tax.amount` is `details.tax_percentage`. As per the following definition: https://github.com/odoo/odoo/blob/5058c01974431af1cb3a59d65bf40cf5b08ba4ea/addons/point_of_sale/static/src/app/store/models.js#L2202-L2209
opw-3924715
Forward-Port-Of: odoo/enterprise#62613Add Bank Indonesia as a provider or currency rate in order to align with the local market needs. Task id # 3217982 Forward-Port-Of: odoo/enterprise#62535 Forward-Port-Of: odoo/enterprise#61008
Original PR description
Add Bank Indonesia as a provider or currency rate in order to align with the local market needs. Task id # 3217982 Forward-Port-Of: odoo/enterprise#62535 Forward-Port-Of: odoo/enterprise#61008
Before this commit: - Select an image (WEBP format) along with other images. - The preview in the inspector is distorted. Reason: - When introducing the support for WEBP images in the following PR -- https://github.com/odoo/odoo/pull/85494, the upload of documents was not taken into account. - The current image processing ensures that the supported image formats are resized at the backend before being sent to the frontend. Fix: - The exact values of the `max-width` and `max-height` dr
Original PR description
Before this commit: - Select an image (WEBP format) along with other images. - The preview in the inspector is distorted. Reason: - When introducing the support for WEBP images in the following PR -- https://github.com/odoo/odoo/pull/85494, the upload of documents was not taken into account. - The current image processing ensures that the supported image formats are resized at the backend before being sent to the frontend. Fix: - The exact values of the `max-width` and `max-height` draw their inspiration from the following image resizing values in the `documents_inspector.xml` ref- https://github.com/odoo/enterprise/blob/saas-16.4/documents/static/src/views/inspector/documents_inspector.xml#L39 After this commit: - The WEBP image, along with the other image formats can now be previewed without breaking any alignment in the Inspector. Task-3749547 Forward-Port-Of: odoo/enterprise#62565 Forward-Port-Of: odoo/enterprise#59339
Steps to Reproduce: 1. Select a doc. 2. Replace it with another doc. 3. You can see the history of the inspector. 4. From the history tab, double-click on the restore button. 5. Delete the previewed doc from the history list. 6. Throws a Traceback. Issue: triggers asynchronous operation on "_onHistoryItemRestore", when clicked, rapid consecutive clicks could result in multiple asynchronous operations being initiated simultaneously, leading to race conditions or unexpected behavior.
Original PR description
Steps to Reproduce: 1. Select a doc. 2. Replace it with another doc. 3. You can see the history of the inspector. 4. From the history tab, double-click on the restore button. 5. Delete the previewed doc from the history list. 6. Throws a Traceback. Issue: triggers asynchronous operation on "_onHistoryItemRestore", when clicked, rapid consecutive clicks could result in multiple asynchronous operations being initiated simultaneously, leading to race conditions or unexpected behavior. Fix: No traceback will occur, registered only once on a button. Task:3843157 Forward-Port-Of: odoo/enterprise#62560 Forward-Port-Of: odoo/enterprise#60227