Daily updates from Odoo
Navigate
Branch
Monday, October 7, 2024
81 changes
12 changes
Resolved issues and error corrections
Users can now duplicate multiple e-learning courses from the list view without encountering an error. This improves reliability for teams managing course catalogs in bulk.
Original PR description
Steps to reproduce: 1. Go to e-learning 2. Switch to list view 3. Select multiple courses 4. Duplicate them Technical Reason: In the 'copy_data' method, there was an incorrect indentation in the loop, and one condition needed to be placed inside the loop. After this Commit: No traceback will occur on duplicating multiple courses. Task-4211075
This fix keeps dragged items aligned with the mouse when users build mailings inside Marketing Automation. It prevents confusing drag-and-drop behavior in editor popups, making campaign creation more reliable.
Original PR description
- open "marketing automation" - create a campaign - add a mailing activity - open the mailing inside the activity (in a modal) - drag an item from the snippet menu - yank the mouse FAST over the editor, such that the mouse overshoots the dragged snippet (editing the dragged element to be smaller may help) - the dragged element does not follow the mouse until the mouse leaves the editor iframe Drag and drop relies on `clientX` and `clientY` being in the coordinates of the viewport. When entering an iframe, mouse event coordinates (other than screen-based) are given relative to the viewport of the iframe. This means the position of the drag and drop does not match the position of the mouse. The only way to avoid this is to either prevent the iframe from becoming the target of the event using style="pointer-event: none;" on the iframe itself. Alternatively we can correct for the offset of the iframe. task-4160857
Miscellaneous changes
Steps to reproduce (from empty runbot): 1. Install pos_loyalty 2. Edit the existing active program named "Loyalty Program" 2a. Set "Program Type" to "Buy X Get Y" 2b. Change the existing reward to "[CONS_0002] Simple Pen"  3. Start a new POS session with the "Shop" POS. 4. Add two Whiteboard Pens, and claim the reward. 5. Pay for the order with bank payment, and start a new order. 6. Start a refund
Original PR description
Steps to reproduce (from empty runbot): 1. Install pos_loyalty 2. Edit the existing active program named "Loyalty Program" 2a. Set "Program Type" to "Buy X Get Y" 2b. Change the existing reward to…
Steps to reproduce (from empty runbot): 1. Install pos_loyalty 2. Edit the existing active program named "Loyalty Program" 2a. Set "Program Type" to "Buy X Get Y" 2b. Change the existing reward to "[CONS_0002] Simple Pen"  3. Start a new POS session with the "Shop" POS. 4. Add two Whiteboard Pens, and claim the reward. 5. Pay for the order with bank payment, and start a new order. 6. Start a refund of the last order, refund the 2 Whiteboard Pens and the 1 Simple Pen.  7. Continue the refund, and back at the main POS screen, now add two more Whiteboard Pens. 8. Notice that no reward is claimable 8a. It becomes claimable if you add two more Whiteboard Pens, for a total of 4.  Before this commit, `pointsForPrograms` would calculate based on every order line present in the POS. However, this could lead to situations where lines that shouldn't be counted do get counted. For instance, a refund line should not be counted, as it would add a negative amount to the total amount. After this commit, only non refund lines are used in `pointsForPrograms`, which are defined as lines that do not have a `refunded_orderline_id` set. opw-4080144 Forward-Port-Of: odoo/odoo#177312
The computation of ODOO.BALANCE with year offsets was wrong as we would apply the offset once to query the debit data and TWICE when querying the credit data, making the computation of the delta completely meaningless. Task-4207414 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#182162 Forwa
Original PR description
The computation of ODOO.BALANCE with year offsets was wrong as we would apply the offset once to query the debit data and TWICE when querying the credit data, making the computation of the delta completely meaningless. Task-4207414 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#182162 Forward-Port-Of: odoo/odoo#181256
Found error during migration in customer database. when company is archived but will get that company on `self.env.company` of pos_config table, this error is generated when it's try to create the record for pos config from pos_resturant module by data file (defined on this commit) https://github.com/odoo/odoo/commit/3236c1cb5025d2c2d446d11f67fda1ea51ceb992 as picking_type_id field in pos_config is required and we set default value by fetching warehouse for related company but here as co
Original PR description
Found error during migration in customer database. when company is archived but will get that company on `self.env.company` of pos_config table, this error is generated when it's try to create the…
Found error during migration in customer database. when company is archived but will get that company on `self.env.company` of pos_config table,
this error is generated when it's try to create the record for pos config from pos_resturant module
by data file (defined on this commit)
https://github.com/odoo/odoo/commit/3236c1cb5025d2c2d446d11f67fda1ea51ceb992
as picking_type_id field in pos_config is required and we set default value by fetching warehouse for related company but here as company is archived, related warehouse is also archived and that why we didnot get picking_type_id for archived company and that will raise Error :
```
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4787, in _create
cr.execute(SQL(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "picking_type_id" of relation "pos_config" violates not-null constraint
```
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#162627
Forward-Port-Of: odoo/odoo#151719The following error occurs when you try to open a session as the superuser. Steps to reproduce: - Install the ``Point_of_sale`` module - Activate developer mode / click on debugger / Become superuser - Point of sale / click on open Register Traceback: ``IndexError: list index out of range`` This error occurs when we open a session as a superuser. When we attempt to open it, at line [1] ``res.users`` is returned as empty. [1]- https://github.com/odoo/odoo/blob/585635e8afa531b8a
Original PR description
The following error occurs when you try to open a session as the superuser. Steps to reproduce: - Install the ``Point_of_sale`` module - Activate developer mode / click on debugger / Become superuser - Point of sale / click on open Register Traceback: ``IndexError: list index out of range`` This error occurs when we open a session as a superuser. When we attempt to open it, at line [1] ``res.users`` is returned as empty. [1]- https://github.com/odoo/odoo/blob/585635e8afa531b8a66295a4afe0fcdd369ed188/addons/point_of_sale/models/pos_session.py#L379 sentry-5082852453 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178140 Forward-Port-Of: odoo/odoo#172468
Problem: When multiple warehouses are selected in the products list page filter, clicking the Forecast button on the product page causes a traceback due to not handling multiple selected warehouses. Steps to reproduce: - Create two warehouses. - Go to Inventory > Products. - Add a filter for Warehouse 1 or Warehouse 2. - Open a product page. - Click the Forecast button. - Traceback occurs. opw-4149904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.c
Original PR description
Problem: When multiple warehouses are selected in the products list page filter, clicking the Forecast button on the product page causes a traceback due to not handling multiple selected warehouses. Steps to reproduce: - Create two warehouses. - Go to Inventory > Products. - Add a filter for Warehouse 1 or Warehouse 2. - Open a product page. - Click the Forecast button. - Traceback occurs. opw-4149904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178909
Similar issue than the one fixed here [^1], if a spreadsheet already contained a pivot with some pivot-view related context, it would be used to load the pivot model inside spreadsheet. This becomes a bigger issue in later versions where we added extented granularity. [^1]: https://github.com/odoo/enterprise/issues/44075 Task: 4129333 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I ha
Original PR description
Similar issue than the one fixed here [^1], if a spreadsheet already contained a pivot with some pivot-view related context, it would be used to load the pivot model inside spreadsheet. This becomes a bigger issue in later versions where we added extented granularity. [^1]: https://github.com/odoo/enterprise/issues/44075 Task: 4129333 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#182376 Forward-Port-Of: odoo/odoo#177428
### Steps to reproduce the issue: 1. Create a Parent Company and a Branch Company 2. In the Parent Company, click on the "Branches" Smart Button 3. From there, create another Branch Company 4. On save, this error appears: > odoo.exceptions.UserError: Incompatible companies on records: > - [Company Name] belongs to company [Company Name] and 'Address' (partner_id: [Company Name]) belongs to another company. ### Explanation: When accessing its branches, the context key `def
Original PR description
### Steps to reproduce the issue: 1. Create a Parent Company and a Branch Company 2. In the Parent Company, click on the "Branches" Smart Button 3. From there, create another Branch Company 4. On…
### Steps to reproduce the issue: 1. Create a Parent Company and a Branch Company 2. In the Parent Company, click on the "Branches" Smart Button 3. From there, create another Branch Company 4. On save, this error appears: > odoo.exceptions.UserError: Incompatible companies on records: > - [Company Name] belongs to company [Company Name] and 'Address' (partner_id: [Company Name]) belongs to another company. ### Explanation: When accessing its branches, the context key `default_parent_id` is set to the Parent Company's `id`. It is used to make sure the Branch Company has the Parent Company as `parent_id`. https://github.com/odoo/odoo/blob/4d5195d6756d47c33929fffa972ee801bb833622/odoo/addons/base/models/res_company.py#L423-L426 It is not removed when creating the Branch Partner, and this value will be used to assign a `parent_id` to the Branch Partner through `get_default`, this alone could create an out of range error if there is no `res.partner` with the same `id` as the Parent Company. https://github.com/odoo/odoo/blob/fbf95d3c4655b23554fe5dfa136382472041c195/odoo/addons/base/models/res_partner.py#L193-L197 https://github.com/odoo/odoo/blob/71b6eeed0a648934525cd758afebdb87500ec939/odoo/models.py#L1488-L1491 If there is a Parent Partner, it will give its `company_id` to the Branch Partner. Afterwards, `stock.warehouse` is created with the Branch Company as `company_id` and the Branch Partner as `partner_id`. https://github.com/odoo/odoo/blob/78e44dc5a3dee67956f380fa468bab02692ce5ac/addons/stock/models/res_company.py#L202-L207 During its creation, `stock.warehouse` will call `_check_company` and, when `res.partner.company_id` is not in `stock.warehouse.company_id.parent_ids`, will report the inconsistency. https://github.com/odoo/odoo/blob/71b6eeed0a648934525cd758afebdb87500ec939/odoo/models.py#L4068-L4073 https://github.com/odoo/odoo/blob/71b6eeed0a648934525cd758afebdb87500ec939/odoo/models.py#L185-L189 ### Fix reasoning: Removing the problematic context key `default_parent_id` during the creation of the Branch Partner will avoid any out of range error and most importantly will not assign a default value to the Partner when it should not have one. opw-4194396 Forward-Port-Of: odoo/odoo#182342
Before these changes, the total price of the invoices was displayed in the kanban view without considering whether it was an outgoing or incoming payment. This can cause confusion for the user when charging customers.  After these changes, the total is displayed with the symbol so that users can easily differentiate the type of invoice, just as it is done in the tree views.  After these changes, the total is displayed with the symbol so that users can easily differentiate the type of invoice, just as it is done in the tree views.  cc @Tecnativa TT50987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182088 Forward-Port-Of: odoo/odoo#181424
This **PR** introduces new TDS rates in accordance with the Union Budget 2024. **task**-4138335 Forward-Port-Of: odoo/odoo#181797
Original PR description
This **PR** introduces new TDS rates in accordance with the Union Budget 2024. **task**-4138335 Forward-Port-Of: odoo/odoo#181797
When installing Event via the Apps menu, you actually install website_event (and therefore Website). This means that the next action the user has to take is installing a theme. In the case of a demo setup, the cron for the mail scheduler of Event will launch immediately post-install and will run for a rather long time, preventing any other module from installing (because module installations are blocked whilst a cron is running). This means that after installing the Website event in a d
Original PR description
When installing Event via the Apps menu, you actually install website_event (and therefore Website). This means that the next action the user has to take is installing a theme. In the case of a demo setup, the cron for the mail scheduler of Event will launch immediately post-install and will run for a rather long time, preventing any other module from installing (because module installations are blocked whilst a cron is running). This means that after installing the Website event in a demo setup, the user is the prevented from finishing the website setup until the cron is finished. This commit introduces a 'grace period' of 15min until the cron first runs, making it possible to finish the website setup right away. Forward-Port-Of: odoo/odoo#182488
23 changes
Enhancements to existing features
Point of Sale related enterprise apps now align with the updated order naming format from the core POS system. Ticket screens also use the standard list view, improving consistency for staff reviewing orders across POS workflows.
Original PR description
In this commit we adapt the code in the pos modules to follow the change in the corresponding community pr, where we change the format of the pos order name. Task: 4141140 https://github.com/odoo/odoo/pull/179093
This update aligns Accounting with a related platform change that restricts creating, updating, or deleting analytic entries tied to journal items. It helps preserve accounting data integrity by preventing accidental changes unless the proper system context is provided.
Original PR description
Adapt to community PR, which add a context key requirement in order to delete an analytic item related to a journal item. Community PR: https://github.com/odoo/odoo/pull/171901 task-3977961
Additional tests were added for the WhatsApp integration in marketing automation. This helps ensure the newer WhatsApp campaign functionality behaves reliably and reduces the risk of regressions in future updates.
Original PR description
The commit intends to add tests to newly introduced functionality of marketing automation where we added whatsapp.
This update simplifies how a project-related document action is configured behind the scenes. It helps keep the project document experience easier to maintain without introducing noticeable changes for everyday users.
Original PR description
task-4184991
Resolved issues and error corrections
In multi-company setups, employee time off is now shown consistently in the Project task Gantt view even when switching companies. This helps planners avoid assigning work during an employee's approved leave and prevents missed scheduling warnings.
Original PR description
In the multi-company environment, the user's holiday warning will be displayedin the project task gantt view.
Steps to reproduce:
------
- Take time off for one employee in their company
- Create a project with no company set
- Go to the tasks > Gantt view
- You will see it greyed out for the time that he is off & if you assign a task to them during time off you will see it with a red error message.
- Change company:
- You don't see it in the gantt view greied out.
- You don't have a warning for the person being in time off.
task-3697932This fixes how German tax report input amounts are displayed after related tax tag signs were updated. It prevents amounts from being incorrectly flipped, helping businesses see accurate tax report figures.
Original PR description
Since we reversed the signs of those tax tags, we don't need to change the sign here anymore. task-3100357
The Documents app now hides the inspector collapse button on mobile devices. This prevents users from opening a blank inspector panel and makes the mobile experience clearer and less confusing.
Original PR description
Before this Commit: The fold button in the inspector within a desktop view collapses the inspector, while in the mobile view, it displays a blank panel in the inspector. After this Commit: the fold button is not visible in the mobile view. Task:3919285
Code cleanup and technical improvements
This draft pull request appears to be a technical refactoring or test-related change, but no changed files or commit details were provided. Based on the title, it likely has minimal direct business impact and is intended to improve internal maintainability.
Miscellaneous changes
Problem: When an issued address for a journal has a different timezone than the journal's company address, the generated date for the CFDI is incorrect because it uses the issued address's timezone instead of the company's timezone. Steps to reproduce: - Install 'l10n_mx' and 'l10n_mx_edi_extended'. - Switch to the "ESCUELA KEMPER URGATE" company. - Go to Settings > Configuration > MX Electronic Invoicing and change the PAC to "Solución Factible." - In Contacts, open "ESCUELA KEMPER UR
Original PR description
Problem: When an issued address for a journal has a different timezone than the journal's company address, the generated date for the CFDI is incorrect because it uses the issued address's timezone…
Problem:
When an issued address for a journal has a different timezone than the journal's company address, the generated date for the CFDI is incorrect because it uses the issued address's timezone instead of the company's timezone.
Steps to reproduce:
- Install 'l10n_mx' and 'l10n_mx_edi_extended'.
- Switch to the "ESCUELA KEMPER URGATE" company.
- Go to Settings > Configuration > MX Electronic Invoicing and change the PAC to "Solución Factible."
- In Contacts, open "ESCUELA KEMPER URGATE" under Contacts and Addresses, and add an invoice address:
- Name: "Invoice Contact"
- Country: Mexico
- State: Tamaulipas (MX) ZIP: 88776
- Create a journal named "Invoice Journal" and assign:
- "Invoice Contact" as the issued address.
- "401.01.01 Sales and/or services taxed at the general rate" as the Default Income Account.
- "Transferencia electrónica de fondos" as the Payment Way.
- Create a new invoice with:
- Customer: "INMOBILIARIA CVA"
- Payment Way: "Transferencia electrónica de fondos"
- Journal: "Invoice Journal"
- Add a product with "UNSPSC Category" under Accounting on the product page set to "01010101 Does not exist in the catalog."
- Confirm the invoice, then Send & Print with "CFDI" checked.
- Register payment with some of the amount.
- Click on "Update Payments."
- On the CFDI tab, in the first row, click on "Force CFDI."
- The payment should succeed.
opw-4076021
Forward-Port-Of: odoo/enterprise#68610**Before this PR:** If no appointment is set, the overview page displays "[object SVGSVGElement]" instead of an image. **Technical:** The outerHTML property accepts an HTML string, while renderToElement(...) returns a node. The issue occurs from commit: https://github.com/odoo/enterprise/commit/9e38975d3f1e9dc87a3061c06ce9df7cf562949c **After this PR:** A proper image appears on the overview page. Task-4208073 Forward-Port-Of: odoo/enterprise#71076
Original PR description
**Before this PR:** If no appointment is set, the overview page displays "[object SVGSVGElement]" instead of an image. **Technical:** The outerHTML property accepts an HTML string, while renderToElement(...) returns a node. The issue occurs from commit: https://github.com/odoo/enterprise/commit/9e38975d3f1e9dc87a3061c06ce9df7cf562949c **After this PR:** A proper image appears on the overview page. Task-4208073 Forward-Port-Of: odoo/enterprise#71076
**How to reproduce:** - Set an appointment as paid and requires 'Manual Confirmation'. - Book the appointment. **Purpose:** Here, it shows as appointment 'Booked', but the appointment status is still in 'request'. **Specifications:** When the status is 'request' show 'Reserved' in blue banner with a thumbs-up icon. Task-4210614 Forward-Port-Of: odoo/enterprise#70707
Original PR description
**How to reproduce:** - Set an appointment as paid and requires 'Manual Confirmation'. - Book the appointment. **Purpose:** Here, it shows as appointment 'Booked', but the appointment status is still in 'request'. **Specifications:** When the status is 'request' show 'Reserved' in blue banner with a thumbs-up icon. Task-4210614 Forward-Port-Of: odoo/enterprise#70707
Enhance the invoice functionality by including the reference field (ref) in the XML sent to Uruware using the <CompraID> tag, and ensure it's automatically included in the PDF generated by Uruware. This info is optional, but it is required by some receptors in order to accept the invoice (big invoicing volume receptors) LATAM task 1267 / ADHOC ticket 80811 Forward-Port-Of: odoo/enterprise#70970
Original PR description
Enhance the invoice functionality by including the reference field (ref) in the XML sent to Uruware using the <CompraID> tag, and ensure it's automatically included in the PDF generated by Uruware.
This info is optional, but it is required by some receptors in order to accept the invoice (big invoicing volume receptors)
LATAM task 1267 / ADHOC ticket 80811
Forward-Port-Of: odoo/enterprise#70970Steps to reproduce ================== - Install studio,project - Open any task - Open studio - Toggle show invisible elements => Some fields are displayed inside the button box Cause of the issue ================== Some always invisible non buttons elements are sometimes used inside a button box. https://github.com/odoo/odoo/blob/1c685b9ce7483c426fc2db964ef357003229ddc6/addons/project/views/project_task_views.xml#L269-L275 opw-4164661 Forward-Port-Of: odoo/enterprise#7105
Original PR description
Steps to reproduce ================== - Install studio,project - Open any task - Open studio - Toggle show invisible elements => Some fields are displayed inside the button box Cause of the issue ================== Some always invisible non buttons elements are sometimes used inside a button box. https://github.com/odoo/odoo/blob/1c685b9ce7483c426fc2db964ef357003229ddc6/addons/project/views/project_task_views.xml#L269-L275 opw-4164661 Forward-Port-Of: odoo/enterprise#71054 Forward-Port-Of: odoo/enterprise#70380
- Install the Field Services (industry_fsm) and sales module. - Create a sale order with the following configuration: - Select any customer. - Select the product 'Junior Architect' (Invoice on Timesheets). - Confirm the sale order. - On the header of the sale order, click on the project option. - Then, in the left side corner, click on 'Share Editable'. - Share the project to your company. - Log in as a portal user. - Open the projects menu. - Open the project you just shared. -
Original PR description
- Install the Field Services (industry_fsm) and sales module. - Create a sale order with the following configuration: - Select any customer. - Select the product 'Junior Architect' (Invoice on…
- Install the Field Services (industry_fsm) and sales module. - Create a sale order with the following configuration: - Select any customer. - Select the product 'Junior Architect' (Invoice on Timesheets). - Confirm the sale order. - On the header of the sale order, click on the project option. - Then, in the left side corner, click on 'Share Editable'. - Share the project to your company. - Log in as a portal user. - Open the projects menu. - Open the project you just shared. - In the kanban view, click on the 'Quick Create Task' button. - Add a task name and click on the edit button. - You will see the form view where the customer and sale order item are not set by default. Issue: ------------------ When logging in as a portal user(project sharing), the fields for Customer and Sale Order Item are not set by default when creating a task via quick create in the Kanban view. Cause: ------------------- The _compute_partner_id function relies on the project_id field to determine the partner_id (customer) for a task. However, in the quick create view, only the partner_id field is mentioned . in the quick view, the project ID is not provided so the partner ID cannot be computed, resulting in an empty field for the partner_id (customer). Solution: ---------------------- add a project_id field in the 'project_sharing_quick_create_task_form_inherit' quick create form view. task-3743360 Forward-Port-Of: odoo/enterprise#70512 Forward-Port-Of: odoo/enterprise#57113
Issue: - The timesheet does not unlink properly when the timer stops. - Consequently, starting the timer again links it to the previous timesheet, causing incorrect behavior. Solution: - Set the timesheet reference to `undefined` when stopping the timer. - This ensures that a new timesheet is created when the timer starts again, preventing any link to the previous timesheet. Steps to reproduce: 1) Install the `timesheet_grid` module. 2) Navigate to Timesheet App > My Timesh
Original PR description
Issue: - The timesheet does not unlink properly when the timer stops. - Consequently, starting the timer again links it to the previous timesheet, causing incorrect behavior. Solution: - Set the timesheet reference to `undefined` when stopping the timer. - This ensures that a new timesheet is created when the timer starts again, preventing any link to the previous timesheet. Steps to reproduce: 1) Install the `timesheet_grid` module. 2) Navigate to Timesheet App > My Timesheet > Kanban view. 3) Start the timer from the Kanban view. 4) Stop the timer from the Kanban view. 5) Repeat step 3. 6) Verify the timer's time. task-4176611 Forward-Port-Of: odoo/enterprise#71285 Forward-Port-Of: odoo/enterprise#70366
Having a fiscal position in multi-vat, annotating an account can lead to a traceback because PostreSQL expects an int and not a recordset Forward-Port-Of: odoo/enterprise#71214
Original PR description
Having a fiscal position in multi-vat, annotating an account can lead to a traceback because PostreSQL expects an int and not a recordset Forward-Port-Of: odoo/enterprise#71214
Forward-Port-Of: odoo/enterprise#71171
Original PR description
Forward-Port-Of: odoo/enterprise#71171
Since PR odoo/enterprise#181141, when a qweb table menu is displayed, it no longer disappears when the pointer moves outside it. This commit will reintroduce the old behavior: - When the pointer quits a closed qweb table menu, we make it disappear. - When the pointer leaves an open qweb table menu, it doesn't disappear. You need to do a pointerdown to make it disappear. We'll also add a close to the qweb table menu when scrolling. This will have the same behavior as the table menu. Forw
Original PR description
Since PR odoo/enterprise#181141, when a qweb table menu is displayed, it no longer disappears when the pointer moves outside it. This commit will reintroduce the old behavior: - When the pointer quits a closed qweb table menu, we make it disappear. - When the pointer leaves an open qweb table menu, it doesn't disappear. You need to do a pointerdown to make it disappear. We'll also add a close to the qweb table menu when scrolling. This will have the same behavior as the table menu. Forward-Port-Of: odoo/enterprise#71173
before this commit, if user need to pass any different value to the sale order creation, there is no direct hook available to do the same after this commit, this hook can be used to pass any value or to modify any existing value passed to the create method Forward-Port-Of: odoo/enterprise#71065 Forward-Port-Of: odoo/enterprise#70151
Original PR description
before this commit, if user need to pass any different value to the sale order creation, there is no direct hook available to do the same after this commit, this hook can be used to pass any value or to modify any existing value passed to the create method Forward-Port-Of: odoo/enterprise#71065 Forward-Port-Of: odoo/enterprise#70151
Steps ----- 1. Create a user A with only Helpdesk User rights. 2. Create a helpdesk team only with "Invited internal users" visibility and "Field Service" enabled. 3. Create a ticket in this team, assign it to user A. 4. With user A, try to create a task from the ticket. ** AccessError ** Change ----- Read the team in sudo mode since a user may not have access to it (invited-interal teams) but have access to the ticket and should be able to create a FSM task. opw-4134278 Forward-Po
Original PR description
Steps ----- 1. Create a user A with only Helpdesk User rights. 2. Create a helpdesk team only with "Invited internal users" visibility and "Field Service" enabled. 3. Create a ticket in this team, assign it to user A. 4. With user A, try to create a task from the ticket. ** AccessError ** Change ----- Read the team in sudo mode since a user may not have access to it (invited-interal teams) but have access to the ticket and should be able to create a FSM task. opw-4134278 Forward-Port-Of: odoo/enterprise#71033 Forward-Port-Of: odoo/enterprise#69784
The worker compensation could be required even though the contract is not with a US company. Forward-Port-Of: odoo/enterprise#71025
Original PR description
The worker compensation could be required even though the contract is not with a US company. Forward-Port-Of: odoo/enterprise#71025
Versions -------- - saas-17.2+ Steps ----- 1. Activiate Stripe, Sips, or Demo as payment provider; 2. create a subscription & confirm; 3. invoice subscription & confirm; 4. click share link & copy; 5. open link in a private window/different browser; 6. pay invoice. Issue ----- The access token is invalid, which is important if you as user don't have regular access to the document (or are logged out). Cause ----- When a subscription payment flow is followed via an invoice, i
Original PR description
Versions -------- - saas-17.2+ Steps ----- 1. Activiate Stripe, Sips, or Demo as payment provider; 2. create a subscription & confirm; 3. invoice subscription & confirm; 4. click share link & copy;…
Versions -------- - saas-17.2+ Steps ----- 1. Activiate Stripe, Sips, or Demo as payment provider; 2. create a subscription & confirm; 3. invoice subscription & confirm; 4. click share link & copy; 5. open link in a private window/different browser; 6. pay invoice. Issue ----- The access token is invalid, which is important if you as user don't have regular access to the document (or are logged out). Cause ----- When a subscription payment flow is followed via an invoice, it sets the `access_token` in the controller and adds a `transaction_route_subscription` value. The `access_token` is valid for the `transaction_route_subscription`, but this route is only followed when payments are automated (added in 36b238b934f). Initially, the invoice token was passed, which worked for non-automated payments getting passed as regular invoices to `account_payment`. Commit 60fd12a6c65 changed this to a subscription token, to allow automated payments, but broke non-automated payments in the process, as those still go via `account_payment`, which expects an invoice token. Solution -------- Concatenate the access tokens, and decide which one to use in the `_submitForm` override. Also partially undo 2b34ba49ef7: `payment_utils.check_access_token` expects a payment access token, the commit made it pass a invoice access token instead. opw-4152257 Forward-Port-Of: odoo/enterprise#71256 Forward-Port-Of: odoo/enterprise#70503
This commit adds an additional step when aggregating the values for sending invoice CFDI, and ensures the final result to be within the allowed maximum rounding error of `0.01`. Purpose: When creating an invoice with the following amounts: - line 1: 505.0, tax_16 - line 2: 495.0, tax_16 - line 3: 475.0, tax_16 - set tax_16.price_include to True The CFDI result of the invoice when generated using "round globally" method on either normal or global sending will be rejected by the
Original PR description
This commit adds an additional step when aggregating the values for sending invoice CFDI, and ensures the final result to be within the allowed maximum rounding error of `0.01`. Purpose: When…
This commit adds an additional step when aggregating the values for sending invoice CFDI, and ensures the final result to be within the allowed maximum rounding error of `0.01`. Purpose: When creating an invoice with the following amounts: - line 1: 505.0, tax_16 - line 2: 495.0, tax_16 - line 3: 475.0, tax_16 - set tax_16.price_include to True The CFDI result of the invoice when generated using "round globally" method on either normal or global sending will be rejected by the mexican authorities. This is caused by an inherent flaw of how Odoo calculates line amounts. The `compute_all` method in taxes rounds all the lines in cfdi_values to 2 digits precision in the final result, resulting in a loss of precision when calculating the total amounts. The mexican authorities requires us to make sure that: 1. the sum of the base/tax amounts in the lines (Conceptos) matches the total 2. the rounding of the total base and tax amount to be within 0.01 rounding error In the provided example, in Odoo, we will generate a total of 1271.54 base amount and 203.46 tax amount. This is not acceptable by the mexican government because 1271.54 * 0.16 equals 203.4464, which when compared with our result of the tax amount exceeds the maximum allowed rounding error. To fix this, we have to sacrifice our correctness and generate amounts that will have disrepancies whenever we need it (for global rounding method). We will now re-calculate the base and tax amounts in `cfdi_values` based on the total amount and generate new amounts with 6 digits precision, and apply that on each line of Conceptos. The 2 digit rounding precision limit on `Importe` and `ValorUnitario` XML will be changed to 6 digits to make sure we pass the first requirement, as the mexican authorities will also calculate their total and check if it matches our total. Due to this change, all of the test files than contain this element needs to be udpated too. task-id: 4071712 Forward-Port-Of: odoo/enterprise#69801 Forward-Port-Of: odoo/enterprise#68319
39 changes
Enhancements to existing features
The Discuss notification settings menu and screen now use clearer wording and improved visual spacing. This helps users better understand and adjust their notification preferences with less confusion.
Original PR description
Notification settings menu and screen had confusing wording. This commit improves clarity of text and makes a few style tweaking to make content more readable. task-4204137
The account search panel now recognizes placeholder account codes from other companies when users select a code range. Accounts without a code in the current company are also shown in placeholder-code order, making results more predictable and easier to navigate.
Original PR description
- Currently, the account search panel only works with accounts' codes in the active company. This means that even if an account's code in another company is displayed as a placeholder, the account won't be selected when clicking on the code range corresponding to the placeholder. We fix this behaviour. - Additionally, accounts that don't have a code in the current company are returned in a random order. We change this so that they are now returned in the order of the placholder code. taskid: 4191368
Customers can now set their own default invoice delivery preferences directly from their portal account page. This reduces manual work for company staff and helps invoices be sent through the customer’s preferred channel, including Peppol or postal mail where available.
Original PR description
With https://github.com/odoo/odoo/pull/180212 we added the possibility to set invoice sending preferences on the partner. With this PR, we add the possibility for users to set it themselves from their portal account view. task-4070132
The HTML editor now offers placeholder buttons for common content actions such as lists, tables, images, and links. This makes it easier for users to find and insert common content elements while editing, improving usability and content creation speed.
Original PR description
Description of the issue/feature this PR addresses: This PR adds placeholder buttons for the following toolbar options to enhance user experience and functionality. 1. Numbered lists 2. Bullet lists 3. Check lists 4. Tables 5. Images 6. Links task-3644644 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now open both list and graph views for WhatsApp messages directly from a template's Messages button. This makes it easier to analyze message activity for a specific template without manually applying filters.
Original PR description
#### Purpose: The purpose of this task is to add graph view directly from 'Messages' Stat Button. #### Before this PR: When users navigate to 'WhatsApp Messages' from a template's Stat button, only the List View is displayed. Thus, users have to add filters in all 'WhatsApp Messages' to get accurate graph view for a particular template. #### After this PR: Users can access both List and Graph view through 'Messages' stat button. Task-4145998
Resolved issues and error corrections
The restaurant point-of-sale dashboard chart now displays its two data series in the correct alignment. This helps users read dashboard trends accurately and avoid confusion from mismatched chart data.
Original PR description
the ranges of the first chart were not properly aligned but since we activated the "dataSets have title" option, the 2 datasets were offset from each other. Task-4236146 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 update streamlines an automated website shop test by removing unnecessary steps and clicks. It helps the test run faster and more reliably without changing the customer-facing shopping experience.
Original PR description
In this commit, we remove unuseful steps and unuseful click actions. We take advantages of this commit to decrease checkDelay to make the tour faster. 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 company switcher search field now keeps working even when the cursor moves over dropdown items. This prevents users from losing focus while searching, making company selection smoother and less frustrating.
Original PR description
This commit fixes a bug where the search input would only work when it was hovered. This was caused by the navigation hook used by the dropdown which would focus the items on hover, loosing the focus of the search input in the process. Task: 4207756 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves automated website test tours so they run faster and more reliably. It removes unnecessary steps and adds checks that help ensure website editing, sales, events, live chat, and loyalty flows are properly validated before changes move forward.
Original PR description
In this commit, we impose a checkDelay on the tours of 150ms (the default checkDelay is 750ms). This makes the tours execute faster. We take advantage of this commit to remove unnecessary actions (like clicks when it is simply a matter of checking that the element is in the DOM). We add verification steps to ensure that the tour executes correctly and waits for mutations before continuing the round. 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
Coupon codes can now be scanned and applied directly in the Point of Sale screen. This avoids manual entry issues and helps staff process promotions faster and more reliably.
Original PR description
Ensured coupon codes can be scanned and applied directly in the POS UI. Task ID: 4221332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Animated website building blocks are now visible when users browse the snippet selection window. This helps editors preview and choose animated content correctly before adding it to a page.
Original PR description
This PR aims to allow animated snippets to be visible within the snippets selection modal. Prior to this PR, the animated content of a snippet was not visible within the modal. This is due to the fact that the `o_animate` class sets a `visibility: hidden` by default. As this scenario is corner case and none of the snippets were using animation, we did not really have the need of introducing such CSS. This PR simply add a CSS property to ensure the content of these snippets will be visible within the modal. task-4204911 | Master | This PR | |--------|--------| |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website numbers grid snippet now uses the correct layout classes for larger screen sizes. This prevents editing handle conflicts and helps the snippet behave more reliably across responsive breakpoints.
Original PR description
This PR aims to fix an issue about the wrong grid classes on the `s_numbers_grid` snippet. Prior to this PR, the snippet was using `g-col-md` classes, which is creating conflicts with the handles of the snippet at some breakpoint. In fact, the classes should match the `col-*` ones and be `g-col-lg-*`. This PR replaces the old `g-col-*` with the right one. task-4187041 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Appointments that require manual confirmation now show as “Reserved” instead of “Booked” after payment. This gives customers a clearer indication that their appointment request is received but still awaiting confirmation.
Original PR description
**How to reproduce:** - Set an appointment as paid and requires 'Manual Confirmation'. - Book the appointment. **Purpose:** Here, it shows as appointment 'Booked', but the appointment status is still in 'request'. **Specifications:** When the status is 'request' show 'Reserved' in blue banner with a thumbs-up icon. Task-4210614
The appointment overview page now shows the intended image when no appointment has been selected. This prevents customers from seeing confusing placeholder text and makes the booking experience look polished.
Original PR description
**Before this PR:** If no appointment is set, the overview page displays "[object SVGSVGElement]" instead of an image. **Technical:** The outerHTML property accepts an HTML string, while renderToElement(...) returns a node. The issue occurs from commit: https://github.com/odoo/enterprise/commit/9e38975d3f1e9dc87a3061c06ce9df7cf562949c **After this PR:** A proper image appears on the overview page. Task-4208073
Studio users can now configure the default sorting order for Kanban views, making records appear in the preferred order automatically. This helps teams tailor workflows without custom development and keeps important items easier to find.
Original PR description
This commit adds the possibility in studio to change the default_order attribute on kanban views. Task-3953827
This update prevents errors when adding annotations to accounts in companies using multiple VAT setups and fiscal positions. Users can annotate account reports more reliably without running into a system traceback.
Original PR description
Having a fiscal position in multi-vat, annotating an account can lead to a traceback because PostreSQL expects an int and not a recordset
Miscellaneous changes
Steps to reproduce: 1. Go to e-learning 2. Switch to list view 3. Select multiple courses 4. Duplicate them Technical Reason: In the 'copy_data' method, there was an incorrect indentation in the loop, and one condition needed to be placed inside the loop. After this Commit: No traceback will occur on duplicating multiple courses. Task-4211075 Forward-Port-Of: odoo/odoo#181526
Original PR description
Steps to reproduce: 1. Go to e-learning 2. Switch to list view 3. Select multiple courses 4. Duplicate them Technical Reason: In the 'copy_data' method, there was an incorrect indentation in the loop, and one condition needed to be placed inside the loop. After this Commit: No traceback will occur on duplicating multiple courses. Task-4211075 Forward-Port-Of: odoo/odoo#181526
Before this commit, attempting to create an order with a configuration that included a rounding method resulted in an error due to the absence of the necessary rounding data. This was caused by the omission of 'account.cash.rounding' during the loading process. opw-4217844 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182580
Original PR description
Before this commit, attempting to create an order with a configuration that included a rounding method resulted in an error due to the absence of the necessary rounding data. This was caused by the omission of 'account.cash.rounding' during the loading process. opw-4217844 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182580
The following error occurs when you try to open a session as the superuser. Steps to reproduce: - Install the ``Point_of_sale`` module - Activate developer mode / click on debugger / Become superuser - Point of sale / click on open Register Traceback: ``IndexError: list index out of range`` This error occurs when we open a session as a superuser. When we attempt to open it, at line [1] ``res.users`` is returned as empty. [1]- https://github.com/odoo/odoo/blob/585635e8afa531b8a
Original PR description
The following error occurs when you try to open a session as the superuser. Steps to reproduce: - Install the ``Point_of_sale`` module - Activate developer mode / click on debugger / Become superuser - Point of sale / click on open Register Traceback: ``IndexError: list index out of range`` This error occurs when we open a session as a superuser. When we attempt to open it, at line [1] ``res.users`` is returned as empty. [1]- https://github.com/odoo/odoo/blob/585635e8afa531b8a66295a4afe0fcdd369ed188/addons/point_of_sale/models/pos_session.py#L379 sentry-5082852453 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179300 Forward-Port-Of: odoo/odoo#172468
Backport of 0a60ea114f690b18d7ef8d06e5f659d0122f1ea6 In the prop definition of `MoneyDetailsPopup` it is specified that the `moneyDetails` prop either not be passed or be an object. There are instances where the prop is passed with value `null`. We adapt the definition to reflect this reality. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182183
Original PR description
Backport of 0a60ea114f690b18d7ef8d06e5f659d0122f1ea6 In the prop definition of `MoneyDetailsPopup` it is specified that the `moneyDetails` prop either not be passed or be an object. There are instances where the prop is passed with value `null`. We adapt the definition to reflect this reality. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182183
It appears that `chromium-browser` sometimes asks for user to sign in, displaying an unwanted popup instead of the IoT Box display homepage. We fix this by adding `--bwsi` argument to the command line. Forward-Port-Of: odoo/odoo#180190
Original PR description
It appears that `chromium-browser` sometimes asks for user to sign in, displaying an unwanted popup instead of the IoT Box display homepage. We fix this by adding `--bwsi` argument to the command line. Forward-Port-Of: odoo/odoo#180190
It was not possible to create a new PoS config in a company branch Steps to reproduce: ------------------- * Create a branch, and switch to the branch * Create a PoS config > Observation: You get a traceback Why the fix: ------------ Instead of searching only on the company we also look for journals in the parent companies opw-4195477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182209
Original PR description
It was not possible to create a new PoS config in a company branch Steps to reproduce: ------------------- * Create a branch, and switch to the branch * Create a PoS config > Observation: You get a traceback Why the fix: ------------ Instead of searching only on the company we also look for journals in the parent companies opw-4195477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182209
This PR implements a few small changes designed to streamline the badge printing flow: - The print notification when printing with a badge printer now includes the attendee's name - When the 'Print' button is pressed, the popup window is closed after printing - If the auto-print option is enabled, the popup doesn't appear at all (the print notification is enough to identify the attendee) task-4191348 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit
Original PR description
This PR implements a few small changes designed to streamline the badge printing flow: - The print notification when printing with a badge printer now includes the attendee's name - When the 'Print' button is pressed, the popup window is closed after printing - If the auto-print option is enabled, the popup doesn't appear at all (the print notification is enough to identify the attendee) task-4191348 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180549
Since #156437, the moves can have a final location representing their final endpoint. This causes some issues for inter-company transactions, as they are meant to deliver to/pick from the 'Inter-Company Transit' location. This means that for sale orders meant to other companies, they are always supposed to deliver their goods there: - Normal delivery: CompA/Stock -> ICT, ICT -> CompB/Stock - Dropship: CompA/Stock -> ICT, ICT -> Customer But this opens a few issues, as the compA SO's `par
Original PR description
Since #156437, the moves can have a final location representing their final endpoint. This causes some issues for inter-company transactions, as they are meant to deliver to/pick from the…
Since #156437, the moves can have a final location representing their final endpoint. This causes some issues for inter-company transactions, as they are meant to deliver to/pick from the 'Inter-Company Transit' location. This means that for sale orders meant to other companies, they are always supposed to deliver their goods there: - Normal delivery: CompA/Stock -> ICT, ICT -> CompB/Stock - Dropship: CompA/Stock -> ICT, ICT -> Customer But this opens a few issues, as the compA SO's `partner_shipping_id` is the customer itself, meaning that the final location would end up as Customers, which we want to avoid. Also, to accomodate both these cases, we need to add a bit complexity computation of the location_dest of a move. We consider that if the location_dest is Customers but its final is ICT, then we apply the ICT. opw-4163612 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181379 Forward-Port-Of: odoo/odoo#179963
Found error during migration in customer database. when company is archived but will get that company on `self.env.company` of pos_config table, this error is generated when it's try to create the record for pos config from pos_resturant module by data file (defined on this commit) https://github.com/odoo/odoo/commit/3236c1cb5025d2c2d446d11f67fda1ea51ceb992 as picking_type_id field in pos_config is required and we set default value by fetching warehouse for related company but here as co
Original PR description
Found error during migration in customer database. when company is archived but will get that company on `self.env.company` of pos_config table, this error is generated when it's try to create the…
Found error during migration in customer database. when company is archived but will get that company on `self.env.company` of pos_config table,
this error is generated when it's try to create the record for pos config from pos_resturant module
by data file (defined on this commit)
https://github.com/odoo/odoo/commit/3236c1cb5025d2c2d446d11f67fda1ea51ceb992
as picking_type_id field in pos_config is required and we set default value by fetching warehouse for related company but here as company is archived, related warehouse is also archived and that why we didnot get picking_type_id for archived company and that will raise Error :
```
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4787, in _create
cr.execute(SQL(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "picking_type_id" of relation "pos_config" violates not-null constraint
```
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#162627
Forward-Port-Of: odoo/odoo#151719Before this commit, the `loadData` function required records to be connected in a specific order, prioritizing models that are dependencies for others. This posed a problem, for instance, when attempting to load `pos.order` before `account.move`, as the latter might be missing, preventing a correct linkage between `pos.order` and `account.move`. This commit eliminates the dependency on loading order. Now, if a record cannot be connected due to a missing dependency, it is temporarily stored and l
Original PR description
Before this commit, the `loadData` function required records to be connected in a specific order, prioritizing models that are dependencies for others. This posed a problem, for instance, when attempting to load `pos.order` before `account.move`, as the latter might be missing, preventing a correct linkage between `pos.order` and `account.move`. This commit eliminates the dependency on loading order. Now, if a record cannot be connected due to a missing dependency, it is temporarily stored and later connected once the missing record becomes available. opw-4229303 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182496
Description of the issue/feature this PR addresses: - The feature of shared trusted PoS is not working in saas~17.4  - This is due to fact, the current order is never added to the pendingOrder object. so when [syncAllOrders](https://github.com/odoo/odoo/blob/saas-17.4/addons/point_of_sale/static/src/app/store/pos_store.js#L981) is called from [_setOrder](https://github.com/odoo/odoo/blob/saas-17.4/
Original PR description
Description of the issue/feature this PR addresses: - The feature of shared trusted PoS is not working in saas~17.4…
Description of the issue/feature this PR addresses: - The feature of shared trusted PoS is not working in saas~17.4  - This is due to fact, the current order is never added to the pendingOrder object. so when [syncAllOrders](https://github.com/odoo/odoo/blob/saas-17.4/addons/point_of_sale/static/src/app/store/pos_store.js#L981) is called from [_setOrder](https://github.com/odoo/odoo/blob/saas-17.4/addons/point_of_sale/static/src/app/screens/ticket_screen/ticket_screen.js#L600-L605) is called, [no orders](https://github.com/odoo/odoo/blob/saas-17.4/addons/point_of_sale/static/src/app/store/pos_store.js#L989) are returned and function [exits early ](https://github.com/odoo/odoo/blob/saas-17.4/addons/point_of_sale/static/src/app/store/pos_store.js#L998) Desired behavior after PR is merged: - Feature works as intended. Steps to reproduce: - install point_of_sale in saas-17.4 version - from setting, add a trusted pos B for Pos A - open both pos in two different tabs/browsers. - Create one order from PoS A, - on opening orders page from pos B, that order should be loaded but it does not.  opw-4160166 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182495
Description of the issue this PR addresses: Current behavior before PR: When many languages were installed, the translate dropdown would become too large and overflow out of the screen. Desired behavior after PR is merged: The translate dropdown has a maximum height of 40vh and scrolls if the content overflows, ensuring it stays within the viewport. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175960
Original PR description
Description of the issue this PR addresses: Current behavior before PR: When many languages were installed, the translate dropdown would become too large and overflow out of the screen. Desired behavior after PR is merged: The translate dropdown has a maximum height of 40vh and scrolls if the content overflows, ensuring it stays within the viewport. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175960
Currently when invoicing through pos, multiple values related to price discounts are incorrect. Steps to reproduce: ------------------- * Go to the **Point of sale** app * Under **Configuration**, select **Settings** * Enable **Flexible Pricelists** * Select **Advanced price rules** * Create a pricelist, 10% discount on all products, visible on the invoice * Go to the **Products list** * Select any product and apply a tax (price excl) * Open shop session * Select the product with th
Original PR description
Currently when invoicing through pos, multiple values related to price discounts are incorrect. Steps to reproduce: ------------------- * Go to the **Point of sale** app * Under **Configuration**,…
Currently when invoicing through pos, multiple values related to price discounts are incorrect. Steps to reproduce: ------------------- * Go to the **Point of sale** app * Under **Configuration**, select **Settings** * Enable **Flexible Pricelists** * Select **Advanced price rules** * Create a pricelist, 10% discount on all products, visible on the invoice * Go to the **Products list** * Select any product and apply a tax (price excl) * Open shop session * Select the product with the tax * Pay and invoice it > Observation: In some cases the line "Price discounted from" does not appear on the invoice. And when it appears, values are not correct. If you also plied a discount on the product line in addition to the pricelist, values are completely mixed. Why the fix: ------------ We see that we are curently comparing `line.price_subtotal_incl` with `line.product_id.lst_price * line.qty`. https://github.com/odoo/odoo/blob/b49159db74cf4c8212a7bd3dfe551eb852df99f3/addons/point_of_sale/models/pos_order.py#L213-L219 To simplify, we consider a quantity of 1. * `line.price_subtotal_incl` includes discounts (order line discounts and pricelist) and always represent a price with taxes included. * `line.product_id.lst_price` reprensents the price set on the prodcut form. It does not account for any sort of discount. If the tax applied on the product is tax excl(resp. incl) it will be a price tex excl(resp. incl). In the case where the pricelist discount is smaller than the tax amount, for products with tax excl, the `line.price_subtotal_incl` will still be greater than `line.product_id.lst_price` and that's why the invoice does not have the line "Price discounted from". I asked MOBT the behavior expected. For the line "Price discounted from", this should only reflect discounts related to pricelist, and should represent the price tax excl/incl depending on the tax set up on the product page. Line discounts are already reflected on the invoice with `Disc.%`. We choose to compare two values that reflect the same price tax configuration. We compare `line.product_id.lst_price` with `line.price_unit` as both will be tax excl(resp. incl) if the tax applied on the product is tax excl(resp. incl). We also remove the `line.qty` as both represent a price per qty. opw-4170357 Forward-Port-Of: odoo/odoo#181935 Forward-Port-Of: odoo/odoo#181007
Problem: When an issued address for a journal has a different timezone than the journal's company address, the generated date for the CFDI is incorrect because it uses the issued address's timezone instead of the company's timezone. Steps to reproduce: - Install 'l10n_mx' and 'l10n_mx_edi_extended'. - Switch to the "ESCUELA KEMPER URGATE" company. - Go to Settings > Configuration > MX Electronic Invoicing and change the PAC to "Solución Factible." - In Contacts, open "ESCUELA KEMPER UR
Original PR description
Problem: When an issued address for a journal has a different timezone than the journal's company address, the generated date for the CFDI is incorrect because it uses the issued address's timezone…
Problem:
When an issued address for a journal has a different timezone than the journal's company address, the generated date for the CFDI is incorrect because it uses the issued address's timezone instead of the company's timezone.
Steps to reproduce:
- Install 'l10n_mx' and 'l10n_mx_edi_extended'.
- Switch to the "ESCUELA KEMPER URGATE" company.
- Go to Settings > Configuration > MX Electronic Invoicing and change the PAC to "Solución Factible."
- In Contacts, open "ESCUELA KEMPER URGATE" under Contacts and Addresses, and add an invoice address:
- Name: "Invoice Contact"
- Country: Mexico
- State: Tamaulipas (MX) ZIP: 88776
- Create a journal named "Invoice Journal" and assign:
- "Invoice Contact" as the issued address.
- "401.01.01 Sales and/or services taxed at the general rate" as the Default Income Account.
- "Transferencia electrónica de fondos" as the Payment Way.
- Create a new invoice with:
- Customer: "INMOBILIARIA CVA"
- Payment Way: "Transferencia electrónica de fondos"
- Journal: "Invoice Journal"
- Add a product with "UNSPSC Category" under Accounting on the product page set to "01010101 Does not exist in the catalog."
- Confirm the invoice, then Send & Print with "CFDI" checked.
- Register payment with some of the amount.
- Click on "Update Payments."
- On the CFDI tab, in the first row, click on "Force CFDI."
- The payment should succeed.
opw-4076021
Forward-Port-Of: odoo/enterprise#68610Enhance the invoice functionality by including the reference field (ref) in the XML sent to Uruware using the <CompraID> tag, and ensure it's automatically included in the PDF generated by Uruware. This info is optional, but it is required by some receptors in order to accept the invoice (big invoicing volume receptors) LATAM task 1267 / ADHOC ticket 80811 Forward-Port-Of: odoo/enterprise#70970
Original PR description
Enhance the invoice functionality by including the reference field (ref) in the XML sent to Uruware using the <CompraID> tag, and ensure it's automatically included in the PDF generated by Uruware.
This info is optional, but it is required by some receptors in order to accept the invoice (big invoicing volume receptors)
LATAM task 1267 / ADHOC ticket 80811
Forward-Port-Of: odoo/enterprise#70970Steps to reproduce ================== - Install studio,project - Open any task - Open studio - Toggle show invisible elements => Some fields are displayed inside the button box Cause of the issue ================== Some always invisible non buttons elements are sometimes used inside a button box. https://github.com/odoo/odoo/blob/1c685b9ce7483c426fc2db964ef357003229ddc6/addons/project/views/project_task_views.xml#L269-L275 opw-4164661 Forward-Port-Of: odoo/enterprise#7105
Original PR description
Steps to reproduce ================== - Install studio,project - Open any task - Open studio - Toggle show invisible elements => Some fields are displayed inside the button box Cause of the issue ================== Some always invisible non buttons elements are sometimes used inside a button box. https://github.com/odoo/odoo/blob/1c685b9ce7483c426fc2db964ef357003229ddc6/addons/project/views/project_task_views.xml#L269-L275 opw-4164661 Forward-Port-Of: odoo/enterprise#71054 Forward-Port-Of: odoo/enterprise#70380
- Install the Field Services (industry_fsm) and sales module. - Create a sale order with the following configuration: - Select any customer. - Select the product 'Junior Architect' (Invoice on Timesheets). - Confirm the sale order. - On the header of the sale order, click on the project option. - Then, in the left side corner, click on 'Share Editable'. - Share the project to your company. - Log in as a portal user. - Open the projects menu. - Open the project you just shared. -
Original PR description
- Install the Field Services (industry_fsm) and sales module. - Create a sale order with the following configuration: - Select any customer. - Select the product 'Junior Architect' (Invoice on…
- Install the Field Services (industry_fsm) and sales module. - Create a sale order with the following configuration: - Select any customer. - Select the product 'Junior Architect' (Invoice on Timesheets). - Confirm the sale order. - On the header of the sale order, click on the project option. - Then, in the left side corner, click on 'Share Editable'. - Share the project to your company. - Log in as a portal user. - Open the projects menu. - Open the project you just shared. - In the kanban view, click on the 'Quick Create Task' button. - Add a task name and click on the edit button. - You will see the form view where the customer and sale order item are not set by default. Issue: ------------------ When logging in as a portal user(project sharing), the fields for Customer and Sale Order Item are not set by default when creating a task via quick create in the Kanban view. Cause: ------------------- The _compute_partner_id function relies on the project_id field to determine the partner_id (customer) for a task. However, in the quick create view, only the partner_id field is mentioned . in the quick view, the project ID is not provided so the partner ID cannot be computed, resulting in an empty field for the partner_id (customer). Solution: ---------------------- add a project_id field in the 'project_sharing_quick_create_task_form_inherit' quick create form view. task-3743360 Forward-Port-Of: odoo/enterprise#70512 Forward-Port-Of: odoo/enterprise#57113
Currently, even tough the quick_create view are defined in the code base, and defines on the kanban view, the quick create view is not used. Step to reproduce: - Install helpdesk - Open helpdesk app - Open the 'all tickets' or the 'My tickets' view - Select the kanban view - Click on the 'new' button A ticket view form is opened. Expected behavior : the quick create view form should be open in the kanban view. Source of the issue: the 'on_create' attribute is missing in the kanba
Original PR description
Currently, even tough the quick_create view are defined in the code base, and defines on the kanban view, the quick create view is not used. Step to reproduce: - Install helpdesk - Open helpdesk app - Open the 'all tickets' or the 'My tickets' view - Select the kanban view - Click on the 'new' button A ticket view form is opened. Expected behavior : the quick create view form should be open in the kanban view. Source of the issue: the 'on_create' attribute is missing in the kanban definition task - 4047630 version 15.0 - master Forward-Port-Of: odoo/enterprise#70605 Forward-Port-Of: odoo/enterprise#66491
Steps to reproduce: 1. Go to Consolidation 2. Create a new consolidation period - Add only Sub-Consolidation Periods, no Company Periods - You can skip this step on runbot and open the "Top Consolidation" period directly 4. Open the Consolidation Balance with the smart button 5. Try to click on an auditable cell 6. You will get an error The problem arises because the action_open_audit function need a journal ID. If no journal is defined, the method returns None. Next, the doActi
Original PR description
Steps to reproduce: 1. Go to Consolidation 2. Create a new consolidation period - Add only Sub-Consolidation Periods, no Company Periods - You can skip this step on runbot and open the "Top Consolidation" period directly 4. Open the Consolidation Balance with the smart button 5. Try to click on an auditable cell 6. You will get an error The problem arises because the action_open_audit function need a journal ID. If no journal is defined, the method returns None. Next, the doAction function in the JavaScript audit method will return an error. To fix the issue, I propose ensuring that a journal is defined, and if so, enabling the audit. opw-4207691 Forward-Port-Of: odoo/enterprise#70845
It has removed the `l10n_mx_edi_payment_method_id` from the batch key and avoids group payments with different payment methods. Any SAT reason indicates that must be grouped the payments by payment method, so, if I receive a payment in any payment method and I register a payment, only a payment complement must be generated. Fixed the next case: 1. Generate a customer invoice with payment method: 99 - To define 2. Generate a second customer invoice with payment method: 01 - Efectivo 3. R
Original PR description
It has removed the `l10n_mx_edi_payment_method_id` from the batch key and avoids group payments with different payment methods. Any SAT reason indicates that must be grouped the payments by payment…
It has removed the `l10n_mx_edi_payment_method_id` from the batch key and avoids group payments with different payment methods. Any SAT reason indicates that must be grouped the payments by payment method, so, if I receive a payment in any payment method and I register a payment, only a payment complement must be generated. Fixed the next case: 1. Generate a customer invoice with payment method: 99 - To define 2. Generate a second customer invoice with payment method: 01 - Efectivo 3. Register a payment for the invoice 1 and 2 in cash In this case, only a payment complement for the total amount related to the 2 invoices must be generated. Note 1: If the user wants to generate 2 payment complements, 1 by each payment method, can select the records and register 2 payments. Note 2: The key was introduced here: https://github.com/odoo/enterprise/commit/b2dd65b9a9c054570d5796a81f2c390c4d8cb6c4#diff-8fbd6620744df804292d8f4158343ef05564035bed962f68bd5ef931d1cb9d70R29 but without any reference that indicates why this was necessary. Forward-Port-Of: odoo/enterprise#56628
Issue: - The timesheet does not unlink properly when the timer stops. - Consequently, starting the timer again links it to the previous timesheet, causing incorrect behavior. Solution: - Set the timesheet reference to `undefined` when stopping the timer. - This ensures that a new timesheet is created when the timer starts again, preventing any link to the previous timesheet. Steps to reproduce: 1) Install the `timesheet_grid` module. 2) Navigate to Timesheet App > My Timesh
Original PR description
Issue: - The timesheet does not unlink properly when the timer stops. - Consequently, starting the timer again links it to the previous timesheet, causing incorrect behavior. Solution: - Set the timesheet reference to `undefined` when stopping the timer. - This ensures that a new timesheet is created when the timer starts again, preventing any link to the previous timesheet. Steps to reproduce: 1) Install the `timesheet_grid` module. 2) Navigate to Timesheet App > My Timesheet > Kanban view. 3) Start the timer from the Kanban view. 4) Stop the timer from the Kanban view. 5) Repeat step 3. 6) Verify the timer's time. task-4176611 Forward-Port-Of: odoo/enterprise#70366
Steps ----- 1. Create a user A with only Helpdesk User rights. 2. Create a helpdesk team only with "Invited internal users" visibility and "Field Service" enabled. 3. Create a ticket in this team, assign it to user A. 4. With user A, try to create a task from the ticket. ** AccessError ** Change ----- Read the team in sudo mode since a user may not have access to it (invited-interal teams) but have access to the ticket and should be able to create a FSM task. opw-4134278 Forward-Po
Original PR description
Steps ----- 1. Create a user A with only Helpdesk User rights. 2. Create a helpdesk team only with "Invited internal users" visibility and "Field Service" enabled. 3. Create a ticket in this team, assign it to user A. 4. With user A, try to create a task from the ticket. ** AccessError ** Change ----- Read the team in sudo mode since a user may not have access to it (invited-interal teams) but have access to the ticket and should be able to create a FSM task. opw-4134278 Forward-Port-Of: odoo/enterprise#71033 Forward-Port-Of: odoo/enterprise#69784
Fixes two uses cases: - Sale Order in Company A that dropships goods *stored* in Company B to the Customer. - Sale Order in Company A that dropships goods from company B to the Customer. But in company B, we also dropship from the vendor to the customer. In both cases, make sure to properly send goods to the Inter-Company Transit location for inter-co transactions, so that goods (and lot/serials) can be properly linked. opw-4163612 Forward-Port-Of: odoo/enterprise#70641 Forward-Port-Of:
Original PR description
Fixes two uses cases: - Sale Order in Company A that dropships goods *stored* in Company B to the Customer. - Sale Order in Company A that dropships goods from company B to the Customer. But in company B, we also dropship from the vendor to the customer. In both cases, make sure to properly send goods to the Inter-Company Transit location for inter-co transactions, so that goods (and lot/serials) can be properly linked. opw-4163612 Forward-Port-Of: odoo/enterprise#70641 Forward-Port-Of: odoo/enterprise#69878
7 changes
New functionality added to Odoo
Odoo now supports Iraq with a new localization package that includes a complete chart of accounts and tax configuration. This enables businesses operating in Iraq to use Odoo with locally compliant accounting and tax structures.
Original PR description
Added base localization package for Iraq 🇮🇶. It inludes the following: - Chart of Accounts - Taxes [task-3927924](https://www.odoo.com/web#model=project.task&id=3927924)
Enhancements to existing features
A QR code has been added to Mexican delivery guide PDFs (cartaporte) to meet legal requirements and enable verification by authorities. The QR code encodes key delivery information and links to the official Mexican service for document validation, making it easier for officials to authenticate the document's legitimacy.
Original PR description
This commit adds a QR code (barcode) to the meixo delivery guide PDF (cartaporte). It is a legal requirement according to the filling guide point 4, but other than that, it is the one thing cops will scan to check if the document is real or not. The QR code is generated by taking the idccp, Salida, and LLegada data and insert them as a parameter to an URL pointing to the mexican service to display the data of the published version of the document. task-id: 4142920 Forward-Port-Of: odoo/enterprise#69581
Resolved issues and error corrections
This fix prevents CABA accounting entries from being manually reversed, which was causing negative tax amounts to appear in the DIOT tax report. CABA entries will now automatically reverse when the original document is reset to draft, ensuring the tax report always shows valid positive amounts.
Original PR description
1. Create Vendor bill and register payment 2. Create credit note for the vendor bill 4. Open the CABA entry created from vendor bill 5. Reverse Entry 6. Check DIOT report Issue: DIOT report shows negative line, but it not allowed CABA Entries should not be reverted, as the reversal generate a document with negative tax grid. They will revert automatically after the original document is reset to draft. opw-4142232
Fixed an issue where automatically generated draft accounting entries were incorrectly assigned sequence numbers. Now, draft entries will display as "Draft" instead of a sequence number, and will only receive a sequence number once they are officially posted. This prevents confusion when reviewing entries that are still in draft status.
Original PR description
When automatic entries are generated, a sequence number should not be assigned on them as long as they are on draft state. This is done because it may be confusing to see a sequence name for a move in draft. This commit ensures that the name of the entries is 'Draft' (or '/') when the move is generated. A sequence number will be assigned once the move is posted. Before this commit, it was possible to generate a draft move with a sequence number when doing a deferred entries with some entries in the future. task-4069862
This fix corrects an issue where electronic invoices (CFDI) generated for Mexican companies were using the wrong timezone when the invoice was issued from a location with a different timezone than the company's main address. The system now correctly uses the company's timezone to generate accurate invoice dates, ensuring compliance with Mexican tax authorities.
Original PR description
Problem: When an issued address for a journal has a different timezone than the journal's company address, the generated date for the CFDI is incorrect because it uses the issued address's timezone…
Problem:
When an issued address for a journal has a different timezone than the journal's company address, the generated date for the CFDI is incorrect because it uses the issued address's timezone instead of the company's timezone.
Steps to reproduce:
- Install 'l10n_mx' and 'l10n_mx_edi_extended'.
- Switch to the "ESCUELA KEMPER URGATE" company.
- Go to Settings > Configuration > MX Electronic Invoicing and change the PAC to "Solución Factible."
- In Contacts, open "ESCUELA KEMPER URGATE" under Contacts and Addresses, and add an invoice address:
- Name: "Invoice Contact"
- Country: Mexico
- State: Tamaulipas (MX) ZIP: 88776
- Create a journal named "Invoice Journal" and assign:
- "Invoice Contact" as the issued address.
- "401.01.01 Sales and/or services taxed at the general rate" as the Default Income Account.
- "Transferencia electrónica de fondos" as the Payment Way.
- Create a new invoice with:
- Customer: "INMOBILIARIA CVA"
- Payment Way: "Transferencia electrónica de fondos"
- Journal: "Invoice Journal"
- Add a product with "UNSPSC Category" under Accounting on the product page set to "01010101 Does not exist in the catalog."
- Confirm the invoice, then Send & Print with "CFDI" checked.
- Register payment with some of the amount.
- Click on "Update Payments."
- On the CFDI tab, in the first row, click on "Force CFDI."
- The payment should succeed.
opw-4076021This fix corrects how payment complements are generated for Mexican invoices by allowing payments with different payment methods to be processed together. Previously, the system would force all invoices to use the same payment method when registering a batch payment. Now, when you register a payment for multiple invoices with different payment methods, a single payment complement is generated for the total amount, which aligns with Mexican tax authority (SAT) requirements.
Original PR description
It has removed the `l10n_mx_edi_payment_method_id` from the batch key and avoids group payments with different payment methods. Any SAT reason indicates that must be grouped the payments by payment…
It has removed the `l10n_mx_edi_payment_method_id` from the batch key and avoids group payments with different payment methods. Any SAT reason indicates that must be grouped the payments by payment method, so, if I receive a payment in any payment method and I register a payment, only a payment complement must be generated. Fixed the next case: 1. Generate a customer invoice with payment method: 99 - To define 2. Generate a second customer invoice with payment method: 01 - Efectivo 3. Register a payment for the invoice 1 and 2 in cash In this case, only a payment complement for the total amount related to the 2 invoices must be generated. Note 1: If the user wants to generate 2 payment complements, 1 by each payment method, can select the records and register 2 payments. Note 2: The key was introduced here: https://github.com/odoo/enterprise/commit/b2dd65b9a9c054570d5796a81f2c390c4d8cb6c4#diff-8fbd6620744df804292d8f4158343ef05564035bed962f68bd5ef931d1cb9d70R29 but without any reference that indicates why this was necessary. Forward-Port-Of: odoo/enterprise#56628
This fix resolves an error that occurred when users tried to audit cells in consolidation balance reports that didn't have an associated journal. The system now properly disables the audit feature when no journal is available, preventing the error and improving the user experience.
Original PR description
Steps to reproduce: 1. Go to Consolidation 2. Create a new consolidation period - Add only Sub-Consolidation Periods, no Company Periods - You can skip this step on runbot and open the "Top Consolidation" period directly 4. Open the Consolidation Balance with the smart button 5. Try to click on an auditable cell 6. You will get an error The problem arises because the action_open_audit function need a journal ID. If no journal is defined, the method returns None. Next, the doAction function in the JavaScript audit method will return an error. To fix the issue, I propose ensuring that a journal is defined, and if so, enabling the audit. opw-4207691