Navigate
Branch
Friday, August 9, 2024
63 changes
22 changes
Resolved issues and error corrections
This fix stops Odoo from repeatedly retrying failed screens when several actions in the URL cannot be opened, preventing users from getting stuck in an endless error cycle. It also improves page reload behavior so previously opened dynamic screens can be restored correctly, making navigation more reliable.
Original PR description
- Open Accounting; - Open Bank Reconciliation; - Change the Company, to a company with not installed a chart of account. Before this commit, an infinity access error loop was raise. This occurs, because when an action is in an error on mounting on the action service, we try to mount the previous action, choose from a list of previously executed actions. The previous action, in this case, was also in error. In these case, it should go to the before last of the list, but as the previous one wasn't removed. It will try to mount it again, and create an infinity loop. opw-[4076702](https://www.odoo.com/web#id=4076702&view_type=form&model=project.task)
Pressing backspace in an empty cashier password popup in Point of Sale no longer causes an error. This improves cashier selection reliability and prevents a small disruption during checkout operations.
Original PR description
Before this commit, pressing backspace in the cashier selection password number popup when it was empty would cause an error. opw-4089617 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Duplicating records from list views now uses the same business context as duplicating from a form view. This prevents inconsistent copied records, such as rental sales orders missing rental-specific behavior when duplicated from a list.
Original PR description
Description of the issue/feature this PR addresses: - Adapting the fix for saas-17.2: https://github.com/odoo/odoo/pull/174137 It is found that context is never passed in '_duplicateRecords' function for list views, when making 'orm' calls from js side, while it is passed in 'duplicate' function of record.js, which is called when duplicating record from form view. 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
Miscellaneous changes
Description of the issue this commit addresses: Wrong invoice label for the tax 25.5 which shows 25%. --- Desired behavior after this commit is merged: The tax has the label 25.5% on invoices. --- no task-feedback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175908
Original PR description
Description of the issue this commit addresses: Wrong invoice label for the tax 25.5 which shows 25%. --- Desired behavior after this commit is merged: The tax has the label 25.5% on invoices. --- no task-feedback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175908
Mistakenly backported. Needed from saas-17.4 up to master Forward-Port-Of: odoo/odoo#175011
Original PR description
Mistakenly backported. Needed from saas-17.4 up to master Forward-Port-Of: odoo/odoo#175011
Steps to reproduce ================== As Admin: - Install project - Go to project - Click on the three dots on a project card - Select "Share" - Copy the link - Select the edit mode - Add "Joel Willis" to the recipients - Click on "Send" As portal in another browser (or in private navigation) - Paste the link - Type some random characters in the search bar so that no records are matched - remove the current filter => Every single column is displayed, for example `<field name
Original PR description
Steps to reproduce ================== As Admin: - Install project - Go to project - Click on the three dots on a project card - Select "Share" - Copy the link - Select the edit mode - Add "Joel…
Steps to reproduce
==================
As Admin:
- Install project
- Go to project
- Click on the three dots on a project card
- Select "Share"
- Copy the link
- Select the edit mode
- Add "Joel Willis" to the recipients
- Click on "Send"
As portal in another browser (or in private navigation)
- Paste the link
- Type some random characters in the search bar so that no records are matched
- remove the current filter => Every single column is displayed, for example
`<field name="sequence" readonly="1" column_invisible="True"/>`
As Admin:
- Go to the shared project settings
- Disable the "Milestones" checkbox
As portal:
- Refresh the page => The milestone column is still displayed
Cause of the issue
==================
The difference between invisible and column_invisible is that
`invisible` is meant to hide a cell in a row and is evaluated with the record data (`record.evalContextWithVirtualIds`).
`column_invisible` is meant to remove a column completely for the list, but is is not evaluated with the record. It only uses the context and a few more keys (`this.model.root.evalContext`).
It is thus not possible to hide an entire column depending on record values. It makes sense as the values could be different for every record displayed.
In this case though, there are a few fields that have the same values for every record. They are in fact related fields, declared on the project.
Those fields are
- allow_milestones
- allow_timesheets
The [ProjectSharingListRenderer] has been created to hide some columns from being displayed when a feature is disabled on the project displayed.
It works by evaluating the column_invisible with the first record. If there are no records, we skip any column_invisible processing,
When calling `setColumns` from `onWillUpdateProps`, we use `nextProps` for the columns, but still `this.props` to get the first record.
This means that we use an outdated first record, and this is why every column is displayed after removing the filter.
Another issue is that
During [View-Pocalypse],
In 16.0, the milestone_id field was
```xml
<field name="milestone_id" attrs="{'column_invisible': [('allow_milestones', '=', False)]}"/>
```
In 17.0, it is
```xml
<field name="milestone_id" invisible="not allow_milestones" context="{'default_project_id': project_id}" groups="project.group_project_milestone" optional="hide"/>
```
Solution
========
As there are some limitations to the js approach (when no records are in the list for example) and there is already a context key for the [allow_timesheets], we use a simpler approach to add the missing keys.
Finally, we put back the column_invisible attributes
---
[ProjectSharingListRenderer]: https://github.com/odoo/odoo/commit/ab2b5d1fd1f09d804ab410bc326cfebf26d5a7c6
[View-Pocalypse]: https://github.com/odoo/odoo/pull/104741
[allow_timesheets]: https://github.com/odoo/odoo/blob/d2a428c07fd728691e3ddd60fe4b7cc5e94455a6/addons/hr_timesheet/models/project_project.py#L290
opw-4015035
Forward-Port-Of: odoo/odoo#175756
Forward-Port-Of: odoo/odoo#172645Since [1], Werkzeug 3.0.1 is used depending on the python version. Unlike its previous versions, Werkzeug 3.0.1's `url_quote` does not escape the single quote character to `%27` anymore. This causes an issue for cover images that use the computed `image_src` in a `background-image` CSS property using `url(...)` or `url('...')`. This commit restores the former behavior of `_compute_image_src` to avoid issues when its output is used in inadequately quoted CSS properties. Steps to rep
Original PR description
Since [1], Werkzeug 3.0.1 is used depending on the python version.
Unlike its previous versions, Werkzeug 3.0.1's `url_quote` does not
escape the single quote character to `%27` anymore.
This causes an issue for cover images that use the computed `image_src`
in a `background-image` CSS property using `url(...)` or `url('...')`.
This commit restores the former behavior of `_compute_image_src` to
avoid issues when its output is used in inadequately quoted CSS
properties.
Steps to reproduce:
- Use python_version >= '3.12' so that Werkzeug is 3.0.1.
- Create a new blog post.
- Set a cover image.
- Save.
=> Image is not displayed anymore because URL contains `'`.
[1]: https://github.com/odoo/odoo/commit/4a019ae9de64b260fe6b18d21f4624902b3bb880
task-4099056
Forward-Port-Of: odoo/odoo#175815Since commit odoo/odoo@adb5357e7f93f2cba70acc576a597ea78bd1de42, we have added a new DIV (`o_form_view_container`) around the form view. But the CSS selector for the sticky control panel was not adapted so the feature was not working anymore. This commit fixes the CSS selector. Steps to reproduce: * Open Odoo on small screen * Open the Contact App * Select a contact * Try to scroll down and up into the form view => Bug the control panel is not sticky Note : backport of PR 176015
Original PR description
Since commit odoo/odoo@adb5357e7f93f2cba70acc576a597ea78bd1de42, we have added a new DIV (`o_form_view_container`) around the form view. But the CSS selector for the sticky control panel was not adapted so the feature was not working anymore. This commit fixes the CSS selector. Steps to reproduce: * Open Odoo on small screen * Open the Contact App * Select a contact * Try to scroll down and up into the form view => Bug the control panel is not sticky Note : backport of PR 176015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176164
This commit's purpose is to rename the other costs & other revenues section to avoid id conflict with other section of the project profitability panel. 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#171949
Original PR description
This commit's purpose is to rename the other costs & other revenues section to avoid id conflict with other section of the project profitability panel. 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#171949
This commit fixes an issue regarding down-payment calculation. ZATCA defines one rule to govern the way prepaid amounts (down-payment) is calculated, where PrepaidAmount = SUM([LINE.TaxableAmount + LINE.TaxAmount for LINE in invoice.invoice_line_ids]), obviously this poses a problem when we have a mix of down-payment and normal lines on our invoice since the formula does not differentiate between those. To fix this, we make sure that only down-payment lines actually include a Tax Subtotal breakd
Original PR description
This commit fixes an issue regarding down-payment calculation. ZATCA defines one rule to govern the way prepaid amounts (down-payment) is calculated, where PrepaidAmount = SUM([LINE.TaxableAmount +…
This commit fixes an issue regarding down-payment calculation. ZATCA defines one rule to govern the way prepaid amounts (down-payment) is calculated, where PrepaidAmount = SUM([LINE.TaxableAmount + LINE.TaxAmount for LINE in invoice.invoice_line_ids]), obviously this poses a problem when we have a mix of down-payment and normal lines on our invoice since the formula does not differentiate between those. To fix this, we make sure that only down-payment lines actually include a Tax Subtotal breakdown (TaxableAmount & TaxAmount) Description of the issue/feature this PR addresses: PrepaidAmount value in invoice XML, representing down-payment amounts, is Wrong, both on the XML and QR code associated, even though ZATCA returns a Valid submission status Current behavior before PR: PrepaidAmount value in invoice XML, representing down-payment amounts, is Wrong, both on the XML and QR code associated, even though ZATCA returns a Valid submission status Desired behavior after PR is merged: PrepaidAMount is calculated correctly on the XML invoice submitted to ZATCA and also represented correctly on the QR code --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174960
If the module l10n_be was installed and you tried to invoice a settled order, you got a traceback Steps to reproduce: ------------------- * Install l10n_be_pos_sale module * Open PoS in a non belgian company * Import an order from sales in PoS * Try to invoice it > Observation: You get a traceback Why the fix: ------------ Intracom taxes where not set and was causing a traceback. opw-4089625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-
Original PR description
If the module l10n_be was installed and you tried to invoice a settled order, you got a traceback Steps to reproduce: ------------------- * Install l10n_be_pos_sale module * Open PoS in a non belgian company * Import an order from sales in PoS * Try to invoice it > Observation: You get a traceback Why the fix: ------------ Intracom taxes where not set and was causing a traceback. opw-4089625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175898 Forward-Port-Of: odoo/odoo#175397
Steps to reproduce: - In website edit mode. - Drop enough blocks into the page to have a vertical scrollbar. - Click on the header. - Select the "Vertical" template in the options of the header. - Select the "Fixed" scroll effect in the options of the header. - click on the logo in the header. - Enter "80px" in the "Height" input in the options of the "Navbar Logo". - Scroll the page to the bottom. - Then, scroll the page to the top. - Bug: the "Navbar Logo" overlaps the navbar links
Original PR description
Steps to reproduce: - In website edit mode. - Drop enough blocks into the page to have a vertical scrollbar. - Click on the header. - Select the "Vertical" template in the options of the header. - Select the "Fixed" scroll effect in the options of the header. - click on the logo in the header. - Enter "80px" in the "Height" input in the options of the "Navbar Logo". - Scroll the page to the bottom. - Then, scroll the page to the top. - Bug: the "Navbar Logo" overlaps the navbar links. This bug occurred because the header size was calculated before the transition animation for the header height was completed. opw-4078173 Forward-Port-Of: odoo/odoo#175653
Before this commit, searching for a sale order with a partner name containing special characters (e.g., &) would fail to correctly filter the sale orders. This commit ensures that partner names with special characters are properly handled, allowing for accurate sale order searches. opw-4062365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174225
Original PR description
Before this commit, searching for a sale order with a partner name containing special characters (e.g., &) would fail to correctly filter the sale orders. This commit ensures that partner names with special characters are properly handled, allowing for accurate sale order searches. opw-4062365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174225
Set Company country to India Create a TAX as follows - Amount: 15% - Included in price: False - Tax repartition line: - 100.00% of tax to 100560 Tax Receivable - -100.00% of tax to 999999 Undistributed Profits/Losses Open Bank Reconciliation Widget Create a statement Match with Manual operation Select created tax Issue: created tax lines have no amount This occurs because when computing the tax amounts with compute_all if the configuration of tax is price included (enforced
Original PR description
Set Company country to India Create a TAX as follows - Amount: 15% - Included in price: False - Tax repartition line: - 100.00% of tax to 100560 Tax Receivable - -100.00% of tax to 999999 Undistributed Profits/Losses Open Bank Reconciliation Widget Create a statement Match with Manual operation Select created tax Issue: created tax lines have no amount This occurs because when computing the tax amounts with compute_all if the configuration of tax is price included (enforced from context) and the tax is in cache we use the computed amount. Unfortunately in this particular configuration the amount is 0 opw-3986439 Forward-Port-Of: odoo/odoo#173674
When a menu link is defined towards an anchor, the scroll effect of the browser does not trigger from within the translated pages where the URL contains the additional path element about the used locale. This scrolling is achieved by the browser itself, it is not related to `scroller_service.js`. The URL is not transformed by `website.menu`'s `clean_url` method. The language is added in `ir.http`'s `url_lang` method, but we cannot always know the current URL at that point, nor during the tem
Original PR description
When a menu link is defined towards an anchor, the scroll effect of the browser does not trigger from within the translated pages where the URL contains the additional path element about the used…
When a menu link is defined towards an anchor, the scroll effect of the browser does not trigger from within the translated pages where the URL contains the additional path element about the used locale. This scrolling is achieved by the browser itself, it is not related to `scroller_service.js`. The URL is not transformed by `website.menu`'s `clean_url` method. The language is added in `ir.http`'s `url_lang` method, but we cannot always know the current URL at that point, nor during the template rendering - making it impossible to determine if the rendered anchor is local. This commit solves this client-side by replacing link's `href` values with their anchor only whenever they are targeting the current page. Steps to reproduce: - Install a second language on the website. - Put some content in the Home page so that the bottom section requires scrolling to be seen. - Add a menu element that targets `#bottom`. - Either be a visitor or a connected user. - Go to the default language Home page. - Click on the new link. => Page scrolls to the bottom. - Switch to the second language Home page. - Click on the new link. => Page reloads targeting the bottom instead of scrolling. opw-3956066 Forward-Port-Of: odoo/odoo#176077 Forward-Port-Of: odoo/odoo#169944
Description of the issue/feature this PR addresses: - i found that context is never passed in [_duplicateRecords()](https://github.com/odoo/odoo/blob/bd922d14051e5cf09628ad20087d5a78c6588919/addons/web/static/src/model/relational_model/dynamic_list.js#L210) function for list views, when making 'orm' calls from js side, while it is passed in [duplicate](https://github.com/odoo/odoo/blob/bd922d14051e5cf09628ad20087d5a78c6588919/addons/web/static/src/model/relational_model/record.js#L191) functi
Original PR description
Description of the issue/feature this PR addresses: - i found that context is never passed in…
Description of the issue/feature this PR addresses: - i found that context is never passed in [_duplicateRecords()](https://github.com/odoo/odoo/blob/bd922d14051e5cf09628ad20087d5a78c6588919/addons/web/static/src/model/relational_model/dynamic_list.js#L210) function for list views, when making 'orm' calls from js side, while it is passed in [duplicate](https://github.com/odoo/odoo/blob/bd922d14051e5cf09628ad20087d5a78c6588919/addons/web/static/src/model/relational_model/record.js#L191) function of record.js, which is called when duplicating record from form view. **use case:** - In `sale_renting` module, There is difference in the result, when a `sale_order` is duplcated from form view(duplicated properly) and when it is duplicated from list view(unexpected result). When duplicating a sale_order, its lines are also being duplicated, and at that time [_compute_is_rental](https://github.com/odoo/enterprise/blob/10006504139abc706ccdb00f71c16846414731eb/sale_renting/models/sale_order_line.py#L56) is being computed, which relies on context key `in_rental_app`. 'in_rental_app' is set in the related action yet was not available when duplicating the sale_order from list view (which resulted in unexpected behaviour). Current behavior before PR: - Context is not passed when duplicating Records from list view. Desired behavior after PR is merged: - Context is passed when duplicating Records from list view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174137
Before this commit: While generating an ewaybill we get the following traceback: ```log File "/home/odoo/odoo/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 418, in _generate_ewaybill_direct 'ewaybill_expiry_date': self._indian_timezone_to_odoo_utc( File "/home/odoo/odoo/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 433, in _indian_timezone_to_odoo_utc local_time = datetime.strptime(str_date, time_format) TypeError: strpti
Original PR description
Before this commit:
While generating an ewaybill we get the following traceback:
```log
File "/home/odoo/odoo/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 418, in _generate_ewaybill_direct
'ewaybill_expiry_date': self._indian_timezone_to_odoo_utc(
File "/home/odoo/odoo/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 433, in _indian_timezone_to_odoo_utc
local_time = datetime.strptime(str_date, time_format)
TypeError: strptime() argument 1 must be str, not None
```
After this commit:
We resolve the traceback it was caused due to
string to datetime conversion because we were
receving `None` value instead of datetime string
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#176183Before this commit, when using a product in a kit with a smaller unit of measure than the base product UoM, and the conversion resulted in a zero quantity, an unclear error message was displayed upon closing the PoS session: "Quantity or Reserved Quantity should be set." This error message lacked sufficient information, making it difficult to diagnose the issue, especially with multiple orders. This commit enhances the error message to clearly indicate the cause of the problem, providing spec
Original PR description
Before this commit, when using a product in a kit with a smaller unit of measure than the base product UoM, and the conversion resulted in a zero quantity, an unclear error message was displayed upon…
Before this commit, when using a product in a kit with a smaller unit of measure than the base product UoM, and the conversion resulted in a zero quantity, an unclear error message was displayed upon closing the PoS session: "Quantity or Reserved Quantity should be set." This error message lacked sufficient information, making it difficult to diagnose the issue, especially with multiple orders. This commit enhances the error message to clearly indicate the cause of the problem, providing specific details about the UoM conversion that resulted in a zero quantity. To reproduce the issue: 1. Create a product with a base UoM in kilograms (kg). 2. Include this product in a kit with a UoM of grams (g). 3. Set the rounding precision for both UoMs to 0.01. 4. Sell one kit through the PoS. The error would occur due to the quantity conversion from grams to kilograms resulting in zero, given the rounding precision settings. opw-4084783 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175007
A field from sale was used in point_of_sale. Introduced here https://github.com/odoo/odoo/pull/173389 opw-4005925-1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176265
Original PR description
A field from sale was used in point_of_sale. Introduced here https://github.com/odoo/odoo/pull/173389 opw-4005925-1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176265
Denmark government need a way to get ec sales. So now we have a report dedicated to denmark with an export to a CSV format This require us to add the triangular sales tax task-4080107 Backporting: https://github.com/odoo/odoo/pull/157211/commits/a6bd4048a20fada2822692107b57dbcd20d2baf9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174810
Original PR description
Denmark government need a way to get ec sales. So now we have a report dedicated to denmark with an export to a CSV format This require us to add the triangular sales tax task-4080107 Backporting: https://github.com/odoo/odoo/pull/157211/commits/a6bd4048a20fada2822692107b57dbcd20d2baf9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174810
Specification: The time should not be reset when dragging an event in the month view. Observed behavior: Time is reset when dragging an event in month mode. Task-3432065 Forward-Port-Of: odoo/odoo#171402
Original PR description
Specification:
The time should not be reset when dragging an event in the month view.
Observed behavior:
Time is reset when dragging an event in month mode.
Task-3432065
Forward-Port-Of: odoo/odoo#171402Before this commit, replying to a message from email author lead to a crash. Steps to reproduce: - Set notification preferences to "Handle in Odoo", in user preferences - Follow a record with chatter - Send a message on the followed record so that it's received by another follower by email - Follower replies to message from email client - Open Inbox in Discuss app and click on "Reply" action on that message => Crash `Cannot read property of undefined (reading 'name')` This happens bec
Original PR description
Before this commit, replying to a message from email author lead to a crash. Steps to reproduce: - Set notification preferences to "Handle in Odoo", in user preferences - Follow a record with chatter - Send a message on the followed record so that it's received by another follower by email - Follower replies to message from email client - Open Inbox in Discuss app and click on "Reply" action on that message => Crash `Cannot read property of undefined (reading 'name')` This happens because the reply-to text above composer when using the message reply feature assumed that the author is necessarily a partner. This is not necessarily the case: some message just have an email address as author. This commit fixes the issue by correctly showing the address email when replying to such a message. opw-4092015 Forward-Port-Of: odoo/odoo#176225 Forward-Port-Of: odoo/odoo#176139
30 changes
Enhancements to existing features
The messaging menu is now available in the public web experience, making it easier for visitors using mobile devices to open and use chat windows. This improves customer communication by ensuring chat access works consistently outside the logged-in backend.
Original PR description
messaging menu moved to public_web
Vendor bills from OCR or e-invoicing can now be automatically posted after the system sees repeated accurate processing for the same vendor. Users remain in control with a vendor-level checkbox, and bills with unusual amounts or restricted audit conditions are excluded to reduce risk.
Original PR description
Purpose ------- The idea is to automate a bit more the post of bills for vendor in which you trust, i.e. vendor with invoices well recognized by OCR or invoices xml Spec ---- - When invoices from a same vendor are input twice in a row without changing anything, so for invoice coming from OCR or e-Invoicing, we should show a banner to the user and allow him to input automatically invoice from this vendor for the next ones - There should be a checkbox on the partner form to enable/disable this autopost feature at any time - If there is a significant difference (see abnormal_amount), don't autopost and show the banner - Not applicable to hashed invoices task-id 3958958 Community PR: https://github.com/odoo/odoo/pull/174540 Enterprise PR: https://github.com/odoo/enterprise/pull/67788 Upgrade PR: https://github.com/odoo/upgrade/pull/6356
Helpdesk teams now include an easier link to the email alias domain settings, helping administrators find and manage incoming email configuration more quickly. Some older default search behavior was also removed from French Intrastat and Romanian SAF-T reporting areas, simplifying those views without changing core business processes.
The maintenance screens linked to manufacturing have been updated to use newer, simpler card layouts. This should make the interface easier to maintain and keep it aligned with current Odoo design standards, with minimal change for everyday users.
Original PR description
In this commit we have simplified the kanban arch for the mrp_maintenance module the goal is to simplify them,make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of <field/> tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use <field name=... widget=image/> instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color=color_field_name on root node - oe_kanban_colorpicker is deprecated, use kanban_color_picker widget instead Task-3992107
Sales-related modules were updated to match the new way product descriptions appear on sales order lines. This keeps automated checks and demo data current, helping ensure smoother sales, rental, subscription, and helpdesk workflows.
Original PR description
* adapt tours to the new product description widget used on Sale Order Lines * use the new tour utils to simplify tours going through sale app or views * clean demo data to remove the values that are the default ones (leftover from previous version, but good to merge anyway). See also odoo/odoo#170610
Appointment and approval-related pages now use clearer, more human-readable web addresses. This makes links easier for customers and staff to understand, share, and recognize across booking, payment, recruitment, CRM, and approval flows.
Original PR description
*= appointment_account_payment, appointment_crm, appointment_hr_recruitment, approvals This commit modifies existing URLs to the new format so that the URL's become more human readable. Task-3820230
Users can now roll back a spreadsheet all the way to its initial uploaded state, not just to later saved revisions. This helps recover from large unwanted edits without needing to reupload the original file.
Original PR description
Currently, a user can only roll back on revisions and not on the original state of the spreadsheet (i.e. the original json in the filestore). This means that for users that upload an xlsx file and start by doing an huge modification on it, they don't have the possibility to return to the spreasheet as it was uploaded and had no choice but to reupload it. This revision allows the user to roll back to the initial state of the spreadsheet. task-3799678
Financial report pages now use cleaner, more human-readable web addresses. This makes report links easier to understand, share, and validate while preserving existing reporting behavior.
Original PR description
This commit modifies existing URLs to the new format so that the URL's become more human readable. Task-3820230
This update changes existing links in Data Cleaning and EasyPost delivery flows to use a cleaner, more human-readable format. This makes URLs easier for users to understand, share, and recognize while preserving the same functionality.
Original PR description
*= delivery_easypost This commit modifies existing URLs to the new format so that the URL's become more human readable. Task-3820230
Document-related links now use a cleaner, more human-readable format across Documents, document accounting, signing, and spreadsheets. This makes shared or bookmarked links easier to recognize and improves the overall navigation experience without changing the underlying business workflows.
Original PR description
*= documents_account, documents_sign, documents_spreadsheet This commit modifies existing URLs to the new format so that the URL's become more human readable. Task-3820230
The Belgian Partner VAT listing report now alerts users when multiple partners share the same VAT number. This helps teams quickly review potentially duplicate or inconsistent partner records before reporting.
Original PR description
This new warning is triggered when multiple partner sharing the same VAT number appear in the report. So the warning open a view showing all the partners sharing Tax id with another. task:4063972
Financial budgeting gets a redesigned entry flow, easier in-report editing, and clearer account visibility controls. Budgets can now be spread by month across the reporting period and compared in multiple ways, helping finance teams plan and adjust figures more accurately.
Original PR description
The commit introduces new features in the financial budget functionality: - Redesigned the UI for new budget item input. - Added an edit icon in the budget filter item to open it. - Replaced the "Add…
The commit introduces new features in the financial budget functionality: - Redesigned the UI for new budget item input. - Added an edit icon in the budget filter item to open it. - Replaced the "Add accounts" feature with a "Show all accounts" filter. - Improved the layout of the budget form by adding a notebook and page. - Added a "date_from" field named "month" to each budget item, allowing users to change the date by selecting the year and month. - Replaced the edit popover in the report with an editable cell component. - When editing a budget cell, it now calculates the difference between the old and new values to create a new budget item or modify the existing one if any instead of directly setting the budget item to the new value. - Budget items are now distributed across all the months in the selected reporting period. For example, if the period is one year and a budget item is set to "120", it will be divided into 12 budget items of "10" each. - We can have several comparison for budgets. task-4070179
Resolved issues and error corrections
This fix ensures restaurant orders reopen correctly after using the booking flow. It prevents staff from seeing a blank screen when returning to a selected table, keeping point-of-sale operations smooth.
Original PR description
Screens are saved on order so that when an order is reselected, the order is rendered on its last recorded screen. In this commit, we exclude the ActionScreen since it doesn't make sense (for now) for it to be a screen for the current order. Steps to reproduce: 1. Install pos_restaurant_appointment. 2. Open a session for the Restaurant config. 3. Open an order by clicking a table. 4. Click Booking button from the navbar. 5. Click the table selector and select the table you selected in step 2. 6. ISSUE: The screen is blank. Community PR: https://github.com/odoo/odoo/pull/176278
An automated website sale test was adjusted to match the updated badge styling used on wishlist elements. This helps keep quality checks reliable after recent visual design changes, without changing the customer-facing shopping experience.
Original PR description
- Requires : https://github.com/odoo/odoo/pull/176254 This commit aims to adapt the test to find the right DOM element. As the front-end badges recently got their design reviewed, we need to set some badges to `bg-*` (aka old badge design) instead of `text-bg-*` depending on the context. As we need to apply that `bg-primary` on the wishlist badge, the test has to be adapted. task-4106164
This fix makes the online bank synchronization connector check proxy mode values exactly as expected, using lowercase-only matching. It helps prevent incorrectly formatted proxy mode values from being accepted, reducing the chance of synchronization setup issues.
Original PR description
The `i` modifier is not needed in the regular expression, we need to check if proxy_mode matches the regex in a case-sensitive way. Task ID: 4067083
This fix ensures more text shown in Odoo Studio's button configuration can be translated correctly. It helps users working in different languages see consistent, localized labels instead of untranslated English text.
Original PR description
add .translate to untranslated props. This commit fixes the props that pass strings to use `.translate` introduced in: https://github.com/odoo/odoo/pull/174697 Community: https://github.com/odoo/odoo/pull/175909
Code cleanup and technical improvements
This change tightens the internal validation rules used by guided tours, making configuration issues easier to detect and reducing unused options. It affects automated onboarding and walkthrough flows in Expense and Subscriptions, with no expected direct change for everyday users.
Original PR description
For Tour : We specify the validation of the rainbowManMessage and fadeout keys of a tour. We also remove the rainbowMan key which is definitely not very useful. For Step : We precise the validation of tootipPosition and timeout. task~3974087 https://github.com/odoo/odoo/pull/176281
Miscellaneous changes
Before this commit: Some softwares do not follow the specification. Our users cannot import the generated XAF file in other softwares because the docRef length is more than 35 characters. After this commit: We allow our users to create a system parameter to change the docRef length if they need to import the XAF file in another software. opw-3792115 opw-3829459 Forward-Port-Of: odoo/enterprise#68174 Forward-Port-Of: odoo/enterprise#66551
Original PR description
Before this commit: Some softwares do not follow the specification. Our users cannot import the generated XAF file in other softwares because the docRef length is more than 35 characters. After this commit: We allow our users to create a system parameter to change the docRef length if they need to import the XAF file in another software. opw-3792115 opw-3829459 Forward-Port-Of: odoo/enterprise#68174 Forward-Port-Of: odoo/enterprise#66551
In AttendanceGanttModel, open ended records have their dateStopField set to the current moment. So, depending on the way time passes, the gantt pills can have different ending columns. In the hr_attendance_gantt tests, we use the hoot helper runAllTimers that accelerates time based on the registered timeouts. Since https://github.com/odoo/odoo/pull/175422, the service imStatusService registers timeouts with delay of 30 minutes. So runAllTimers often needs to advance time by steps of 30 min
Original PR description
In AttendanceGanttModel, open ended records have their dateStopField set to the current moment. So, depending on the way time passes, the gantt pills can have different ending columns. In the…
In AttendanceGanttModel, open ended records have their dateStopField set to the current moment. So, depending on the way time passes, the gantt pills can have different ending columns. In the hr_attendance_gantt tests, we use the hoot helper runAllTimers that accelerates time based on the registered timeouts. Since https://github.com/odoo/odoo/pull/175422, the service imStatusService registers timeouts with delay of 30 minutes. So runAllTimers often needs to advance time by steps of 30 minutes, sometimes more nondeterministically. This means that sometimes time has to advance more than 1 hours and this make some assertions on the pill ending columns fail. Here similarly to what is done in https://github.com/odoo/enterprise/pull/67088, we remove some services/main components only used by mail, so that imStatusService is no longer there and does no longer interfer with ours tests. We also take the oportunity to replace some calls to selectGanttRange by some clicks on the previous/next buttons. In that way, the intention behind the tests is clearer and time has to advance a bit less. This also corrects the wrong fix https://github.com/odoo/enterprise/pull/68033. Build 66645450 Forward-Port-Of: odoo/enterprise#68143
Steps to reproduce: 1. Create a product and add stock in the following location: WH/Stock/Shelf 2 2. Create a field service task and add this product 3. validate the task, the transfer will happen from WH/Stock Bug: If you validate the Sale Order, then the transfer, then the field service task, then transfer will happen from WH/Stock/Shelf 2 (as expected) Fix: apply same logic as for serial tracked products opw-3835698 Forward-Port-Of: odoo/enterprise#67948 Forward-Port-Of: odoo/e
Original PR description
Steps to reproduce: 1. Create a product and add stock in the following location: WH/Stock/Shelf 2 2. Create a field service task and add this product 3. validate the task, the transfer will happen from WH/Stock Bug: If you validate the Sale Order, then the transfer, then the field service task, then transfer will happen from WH/Stock/Shelf 2 (as expected) Fix: apply same logic as for serial tracked products opw-3835698 Forward-Port-Of: odoo/enterprise#67948 Forward-Port-Of: odoo/enterprise#65316
### Steps to reproduce * install python 3.12 * install odoo's python required libraries (requirements.txt) * install `l10n_ar_edi` * switch to an Argentinean company * in the Invoicing settings, under the AFIP Web Services section, click 'Test Connections' You should be met with the following error: `AttributeError: module 'lib' has no attribute 'PKCS7_sign'` ### Cause `PKCS7_sign()` was removed in recent version of `pyopenssl`. opw-4085411 opw-4085389 Forward-Port-Of: odoo/ent
Original PR description
### Steps to reproduce * install python 3.12 * install odoo's python required libraries (requirements.txt) * install `l10n_ar_edi` * switch to an Argentinean company * in the Invoicing settings, under the AFIP Web Services section, click 'Test Connections' You should be met with the following error: `AttributeError: module 'lib' has no attribute 'PKCS7_sign'` ### Cause `PKCS7_sign()` was removed in recent version of `pyopenssl`. opw-4085411 opw-4085389 Forward-Port-Of: odoo/enterprise#68024
This commit refactors the generation of pretty printed raw xml string to a helper function in `l10n_mx_edi.document` for `l10n_mx_edi` and `l10n_mx_reports`. It modifies the xml declaration to be a custom generated string, which only difference from the normal one is that it uses double quoted string rather than single quoted string in it. This way, the top file of the generated xml string will look like this: ```xml <?xml version="1.0" encoding="UTF-8"?> ``` This ensures as mu
Original PR description
This commit refactors the generation of pretty printed raw xml string to a helper function in `l10n_mx_edi.document` for `l10n_mx_edi` and `l10n_mx_reports`. It modifies the xml declaration to be a custom generated string, which only difference from the normal one is that it uses double quoted string rather than single quoted string in it. This way, the top file of the generated xml string will look like this: ```xml <?xml version="1.0" encoding="UTF-8"?> ``` This ensures as much support as possible from third party vendors because some do not consider single quoted string to be valid (even though it should be). related opw-4085399 task-id: no task Forward-Port-Of: odoo/enterprise#67963
This traceback arises when the user adds an existing attendee email to a guest email while adding a guest. To reproduce this traceback: 1) Install `website_appointment` 2) Choose any `appointment` from the website 3) Click on `Appointment Type` in the right corner and on the `options page` enable `Allow Guests` 4) Get back to the website and select one user, date & time 5) Now give Email value as email in Guests 6) Confirm Appointment Error:- ``` ValueError: Expected single
Original PR description
This traceback arises when the user adds an existing attendee email to a guest email while adding a guest. To reproduce this traceback: 1) Install `website_appointment` 2) Choose any `appointment`…
This traceback arises when the user adds an existing attendee email to a guest email while adding a guest. To reproduce this traceback: 1) Install `website_appointment` 2) Choose any `appointment` from the website 3) Click on `Appointment Type` in the right corner and on the `options page` enable `Allow Guests` 4) Get back to the website and select one user, date & time 5) Now give Email value as email in Guests 6) Confirm Appointment Error:- ``` ValueError: Expected singleton: calendar.attendee(4762, 4763) ``` When the user adds a guest with the current user email, multiple attendees will be created with the same partner ID in a calendar event (see below) https://github.com/odoo/enterprise/blob/1aff50d91fad45221377591b80ca8b1df2ecb593/appointment/models/appointment_type.py#L944-L955 This leads to the above traceback from here https://github.com/odoo/enterprise/blob/1aff50d91fad45221377591b80ca8b1df2ecb593/appointment/controllers/calendar.py#L103 This commit will resolve the issue by filtering out the existing attendees while creating a new attendee from the guest email. sentry-5646921453 Forward-Port-Of: odoo/enterprise#67516
During the development of the new annotation system, some comments were left on the side to implement the annotation systems as fast as possible, this PR takes care of two of those comments. Each in a separate commit. task-4045835 Forward-Port-Of: odoo/enterprise#67112
Original PR description
During the development of the new annotation system, some comments were left on the side to implement the annotation systems as fast as possible, this PR takes care of two of those comments. Each in a separate commit. task-4045835 Forward-Port-Of: odoo/enterprise#67112
At the moment, if any of the taxes for which l10n_ke_edi_oscu adds tax types doesn't exist, the upgrade to 17.0 fails, because l10n_ke_edi_oscu is set to auto_install. We don't want this upgrade to fail, especially given that this might affect customers who have no intention of using l10n_ke_edi_oscu. Solution: we simply don't set the tax type on those taxes which don't exist. If the user wants to use l10n_ke_edi_oscu properly, they should re-load the taxes via the Reload button in the Acc
Original PR description
At the moment, if any of the taxes for which l10n_ke_edi_oscu adds tax types doesn't exist, the upgrade to 17.0 fails, because l10n_ke_edi_oscu is set to auto_install. We don't want this upgrade to fail, especially given that this might affect customers who have no intention of using l10n_ke_edi_oscu. Solution: we simply don't set the tax type on those taxes which don't exist. If the user wants to use l10n_ke_edi_oscu properly, they should re-load the taxes via the Reload button in the Accounting settings. Forward-Port-Of: odoo/enterprise#67180
Currently, an error is generated when the user tries to add a new 'One2Many' field in the model. Steps to produce: 1. Create a new app and new model with studio 2. Try to add the 'One2Many' field in view >>> error occurs Stack Trace: ``` KeyError: 'node' File "odoo/http.py", line 2373, in __call__ response = request._serve_db() File "odoo/http.py", line 1903, in _serve_db return self._transactioning( File "odoo/http.py", line 1966, in _transactioning return serv
Original PR description
Currently, an error is generated when the user tries to add a new 'One2Many' field in the model. Steps to produce: 1. Create a new app and new model with studio 2. Try to add the 'One2Many' field in…
Currently, an error is generated when the user tries to add a new 'One2Many' field in the model.
Steps to produce:
1. Create a new app and new model with studio
2. Try to add the 'One2Many' field in view >>> error occurs
Stack Trace:
```
KeyError: 'node'
File "odoo/http.py", line 2373, in __call__
response = request._serve_db()
File "odoo/http.py", line 1903, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1966, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1933, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2177, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "home/odoo/src/enterprise/saas-17.4/web_studio/controllers/main.py", line 692, in edit_view
getattr(self, '_operation_%s' % (op['type']))(arch, op, model)
File "home/odoo/src/enterprise/saas-17.4/web_studio/controllers/main.py", line 905, in _operation_add
node = operation['node']
```
This is because when we try to add 'One2Many' in view, there is no 'one2many' field available in the model, so it tries to add a new field without a node.
This commit will fix the above issue by preventing adding structure when there is no node (_operation).
With the recent changes with https://github.com/odoo/enterprise/commit/e59cf81bd4b18bdbc3da640f9a079209c06626a4, code was refactored for ading field but not added condition for an empty node .
sentry-5656743440
Forward-Port-Of: odoo/enterprise#67692Asia/Calcutta was removed in ubuntu Noble in favor of Asia/Kolkata This is only visible in the pure noble build and not in the standard build. The assumption is that since requirements are installed as root, the tz is added when installing the pip package. Since we will soon install requirements as odoo on runbot in the docker image, this should will start to break in standard builds too. Forward-Port-Of: odoo/enterprise#68150
Original PR description
Asia/Calcutta was removed in ubuntu Noble in favor of Asia/Kolkata This is only visible in the pure noble build and not in the standard build. The assumption is that since requirements are installed as root, the tz is added when installing the pip package. Since we will soon install requirements as odoo on runbot in the docker image, this should will start to break in standard builds too. Forward-Port-Of: odoo/enterprise#68150
PERIODS_PER_YEAR is using "yearly" but hr_contract uses "anually" and since this model uses the hr_contract, we need to keep the same dictionary keys. In customer database the installation of the module is failing because cannot find key "anually". The issue would also happen if you just set a yearly wage opw-4083058 Forward-Port-Of: odoo/enterprise#68127 Forward-Port-Of: odoo/enterprise#68036
Original PR description
PERIODS_PER_YEAR is using "yearly" but hr_contract uses "anually" and since this model uses the hr_contract, we need to keep the same dictionary keys. In customer database the installation of the module is failing because cannot find key "anually". The issue would also happen if you just set a yearly wage opw-4083058 Forward-Port-Of: odoo/enterprise#68127 Forward-Port-Of: odoo/enterprise#68036
Overrides the generic xlsx export button on the intrastat report for Denmark. When pressing the button, it now generates the official documents that can then be uploaded on the official website "Statistics Denmark" for intrastat reporting. Depending on the filter 'intrastat type', the following use cases are possible: Intratat type filter | Document generated ----------------------------------------------- arrivals | official xlsx for arrivals dispatches |
Original PR description
Overrides the generic xlsx export button on the intrastat report for Denmark. When pressing the button, it now generates the official documents that can then be uploaded on the official website "Statistics Denmark" for intrastat reporting. Depending on the filter 'intrastat type', the following use cases are possible: Intratat type filter | Document generated ----------------------------------------------- arrivals | official xlsx for arrivals dispatches | official xlsx for dispatches none or both | zip file containing both xlsx The xlsx files that are generated follow the official format, which can be found at this address in the file examples 'Intrastat eksport/import Excel Line' https://www.dst.dk/en/Indberet/hjaelp-til-indberetning/om-idep-web/intrastat task-3976189 Forward-Port-Of: odoo/enterprise#68079 Forward-Port-Of: odoo/enterprise#65412
This commit aims to move the context manager '_get_edi_creation()' from account.move to the import methods inside edi's such as mx_edi, ke_edi because moving it to account_move method: '_extend_with_attachments' was causing issue to the importation of bills from account_edi_ubl_cii. related: https://github.com/odoo/odoo/pull/173843 Forward-Port-Of: odoo/enterprise#67900 Forward-Port-Of: odoo/enterprise#67002
Original PR description
This commit aims to move the context manager '_get_edi_creation()' from account.move to the import methods inside edi's such as mx_edi, ke_edi because moving it to account_move method: '_extend_with_attachments' was causing issue to the importation of bills from account_edi_ubl_cii. related: https://github.com/odoo/odoo/pull/173843 Forward-Port-Of: odoo/enterprise#67900 Forward-Port-Of: odoo/enterprise#67002
11 changes
New functionality added to Odoo
This update introduces a new corporate tax report for Bangladesh operations. Users can now configure specific accounts in settings and automatically generate accounting entries with tax amounts directly from the report. The update also fixes a duplicate naming issue in the tax report.
Original PR description
[ADD] l10n_bd_reports: Create corporate tax report * Create new account tags * Create new corporate report * Create new fields in the settings to allow the user specifying accounts that should be used in the accounting entry * Create custom accounting entry button to create a move with the accounts specified by the user with amounts specified in the 'corporate tax amount' line in the corporate tax report NOTE: there is an issue with the name of the tax report, '(BD)' in the name is duplicate. So, Fixed it in this pr task-id#3974212 odoo-pr#https://github.com/odoo/odoo/pull/172254
Enhancements to existing features
The Kenya EDI system now accepts serial numbers with varying capitalization (e.g., "Odoo/pin/1" or "odoo/Pin/1" instead of only "ODOO/pin/1"). This change makes the system more user-friendly by accepting serial numbers regardless of how users capitalize the text when copying and pasting, reducing data entry errors.
Original PR description
We want to provide more flexibility to the user that instead of ODOO/pin/1 they did Odoo/pin/1 or odoo/Pin/1 as the serial number, we will still accept it. Because, while copying, you do not necessarily pay attention to capital letters or not.
This update improves how asset depreciation is calculated for Indian companies to comply with the Company Act of 2013. The depreciation calculation now uses the full original asset cost with a fixed 5% residual value, rather than the previous method. This ensures Indian businesses calculate depreciation correctly according to local regulations.
Original PR description
[IMP] l10n_in_reports, account_asset: Improve indian degressive depreciation according to the Company Act of 2013, depreciation should be calculated on the full cost 'original_value' and the residual value should be 5%, which is 5,000 in this casefor the indian case only so, it's not the general case. So, we need to overwrite the logic of the degressive depreication to adapt the desired flow. Now, We calculate the degressive amount by 'factor * current_value of asset' excluding 'salvage_value' task-id#3909619
A new EC sales list report has been added specifically for Denmark, allowing businesses to generate and export sales data in CSV format as required by Danish government regulations. This improvement enables Danish companies to easily comply with EC sales reporting requirements directly from Odoo.
Original PR description
Denmark government need a way to get ec sales. So now we have a report dedicated to denmark with an export to a CSV format task: 4080107 Backporting: https://github.com/odoo/enterprise/pull/58413/commits/d9f7ccdfd062fdc4e372951ff65a5f09046ad7b7
This update allows users to adjust the document reference length in XAF file exports for Dutch accounting reports. Previously, the fixed length exceeded what some accounting software could accept, preventing file imports. Now users can configure a system parameter to customize this length, making the exported files compatible with more third-party accounting systems.
Original PR description
Before this commit: Some softwares do not follow the specification. Our users cannot import the generated XAF file in other softwares because the docRef length is more than 35 characters. After this commit: We allow our users to create a system parameter to change the docRef length if they need to import the XAF file in another software. opw-3792115 opw-3829459 Forward-Port-Of: odoo/enterprise#68053 Forward-Port-Of: odoo/enterprise#66551
Resolved issues and error corrections
This fix resolves a visual problem where the MRP work order display showed a black box in dark mode instead of properly adapting to the theme. The update ensures the display looks correct and consistent whether users are working in light or dark mode by using Odoo's color scheme instead of Bootstrap's default styling.
Original PR description
Instead of using the `bg-white` class from boostrap, which is translated to black in dark-mode, make use of the color-scheme from odoo. This avoids having a mismatch between light and dark mode. Before (Dark / Light):  After (Dark / Light): 
This update fixes a missing required field in the Swiss payroll sickness insurance form view. The field was not properly configured in the system interface, which could have caused issues when users tried to enter sickness insurance information. This fix ensures the form displays and functions correctly for HR teams managing Swiss payroll.
Fixed an issue where appointment booking buttons with custom formatting would incorrectly route users to all appointments instead of the specific appointment type they selected. The fix ensures that styled buttons properly direct customers to their intended appointment type by accounting for nested HTML elements within the button.
Original PR description
Issue ----- When adding formating to an appointment button linked to a specific type of appointment, the button will lead to all appointments instead of just the specific type. Change ----- Since buttons can have custom formatting, this will add HTML elements inside the button element. Therefore, we need to take into account that the target of the event may not be the button itself. opw-4080512
This fix ensures that branch companies can properly access and report on unaffected earnings accounts from their parent company in general ledger and trial balance reports. When both a company and its branch are selected, the system now correctly sums the financial movements on the unaffected earnings account, providing accurate financial reporting across the organization.
Original PR description
On the general ledger and trial balance, the branch company needs to get access to the parent unaffected earning account. Also if a company and a branch is selected, we need to sum the moves on the unaffected earnings account. opw-3937063
Users with proper timesheet access permissions can now create invoices for sales orders with validated timesheets without encountering access errors. The fix adjusts permission checks to properly recognize authorized users, enabling the invoicing workflow to function correctly when timesheets are locked and validated.
Original PR description
## Issue: - A user with sufficient access rights to timesheet, ('User: all timesheets' or 'User: own timesheets only') cannot create an invoice for a sales order within a specific timesheet period,…
## Issue:
- A user with sufficient access rights to timesheet, ('User: all timesheets' or 'User: own timesheets only') cannot create an invoice for a sales order within a specific timesheet period, receiving the error: 'Timesheets before [PERIOD] are validated and cannot be modified.'
## Steps To Reproduce:
- Edit `Create on Order` of the `Service on Timesheets` product to be `Project & Task`.
- in settings:
- enable the `Lock Timesheets` option.
- set the invoicing policy for Timesheets to `validated timesheets only` .
- set the invoicing policy for Sales to 'invoice what is delivered'.
- Update the timesheet access for `Marc Demo` and set it as 'User: all timesheets'.
- Create a SO with `Service on Timesheets` as a product.
- On the related Task create a timesheet for period 01 May to 31 May and validate it.
- With Marc Demo click on Create an Invoice on the SO, for the same period notice The Access Error.
## Solution:
- in `check_if_allowed` I modified the condition to check if the current user is not a superuser.
opw-3965532
Forward-Port-Of: odoo/enterprise#65435This fix resolves issues with scanning GS1 barcodes that contain packaging information for tracked products. Previously, when scanning such barcodes, the system failed to retrieve packaging data and lot/serial numbers correctly. Now users can successfully scan and process tracked products with packaging using GS1 barcodes, improving warehouse operations efficiency.
Original PR description
Before this commit, when scaning a GS1 barcode containing a packaging for a tracked product and a lot, it doesn't work. This commit fixes two issues: 1. Get back packaging data (product and quantity) when a GS1 barcode is scanned; 2. Be able to find the lot/serial number when a GS1 barcode with no product but a packaging is scanned. Forward-Port-Of: odoo/enterprise#67947 Forward-Port-Of: odoo/enterprise#67727