Daily updates from Odoo
Thursday, January 16, 2025
70 changes · 18.0
Enhancements to existing features
The stock return wizard now includes a "Return All" button that automatically fills return quantities with the delivered amounts. This reduces manual entry and lowers the risk of mistakes in workflows where most or all items need to be returned.
Original PR description
### Issue: Since 57b8b2487def43a1b9c461c0fa4eb02200b5c1ef (18.0), the return picking wizard sets a default quantity of 0. This fits the new design of returns that are no longer exclusively tied to the initial delivery. However, in workflows where you are expected to return all/almost all products of a consequent picking this is both fastidious and error prone to set all the quantities to match the delivered values by hand. ### Solution: We add a "Return All" button in the wizard view to allow the user to create a return whose quantity matches the delivered quantities. opw-4416167 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Brings Korean translation to the recently released accounting modules for the Republic Of Korea. task-4415944 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Brings Korean translation to the recently released accounting modules for the Republic Of Korea. task-4415944 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
New spreadsheets created in My Drive are kept private to their owner, while spreadsheets created in Company folders now automatically follow the folder's access rules. This makes document sharing more consistent and helps prevent unintended access differences.
Original PR description
**Specifications:** When creating a spreadsheet in My Drive, access should be restricted to the owner only. When creating a spreadsheet in a Company folder, it should inherit the access permissions of the parent folder. **Task**-4297505
Resolved issues and error corrections
Batch invoice sending now uses clearer wording when invoices are prepared manually, reducing confusion for users who expected downloads. Italian electronic invoicing users can again download all FatturaPA XML files in one batch, and related error messages now show understandable text instead of internal keys.
Original PR description
## Commit 1: ### [FIX] account: Batch invoice sending when partner on "Download" Context: In 18.0, all batch/multiple invoice sending are processed asynchronously, we never directly download the…
## Commit 1: ### [FIX] account: Batch invoice sending when partner on "Download" Context: In 18.0, all batch/multiple invoice sending are processed asynchronously, we never directly download the generated PDF/XML files. The sending method that is used depends on what is set on the partner. Problem: If you set your partner to "Download" by default, in the batch Send & Print, it will display "You are about to send: x invoice(s) Download". While it's actually not downloading, only generating. In 18.1 we changed this to "Manual" which is better but doesn't go well in a sentence. Solution: Let's align everything to "Manually" in batch sending to avoid confusion. Before:  After:  opw-4315079 ## Commit 2: ###[IMP] l10n_it_edi: Add possibility to download in batch XML FatturaPA Context: In 18.0, when sending invoices in batch, we never download a zip of all generated files (PDF, XML) since we always process invoices asynchronously with the partner's sending method set on the partner's form. Problem: It's no longer possible to retrieve all XML Fattura PA at once. Solution: Add a button under the "Print/Download" button to download them all. opw-4315079 ## Commit 3: ### [FIX] l10n_it_edi: Fix error message display in Print & Send The italian error dict does not comply to the default format expected by the generic Print & Send. It displays the key of the error instead of the message. Before:  After:  task-no
The POS session chatter now shows the expected opening amount based on the previous session's closing balance, rather than a manually edited value. This keeps cash opening records and displayed differences accurate for store staff and managers.
Original PR description
- Resolved issue where the "expected opening" amount in the POS session chatter incorrectly displayed the manually modified amount instead of the previous closing balance. - Adjusted the sequence of setting `cash_register_balance_start` to maintain consistent chatter messages with accurate deltas. task-id: 4471816 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
Users trying to process invoices with an invalid certificate private key will now see a clear error instead of a technical crash. The message identifies the problematic key, helping users or support teams resolve invoice signing issues faster.
Original PR description
When the private key has an issue if we attempt to sing an invoice we may get a traceback in the frontend. We can instead show an error and include the key that's failing. Example traceback if the…
When the private key has an issue if we attempt to sing an invoice we may get a traceback in the frontend. We can instead show an error and include the key that's failing.
Example traceback if the key is invalid:
```
File "/home/odoo/src/odoo/18.0/addons/certificate/models/key.py", line 206, in _sign_with_key
private_key = serialization.load_pem_private_key(base64.b64decode(pem_key), pwd)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/base64.py", line 83, in b64decode
s = _bytes_from_decode_data(s)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/base64.py", line 45, in _bytes_from_decode_data
raise TypeError("argument should be a bytes-like object or ASCII "
TypeError: argument should be a bytes-like object or ASCII string, not 'bool'
```
Steps to reproduce:
1. Install l10n_sa_edi
3. Alter the key in a way that makes it fail to load, e.g. upload a garbage text file as a key (note the error in the warning)
2. Make an invoice to ARAMCO partner
4. Click in the `Process now` link at the top of the invoice
We get the traceback.
This issue was seen during upgrades due to improper migration of SA keys (already solved). Still the UX here is suboptimal. This patch proposes to show an error that can help users understand the issue. We already show the error in the keys management interface, but the user working in invoices may be unaware of the issue with the key.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prUsers can now reverse certain payroll-related journal entries without encountering an error caused by missing currency information. When no specific currency is available, the system uses the company currency so the reversal process can continue reliably.
Original PR description
Currently, an error was occurring when a user tried to reverse a journal entry. Step to reproduce: --- - Enabled payroll entries in Payroll > Configuration > Settings. - Created a new employee and its corresponding contract in payroll. - Computed the payslip, generated draft journal entries, and created a payment. - In accounting check in payments by payslip, currency id will not get fetched. - Make a reverse entry. Traceback: --- ValueError: Expected singleton: res.currency(). This is because at [1] does not have ``currency_id`` in self so it does not link any currency with account payment register This commit will fix the above issue by providing default company currency when currency is not found in self. [1] - https://github.com/odoo/odoo/blob/0583db332efdc884975da1a074c91981d2865c9d/addons/account/wizard/account_payment_register.py#L972 sentry-6207053954 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customer reports now correctly show only the serial-numbered products that were actually returned. This prevents non-returned items from being mislabeled, improving inventory traceability and customer service accuracy.
Original PR description
**Steps to reproduce:** In Inventory > Settings > Traceability, enable Lots & Serial Numbers - Create a product P1 tracked by unique serial number - Update on-hand quantities: 2 x P1 - Create a quotation with 2 units of P1 - Deliver products (assign the two serial numbers) - Return only 1 product - Go to the Customer view, click Lot/Serial Numbers, and remove all filters. **Issue:** When returning just one product from a delivery containing multiple products, all products in the picking appear as returned. **Expected:** Only the product that was actually returned should be marked as returned. **Cause:** The logic that sets `has_return` relies solely on the `return_id` field, incorrectly marking all items in the picking as returned if one item is returned. opw-4417716 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users with limited sales permissions can now log timesheets on assigned billable tasks linked to a sales order without being blocked by an access error. This keeps timesheet entry working while preserving the existing sales permission setup.
Original PR description
### Steps to reproduce: - Create a project and make it billable - Create a task in this project and assign it to a user that has Own Documents access in Sales - Set a customer for this task and SO - Using the user that has been assigned to the task try to timesheet something - Notice an access error will be triggered ### Cause: This is happening because when timesheeting we are checking the so_line analytic distribution https://github.com/odoo/odoo/blob/18.0/addons/sale_timesheet/models/hr_timesheet.py#L216 and since the user doesn't have access for the so_line we are getting this access error. ### Fix: Use sudo() for this check to give the user access for this field opw-4338754
Fixes an issue where the Discuss call sidebar could fail when a participant session was missing expected membership information. This improves reliability for users viewing call participant cards and avoids disruptive error screens.
Original PR description
Since [1], the session getter for the sidebar cards assumes that channelMember is always defined on rtcSessions, this could cause tracebacks. [1]: https://github.com/odoo/odoo/pull/190050
Recruitment application creation now checks a candidate's company before linking records, preventing errors when similar candidates exist in another company. It also allows applications to link to candidates without a company, helping teams process incoming applications more reliably.
Original PR description
Before this commit, the creation of an applicant though `message_new`, It would check for existing candidates but not for the company; however, if the company is different, an error would be raised upon applicant creation and prevent it. This commit adds the company to the candidate check to avoid raising the constraint, and adjusts the said constraint so that it allows linking to candidates with no company set.
This fixes an issue where the “See all” link in dynamic website product blocks was reset to the default shop page after saving. Businesses can now customize that link and trust it will keep sending visitors to the intended page.
Original PR description
Steps to reproduce: - Install the e-commerce module. - Go to the homepage. - Enter edit mode. - Drag and drop a "Products" block onto the page. - Click on the "See all" link. - Edit the link (e.g.,…
Steps to reproduce: - Install the e-commerce module. - Go to the homepage. - Enter edit mode. - Drag and drop a "Products" block onto the page. - Click on the "See all" link. - Edit the link (e.g., change "/shop" to "/contactus"). - Save the page. - Click on the "See all" link. - Bug: You are redirected to the "/shop" page instead of the "/contactus" page as expected. The bug occurs since commit [1], where the "See all" link was added to "Dynamic" snippets. Each time a "Dynamic" snippet is rendered during a page load, the href of the "See all" link is reset to the main module page. While this behavior is useful when the snippet is first rendered after being dropped onto the page, it is problematic afterward. Once the user has edited the link with a different href, it should not be reset on every page load. [1]: https://github.com/odoo/odoo/commit/bbcff746075485be61807d08ad8232dbad347713 [opw-4418048](https://www.odoo.com/web#id=4418048&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form)
The Point of Sale category display now adapts better to different screen sizes when there are many categories. This prevents the category area from blocking product visibility, helping cashiers continue browsing and selecting products smoothly.
Original PR description
Currently when users have too many categories in their pos, their are not able to see the products and cannot scroll. Steps to reproduce: ------------------- * Add categories to the pos `> 100` * Open pos shop > Observation: We cannot see all categories, cannot scroll through them, and cannot see/select products Why the fix: ------------ This issue is the same as the one in this commit: https://github.com/odoo/odoo/commit/dd14967a037a93346123265ed489a0b4ce5f8218 But this time we expend the scope of the fix because the issue can also appear on other size screens. The number of rows of category displayed depends of the size of the screen. opw-4457772
This fixes a problem where visitors using embedded live chat on external websites could not answer calls from an operator. The call feature now loads the required calling component from the correct Odoo address, restoring the expected live chat calling experience.
Original PR description
__Current behavior before commit:__ Since [`9592bd1`][1] when the livechat is integrated on a third-party website, a visitor can not answer the call of an operator. This is because the script `selfie_segmentation.js` is being fetched from the third-party website domain instead of the Odoo database domain; resulting in the following error: `AssetsLoadingError: The loading of /mail/static/lib/selfie_segmentation/selfie_segmentation.js failed` __Description of the fix:__ Use of the `url` function to prepend the correct domain name. opw-4417974 [1]: https://github.com/odoo/odoo/commit/9592bd1
Fixes an issue where repeatedly clicking the SEO notification button could open several optimization dialogs at once. The notification now closes properly after the button is clicked, keeping the website publishing flow clearer and less confusing.
Original PR description
Since [1], clicking the button while the SEO toaster was visible could repeatedly open the SEO optimization dialog, resulting in multiple instances of the dialog box being opened. This commit addresses this issue by: - Adding logic to ensure toasters close properly when a button is clicked. (i.e the SEO toaster when you publish a page with missing important SEO informations). [1]: https://github.com/odoo/odoo/commit/45ea6e4a4a5c8e314b110a45198fbe3d57bb996e task-4384773
This fixes an accounting setup issue by ensuring the system only tries to retrieve fields that belong to the company record. It helps prevent errors during configuration or template processing when unrelated fields could otherwise be requested.
Original PR description
We can only attempt to get fields from `res.company` model. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change corrects an automated test setup for restaurant self-order online payments so it works reliably in no-demo test environments. It helps keep release validation stable without changing customer-facing behavior.
Original PR description
The `test_01_online_payment_with_multi_table` fails in runbot when running in "no-demo" mode. This is because it's not using the correct setup for testing restaurant configs. We ensure, in this commit, that the test uses the correct setup for testing by inheriting from the pos_restaurant's TestFrontendCommon. The total amount in the tour is adjusted because the test product from the default setup has no tax. Runbot Error: [111171](https://runbot.odoo.com/odoo/runbot.build.error/111171)
Users who manage projects and timesheets can now record time on tasks linked to sales orders without needing Sales access. This removes an unnecessary access error while keeping sales order details restricted to authorized users.
Original PR description
This PR addresses the issue of users without Sales access not being able to record on time on timesheets that are linked to a sale order line. If a user with access to Projects and Timesheets, but…
This PR addresses the issue of users without Sales access not being able to record on time on timesheets that are linked to a sale order line. If a user with access to Projects and Timesheets, but not Sales, wants to record time on a timesheet linked to a sales order, they will get an access rights error. This is because we check to see if there is an analytic distribution associated with the sale order line associated with the project task. However, this check is done without `sudo()` access in its current state. This PR provides that access because the result is not propagated further than simply evaluating whether or not there is an analytic distribution at all. The result is that this workflow is no longer blocking for users who should be able to timesheet, but not necessarily view or edit the sale order. This can be tested on Runbot by following these steps: Configuration: - User A does not have any Sales access, but has full rights to Projects and Timesheets - Have a service product that creates a task in a project - Have a sale order made for this product by User B, who does have Sales access Now, 1) On User A, navigate to the associated project and task made by the sale order from earlier 2) Click on the Timesheets tab in the notebook part of the view 3) Attempt to record an hour of work by adding a line to the timesheet, then clicking the "save" button Prior to this PR, the user will get an access rights error. Once this is merged, that error will no longer appear. opw-4409571
This fix prevents newly created linked records from appearing twice during record creation in certain business flows. It helps avoid errors in features such as duplicating commission plans and keeps related data consistent during the same request.
Original PR description
### To reproduce: - Model A has an inverse X2many stored field pointing to model B. - Calling `A.create({'X2many': [Command.create({...})]})` returns `A(1)`. - `A(1).X2many` returns `B(1, <NewId…
### To reproduce:
- Model A has an inverse X2many stored field pointing to model B.
- Calling `A.create({'X2many': [Command.create({...})]})` returns `A(1)`.
- `A(1).X2many` returns `B(1, <NewId NoOrigin>)`. This breaks one of the implicit invariants of the ORM, we shouldn't have a mix of real and New ids in the same recordset. Also, it may break some computation done on this X2many later in the same request, since `A(1).X2many` contains two records instead of one.
This happens because `create()` calls `_update_cache()` with X2many values, but the value of that X2many is already in the cache with the record created from the command values. This causes the X2many values to be duplicated with the new record version of the command values.
### Real Issue in the standard code
In the case of the 'sale.commission.plan' model and due to the inversed `target_commission_ids` field, it breaks the duplicate feature (`copy()` method):
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/http.py", line 1960, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/service/model.py", line 138, in retrying
result = func()
^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/http.py", line 1927, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/http.py", line 2174, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/addons/base/models/ir_http.py", line 329, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/http.py", line 729, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5921, in copy
old_record.copy_translations(new_record, excluded=default or ())
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5874, in copy_translations
new_lines = new[name].sorted(key='id')
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6690, in sorted
ids = tuple(item.id for item in sorted(self, key=key, reverse=reverse))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'NewId' and 'int'
```
Explanation of the traceback:
A `copy()` calls `create()` on 'sale.commission.plan', which returns a `commission` record that should contain the same `target_commission_ids` values. Instead of that, `commission.target_commission_ids` (after the create and before `copy_translations`) returns twice as many records and with a mix of New and real ids, causing `copy_translations()` to crash when sorting by id.
### Fix
To avoid this issue, we don't call `_update_cache()` for the stored fields because we are sure that the cache has already been set in `_create()` and not invalidated by `modified()`.Department employee totals now respect the companies currently active for the user. This prevents misleading counts in multi-company setups and adds test coverage to help keep the behavior reliable.
Original PR description
- edit the `_read_group` domain to include the current active companies Task: 4353391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refreshes Odoo's spreadsheet engine with fixes that make spreadsheets behave more reliably in everyday use. Users should see better Excel import/export handling, more accurate charts and pivots, improved collaboration behavior, and fewer display issues.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/94c45c7c3 [REL] 18.0.10 Task: 0 https://github.com/odoo/o-spreadsheet/commit/e1d850152 [REV] collaborative: always…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/94c45c7c3 [REL] 18.0.10 Task: 0 https://github.com/odoo/o-spreadsheet/commit/e1d850152 [REV] collaborative: always trigger collaborative event received Task: 0 https://github.com/odoo/o-spreadsheet/commit/0c5220e86 [REL] 18.0.9 Task: 0 https://github.com/odoo/o-spreadsheet/commit/883dc0ae4 [FIX] borders: fix border on column/row deletion Task: 4089281 https://github.com/odoo/o-spreadsheet/commit/57aa8a7c7 [IMP] functions: add VALUE function Task: 4373019 https://github.com/odoo/o-spreadsheet/commit/d71d23f97 [FIX] charts: Account for correct locale when filtering empty datasets Task: 4465324 https://github.com/odoo/o-spreadsheet/commit/de1268b08 [FIX] pivot: notify only with static formulas Task: 4453844 https://github.com/odoo/o-spreadsheet/commit/d926ab9e3 [FIX] spreadsheet: avoid parasitic renders Task: 4373054 https://github.com/odoo/o-spreadsheet/commit/4eb819fa8 [IMP] model: create snapshot when loading xlsx file Task: 4080514 https://github.com/odoo/o-spreadsheet/commit/fa35e56dc [FIX] Package: update owl to 2.5.1 Task: 0 https://github.com/odoo/o-spreadsheet/commit/5ae37ce00 [FIX] chart: fix trend line axis alignment Task: 0 https://github.com/odoo/o-spreadsheet/commit/bef5abccc [FIX] xlsx: ignore charts without data set Task: 4460515 https://github.com/odoo/o-spreadsheet/commit/226fa6ad5 [FIX] pivot: ensure correct format status in menu Task: 4373606 https://github.com/odoo/o-spreadsheet/commit/85aaab61d [FIX] pivot: mouse events do not work in pivot text input Task: 4350439 https://github.com/odoo/o-spreadsheet/commit/aebd38c9d [FIX] chart: fix misalignment with trend line axis Task: 4251695 https://github.com/odoo/o-spreadsheet/commit/93eb716fc [FIX] xlsx: preserve leading whitespace at export Task: 4044862 https://github.com/odoo/o-spreadsheet/commit/3d0c96bd3 [FIX] xlsx: import new lines in sharedStrings Task: 4044862 https://github.com/odoo/o-spreadsheet/commit/3627052ae [FIX] charts: translate gauge chart titles Task: 4421055 https://github.com/odoo/o-spreadsheet/commit/61d79cd1e [FIX] index: export isNumber/isDateTime helper Task: 0 https://github.com/odoo/o-spreadsheet/commit/707d19875 [FIX] pivot: prevent duplicating pivot in error Task: 4361353 https://github.com/odoo/o-spreadsheet/commit/2687f536a [FIX] bottom_bar: ensure active sheet is scrolled into view Task: 4377840 https://github.com/odoo/o-spreadsheet/commit/144842902 [FIX] package: 18.0 is no longer the latest version Task: 0 https://github.com/odoo/o-spreadsheet/commit/66f0c66f8 [FIX] chart: trend line tooltip for scatter/line charts Task: 4279972 https://github.com/odoo/o-spreadsheet/commit/a59494344 [FIX] custom currency: panel on very long currency code Task: 4402647 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Employee profile images are now displayed correctly when using the Employees app on a mobile-sized screen. This fixes a visual issue that made employee records harder to recognize on phones or narrow displays.
Original PR description
Steps to Reproduce: • Install the Employee app. • Switch to mobile view. • Open the Employee app; employee images are not visible. Cause: CSS was not defined for screen sizes smaller than medium. Fix: Added CSS rules for screens smaller than medium to ensure employee images are displayed correctly in mobile view. task-4380126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes a problem where some links from emails to Odoo records could fail instead of opening the intended page. Users clicking these email links are now redirected correctly to the cleaner record URL, improving reliability for everyday navigation from notifications.
Original PR description
Commit c63d14a0485a553b74a8457aee158384e9ae6d3f introduced new nicer urls to get to Odoo. Commit 5776b574b3aba190c54b2e4974ce514d9b0bec2a adapted the /mail/view controller for it, allowing people clicking on a link to a record in a mail to be redirected to a nice new URL. Although one case was missing: when the model doesn't contain dots, the string is considered an action's path. So, when opening a record from a mail, there was a crash in odoo because the action could not be found. After this commit, there is no crash, and the record is opened correctly with a nice url. see router.js: heuristics to discrimate a model name from an action path is the presence of dots, or the prefix m- for models opw-4475237 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
Users can now drag selected text from one field and drop it into another field in form views. This fixes a small but frustrating editing issue and makes data entry smoother.
Original PR description
Before this commit: It is not able to drag and drop text between fields in the form view. After this commit: It is possible to drag and drop text between fields in the form view. Task-4286285
This fix makes the full message composer start with the expected empty paragraph when default content is present. It prevents formatting actions like bullet lists from accidentally applying to the whole message, making message editing more predictable for users.
Original PR description
**Problem**: When a `default_body` is added, it contains only a `div` in the editable area. This causes issues with some editor features, such as bullet lists, which do not behave as expected. **Solution**: Ensure the content includes a `<p><br/></p>` by default, selected for proper functionality, aligning with the default behavior of the editor. **Steps to reproduce**: 1. Go to Sales > Send Message > Full Composer. 2. Write content spanning 2+ lines. 3. On a new line, apply a bullet list. 4. Observe that the bullet list is applied to the entire content instead of just the current line. opw-4419775 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error during checkout when a customer buys only services and changes their delivery address. The checkout now handles cases where no delivery option is needed, allowing customers to continue smoothly.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Go to eCommerce; 2. add only services to cart; 3. go to checkout; 4. on payment page, go back to Delivery page; 5. add a second address if needed; 6. change selected address. Issue ----- > Uncaught Promise > Cannot read properties of null Cause ----- The query selector in `_canEnabledMainButton` assumes a radio input is always present on this step, but this is only the case when deliverable products were added to the cart. Solution -------- Skip the remainder of the method if the delivery radio wasn't found. opw-4365246 opw-4422905
Opening the invoice report in the report editor could fail for Kenyan OSCU setups because the report used invalid page structure. The report layout has been corrected so users can open and edit it reliably.
Original PR description
- Install `web_studio` and `l10n_ke_edi_oscu`
- Open the report editor from anywhere
- Search for report_invoice
- Open it
- Traceback
This is caused by the div inside the table, this is incorrect in HTML
See https://html.spec.whatwg.org/multipage/tables.html#the-table-element
replace with a tr/td
opw-4369019This fixes the maximum mobility budget amount used in Belgian payroll calculations. It helps ensure payroll results follow the correct legal limit and reduces the risk of incorrect employee compensation calculations.
Fixed an issue where sharing one error dialog could also trigger sharing actions for other stacked error dialogs. This prevents duplicate link copies and notifications, making error sharing clearer and less confusing for users.
Original PR description
This commit fixes an issue with the sharing functionality of the error dialogs where if multiple of these were stacked onto each other, the share button would trigger the URL copy and notification for all errors instead of only the relevant one.
This fix makes India reporting more efficient by only loading the accounting information it actually needs. It helps prevent memory errors for customers with very large accounting databases, improving report reliability.
Original PR description
_compute_l10n_in_transaction_type fetches all columns of account_move but we need only few columns. And account_move table is usually large in client database which can lead to memory_error. The database in question has: ``` select COUNT(*) from account_move +---------+ | count | |---------| | 3447401 | +---------+ ```
This fixes an error that prevented payroll users from generating Mexican payslips when using a newly created salary structure. The change adds a safe fallback so payslip creation can continue instead of failing with a system error.
Original PR description
Using a newly created payslip structure for Mexico it is not possible to generate payslips Steps to reproduce: - With an MX Company setup - Go to Payroll > Configuration > Salary > Structures - Create new structure with the following attributes: - Type: "Mexico: employee" - Country: "Mexico" - Go to Payroll > Payslips > Batches, create a new batch - Click "Generate Payslips" - Select the freshly created salary structure in the wizard, then click "Generate" Issue: An error is raised while creating the payslip Error: float() argument must be a string or a real number, not 'NoneType' This occurs because we don't have a fallback in `_get_paid_amount` opw-4328900
Fixes Belgian payroll social balance sheet reporting so traineeships are handled correctly. It also restores the yearly summary, helping businesses produce complete and accurate statutory HR payroll reports.
This update prevents subscription sales orders from comparing empty date fields. It helps avoid unnecessary errors when start or next invoice dates have not yet been set.
Original PR description
The fields start_date and next_invoice_date of sale.order can be null. We only want to compare to dates. So its better to check that the dates are not null before comparing them.
This update prevents already signed signature fields from being dragged when reviewing or completing documents in Odoo Sign. It reduces accidental movement of signed content and makes the signing experience more reliable for users.
This change updates automated tests for the Documents Spreadsheet pivot side panel to match a recent spreadsheet interaction fix. It helps keep quality checks reliable so future updates do not accidentally reintroduce issues around focusing spreadsheet elements.
Original PR description
The hoot dom helpers rely on a single 'pointerdown' to focus its node which is precisely the behaviour that we act upon in https://github.com/odoo/o-spreadsheet/commit/85aaab61dd3fc4ea2a8c10f9e70b8e7fa650f170
The Belgian payroll calculation now separates the employment bonus into two sections, aligning payslips and related accounting validation with the expected structure. This helps payroll teams review and report the bonus more accurately while reducing the risk of incorrect payslip totals or categorization.
Features or functions removed from Odoo
The Sales Commission module no longer includes a temporary workaround that is no longer needed. The underlying issue has been fixed elsewhere, reducing unnecessary complexity while keeping the expected behavior intact.
Original PR description
Remove the workaround introduced in https://github.com/odoo/enterprise/pull/76546 because the root cause has been fixed in the linked community PR. https://github.com/odoo/odoo/pull/193256
Miscellaneous changes
Steps to reproduce the bug: - Create a workcenter: Problem: All the resource calendar from all the companies are displayed. opw-4478393 Forward-Port-Of: odoo/odoo#193634
Original PR description
Steps to reproduce the bug: - Create a workcenter: Problem: All the resource calendar from all the companies are displayed. opw-4478393 Forward-Port-Of: odoo/odoo#193634
Versions -------- - 17.0+ Steps ----- 1. Create a pricelist with 200 price rules; 2. export pricelist to xlsx; 3. delete original pricelist; 4. import pricelist, setting batch size to 100. Test files ready for import: - [200_products.xlsx](https://github.com/user-attachments/files/17848187/200_products.xlsx) - [200_pricelist_rules.xlsx](https://github.com/user-attachments/files/17848188/200_pricelist_rules.xlsx) Issue ----- Pricelist is imported with 400 price rules. Cause
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a pricelist with 200 price rules; 2. export pricelist to xlsx; 3. delete original pricelist; 4. import pricelist, setting batch size to 100. Test files…
Versions -------- - 17.0+ Steps ----- 1. Create a pricelist with 200 price rules; 2. export pricelist to xlsx; 3. delete original pricelist; 4. import pricelist, setting batch size to 100. Test files ready for import: - [200_products.xlsx](https://github.com/user-attachments/files/17848187/200_products.xlsx) - [200_pricelist_rules.xlsx](https://github.com/user-attachments/files/17848188/200_pricelist_rules.xlsx) Issue ----- Pricelist is imported with 400 price rules. Cause ----- The back-end signals there's nothing left to import by having `nextrow` be falsy[^1]. The front-end ignores this, and continues looping until it's taken as many steps as it initially planned. The upfront `totalSteps` calculation is too high when an imported record has a number of nested relational records that's larger than the batch size. Solution -------- If the ORM returns a falsy `nextrow` value, call `stopImport`. opw-4164056 [^1]: see note on f58368210c9c Forward-Port-Of: odoo/odoo#193817 Forward-Port-Of: odoo/odoo#188092
Description of the issue this PR addresses: I. Commit [1] handled cases of pressing enter at the edge of an anchor, which is a child of an unbreakable element. The commit inserted the `br`'s after anchors; however, it missed the situation where the anchor tags are block elements nested inside an unbreakable element inside a `li`. In this specific case, inserting two `br` tags after a anchor block resulted in the creation of two new lines. This PR handles that case by only inserting one `
Original PR description
Description of the issue this PR addresses: I. Commit [1] handled cases of pressing enter at the edge of an anchor, which is a child of an unbreakable element. The commit inserted the `br`'s after…
Description of the issue this PR addresses: I. Commit [1] handled cases of pressing enter at the edge of an anchor, which is a child of an unbreakable element. The commit inserted the `br`'s after anchors; however, it missed the situation where the anchor tags are block elements nested inside an unbreakable element inside a `li`. In this specific case, inserting two `br` tags after a anchor block resulted in the creation of two new lines. This PR handles that case by only inserting one `br` tag after the anchor, rather than both. II. Previously when changing selection between links in website, when clicking on a link the previous link used to get selected. This commit makes sure that when changing selection in between links it selects the correct link. III. This PR ensures that the link popover closes when the cursor moves outside the link. [1]: https://github.com/odoo/odoo/commit/df6f8dd0c54c40ea7edbd3821ae068d79b1b7af7 task-3631910 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192761 Forward-Port-Of: odoo/odoo#171469
Before this commit, if there was a custom one2many field with the same related field as an existing one, it would cause issues in PoS when capturing an order. For example, if there was a custom field in pos.order with a related field of order_id, adding products to the order would not show them in the order summary. opw-4462991 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193041
Original PR description
Before this commit, if there was a custom one2many field with the same related field as an existing one, it would cause issues in PoS when capturing an order. For example, if there was a custom field in pos.order with a related field of order_id, adding products to the order would not show them in the order summary. opw-4462991 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193041
Before this commit, when a time off request based on extra hours was set to draft, a new overtime record with negative duration was created. This commit makes sure that the record is only created when the time off request is in the state confirm or validate. task-4096548 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189711 Forward-Port-Of: odoo/odoo#185962
Original PR description
Before this commit, when a time off request based on extra hours was set to draft, a new overtime record with negative duration was created. This commit makes sure that the record is only created when the time off request is in the state confirm or validate. task-4096548 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189711 Forward-Port-Of: odoo/odoo#185962
_* = website_crm, website_project, website_hr_recruitment - This commit reverts [#128964 ](https://github.com/odoo/odoo/pull/128964)because the feature has been made in generic instead of doing it in project and helpdesk which is caused some issues in other models using website form feature. Also, the feature adds more complexity to just add a warning in the task description and in a message linked to the task generated to notify the user the task has been generated from an external submiss
Original PR description
_* = website_crm, website_project, website_hr_recruitment - This commit reverts [#128964 ](https://github.com/odoo/odoo/pull/128964)because the feature has been made in generic instead of doing it in project and helpdesk which is caused some issues in other models using website form feature. Also, the feature adds more complexity to just add a warning in the task description and in a message linked to the task generated to notify the user the task has been generated from an external submission (when the email set in the website form is not the one set on the user who submits the form) since the feature used the email set to search the partner to set on the task. task-4295363 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192322
**Behaviour before PR:** In website, in some snippets font-size of paragraph like elements is not displayed correctly in toolbar. This issue happens because in `getFontSizeDisplayValue` method if there is no font-size class applied to element then it will set the value of `--font-size-base` css variable which is `16px`. **Behaviour after PR is merged:** Now, `getFontSizeDisplayValue` method will set font-size using `getComputedStyle` if there is no font related class is applied to that
Original PR description
**Behaviour before PR:** In website, in some snippets font-size of paragraph like elements is not displayed correctly in toolbar. This issue happens because in `getFontSizeDisplayValue` method if there is no font-size class applied to element then it will set the value of `--font-size-base` css variable which is `16px`. **Behaviour after PR is merged:** Now, `getFontSizeDisplayValue` method will set font-size using `getComputedStyle` if there is no font related class is applied to that element. task-4420329 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191577
Versions -------- - 16.0 (fix issue) - 17.0+ (skip useless constraint) Commit 3871ae2c6c45 enabled automated m2m CRUD in 17.0+ Steps ----- 1. Create an automated action on a Model with tags (e.g. Contact); 2. set trigger to On Creation; 3. in data to write, have evaluation type to Value; 4. fill in the value (e.g. 1); 5. create a record that would trigger the automation. Issue ----- > ValueError: Wrong value for res.partner.category_id: 1 Cause ----- In the `eval_value`
Original PR description
Versions -------- - 16.0 (fix issue) - 17.0+ (skip useless constraint) Commit 3871ae2c6c45 enabled automated m2m CRUD in 17.0+ Steps ----- 1. Create an automated action on a Model with tags (e.g.…
Versions -------- - 16.0 (fix issue) - 17.0+ (skip useless constraint) Commit 3871ae2c6c45 enabled automated m2m CRUD in 17.0+ Steps ----- 1. Create an automated action on a Model with tags (e.g. Contact); 2. set trigger to On Creation; 3. in data to write, have evaluation type to Value; 4. fill in the value (e.g. 1); 5. create a record that would trigger the automation. Issue ----- > ValueError: Wrong value for res.partner.category_id: 1 Cause ----- In the `eval_value` method, the `many2many` type doesn't get covered. Solution -------- 1. Have `eval_value` handle `many2many` values (linking them to relevant record, and existing as a single expression per column). 2. Undo 09a6df204f2a which disallowed writing by reference for many2many fields. This change makes writing by reference possible as well, and allows you to select the desired record, instead of having to manually fill in its ID. opw-4054461 Forward-Port-Of: odoo/odoo#193610 Forward-Port-Of: odoo/odoo#190047
Fonctionnal changes: - Add a `Clear cache` button in debug mode to allow Android and IOS devices to clear the cache easily. - Ensure that the splitting and transferring of orders works correctly when the order is sent to the server. Technical changes: - Ensure that change quantities are numbers (technical change). - Do not send items that wasn't sent to the preparation display when reaching the receipt screen. - When deleting all orderlines with backspace on the product_screen and cl
Original PR description
Fonctionnal changes: - Add a `Clear cache` button in debug mode to allow Android and IOS devices to clear the cache easily. - Ensure that the splitting and transferring of orders works correctly when the order is sent to the server. Technical changes: - Ensure that change quantities are numbers (technical change). - Do not send items that wasn't sent to the preparation display when reaching the receipt screen. - When deleting all orderlines with backspace on the product_screen and clicking on release table, cancel the order if it was sent to the server Forward-Port-Of: odoo/odoo#193024
Devices detected through usb don't always have there manufactured and product name which can be retrieved. For example, our foot pedal in the office doesn't which leads to it having a name `"None - None"` in Odoo. After this PR if a device doesn't have a product name / manufacturer name it will be saved as `"Unknown input device"` task-4472585 Forward-Port-Of: odoo/odoo#193295 Forward-Port-Of: odoo/odoo#193277
Original PR description
Devices detected through usb don't always have there manufactured and product name which can be retrieved. For example, our foot pedal in the office doesn't which leads to it having a name `"None - None"` in Odoo. After this PR if a device doesn't have a product name / manufacturer name it will be saved as `"Unknown input device"` task-4472585 Forward-Port-Of: odoo/odoo#193295 Forward-Port-Of: odoo/odoo#193277
Since commit 567b8d676b3b6dc747df4d9bf10e7a91b4cb61bb It used to insert a placeholder when the data is not there but we won't on real report 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#193531
Original PR description
Since commit 567b8d676b3b6dc747df4d9bf10e7a91b4cb61bb It used to insert a placeholder when the data is not there but we won't on real report 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#193531
To run tours or unit tests, we instrument Chrome and run it headlessly. One of the arguments passed while doing so is the "window size" it needs to use to emulate desktop-like or mobile-like screen sizes. Newer versions of Chrome sometimes introduce slight variation between the Chrome's window size and its viewport size (due to changes in the interface layout...). While often not a deal-breaker, Chrome 128 forces a min-width for the window greater than the breakpoint we use for smaller/
Original PR description
To run tours or unit tests, we instrument Chrome and run it headlessly. One of the arguments passed while doing so is the "window size" it needs to use to emulate desktop-like or mobile-like screen…
To run tours or unit tests, we instrument Chrome and run it headlessly. One of the arguments passed while doing so is the "window size" it needs to use to emulate desktop-like or mobile-like screen sizes. Newer versions of Chrome sometimes introduce slight variation between the Chrome's window size and its viewport size (due to changes in the interface layout...). While often not a deal-breaker, Chrome 128 forces a min-width for the window greater than the breakpoint we use for smaller/mobile-like testing (e.g. 375px, which matches a small smartphone). This commit changes the way we instrument Chrome to use a specific size by using the DevTools' Emulated Device (aka. "responsive mode"). It allows to apply a very specific viewport's size independently of the actual Chrome's window size, which makes it way more predictable than before. Note: this change is part of the preparation to support the "new" headless mode, which becomes the default starting with Chrome 128. Reference: - https://chromedevtools.github.io/devtools-protocol/tot/Emulation/#method-setDeviceMetricsOverride Forward-Port-Of: odoo/odoo#193847 Forward-Port-Of: odoo/odoo#193696
Description of the issue/feature this PR addresses: This PR addresses the issue where the currency column repeats in view_move_line_payment_tree view when there are multiple active currencies. This can lead to confusion and clutter in the user interface. Current behavior before PR: Before this PR, when multiple active currencies are set up, the currency column is duplicated in view_move_line_payment_tree view, displaying the same information multiple times. Desired behavior after PR is m
Original PR description
Description of the issue/feature this PR addresses: This PR addresses the issue where the currency column repeats in view_move_line_payment_tree view when there are multiple active currencies. This can lead to confusion and clutter in the user interface. Current behavior before PR: Before this PR, when multiple active currencies are set up, the currency column is duplicated in view_move_line_payment_tree view, displaying the same information multiple times. Desired behavior after PR is merged: After merging this PR, the currency column will appear only once when the optional hide setting is enabled, even with multiple active currencies, resulting in a cleaner and more readable report. [Video](https://drive.google.com/file/d/1bL8L88y81HomX6Q9MkErmOGVDWHdE4_r/view) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193189 Forward-Port-Of: odoo/odoo#192784
Before this commit, when splitting an order, the preparation changes were not correctly applied to the new order and modified on the original one. This commit fix the issue. Forward-Port-Of: odoo/odoo#193734
Original PR description
Before this commit, when splitting an order, the preparation changes were not correctly applied to the new order and modified on the original one. This commit fix the issue. Forward-Port-Of: odoo/odoo#193734
Steps to reproduce: Not reproducible in V16. However, in older versions, it was possible to have multiple finished_moves with different quantities (see https://github.com/odoo/odoo/pull/46718). This fix ensures such issues are avoided in the future and also addresses potential problems for clients migrating from older versions. Example: Two finished_moves with different quantities. Before the fix, both moves would be updated based on the unbuild quantity, resulting in incorrect quantit
Original PR description
Steps to reproduce: Not reproducible in V16. However, in older versions, it was possible to have multiple finished_moves with different quantities (see https://github.com/odoo/odoo/pull/46718). This fix ensures such issues are avoided in the future and also addresses potential problems for clients migrating from older versions. Example: Two finished_moves with different quantities. Before the fix, both moves would be updated based on the unbuild quantity, resulting in incorrect quantities. After the fix, the moves for unbuild will use only the move's quantity. opw-4379204 Forward-Port-Of: odoo/odoo#193777 Forward-Port-Of: odoo/odoo#191908
Steps to reproduce: - Go to a form view with a one2many with a handle widget - Move a line in the one2many that make Odoo crash with the onchange To generate a faulty view, create a form view with a one2many and add an automation "On UI change" to make the resequence crash. Current behaviour ----------------- After the error being thrown, the user will not be able to resequence this line again. Expected Behaviour ------------------ After the error, the user will still be able to r
Original PR description
Steps to reproduce: - Go to a form view with a one2many with a handle widget - Move a line in the one2many that make Odoo crash with the onchange To generate a faulty view, create a form view with a one2many and add an automation "On UI change" to make the resequence crash. Current behaviour ----------------- After the error being thrown, the user will not be able to resequence this line again. Expected Behaviour ------------------ After the error, the user will still be able to resequence this line Forward-Port-Of: odoo/odoo#190318 Forward-Port-Of: odoo/odoo#157539
Steps to reproduce ================== - Open any project - Create many project stages (80+) - Switch to the list view - Group by stage - Switch to to next page => The pager keeps increasing Cause of the issue ================== `stage_id` has a group_expand: `_read_group_stage_ids` This method is used to include empty stages in the result for the kanban view, so that we can drag tasks to an empty stage. Solution ======== Add a context key `project_kanban` and only add em
Original PR description
Steps to reproduce ================== - Open any project - Create many project stages (80+) - Switch to the list view - Group by stage - Switch to to next page => The pager keeps increasing Cause of the issue ================== `stage_id` has a group_expand: `_read_group_stage_ids` This method is used to include empty stages in the result for the kanban view, so that we can drag tasks to an empty stage. Solution ======== Add a context key `project_kanban` and only add empty stages in that case. opw-4408061 Forward-Port-Of: odoo/odoo#193488 Forward-Port-Of: odoo/odoo#192492
Interfaces/Drivers inherit from an `Interface`/`Driver` class. These parent classes should not be registered as an actual interface/driver. This is now filterered at instanciation in order to avoid looping over useless elements later. Forward-Port-Of: odoo/odoo#193510
Original PR description
Interfaces/Drivers inherit from an `Interface`/`Driver` class. These parent classes should not be registered as an actual interface/driver. This is now filterered at instanciation in order to avoid looping over useless elements later. Forward-Port-Of: odoo/odoo#193510
Fixes an issue where splitting an order line with a decimal quantity (e.g., 2.5) would cause indefinite increments in the split bill screen. This adds a check to ensure the split quantity does not exceed the original order line quantity. task-id: 4461861 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:
Original PR description
Fixes an issue where splitting an order line with a decimal quantity (e.g., 2.5) would cause indefinite increments in the split bill screen. This adds a check to ensure the split quantity does not exceed the original order line quantity. task-id: 4461861 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#193514
The cloc_exclude entry of the manifest was activated for data modules*, and it works for records with a new id. But it fails for records with external ids from another module, as it tries to lookup for a record with an xmlid like `new_module.external_module.id`, which is not a valid xmlid. This commit fixes the issue by first checking if the record to exclude from cloc is from another module or not, before creating the ir_model_data entry. *https://github.com/odoo/odoo/commit/a47de680de149
Original PR description
The cloc_exclude entry of the manifest was activated for data modules*, and it works for records with a new id. But it fails for records with external ids from another module, as it tries to lookup for a record with an xmlid like `new_module.external_module.id`, which is not a valid xmlid. This commit fixes the issue by first checking if the record to exclude from cloc is from another module or not, before creating the ir_model_data entry. *https://github.com/odoo/odoo/commit/a47de680de149a60dd479c4c0b14f2c1bf5afcbe opw-4472893 Forward-Port-Of: odoo/odoo#193592
Steps to reproduce: - Open planning app and click on New. - A form is opened and searched for a material resource in the Resource field ex. Crane - An empty photo icon is displayed in the selection bar. Issue: - An empty photo icon is being displayed instead of a wrench. Cause: - Many2XAutocomplete which adds an image in the many2one selection field is not modified to display - the wrench icon in the many2one_avatar_resource_field. Solution: - A similar modification is do
Original PR description
Steps to reproduce: - Open planning app and click on New. - A form is opened and searched for a material resource in the Resource field ex. Crane - An empty photo icon is displayed in the selection bar. Issue: - An empty photo icon is being displayed instead of a wrench. Cause: - Many2XAutocomplete which adds an image in the many2one selection field is not modified to display - the wrench icon in the many2one_avatar_resource_field. Solution: - A similar modification is done in many2many_avatar_resource_field through class which extends Many2XAutocomplete which can be imported and added into components of many2one_avatar_resource_field. fix the alignment between of icon and text in many2many_avatar_resource. task-3801551 Forward-Port-Of: odoo/odoo#193083 Forward-Port-Of: odoo/odoo#157968
Steps to reproduce: - Go to the "/blog/astronomy-2/what-if-they-let-you-run-the-hubble-5" page. - Click on the "Mobile Preview" button. - Bug: The breadcrumb is broken. In stable versions, we fixed this in the least intrusive way possible to avoid making significant layout changes to existing databases. **BEFORE:** <kbd></kbd> **AFTER:** <kbd>![2025-01-14_09-53](https://github.com/
Original PR description
Steps to reproduce: - Go to the "/blog/astronomy-2/what-if-they-let-you-run-the-hubble-5" page. - Click on the "Mobile Preview" button. - Bug: The breadcrumb is broken. In stable versions, we fixed this in the least intrusive way possible to avoid making significant layout changes to existing databases. **BEFORE:** <kbd></kbd> **AFTER:** <kbd></kbd> In master version, in mobile view, we replaced the breadcrumb with a "< All Blogs" button to return to the blogs list, similar to what is done in "website_sale" and "website_event". opw-4457408 Forward-Port-Of: odoo/odoo#193508
Steps: - Go to the 'Activity Plans' section. - Select a company in the company widget. - Activity plans were not filtered based on the selected company. Issues: - Activity plans were not filtered correctly by the selected company, showing plans from unrelated companies. Fix: - Added domain to display activity plans assigned to the selected company. - Added domain to display global activity plans when no company is selected. Task - 4441838 Description of the issue/feature this P
Original PR description
Steps: - Go to the 'Activity Plans' section. - Select a company in the company widget. - Activity plans were not filtered based on the selected company. Issues: - Activity plans were not filtered correctly by the selected company, showing plans from unrelated companies. Fix: - Added domain to display activity plans assigned to the selected company. - Added domain to display global activity plans when no company is selected. Task - 4441838 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: Forward-Port-Of: odoo/odoo#192171
### Before -When the eFactura status was fetched and there was an invoice content error it was not displayed. This issue was due to both the overlooking of: - the 'nok' status (sent back by the Romanian authorities regarding the presence of errors in the invoice content) - the file provided in the zip that would contain the errors -The error message shown would also only contain the first error even if many were present. ### Now -If the status fetched contains 'nok' and is theref
Original PR description
### Before -When the eFactura status was fetched and there was an invoice content error it was not displayed. This issue was due to both the overlooking of: - the 'nok' status (sent back by the Romanian authorities regarding the presence of errors in the invoice content) - the file provided in the zip that would contain the errors -The error message shown would also only contain the first error even if many were present. ### Now -If the status fetched contains 'nok' and is therefore signaling the presence of invoice content errors, then the apposite error file is chosen instead of the file with the electronic signature. This allows for following logic to account for errors, to retrieve the error message and to provide the error file as the downloadable document. -The pop up shows all the errors with an increased width to account for more content. task-4306506 Forward-Port-Of: odoo/odoo#190618
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.6.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193722
Original PR description
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.6.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193722
Steps to Reproduce: ----------------------------------------------- 1. Install the `planning` module. 2. Create a shift from `8:00 AM to 9:30 AM` for any resource. The allocated hours will show as `1:30`. 3. Go to the list view and print the planning report. 4. In the report, you will notice that the allocated hours are rounded up to `2` Issue: ----------------------------------------------- - The allocated hours are being rounded up to a higher value but it should match
Original PR description
Steps to Reproduce:
-----------------------------------------------
1. Install the `planning` module.
2. Create a shift from `8:00 AM to 9:30 AM` for any resource. The allocated
hours will show as `1:30`.
3. Go to the list view and print the planning report.
4. In the report, you will notice that the allocated hours are rounded
up to `2`
Issue:
-----------------------------------------------
- The allocated hours are being rounded up to a higher value but it should match
with the UI and stay consistent.
Cause:
-----------------------------------------------
- The `ceil` function is being used, which rounds the value up to the next
higher number.
Fix:
-----------------------------------------------
- In this commit we removed the `ceil` function to ensure that the allocated
hours are not rounded up.
task-4416792
Forward-Port-Of: odoo/enterprise#77110
Forward-Port-Of: odoo/enterprise#76198task-4295363 Forward-Port-Of: odoo/enterprise#76449
Original PR description
task-4295363 Forward-Port-Of: odoo/enterprise#76449
This pull request is marked as a work in progress and does not include enough detail to identify a specific business change. Based on the available information, the impact and affected areas are unclear and should be reviewed once the description or file changes are provided.
Original PR description
TODO: PR message
* is l10n_{au,be,ch,hk,lu,ma,us}_hr_payroll - When miltiple companies it shows `X Localization` block only in payroll settings Where X is the cuntry of the current chosien company Task: 4409568 Forward-Port-Of: odoo/enterprise#75683
Original PR description
* is l10n_{au,be,ch,hk,lu,ma,us}_hr_payroll
- When miltiple companies it shows `X Localization` block only in payroll settings Where X is the cuntry of the current chosien company
Task: 4409568
Forward-Port-Of: odoo/enterprise#75683This file was not loaded in the manifest and is a duplicated of `/mrp_account_enterprise/views/cost_structure_report.xml` Forward-Port-Of: odoo/enterprise#77177
Original PR description
This file was not loaded in the manifest and is a duplicated of `/mrp_account_enterprise/views/cost_structure_report.xml` Forward-Port-Of: odoo/enterprise#77177
Before this commit, when editing a default value for a field, it was always setting th default on the company of the user (as set on the user), not on the current company the user is logged into. This was largely misleading. After this commit, we get and set the default on the current company. Some work need to be done in master to improve those flows. opw-4427384 Forward-Port-Of: odoo/enterprise#77015 Forward-Port-Of: odoo/enterprise#76819
Original PR description
Before this commit, when editing a default value for a field, it was always setting th default on the company of the user (as set on the user), not on the current company the user is logged into. This was largely misleading. After this commit, we get and set the default on the current company. Some work need to be done in master to improve those flows. opw-4427384 Forward-Port-Of: odoo/enterprise#77015 Forward-Port-Of: odoo/enterprise#76819
task-4285805 Forward-Port-Of: odoo/enterprise#77108 Forward-Port-Of: odoo/enterprise#76950
Original PR description
task-4285805 Forward-Port-Of: odoo/enterprise#77108 Forward-Port-Of: odoo/enterprise#76950
Changes in enterprise related to PR https://github.com/odoo/odoo/pull/157968 Added the resource_color as dependency for the widget to display the color task-3801551 Forward-Port-Of: odoo/enterprise#76835 Forward-Port-Of: odoo/enterprise#70453
Original PR description
Changes in enterprise related to PR https://github.com/odoo/odoo/pull/157968 Added the resource_color as dependency for the widget to display the color task-3801551 Forward-Port-Of: odoo/enterprise#76835 Forward-Port-Of: odoo/enterprise#70453