Wednesday, November 20, 2024
13 changes · 18.0
Enhancements to existing features
Users can now re-import exported chart of accounts spreadsheets that include company-specific account code mappings without import failures. The update also improves account code uniqueness checks so Odoo proposes valid, available account codes more reliably across companies.
Original PR description
When exporting a CoA in Excel format, the user can export the code mapping for all the companies via the `code_mapping_ids/company_id` and `code_mapping_ids/code` columns. However, importing these…
When exporting a CoA in Excel format, the user can export the code mapping for all the companies via the `code_mapping_ids/company_id` and `code_mapping_ids/code` columns. However, importing these values fails because the import transforms these values into `CREATE` commands on `code_mapping_ids`, which are currently not handled. With this commit, we catch those CREATE commands in `account.account` `create` and `write` methods and modify the account's code in the relevant company. In addition, we take the opportunity to correctly rewrite the `_ensure_code_is_unique` check method. In https://github.com/odoo/odoo/pull/181352, we relaxed the constraint that prevented accounts from being mapped to an account code in a company the account doesn't belong to, if there already exists an account in that company that already has that code. However, the `_ensure_code_is_unique` wasn't rigorously rewritten, and it didn't apply the check in a consistent manner. We now rewrite it and provide tests for it. We also modify the `_search_new_account_codes` method accordingly, such that it proposes the first non-reserved account code. Enterprise PR: https://github.com/odoo/enterprise/pull/71910 task-4247869
Indian localization settings now clarify which HSN code length applies based on business value thresholds. Companies below 5 crore use 4-digit HSN codes, while those above 5 crore use 6-digit HSN codes, helping users follow reporting requirements more clearly.
Original PR description
Modified HSN display format based on crore thresholds: - 4-digit HSN for values below 5 crore. - 6-digit HSN for values above 5 crore. This update enhances clarity by providing distinct formats for HSN codes based on value thresholds. > Task: 4252228
Restaurant point-of-sale users can now return to the floor plan without waiting for a background server update to finish. This makes navigation feel quicker and removes an unnecessary notification when moving to the ticket screen.
Original PR description
- We don't wait anymore the server's response (from the call to `sync_from_ui`) when going to the floorplan. - Remove useless toaster notification when going to the ticket screen. task_id: 4329314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Account imports now support accounts shared across companies by making the account code optional and allowing accounts to be matched by company-specific code, external ID, or database ID. Users can also import company-specific code mappings, helping multi-company setups maintain different account codes accurately.
Original PR description
We adjust the account import mechanism to the new reality that accounts can now be shared between companies, and have different codes in different companies. - The `code` column is now no longer required. Users can reference an account by its code in the current company (in which case only the account with that code that belongs to the current company will be matched), but can also reference an account by its external ID or database ID. - The user can import a code mapping for accounts via the `code_mapping_ids/company_id` and `code_mapping_ids/code` columns. We add a check that both of these columns must be simultaneously present. Community PR: https://github.com/odoo/odoo/pull/183695 task-4247869
Resolved issues and error corrections
This fix lets website grid sections expand vertically when content needs more room, such as on smaller screens or in longer translated text. It helps prevent cramped or overflowing content, improving the visitor experience across devices and languages.
Original PR description
Website CSS grid bug fix affecting responsiveness to smaller screen resolutions. **Description of the issue/feature this PR addresses:** Having `grid-auto-rows` fixed at 50px stops the grid cells from growing in order to accommodate its content when the content narrows and increases in height. **Current behavior before PR:** Div does not respond to changes in screen resolution or changes caused by the content being translated to a different language. **Desired behavior after PR is merged:** Using the `minmax()` CSS function allows the grid cells to expand vertically to accommodate content that exceeds the minimum height of 50px, improving responsiveness on smaller screens. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix allows website content blocks to grow vertically when text wraps on smaller screens or after translation. It helps prevent cramped or cut-off content, improving the viewing experience across devices and languages.
Original PR description
Website CSS grid bug fix affecting responsiveness to smaller screen resolutions. **Description of the issue/feature this PR addresses:** Having `grid-auto-rows` fixed at 50px stops the grid cells from expanding vertically in order to accommodate it's content when the content narrows and increases in height. **Current behavior before PR:** Div does not respond to changes in screen resolution or changes caused by the content being translated to a different language. **Desired behavior after PR is merged:** Using the `minmax()` CSS function allows the grid cells to expand vertically to accommodate content that exceeds the minimum height of 50px, improving responsiveness on smaller screens. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where empty company-specific numeric or yes/no fields could cause database errors when records were loaded. Businesses using multi-company setups should see more reliable access to records with optional fields left blank.
Original PR description
Issue --> For company dependant fields of type `boolean`, `integer`, `float`, `monetary`, casting a `null` value leads to a `cannot cast jsonb null to type _` error on postgresql. For example,…
Issue -->
For company dependant fields of type `boolean`, `integer`, `float`, `monetary`, casting a `null` value leads to a `cannot cast jsonb null to type _` error on postgresql.
For example, consider the following ->
1. Database has two companies : 'a' and 'b'
2. has one res.partner record with no `credit_limit` set.
3. `credit_limit` (float or numeric) is not a required field and does not have a default value
`credit_limit` on the backend looks like `{"a.id": null, "b.id": null}`
Fetching the value for this field leads to method `_field_to_sql` which builds the select query, while also casting the type to each field. In this case, with no fallback default value and a float field, the query is `SELECT ("res_partner"."credit_limit"->'a.id')::double precision FROM res_partner` which resolves to `null(jsonb)::double precision` which unfortunately, is not supported on Postgresql.
Solution -->
Remove the condition for the types `boolean`, `integer`, `float`, `monetary` and use the `field->company_id->>0` logic instead. This works because the `->>` operator returns a text object; the text `null` value can be cast into the types mentioned above.
https://github.com/odoo/odoo/blob/2ed38db47ac3152eef1a0e328c8ff572474d079f/odoo/models.py#L2964-L2967
opw-4313425
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prPortal users can now view pages containing the Blog snippet without hitting an error. The fix changes how the author name is shown so it no longer depends on permissions that portal users do not have.
Original PR description
Since [1], the template attempted to display the author's name using `record.author_id.name`, which caused access errors for portal users due to insufficient permissions on the res.partner model. By switching to the related field `author_name`, the template no longer requires direct access to `res.partner`, ensuring smooth functionality for all users. Steps to reproduce: - Log in as an administrator - Navigate to Website - Enter Edit Mode - Add a "Blog" snippet to the home page - Save the changes - Log out - Log in as a portal user - Observe that a traceback occurs [1]: https://github.com/odoo/odoo/commit/dbb72d1f68cf7f462e1d6bdf8998f29627ccc2f0 opw-4330845
This fix removes an incorrect blocking warning that prevented credit notes from being sent with UBL XML files when no recipient bank was set. Businesses can now process and send credit notes normally while keeping the bank requirement for customer invoices where it applies.
Original PR description
The previous warning asking to add a Recipient Bank was shown incorrectly in previous versions in case of Credit Notes. With the rework, we escalated this warning to a danger warning that prevent from sending, as in case of Customer Invoices it is a blocking error. The combinations of those two is now preventing Credit Notes to be sent with an UBL XML file. See: https://github.com/odoo/odoo/commit/9e769e1b11f22890e5245859053bc8dd31e42634 task-no
Regular employees can once again open their time off dashboard when their allocation uses an accrual plan. The fix ensures available time off is calculated correctly without exposing unnecessary setup details to users.
Original PR description
Accrual plans are not readable for regular users, so once a user has an accrual plan set on one of his allocation, he cannot open anymore his time off dashboard when it tries to get his allocation data (the time off he has). To ensure the correct computation of available time off, we add a sudo. This has been introduced in https://github.com/odoo/odoo/pull/172892/ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The product catalog now waits for component changes to finish before refreshing shopfloor records. This prevents newly added manufacturing components from temporarily disappearing when users close the catalog quickly, improving reliability for shopfloor workflows and tests.
Original PR description
### Issue: Since 18.0, the catalog is used in certain actions of the shopfloor However, if you leave the catalog fast enough after your last change (something of the order of ~0.5 sec in localhost),…
### Issue: Since 18.0, the catalog is used in certain actions of the shopfloor However, if you leave the catalog fast enough after your last change (something of the order of ~0.5 sec in localhost), you can trigger a reload of the shopfloor records and call a `web_read` prior to the update of these records. ### Note: This is easily reproducible by hand in localhost and should worsen if you have server delay.In addition, Also, it makes it impossible to write a proper tour involving the catalog in the shopfloor. ### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > wheel > Add component - Add a component to be consumed in that operation - Close the catalog fast (using ESC for instance) #### > While the componenet was correctly added to the MO and linked to the WO it is not visible on the shopfloor. ### Cause of the issue: When a product is added from the catalog it triggers an rpc call to update the data's of the MO (notably creating a new raw move): https://github.com/odoo/odoo/blob/193c9a49dfc039ee93fbc8e171819236697b5c50/addons/product/static/src/product_catalog/kanban_record.js#L62-L69 https://github.com/odoo/odoo/blob/193c9a49dfc039ee93fbc8e171819236697b5c50/addons/mrp/models/mrp_production.py#L2898-L2901 On the other hand, closing the product catalog will reload the mrp record that started the action that opened the catalog: https://github.com/odoo/enterprise/blob/c1346dd2279bf3882b47b260b8d03ef9651ffaf1/mrp_workorder/static/src/mrp_display/dialog/mrp_menu_dialog.js#L41-L45 Since this reload is currently not waiting for the update of the record the associated `web_read` might be called prior to the last update of the record and the newly created raw moves might not be displayed. ### Fix: We use the props option of the action opening the catalog to transfer a callback to reload the records when all the record update promisses are resolved. Enterprise: https://github.com/odoo/enterprise/pull/72942 opw-4199156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing the project while creating a new timesheet no longer accidentally starts timers or creates duplicate records. The timer now starts only when users intentionally launch it from the timesheet timer header, reducing erroneous timesheet entries.
Original PR description
Steps to reproduce:
- List/grid view
- Click 'New'
- Change project field (1 or more times)
- Switch to kanban view
=> Timer started and many records created
Source of the bug:
- due to this condition 'record.isNew && record.data.project_id', introduced in commit 576c0eac3b8431a5080b6383ae256a0699ba7c7d,
each time project_id field is changed, action_start_new_timesheet_timer is called to start the timer and create a new record.
Fix:
- Start the timer only if new is called from the header timer by checking is_timer_running for that record.
task-4210112This update improves the signing experience by fixing mobile display problems, preventing expired items from appearing in completion dialogs, and ensuring refused signature requests are properly cancelled. It also stabilizes related automated checks so archived or cancelled requests are handled consistently.
Original PR description
Before this commit, some things were unclear. The mobile view was not working as expected and expired sign items were displayed in the thank you dialog. Refusing sign request would not cancel them.…
Before this commit, some things were unclear. The mobile view was not working as expected and expired sign items were displayed in the thank you dialog. Refusing sign request would not cancel them. Moreover this commit fix the sign tests. This commit aims to fix an issue with test_archived_requests_dont_send_reminders. Previously the test was trying to archive a record by performing a direct write command, but since we have a designated action for archiving sign requests, it should be used. Another issue is that when we archive a sign request, its state is set to 'canceled', and for canceled sign requests we cannont update the validity, however the test was trying to update the validity (as a way of jumping to the future). But this is not the correct way of doing it, since we shouldn't change the validity if state is canceled. To fix the issue, a mock_datetime_and_now is introduced. Note: this is the backport of https://github.com/odoo/enterprise/pull/73156 task: 4294860