Daily updates from Odoo
Monday, October 28, 2024
59 changes · 18.0
Enhancements to existing features
The chatter search experience now opens the search field directly in place, keeping the conversation visible until the user starts searching. This makes it easier for users to look up messages without losing context in the thread.
Original PR description
Purpose of this commit: Previously, to search for a message in the chatter, users needed to click the search icon, which would open the search panel and hide the thread. With this update, clicking the search icon now opens only the search input, keeping the thread visible until the user actively begins a search taskid-4260440 Backport of https://github.com/odoo/odoo/pull/185301
The event badge printing setup now keeps only the supported 96x82mm Epson badge format and removes the unsupported 96x134mm option. Printed badge notifications also show the badge type, such as VIP or Standard, making it clearer which badge was produced.
Original PR description
in this [PR](https://github.com/odoo/odoo/pull/179903) configured two badge formats for the EPSON C4000e printer: - 96x82mm, - 96x134mm. As we don't have a dedicated proper template for the 96x134mm format, we remove it. In addition, we added the badge type (e.g. VIP, Standard, ...) in the notification displayed once a badge is printed. Tasks: 4231455, 4229143
Online delivery orders now handle discounts and taxes on extra charges such as packaging fees more accurately. Rider status updates from delivery platforms are also aligned with the latest data format, helping restaurants keep order tracking reliable.
Original PR description
In this commit: === - Discounts for online delivery orders are now handled. - Tax is now applied to charges (e.g., packaging charges). - The rider_status_updated payload has been updated. task-4075113
Resolved issues and error corrections
This fix prevents an error that could occur when the customer credit field is added to an invoice form through Studio. It updates the sales invoice logic to use the current tax total value, keeping customized invoice views from crashing.
Original PR description
Currently, a traceback occurs when the user tries to add the `partner_credit` field to the form view of the `account.move` through the studio. Error:- ``` KeyError: 'amount_total' ``` This error is…
Currently, a traceback occurs when the user tries to add the `partner_credit` field to the form view of the `account.move` through the studio. Error:- ``` KeyError: 'amount_total' ``` This error is occurring because the `amount_total` was removed from the `tax_taotals` from the commit [1]. A major refactor was done to compute the tax_totals from [1] [1] https://github.com/odoo/odoo/commit/d0e7be7832672d476f1b289af52d3a425990d719 We can resolve this issue by taking the `total_amount_currency` from tax_totals Note:- However, the actual problem was the field and the compute method itself. Initially the field `partner_credit` was used for building the warning from [2] [2] https://github.com/odoo/odoo/commit/7bd93cc64b582cdd559a6b6f855c1950a992df68#diff-1e3bd6be3bfb83a37ec9fb800ce8b1c95afe0be90ff792874ae7299c320a2f6eR1383 But later it was removed from the commit [3] [3] https://github.com/odoo/odoo/pull/126575/commits/32954ca0ae54752073c7b5ae46793d1f2e34f0d1#diff-1e3bd6be3bfb83a37ec9fb800ce8b1c95afe0be90ff792874ae7299c320a2f6eL1416 So the field `partner_credit` was neither used in the Python side nor used in the XML side also. which is completely dead code and has never been executed. We should remove both the field and compute method in the master sentry-5987829118
The product demo import templates have been updated so they match the current product fields and sample data. This prevents users from running into errors when using the provided spreadsheet templates and adds a safeguard to keep them valid in future updates.
Original PR description
The demo import templates of the product module were not adapted to recent changes to fields and demo data. This commit makes sure the xls are valid, and adds a test to ensure they are adapted in the future when needed. Fixes #185430
The product import template has been corrected to use the current "Goods" product type instead of the outdated "consumable" value. This prevents import failures when users download the sample template and import it back into Odoo.
Original PR description
before this commit, in the import template of product the type is recorded as consumable, which is no longer valid and when user try to import into system the import will be valid * open import for product * export the import template * import it back, import wont work after this commit, the given sample template is update with Goods instead of consumable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix updates several help and documentation links so they open the Odoo 18.0 documentation instead of the older 17.0 pages. Users are less likely to land on outdated guidance when looking for product, website link, or localization documentation.
Original PR description
before this commit, many of the url is pointing to 17.0 after this commit, the url will point to 18.0 documentation link Enterprise: https://github.com/odoo/enterprise/pull/72858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A small typo in an automated test setup was corrected so invoice-related snail mail tests run reliably again. This helps maintain confidence that sending invoices by post still works for partners who do not have an email address.
Original PR description
Since pr https://github.com/odoo/odoo/commit/9e769e1b11f2 there was a typo, causing tests to break because value of country_id was missing .id at the end. This commit fixes the issue.
Fixes an error that occurred when HR users selected multiple employees and chose “Create a Time Off” from the Presence Control menu. The action now uses the appropriate multi-employee wizard, allowing time off to be created for several employees without a system traceback.
Original PR description
Steps: - Install the hr_presence module - open employee list view - Click on the `Create a Time Off` from Presence Control Menu Description of the issue/feature this PR addresses: In the HR module, When selecting multiple employees from the list view and clicking `Create a Time Off` in the Presence Control menu, a traceback error occurs. Cause: The error is caused by opening the hr.leave form view, which contains the employee_id field that allows the selection of only one employee. Since multiple employees are selected, a singleton error is triggered. Fix: This PR resolves the issue by updating the wizard of the model `hr.leave.generate.multi.wizard`, enabling the creation of time off for multiple employees. task-4207392
Selected course tags now keep their intended colors when learners filter courses, instead of appearing plain until hovered. This makes the course filtering experience clearer and more consistent with the main course listing page.
Original PR description
After this commit https://github.com/odoo/odoo/commit/b4a5bf03cd81ece2a7fd21a3c5a058ee2d3336fe , we have to hover on tags to see solid/bg colors. Here, the selected tag's color is 'primary' but due to hovering behavior, it will display similar to `o_color_0`, unless user hover on the tag. This PR modify selected tags colors to `tag.color` used in 'All courses' page Task-4274049
Fixed an issue that prevented users from downloading payment receipts in certain vendor payment setups. The receipt now uses the correct payment reference information, avoiding an error page and allowing accounting teams to retrieve receipts as expected.
Original PR description
1. Create a new Account called "Outstanding Payment". 2. Create a new Bank Journal and adde the new account in the Outgoing Payment tab. 3. Create a Vendor Bill, add partner details, product, date and confirm. 4. Process the payment using the newly created Bank Journal. 5. Opened the payment record. 6. Attempted to download the payment receipt. Traceback will raise ``` odoo.addons.base.models.ir_qweb.QWebException: Error while render the template KeyError: 'memo' Template: account.report_payment_receipt_document Path: /t/t/div[1]/table/tbody/t/t/tr[2]/td[3]/span Node: <span t-field="payment.move_id.memo"/> ``` It occurs because the field `memo` is defined on the payment and not on the move opw-4280508
This update adjusts several automated website and messaging test flows so they first move over page elements before clicking them. This helps ensure the elements are visible and ready, reducing false test failures without changing customer-facing functionality.
Original PR description
In this commit, we use "hover" action in run to ensure element are visible before clicking on it.[REF] brol 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
Spreadsheet pivots now avoid reloading data when users add or remove computed measures, because those changes do not require fetching data again. This improves responsiveness while still refreshing data when real source measures are added, removed, or changed.
Original PR description
Before this commit, the pivot was reloaded even when the user add or remove a computed measure, which does not require a new data fetch. With this commit, the data is only re-fetched only when the user makes some changes on the measures that require a new data fetch: - Add/remove a non-computed measure - Update the fieldName or aggregator of a non-computed measure Task: 4210672 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
The website SEO optimization screen no longer crashes when a blog's name has been removed. This helps website editors continue managing SEO settings reliably even when blog details are incomplete.
Original PR description
Steps to reproduce: --- - Install the ``website_blog`` module - Click on ``Blog`` > Open editor > Click on blog name(eg: Travel) - Remove that blog name and Save Traceback: --- ``TypeErrornormalize() argument 2 must be str, not bool`` This error comes after this commit https://github.com/odoo/odoo/commit/25abac896f53240b08dd38a89110ec811132ee1d Previous Behaviour: --- When trying to open optimize SEO without a blog name at [1] we are getting ``record.display_name`` as false. [1]- https://github.com/odoo/odoo/blob/e4a4806e5c58c599815204a73c78a228ee230613/addons/website/controllers/main.py#L785-L786 sentry-5967410495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Half-day time off entries now show the correct duration in calendar and Gantt reports instead of being reduced to an incorrect "00 hours" label. This helps HR users read leave schedules accurately when employee names are hidden.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a half-day leave of any type allowing custom hours; 2. open All Time Off in Gantt view. Issue ----- Leave is displayed as "00 hours". Cause ----- PR #177570 changed the way leave hours are displayed, from decimal to HH:MM. With the `hide_employee_name` context value set, the name of `hr.leave.report.calendar` records was computed by splitting on `':'`, and taking the last part. Before the hour formatting change, this was everything after the employee name. After the formatting change, only the "MM" part remains. Solution -------- We can remove the `_fetch_query` override which updates names in cache only, and instead add a `_compute_display_name` override, in turn using the `removeprefix` method added in Python 3.9 to reliably strip the employee name. opw-4274365
This fix prevents an error when a website page title is cleared and the page properties are saved. Users can now save changes without seeing a traceback, improving reliability in the website editor.
Original PR description
When the user tries to save page properties without a Page Title, a traceback will appear. Steps to reproduce the error: - Go to Website > Site > Properties > Remove the Page Title > Save & Close…
When the user tries to save page properties without a Page Title,
a traceback will appear.
Steps to reproduce the error:
- Go to Website > Site > Properties > Remove the Page Title > Save & Close
Traceback:
```
TypeError: normalize() argument 2 must be str, not bool
File "odoo/http.py", line 2364, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 728, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 70, in web_save
self.write(vals)
File "addons/website/models/website_page_properties.py", line 179, in write
write_result = super().write(vals)
File "odoo/models.py", line 4786, in write
fields[0].determine_inverse(real_recs)
File "odoo/fields.py", line 1478, in determine_inverse
determine(self.inverse, records)
File "odoo/fields.py", line 112, in determine
return needle(records, *args)
File "odoo/fields.py", line 724, in _inverse_related
target[field.name] = record_value[record]
File "odoo/models.py", line 7009, in __setitem__
return self._fields[key].__set__(self, value)
File "odoo/fields.py", line 1402, in __set__
records.write({self.name: write_value})
File "addons/website/models/website_page.py", line 158, in write
vals['key'] = self.env['website'].with_context(website_id=website_id).get_unique_key(self.env['ir.http']._slugify(vals['name']))
File "odoo/addons/base/models/ir_http.py", line 161, in _slugify
return cls._slugify_one(value, max_length=max_length)
File "odoo/addons/base/models/ir_http.py", line 154, in _slugify_one
uni = unicodedata.normalize('NFKD', value).encode('ascii', 'ignore').decode('ascii')
```
This error generates after this commit: https://github.com/odoo/odoo/commit/58705803a9e7ef0b0f5ff9e8b82d52ad1321b64a
https://github.com/odoo/odoo/blob/4b99aa4e48158ddc7cea8910c0f610e62778bc9c/addons/website/models/website_page.py#L158
When, user tries to save page properties without a page title,
``vals['name']`` will be False,
So, It will lead to the above traceback.
sentry-5989403584
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prZero-rated supplies under LUT will now appear correctly as exports without payment of tax in the GSTR spreadsheet. This fixes a reporting classification issue caused by unnecessary IGST tags, helping Indian localization tax reports better match expected GST treatment.
Original PR description
In GSTR spreadsheet the zero-rated supplies under lut are shown as `wopay` export type, earlier it was showing as `wpay` due to igst tags being applied on zero-rated lut taxes, that are unnecessary and as we don't need this items for gstr calculations hence igst tags are removed from this taxes. task-4263013
This change prevents an error when users edit and save email-related rich text fields in Safari on iOS, such as email signatures or quotation email subjects. It improves reliability for Safari users by ignoring a browser-unsupported formatting rule that could block saving.
Original PR description
Issue On Safari iOS, editing `html_mail` fields (such as "Email signature" in user profile or "Subject" in Quotation send by mail) throws an error: `@page is not a valid selector` at save. Change Add `@page` to the list of ignored selectors as it was done in commit 7b68c9eaf8ad94ecbcc3893bf6cc220b7e9b6636 as it is currently not supported by all browsers. opw-4256252
Fixes an issue in Manufacturing where clicking a subcontracting line in the bill of materials overview could show an error pop-up. Users can now expand subcontracting details smoothly, reducing interruptions when reviewing production setup.
Original PR description
When the user clicks on a subcontracting line in the BOM overview, an error is raised. This occurs because we are passing false when subcontracting lines are not folded, but a function is expected. The solution is to pass a function, which should be a void function when toggleFolded is false. Steps to Reproduce: 1. Go to the Manufacturing app. 2. Enable the Subcontracting feature in the Settings tab. 3. Navigate to the BoM overview in the Products tab. 4. Open a BoM that includes subcontracting. 5. Click to expand the subcontracting line. Previous Behaviour: An error pop-up appears. Current Behaviour: Opens without any error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents project scheduling tests from failing when the HR app is not installed. HR-dependent test coverage is moved to the HR-specific project module, keeping automated checks reliable without changing customer-facing behavior.
Original PR description
## [FIX] project_enterprise: avoid creating employee in test Before this commit, `:TestSmartSchedule.test_multi_users_tasks` test in `project_enterprise` module creates 2 employees but the problem is `hr` module is not in the dependencies of `project_enterprise` and so that test fails when `hr` is not installed. This commit adapts the test to make sure to not create any employees inside that test. ## [FIX] project_enterprise_hr: adds test_smart_schedule test Before this commit, the `test_multi_users_tasks` test defined in `/project_enterprise:TestSmartSchedule` failed when `hr` module is not installed since that test create 2 employees. This commit moves the test in `project_enterprise_hr` to make sure the test works as expected and we can create employee since `hr` is in the dependencies of `project_enterprise_hr` module. runbot-76567
Selecting a document no longer causes the control panel to visually flicker. The selection button now matches the height of neighboring buttons, creating a smoother and more stable experience for users.
Original PR description
Fix the flicker of the control panel when selecting a document. Remove the extra padding that was set around the current selection button so that its height matches the one of the other control panels buttons preventing the flicker. Task-4266281
This fix ensures Belgian payroll group sequence values are properly checked against the allowed maximum length. It prevents invalid sequence data from passing validation, reducing the risk of payroll export errors.
Original PR description
The check for the sequence of the group_s was always true because the length was not compared. Now it is compared to the max length of the sequence. task-4203261
Documentation links across several Odoo Enterprise modules have been corrected to point to the 18.0 documentation instead of the older 17.0 pages. This helps users access the right guidance for their current version and reduces confusion when following help links.
Original PR description
before this commit, many of the url is pointing to 17.0 after this commit, the url will point to 18.0 documentation link
Code cleanup and technical improvements
This change simplifies the internal structure used to run automated web tours by removing an extra conversion step. It should make the tour code easier for developers to understand and maintain, without changing the user-facing behavior of Odoo.
Original PR description
In this commit, we remove compileToMacro method from TourStepAutomatic class. The compileToMacro method complicates the understanding of how tours work. It is more obvious and above all simpler to directly return an object corresponding to the macro input (in TourAutomatic) rather than going through nested method calls. It also makes the TourStepAutomatic and TourAutomatic classes simpler and more understandable. (And this allows you to only have methods of less than 60 lines) 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
This refactoring streamlines how IoT Boxes communicate with Odoo databases across delivery, POS, manufacturing, and self-order workflows. It should make device connectivity easier to maintain and more consistent, reducing future complexity without introducing a new business feature.
Original PR description
The communication between the IoT Box and a DB can be: - Longpolling, - Websocket, - Simple fetch from one side or the other. We refactored all this in order to simplify the communication. Task: 4283647
Documentation and clarification updates
This pull request records the contributor license agreement signature for rom10811. It is an administrative compliance update that helps ensure contributions can be accepted under Odoo's contribution rules.
Original PR description
Description of the issue/feature this PR addresses: CLA sign for rom10811 Current behavior before PR: CLA not signed Desired behavior after PR is merged: CLA signed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Whe the user clicks on a subcontracting line in the BOM overview, an error is raised. This occurs because we are passing false when subcontracting lines are not folded, but a function is expected. The solution is to pass a function, which should be a void function when toggleFolded is false. Steps to reproduce: 1. Go to the Manufacturing app. 2. Enable the Subcontracting feature in the Setting tab. 3. Navigate to the BoM overview in the Products tab. 4. Open a BoM that includes subcontrac
Original PR description
Whe the user clicks on a subcontracting line in the BOM overview, an error is raised. This occurs because we are passing false when subcontracting lines are not folded, but a function is expected. The solution is to pass a function, which should be a void function when toggleFolded is false. Steps to reproduce: 1. Go to the Manufacturing app. 2. Enable the Subcontracting feature in the Setting tab. 3. Navigate to the BoM overview in the Products tab. 4. Open a BoM that includes subcontracting. 5. Click to expand the subcontracting line. Previous behaviour: An error pop-up appears. Current behaviour: Opens without any error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185467
When typing '>:)' in the composer, it should be replaced by '😈'. The problem is that the emoji generator doesn't work with '<', '>' because the text is escaped and the '<', '>'is replaced by '<', '>'. In this case, the regrex doesn't match. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185332 Forward-Port-Of: odoo/odoo#185091
Original PR description
When typing '>:)' in the composer, it should be replaced by '😈'. The problem is that the emoji generator doesn't work with '<', '>' because the text is escaped and the '<', '>'is replaced by '<', '>'. In this case, the regrex doesn't match. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185332 Forward-Port-Of: odoo/odoo#185091
When the language is not in the context the report will always show the en_US version. opw-4220270 Description of the issue/feature this PR addresses: Current behavior before PR: - translation is bypassed Desired behavior after PR is merged: - report will be shown in the correct language --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184538
Original PR description
When the language is not in the context the report will always show the en_US version. opw-4220270 Description of the issue/feature this PR addresses: Current behavior before PR: - translation is bypassed Desired behavior after PR is merged: - report will be shown in the correct language --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184538
**Prior to this commit:** - While configuring a pricelist, if we don't select any website in the Website field, the placeholder let us think that it should be applied on 'All websites'. **Post this commit:** - The placeholder is renamed as 'Select a website' as the pricelist doesn't apply to any website when the field is empty. **Affected version:** saas-17.4~master **opw**-4256656 Forward-Port-Of: odoo/odoo#185045
Original PR description
**Prior to this commit:** - While configuring a pricelist, if we don't select any website in the Website field, the placeholder let us think that it should be applied on 'All websites'. **Post this commit:** - The placeholder is renamed as 'Select a website' as the pricelist doesn't apply to any website when the field is empty. **Affected version:** saas-17.4~master **opw**-4256656 Forward-Port-Of: odoo/odoo#185045
Before this commit, the sales team could be missing from an order captured as draft due to writing a false value. opw-4230882 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184949
Original PR description
Before this commit, the sales team could be missing from an order captured as draft due to writing a false value. opw-4230882 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184949
This commit fixes an issue where the dynamic placeholder popover would not fully close upon pressing escape or clicking on the cross when a relation field was selected. This is because its previous condition for changing state instead of closing was if it had some field path selected upon closing the model field selector popover. This would not handle well the case where a relation is selected before closing. The fix is therefore to specify inside calls to the close function of the model field s
Original PR description
This commit fixes an issue where the dynamic placeholder popover would not fully close upon pressing escape or clicking on the cross when a relation field was selected. This is because its previous condition for changing state instead of closing was if it had some field path selected upon closing the model field selector popover. This would not handle well the case where a relation is selected before closing. The fix is therefore to specify inside calls to the close function of the model field selector popover whether it closed because a final value was selected or not. task-4066184 Forward-Port-Of: odoo/odoo#184907 Forward-Port-Of: odoo/odoo#184838
Issue: ====== Empty inline code block isn't working as expected and produces issues in the following flows: First Flow: - Create a note - Add ` 2 times - Delete forward 2 times - The button send message is modified!! Second Flow: - Log a note in the chatter of the note - Open composer - Add ` 2 times - Delete forwart 2 times - Traceback Origin of the issue: ===================== After adding the {backtick} 2 times, it will have the following html `<p>{backtick}[]<code cla
Original PR description
Issue: ====== Empty inline code block isn't working as expected and produces issues in the following flows: First Flow: - Create a note - Add ` 2 times - Delete forward 2 times - The button send…
Issue:
======
Empty inline code block isn't working as expected and produces issues in
the following flows:
First Flow:
- Create a note
- Add ` 2 times
- Delete forward 2 times
- The button send message is modified!!
Second Flow:
- Log a note in the chatter of the note
- Open composer
- Add ` 2 times
- Delete forwart 2 times
- Traceback
Origin of the issue:
=====================
After adding the {backtick} 2 times, it will have the following html
`<p>{backtick}[]<code class="o_inline_code">{backtick}</code></p>` which
is not the expected behavior. now after delete forward we will have the
following html
`<p>{backtick}[]<code class="o_inline_code" data-oe-zws-empty-inline></code></p>`
now we delete forward again it will delete the inline block which
validate the following condition [1] which forces a deleteForward in the
parent element at offset one which is basically here
`<p>{backtick}[]<p>` which now will reach this part of code [2] and the
`findNode` will return a node outside the editable because we didn't
specify the `root` element as a stopping condition.
Solution:
=========
- First we fix the spec of the inline code block which should do nothing
in case there is no content inside it.
- We add the root as stopping condition while generating the path.
[1]: https://github.com/odoo/odoo/blob/16.0/addons/web_editor/static/src/js/editor/odoo-editor/src/commands/deleteForward.js#L125-L143
[2]: https://github.com/odoo/odoo/blob/d0828eecf60f7c8622d6875b8651eb663bc7d695/addons/web_editor/static/src/js/editor/odoo-editor/src/commands/deleteForward.js#L214-L241
opw-4254182
Forward-Port-Of: odoo/odoo#183567Issue: ===== FontSize isn't being applied on table selection. Steps to reproduce the issue: ============================= - Create a new to do - Add a table - Add content in some cells - Select from the middle of the content of the first cell to the middle of the content of the last cell - Apply font size - Nothing happens Origin of the issue: ==================== When we have `useResponsiveFontSizes` enabled, we first set the fontSize with undefined and then we set the font
Original PR description
Issue: ===== FontSize isn't being applied on table selection. Steps to reproduce the issue: ============================= - Create a new to do - Add a table - Add content in some cells - Select from the middle of the content of the first cell to the middle of the content of the last cell - Apply font size - Nothing happens Origin of the issue: ==================== When we have `useResponsiveFontSizes` enabled, we first set the fontSize with undefined and then we set the fontSizeClassName, but in the first execCommand we trigger `historyStep` event. The event is handled by the `html_field` and it will check if the field is dirty. In the process of checking we call `getValue` of `Wysiwyg`. `getValue` will run `cleanForSave` on the editor which will deselect tables. Solution: ========= We reset the selection after the first execCommand. opw-4237983 Forward-Port-Of: odoo/odoo#184104
Changing bootstrap versions caused a change in how the color for the alert-link class was being chosen which broke something with pdf reports. A change was then made to fix pdf reports but this ended up breaking alert-links elsewhere in Odoo and the light mode colors for alert-links were being used in dark mode. This change moves the styling to a report specific scss file to resolve the issue in the backend. Here is the aforementioned change: https://github.com/odoo/odoo/pull/178824
Original PR description
Changing bootstrap versions caused a change in how the color for the alert-link class was being chosen which broke something with pdf reports. A change was then made to fix pdf reports but this ended up breaking alert-links elsewhere in Odoo and the light mode colors for alert-links were being used in dark mode. This change moves the styling to a report specific scss file to resolve the issue in the backend. Here is the aforementioned change: https://github.com/odoo/odoo/pull/178824 opw-[4211334](https://www.odoo.com/web#id=4211334&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#182692
**[FIX] l10n_in: Remove Enterprise Widget from Indian Electronic Waybill** **Description of the issue/feature this PR addresses:** System shows Enterprise Widget on Indian Electronic Waybill module. Although Indian Electronic Waybill is available in community addons . **Impacted versions:** * 17.0 * 18.0 **Steps to Reproduce :** - Install l10n_in module. - Now Go to the invoicing --> Configuration --> Setting. - See the Enterprise Widget is on Indian Electronic Waybill. **Curr
Original PR description
**[FIX] l10n_in: Remove Enterprise Widget from Indian Electronic Waybill** **Description of the issue/feature this PR addresses:** System shows Enterprise Widget on Indian Electronic Waybill module. Although Indian Electronic Waybill is available in community addons . **Impacted versions:** * 17.0 * 18.0 **Steps to Reproduce :** - Install l10n_in module. - Now Go to the invoicing --> Configuration --> Setting. - See the Enterprise Widget is on Indian Electronic Waybill. **Current behaviour before PR:** Enterprise Widget Should not show on Indian Electronic Waybill as it is available in community addons. **Desired behaviour after PR is merged:** After this PR merge, System will allow to install Indian Electronic Waybill module in community version. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184401
The `move.reversed_move_id` field only represents the credit note that the user has manually created to revert a move, entirely or partially, but it doesn't take into consideration all moves reconciled through other means. We now use the method `move._get_reconciled_invoices()` which goes through all the partials to retrieve them instead. This enables also the reconciliation with the outstanding credits case to be covered. Closed 16.0 PR: odoo/odoo#119132 Task [link](https://www.odoo
Original PR description
The `move.reversed_move_id` field only represents the credit note that the user has manually created to revert a move, entirely or partially, but it doesn't take into consideration all moves reconciled through other means. We now use the method `move._get_reconciled_invoices()` which goes through all the partials to retrieve them instead. This enables also the reconciliation with the outstanding credits case to be covered. Closed 16.0 PR: odoo/odoo#119132 Task [link](https://www.odoo.com/odoo/project/967/tasks/3281816) task-3281816 Forward-Port-Of: odoo/odoo#184783
Steps to reproduce: Make a regular allocation for a time off type that can be taken in hours for an employee that has a working schedule other than standard 40h/week, and click save. The number of hours is updated to an amount different to what was entered. The issue is that https://github.com/odoo/odoo/pull/163711 changes the computation of number of hours to only work with the standard `HOURS_PER_DAY` without considering the employee's schedule, meanwhile `_compute_number_of_days` still
Original PR description
Steps to reproduce: Make a regular allocation for a time off type that can be taken in hours for an employee that has a working schedule other than standard 40h/week, and click save. The number of hours is updated to an amount different to what was entered. The issue is that https://github.com/odoo/odoo/pull/163711 changes the computation of number of hours to only work with the standard `HOURS_PER_DAY` without considering the employee's schedule, meanwhile `_compute_number_of_days` still takes the employee's schedule into account, causing an inconsistency leading to the bug. This commit, makes the computation of days and hours consistent, so at least the amount entered is kept. opw-4190998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180630
Steps to reproduce: - Drop the "Team" snippet and toggle it to grid mode. - Change the grid items padding with the "Padding (Y, X)" option. => The `o_we_padding_highlight` class used to show the padding preview is also added on the inner row of the grid items. This happens because the `data-apply-to` attribute of this option targets the `.row` elements in general, instead of only the grid mode one (so having the `o_grid_mode` class). This commit fixes this issue by changing this attribut
Original PR description
Steps to reproduce: - Drop the "Team" snippet and toggle it to grid mode. - Change the grid items padding with the "Padding (Y, X)" option. => The `o_we_padding_highlight` class used to show the padding preview is also added on the inner row of the grid items. This happens because the `data-apply-to` attribute of this option targets the `.row` elements in general, instead of only the grid mode one (so having the `o_grid_mode` class). This commit fixes this issue by changing this attribute, by patching the template in JS as a stable fix. Note that in above versions, the padding option changed so this fix will not be needed (but other grid options will need a similar fix). task-4247543 Forward-Port-Of: odoo/odoo#185201 Forward-Port-Of: odoo/odoo#183219
### Issue: `test_dblclick_event_from_calendar` tour test fails on Saturday ### Explanation: In the tour, we test an event with daily recurrence. Since the Weekly Calendar starts on Sunday and ends on Saturday, if an event starts on Saturday, the second occurrence of the event is on the next week and can not be reached. ### Fix: Moving to next week for the occurrence test, limiting recurrence to 8 days to remove useless rendering. Setting `drag_and_drop` tour in Monthly Calendar v
Original PR description
### Issue: `test_dblclick_event_from_calendar` tour test fails on Saturday ### Explanation: In the tour, we test an event with daily recurrence. Since the Weekly Calendar starts on Sunday and ends on…
### Issue: `test_dblclick_event_from_calendar` tour test fails on Saturday ### Explanation: In the tour, we test an event with daily recurrence. Since the Weekly Calendar starts on Sunday and ends on Saturday, if an event starts on Saturday, the second occurrence of the event is on the next week and can not be reached. ### Fix: Moving to next week for the occurrence test, limiting recurrence to 8 days to remove useless rendering. Setting `drag_and_drop` tour in Monthly Calendar view to avoid issues caused by potential `drag_and_drop` behaviour changes. In Monthly Calendar view, some days from previous and following months are visible, with a maximum of 6 before (Feb 23, see Mar 2025) and 14 after (Mar 14, see Feb 2026). Initial date being set in the backend, it does not have to respect those limitations. Changes operated in the frontend are bound to these and must be set between 15 and 22 included with the current selector. runbot-error-65494 Forward-Port-Of: odoo/odoo#185196 Forward-Port-Of: odoo/odoo#166502
If the bank account number is not in a valid format, it is rejected by `NAV`. When that happened we returned a `(None) None: None` error message, which is not very useful. This was due to an error in xml namespace when looking for the error message. Now, we return the proper error message. We also check that the bank account number is in a valid format before sending it to `NAV` and **warn** the user. The user is still free to send the document anyway. Task-id: 4254627 --- I confirm
Original PR description
If the bank account number is not in a valid format, it is rejected by `NAV`. When that happened we returned a `(None) None: None` error message, which is not very useful. This was due to an error in xml namespace when looking for the error message. Now, we return the proper error message. We also check that the bank account number is in a valid format before sending it to `NAV` and **warn** the user. The user is still free to send the document anyway. Task-id: 4254627 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184470
* STEP TO REPRODUCE: create a new uom category and add a new line -> Save. Then delete one line (uom_ids) -> raise UserError because the system force an uom category need to have at least one reference unit. * Fix by allowing to delete uom categ when it only has one single line of reference (by first delete the line and then delete the category), just like behaviour in v15 when we just make a user warning and still allow user to delete it Related forum issue: https://www.odoo.com/forum/
Original PR description
* STEP TO REPRODUCE: create a new uom category and add a new line -> Save. Then delete one line (uom_ids) -> raise UserError because the system force an uom category need to have at least one reference unit. * Fix by allowing to delete uom categ when it only has one single line of reference (by first delete the line and then delete the category), just like behaviour in v15 when we just make a user warning and still allow user to delete it Related forum issue: https://www.odoo.com/forum/help-1/unit-of-measure-categories-archive-option-255227 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#173990
This is a complement of previous fix: https://github.com/odoo/odoo/commit/792773296fce27340bf866fef8a6f6e8969b682e Add the company of the move in the context as it is possible that the company of the move and the current company are different. opw-4227241 Related enterprise PR: https://github.com/odoo/enterprise/pull/71725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185204 Forward-Port-Of: odoo/odoo#1850
Original PR description
This is a complement of previous fix: https://github.com/odoo/odoo/commit/792773296fce27340bf866fef8a6f6e8969b682e Add the company of the move in the context as it is possible that the company of the move and the current company are different. opw-4227241 Related enterprise PR: https://github.com/odoo/enterprise/pull/71725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185204 Forward-Port-Of: odoo/odoo#185096
We improved in 17.3/17.4 the Customer Invoice form view, and one of the changes where hiding the Payment Reference field. See https://github.com/odoo/odoo/commit/112c68a07b817e5e9a6c01e34a0fe7238b2eaa07 The rationale was: as it's most often generated by Odoo, let's not clutter the interface with a field that is left open most of the time. While this is true, in some cases people need to manage them by hand, for example when they import invoices, or they use specific formats not yet handled by
Original PR description
We improved in 17.3/17.4 the Customer Invoice form view, and one of the changes where hiding the Payment Reference field. See https://github.com/odoo/odoo/commit/112c68a07b817e5e9a6c01e34a0fe7238b2eaa07 The rationale was: as it's most often generated by Odoo, let's not clutter the interface with a field that is left open most of the time. While this is true, in some cases people need to manage them by hand, for example when they import invoices, or they use specific formats not yet handled by Odoo. This commit restores the field in the Other Info tab for those cases. Task: 4276812 Forward-Port-Of: odoo/odoo#185036
Steps to reproduce: ==== - Create a quotation and confirm it. - Open Point of Sale. - Load the order in POS. - Choose option Apply a down payment(percentage). - Insert 50. - Do payment and again place new order. - Select the same Quotation and do same 50% down payment. Issue: ==== - Next time value should be calculated from due balance not from initial total amount of the quotation. Fix: ==== - Instead of total_amount , now amount_unpaid is used. task- 4231244 Forward-Port-
Original PR description
Steps to reproduce: ==== - Create a quotation and confirm it. - Open Point of Sale. - Load the order in POS. - Choose option Apply a down payment(percentage). - Insert 50. - Do payment and again place new order. - Select the same Quotation and do same 50% down payment. Issue: ==== - Next time value should be calculated from due balance not from initial total amount of the quotation. Fix: ==== - Instead of total_amount , now amount_unpaid is used. task- 4231244 Forward-Port-Of: odoo/odoo#185255 Forward-Port-Of: odoo/odoo#182542
Delete the ad site, this site is pornographic 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
Original PR description
Delete the ad site, this site is pornographic 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
Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions with content result in `<p>[description]</p>` being printed. Steps To Reproduce: - Create a field service task and add products on it. - Add a Sales Order Item that has taxes. - Print the field service report. - Notice when the taxes has no description it print `<p><br><p>`. - Notice w
Original PR description
Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions…
Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions with content result in `<p>[description]</p>` being printed. Steps To Reproduce: - Create a field service task and add products on it. - Add a Sales Order Item that has taxes. - Print the field service report. - Notice when the taxes has no description it print `<p><br><p>`. - Notice when the taxes has has something in the [description] field it print `<p>[description]><p>`. Solution: - In the `account.tax` model, the description field was changed to an HTML field with this commit: https://github.com/odoo/odoo/commit/112c68a - Added `_get_description_plaintext` method to convert HTML content to plaintext using `html2plaintext`. This will also ensure compatibility for future changes to the description field. - related enterprise fix: https://github.com/odoo/enterprise/pull/68454 opw-4104951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184053
As the portal user, change your profile picture to a svg image, then show it via the normal /web/image URL. The downloaded picture lacks a valid content-type header. Related stored attachment fields were served via the method `Stream.from_binary_field` instead of `Stream.from_attachment`, only the latter is capable of copying the attachment mimetype on the stream. --- Also gave a shot at making the `odoo-bin --test-tags webserver:TestHttpStaticWebServer` test green again. Forward-Port-
Original PR description
As the portal user, change your profile picture to a svg image, then show it via the normal /web/image URL. The downloaded picture lacks a valid content-type header. Related stored attachment fields were served via the method `Stream.from_binary_field` instead of `Stream.from_attachment`, only the latter is capable of copying the attachment mimetype on the stream. --- Also gave a shot at making the `odoo-bin --test-tags webserver:TestHttpStaticWebServer` test green again. Forward-Port-Of: odoo/odoo#184667 Forward-Port-Of: odoo/odoo#177105
Bug introcued by this commit: https://github.com/odoo/odoo/pull/174984/commits/7bcfc3a1107650deff9dd8af02a3717304cb7d4e Steps to reproduce the bug: - Create a storable product “P1” tracked by serial number - update the qty with SN1 - Create a delivery order with SN1 - Validate it - go to the product and come back to the delivery - click on detailed operation in the move line Problem: “Unnamed” is displayed instead of the display_name of the quant opw-4279953 opw-4277630 opw-42
Original PR description
Bug introcued by this commit: https://github.com/odoo/odoo/pull/174984/commits/7bcfc3a1107650deff9dd8af02a3717304cb7d4e Steps to reproduce the bug: - Create a storable product “P1” tracked by serial number - update the qty with SN1 - Create a delivery order with SN1 - Validate it - go to the product and come back to the delivery - click on detailed operation in the move line Problem: “Unnamed” is displayed instead of the display_name of the quant opw-4279953 opw-4277630 opw-4276882 opw-4276058 opw-4252901 Forward-Port-Of: odoo/odoo#184920
Before this commit: Steps 1) Switch to DE company 2) Upload invoice using corrupted PDF (size = 0 KB) 3) Delete that invoice => It shows an error with a traceback File "/data/build/odoo/addons/l10n_de/models/ir_attachment.py", line 17, in <lambda> and guess_mimetype(attachment.raw) in ( File "/data/build/odoo/odoo/tools/mimetypes.py", line 156, in _odoo_guess_mimetype if bin_data.startswith(signature): AttributeError: 'bool' object has no attribute 'startswith' After this commit:
Original PR description
Before this commit: Steps 1) Switch to DE company 2) Upload invoice using corrupted PDF (size = 0 KB) 3) Delete that invoice => It shows an error with a traceback File "/data/build/odoo/addons/l10n_de/models/ir_attachment.py", line 17, in <lambda> and guess_mimetype(attachment.raw) in ( File "/data/build/odoo/odoo/tools/mimetypes.py", line 156, in _odoo_guess_mimetype if bin_data.startswith(signature): AttributeError: 'bool' object has no attribute 'startswith' After this commit: Invoices in l10n_de with corrupted attachments will be deleted without errors screen recording: https://drive.google.com/file/d/1TMjkwYbLZwEXyLfbSzjmDaO6jOrRk2RO/view?usp=sharing opw-4115496 Forward-Port-Of: odoo/odoo#183768
Using a computed field that perform external API calls to decide about when to hide UI elements is problematic. If the external API is unreachable this will raise an exception each time users try to open the form view. If the API is slow this will also cause general slow downs for users. Finally during upgrades this causes unnecessary failures because the upgrade process is run without external internet access. This is partial revert of odoo/odoo@edf1a7d This issue blocks multiple up
Original PR description
Using a computed field that perform external API calls to decide about when to hide UI elements is problematic. If the external API is unreachable this will raise an exception each time users try to open the form view. If the API is slow this will also cause general slow downs for users. Finally during upgrades this causes unnecessary failures because the upgrade process is run without external internet access. This is partial revert of odoo/odoo@edf1a7d This issue blocks multiple upgrades to 17.4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184151
The `use_create_lots` field was missing in the parent view after this https://github.com/odoo/odoo/pull/137031/commits/ecc6a3c0776501ca79604af21fd5515f74f6b7e8#diff-7a1e0a179b7361b04b4bb165dbfc18fabd2fc972ff190fbf21144db03f9b86b1L139 , causing a silent failure in the `options` condition for allowing users to create new lots/serial numbers. As a result, users were unable to add serial numbers during receipt creation because the condition `options="{'create': [('parent.use_create_lots', '=', True)
Original PR description
The `use_create_lots` field was missing in the parent view after this…
The `use_create_lots` field was missing in the parent view after this https://github.com/odoo/odoo/pull/137031/commits/ecc6a3c0776501ca79604af21fd5515f74f6b7e8#diff-7a1e0a179b7361b04b4bb165dbfc18fabd2fc972ff190fbf21144db03f9b86b1L139 , causing a silent failure in the `options` condition for allowing users to create new lots/serial numbers. As a result, users were unable to add serial numbers during receipt creation because the condition `options="{'create': [('parent.use_create_lots', '=', True)]}"` was never met.
Steps to reproduce the error:
1. Create a new product with lot/serial number tracking.
2. Create a receipt for that product.
3. Try to add serial numbers to the receipt.
The expected behavior is to be able to add serial numbers, but users were blocked from doing so due to the missing field.
To resolve this, the `use_create_lots` field has been added to the parent view, ensuring that the condition for allowing lot creation works as expected.
opw-4150626
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#184431**Current behavior:** Using the DHL delivery shipping module, if you complete a sale order's delivery and then add new product to the order and, again, validate the new delivery, the shipping chatter will be posted in all of the sale order's pickings. **Expected behavior:** The chatter should only be posted in the picking which was actually validated. **Steps to reproduce:** *Install delivery_dhl and l10n_be_hr_payroll* *Swap to My Belgian Company* *Duplicate the My Belgian Compan
Original PR description
**Current behavior:** Using the DHL delivery shipping module, if you complete a sale order's delivery and then add new product to the order and, again, validate the new delivery, the shipping chatter…
**Current behavior:** Using the DHL delivery shipping module, if you complete a sale order's delivery and then add new product to the order and, again, validate the new delivery, the shipping chatter will be posted in all of the sale order's pickings. **Expected behavior:** The chatter should only be posted in the picking which was actually validated. **Steps to reproduce:** *Install delivery_dhl and l10n_be_hr_payroll* *Swap to My Belgian Company* *Duplicate the My Belgian Company partner record, giving it new unique values where necessary (VAT, address, etc.)* 1. Create a new sale order to the copied Belgian company 2. Add some storable product and add DHL EU shipping to the order (only DHL connector working) 3. Confirm the order, and validate the delivery 4. Back on the sale order, add another order line and save 5. Validate the new delivery, see that the delivery chatter is posted on both deliveries **Cause of the issue:** The message is currently logged on `sale_id.picking_ids`. **Fix:** Change the line in question to only log the message on the currently iterated over picking, as well as any relevant, previously created ones (e.g., in a multistep route context). opw-4059145 Forward-Port-Of: odoo/enterprise#72730 Forward-Port-Of: odoo/enterprise#71441
When generating either a PO or SO from one company to another, currently the commitment date of a Sale Order or the Expected Arrival of a Purchase Order are not used to generate their counter-part in the other company. This means that if you set the expected arrival of the PO in Company A to 10 days in the future, the SO generated in Company B will still try to deliver it as soon as possible, regardless of the date set. Forward-Port-Of: odoo/enterprise#72770 Forward-Port-Of: odoo/enterprise#
Original PR description
When generating either a PO or SO from one company to another, currently the commitment date of a Sale Order or the Expected Arrival of a Purchase Order are not used to generate their counter-part in the other company. This means that if you set the expected arrival of the PO in Company A to 10 days in the future, the SO generated in Company B will still try to deliver it as soon as possible, regardless of the date set. Forward-Port-Of: odoo/enterprise#72770 Forward-Port-Of: odoo/enterprise#72586
This is a complement of previous fix: https://github.com/odoo/enterprise/commit/9b2d9508745fb1b00e42c8d729d01ad7ae1b4b85 Add the company of the move in the context as it is possible that the company of the move and the current company are different. Related community PR: https://github.com/odoo/odoo/pull/185096 Forward-Port-Of: odoo/enterprise#72746 Forward-Port-Of: odoo/enterprise#71725
Original PR description
This is a complement of previous fix: https://github.com/odoo/enterprise/commit/9b2d9508745fb1b00e42c8d729d01ad7ae1b4b85 Add the company of the move in the context as it is possible that the company of the move and the current company are different. Related community PR: https://github.com/odoo/odoo/pull/185096 Forward-Port-Of: odoo/enterprise#72746 Forward-Port-Of: odoo/enterprise#71725
Steps to reproduce the bug: - Create a storable product “P1”: - Tracked with SN - Create a BoM: - no need to component - Add an operation “OP1” with steps - Control by product - Create a manufacturing order for one unit of P1 - Confirm the MO - Go to the shop floor and process “OP1” - Validate the MO - Go to the SN of P1 Problem: The quality check smart button is not displayed, while the SN is linked to a QC. opw-4189396 Forward-Port-Of: odoo/e
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked with SN
- Create a BoM:
- no need to component
- Add an operation “OP1” with steps
- Control by product
- Create a manufacturing order for one unit of P1
- Confirm the MO
- Go to the shop floor and process “OP1”
- Validate the MO
- Go to the SN of P1
Problem:
The quality check smart button is not displayed, while the SN is linked to a QC.
opw-4189396
Forward-Port-Of: odoo/enterprise#72693## Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions with content result in `<p>[description]</p>` being printed. ## Steps To Reproduce: - Create a field service task and add products on it. - Add a Sales Order Item that has taxes. - Print the field service report. - Notice when the taxes has no description it print `<p><br><p>`. - Notic
Original PR description
## Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax…
## Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions with content result in `<p>[description]</p>` being printed. ## Steps To Reproduce: - Create a field service task and add products on it. - Add a Sales Order Item that has taxes. - Print the field service report. - Notice when the taxes has no description it print `<p><br><p>`. - Notice when the taxes has has something in the [description] field it print `<p>[description]><p>`. ## Solution: - In the `account.tax` model, the description field was changed to an HTML field with this commit: https://github.com/odoo/odoo/commit/112c68a07b817e5e9a6c01e34a0fe7238b2eaa07 - Added `_get_description_plaintext` method to convert HTML content to plaintext using `html2plaintext`. This will also ensure compatibility for future changes to the description field. related community fix: https://github.com/odoo/odoo/pull/184053 opw-4104951 Forward-Port-Of: odoo/enterprise#68454
With a BE Company Setup Go to Documents > Configuration > Settings - Enable Accounting (Centralize accounting files and documents) - Open Journals and synchronize the Customer Invoices journal with a workspace Create an invoice Click Send&Print - Check "BIS Billing 3.0" - Send the message, the invoice will now have 2 attachments: pdf and xml Check the documents workspace Issue: Only the pdf is present This occurs because of the conditions needed to create the document.
Original PR description
With a BE Company Setup Go to Documents > Configuration > Settings - Enable Accounting (Centralize accounting files and documents) - Open Journals and synchronize the Customer Invoices journal with a workspace Create an invoice Click Send&Print - Check "BIS Billing 3.0" - Send the message, the invoice will now have 2 attachments: pdf and xml Check the documents workspace Issue: Only the pdf is present This occurs because of the conditions needed to create the document. When we send the message we create the attachment but the move does not have attachment_ids set yet, so we fail to assign the first one. In this phase we just need to link the xml as the pdf will be registered when assigned as main attachment of the move opw-4088910 Forward-Port-Of: odoo/enterprise#69085
Change the checkbox label of stacked charts from `stacked linechart` to `stacked line chart` in the chart configuration panel. Same for bar charts. Also removed padding between `stacked` and `cumulative` checkboxes in the line chart panel. Task: [3978443](https://www.odoo.com/web#id=3978443&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#64336
Original PR description
Change the checkbox label of stacked charts from `stacked linechart` to `stacked line chart` in the chart configuration panel. Same for bar charts. Also removed padding between `stacked` and `cumulative` checkboxes in the line chart panel. Task: [3978443](https://www.odoo.com/web#id=3978443&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#64336