Monday, February 10, 2025
34 changes · saas-17.4
Resolved issues and error corrections
The product configurator now hides quantity change buttons when an online store does not allow customers to change quantities. This prevents shoppers from seeing controls that should not be available and keeps the buying experience aligned with store settings.
Original PR description
Before this fix, the quantity buttons were always visible in eCommerce, even if the website didn't allow changing the quantity.
Users can now drag and drop pivot dimensions even when the side panel contains many items. The panel scrolls correctly during the action, making spreadsheet pivot configuration smoother and less frustrating.
Original PR description
The pivot side panel did not scroll during drag-and-drop of dimensions when multiple dimensions were present. This occurred because the dimensions container lacked a specific height. Adding a height to fill the available space would only enable scrolling within the dimensions list, not the entire side panel. This fix resolves the issue by passing the pivot side panel's reference as the container to drag and drop hook for it's calculations, leveraging its `100vh` height. This approach ensures that scrolling affects the entire side panel, allowing drag-and-drop to function correctly. Task: 3817565
Fixes a receipt printing issue in the Chilean point of sale flow where the required document number was missing from the receipt header. This helps businesses provide complete receipts and reduces confusion during sales.
Original PR description
Currently, when printing receipt, the number in the header is not printed. Steps to reproduce: ------------------- * Install Chilean localization and switch company to `CL Company` * Create a shop and open a session * Make an order * Pay the order > Observation: On the receipt, the header shows ** N°: ** but no number printed beside Why the fix: ------------ `order.account_number` is not an object, just the id of the account move. opw-4494756
Miscellaneous changes
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
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
Description of the issue/feature this PR addresses: allow portal attendees to be synced by google calendar Current behavior before PR: There was an `AccessError` happening when: - One portal user was invited to more than one event. - At least one of them was going to be notified in the future. - Google cancelled the first of those. <details> ``` 2024-12-11 10:19:02,144 31 INFO odoo odoo.addons.base.models.ir_cron: Manually starting job `Google Calendar: sincronización`. 2024-12-1
Original PR description
Description of the issue/feature this PR addresses: allow portal attendees to be synced by google calendar Current behavior before PR: There was an `AccessError` happening when: - One portal user was…
Description of the issue/feature this PR addresses:
allow portal attendees to be synced by google calendar
Current behavior before PR:
There was an `AccessError` happening when:
- One portal user was invited to more than one event.
- At least one of them was going to be notified in the future.
- Google cancelled the first of those.
<details>
```
2024-12-11 10:19:02,144 31 INFO odoo odoo.addons.base.models.ir_cron: Manually starting job `Google Calendar: sincronización`.
2024-12-11 10:19:02,151 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(29,)
2024-12-11 10:19:02,539 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(15,)
2024-12-11 10:19:03,029 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(50,)
2024-12-11 10:19:03,414 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(40,)
2024-12-11 10:19:03,823 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(52,)
2024-12-11 10:19:04,219 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(10,)
2024-12-11 10:19:04,580 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(28,)
2024-12-11 10:19:04,936 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(2,)
2024-12-11 10:19:05,501 31 INFO odoo odoo.models.unlink: User #2 deleted mail.message records with IDs: [1055490, 1055487, 1055480, 1055478, 1055403]
2024-12-11 10:19:05,518 31 INFO odoo odoo.models.unlink: User #2 deleted calendar.event records with IDs: [2920874, 2920875, 2920880]
2024-12-11 10:19:05,520 31 INFO odoo odoo.models.unlink: User #2 deleted mail.followers records with IDs: [6232226, 6232227, 6232228, 6232229, 6232230, 6232231, 6232232, 6232233, 6232234, 6232235, 6232236, 6232237, 6232238, 6232239, 6232240, 6232241, 6232242, 6232243, 6232270, 6232271, 6232272, 6232283]
2024-12-11 10:19:05,544 31 INFO odoo odoo.addons.base.models.ir_model: Access Denied by ACLs for operation: read, uid: 65, model: calendar.alarm
2024-12-11 10:19:05,545 31 INFO odoo odoo.addons.base.models.ir_model: Access Denied by ACLs for operation: read, uid: 65, model: calendar.alarm
2024-12-11 10:19:05,545 31 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(2,)] Calendar Synchro - Exception : No puede ingresar a los registros 'Event Alarm' (calendar.alarm)
Se permite esta operación para los grupos siguientes:
- User types/Internal User
Póngase en contacto con su administrador para solicitar acceso si es necesario. !
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 997, in get
cache_value = field_cache[record._ids[0]]
KeyError: 8
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1161, in __get__
value = env.cache.get(record, self)
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 1004, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'calendar.alarm(8,).alarm_type'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1187, in __get__
recs._fetch_field(self)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3210, in _fetch_field
self._read(fnames)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3220, in _read
self.check_access_rights('read')
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3480, in check_access_rights
return self.env['ir.model.access'].check(self._name, operation, raise_exception)
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_model.py", line 1924, in check
raise AccessError(msg)
odoo.exceptions.AccessError: No puede ingresar a los registros 'Event Alarm' (calendar.alarm)
Se permite esta operación para los grupos siguientes:
- User types/Internal User
Póngase en contacto con su administrador para solicitar acceso si es necesario.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 100, in _sync_all_google_calendar
user.with_user(user).sudo()._sync_google_calendar(google)
File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 79, in _sync_google_calendar
synced_events = self.env['calendar.event'].with_context(write_dates=events_write_dates)._sync_google2odoo(events - recurrences, default_reminders=default_reminders)
File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 185, in _sync_google2odoo
cancelled_odoo._cancel()
File "/opt/odoo/auto/addons/google_calendar/models/calendar.py", line 326, in _cancel
super(Meeting, my_cancelled_records)._cancel()
File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 152, in _cancel
self.unlink()
File "/opt/odoo/auto/addons/calendar/models/calendar_event.py", line 721, in unlink
self.env['calendar.alarm_manager']._notify_next_alarm(partner_ids)
File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 242, in _notify_next_alarm
notif = self.with_user(user).with_context(allowed_company_ids=user.company_ids.ids).get_next_notif()
File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 210, in get_next_notif
last_found = self.do_check_alarm_for_one_date(in_date_format, meeting, max_delta, time_limit, 'notification', after=partner.calendar_last_notif_ack)
File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 130, in do_check_alarm_for_one_date
if alarm.alarm_type != alarm_type:
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1189, in __get__
record._fetch_field(self)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3210, in _fetch_field
self._read(fnames)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3220, in _read
self.check_access_rights('read')
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3480, in check_access_rights
return self.env['ir.model.access'].check(self._name, operation, raise_exception)
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_model.py", line 1924, in check
raise AccessError(msg)
odoo.exceptions.AccessError: No puede ingresar a los registros 'Event Alarm' (calendar.alarm)
Se permite esta operación para los grupos siguientes:
- User types/Internal User
Póngase en contacto con su administrador para solicitar acceso si es necesario.
2024-12-11 10:19:05,547 31 INFO odoo odoo.addons.base.models.ir_cron: Job `Google Calendar: sincronización` done.
```
</details>
Desired behavior after PR is merged:
Google Sync works.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
@moduon MT-8345
cc @arj-odoo
Forward-Port-Of: odoo/odoo#190708
Forward-Port-Of: odoo/odoo#190356Since the function message_post on mail thread has been built to be called on exactly one record and the function write on employee is for multiple records, we need to call it for each employee we are writing on. It has been introduced in: https://github.com/odoo/odoo/pull/143217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196257
Original PR description
Since the function message_post on mail thread has been built to be called on exactly one record and the function write on employee is for multiple records, we need to call it for each employee we are writing on. It has been introduced in: https://github.com/odoo/odoo/pull/143217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196257
__Current behavior before commit:__ If an unexpected error that has no body is thrown inside `printHtml`, the popup shows "undefinedDo you want to print using the web printer?" and nothing is written in the console, making it impossible to troubleshoot. __Description of the fix:__ Don't print "undefined" in the popup if the error has no body but write the error in the console. opw-4322339 Forward-Port-Of: odoo/odoo#194985
Original PR description
__Current behavior before commit:__ If an unexpected error that has no body is thrown inside `printHtml`, the popup shows "undefinedDo you want to print using the web printer?" and nothing is written in the console, making it impossible to troubleshoot. __Description of the fix:__ Don't print "undefined" in the popup if the error has no body but write the error in the console. opw-4322339 Forward-Port-Of: odoo/odoo#194985
Backport of the original issue (ref.1) with the following message: The issue occurs when an email is sent to create a `project.task`. If the sender of the email is an existing user, this user is later set as the author of any outgoing emails related to that task. Since the system is configured to skip sending emails to the author, no email is delivered to the sender in this scenario. Reproduce --- - -i project,contacts - add `example.com` to domains in the settings - create new projec
Original PR description
Backport of the original issue (ref.1) with the following message: The issue occurs when an email is sent to create a `project.task`. If the sender of the email is an existing user, this user is later set as the author of any outgoing emails related to that task. Since the system is configured to skip sending emails to the author, no email is delivered to the sender in this scenario. Reproduce --- - -i project,contacts - add `example.com` to domains in the settings - create new project with an alias: `project@example.com` - Have a stage with some "Email Template" set - send email creating project tasks as a portal user - BUG: email about stage update is NOT sent (even tho task appeared in stage) (ref.1) [FIX] project_task,hr_recruitment: include ticket author in stage update email c1a430a6ee8ade9c27a0c01d8840139942e168ef opw-3941928 opw-4262422 Forward-Port-Of: odoo/odoo#196185
Scenario: set a menu to be visible only to a group you don't have Result: the menu is not shown in the list of menu on the group form view Why: in 17.0, web_read was added that is adding a search for ordering results of x2many according to order in specification. This is interfering with custom code of ir.ui.menu that is filtering out menu that are not visible (in the interface) to you. Fix: add context key that bypass the ir.ui.menu filtering in the res.groups window action. opw-4376374 For
Original PR description
Scenario: set a menu to be visible only to a group you don't have Result: the menu is not shown in the list of menu on the group form view Why: in 17.0, web_read was added that is adding a search for ordering results of x2many according to order in specification. This is interfering with custom code of ir.ui.menu that is filtering out menu that are not visible (in the interface) to you. Fix: add context key that bypass the ir.ui.menu filtering in the res.groups window action. opw-4376374 Forward-Port-Of: odoo/odoo#195329
Scenario: - install hr_recruitment but not documents (to have the right view) - go to Employee > Configuration > Recruitment | Job Positions - choose a job positions with documents and click on Documents - click on Applicant column on one of the rows => traceback shown: OwlError: Invalid props for component 'FormController': 'resId' is not a number or boolean at Object.validateProps Reason: In saas-17.2 with a7586fdb4123481fd8794ef99fdc372e95de7459 merged in february 2024, m
Original PR description
Scenario: - install hr_recruitment but not documents (to have the right view) - go to Employee > Configuration > Recruitment | Job Positions - choose a job positions with documents and click on…
Scenario: - install hr_recruitment but not documents (to have the right view) - go to Employee > Configuration > Recruitment | Job Positions - choose a job positions with documents and click on Documents - click on Applicant column on one of the rows => traceback shown: OwlError: Invalid props for component 'FormController': 'resId' is not a number or boolean at Object.validateProps Reason: In saas-17.2 with a7586fdb4123481fd8794ef99fdc372e95de7459 merged in february 2024, many2one_reference was changed from a simple integer to either 0 if unset, or a object containing resId and displayName keys. Fix: Get the id with .resId and this should not happen, but test if the record is set with "if(res_id && ...)" in case res_id was 0. Note: without the fix, the added test fails by opening the view if res_id was 0, and if not the next click would fail with: OwlError: Invalid props for component 'FormController': 'resId' is not a number or boolean opw-4384139 PR note: the test could be run without mails models, but then we would need to mock a lot of models for services (like `mail.ChatHub`) or a method like `prepareRegistry` [from studio](https://github.com/odoo/enterprise/blob/f5b7b53963829b351446e9b6f71e00f21291bc58/web_studio/static/tests/view_editor_tests_utils.js#L123-L153) that would remove all unnecessary services for the test. Forward-Port-Of: odoo/odoo#191510
Versions -------- - 16.0+ Steps ----- 1. Enable Stripe Express Checkout; 2. go to eCommerce as Public User; 3. pay via express checkout for a deliverable item; 4. in Stripe, set shipping address to somewhere in California; 5. finish payment. Issue ----- The new partner is created with its state set to Cadiz instead of California. Cause ----- When searching for a state using its code, it fetches the first matching item. The problem is that unlike country codes, state codes ar
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Stripe Express Checkout; 2. go to eCommerce as Public User; 3. pay via express checkout for a deliverable item; 4. in Stripe, set shipping address to somewhere in California; 5. finish payment. Issue ----- The new partner is created with its state set to Cadiz instead of California. Cause ----- When searching for a state using its code, it fetches the first matching item. The problem is that unlike country codes, state codes aren't unique, e.g. there are 4 states that match the 'CA' code (only one of them being in the United States). Solution -------- Add `country_id` to the search domain to ensure the fetched state belongs to the relevant country. opw-4396024 Forward-Port-Of: odoo/odoo#197055 Forward-Port-Of: odoo/odoo#196428
if they use import export or any automated action that write same journal then it's take new number. here assume that journal_id is only change on draft and if posted then it's raise error but not consider what is same journal_id come to write. 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#19
Original PR description
if they use import export or any automated action that write same journal then it's take new number. here assume that journal_id is only change on draft and if posted then it's raise error but not consider what is same journal_id come to write. 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#196777
**Current behavior:** After commit https://github.com/odoo/odoo/commit/7c808beaf36853b4d9171ef0981d1ec9c4b73a44 all writes on `date_start` would silently alter the written date value (totally unintuiative for a user & undesired behavior regardless). **Expected behavior:** Only when handling indirect writes on `date_start` from a linked-via-subcontract purchase order should we modify `date_start` to account for the manufacture delay. opw-4489485 Forward-Port-Of: odoo/odoo#196664 Forw
Original PR description
**Current behavior:** After commit https://github.com/odoo/odoo/commit/7c808beaf36853b4d9171ef0981d1ec9c4b73a44 all writes on `date_start` would silently alter the written date value (totally unintuiative for a user & undesired behavior regardless). **Expected behavior:** Only when handling indirect writes on `date_start` from a linked-via-subcontract purchase order should we modify `date_start` to account for the manufacture delay. opw-4489485 Forward-Port-Of: odoo/odoo#196664 Forward-Port-Of: odoo/odoo#195742
Forward-Port-Of: odoo/odoo#197054 Forward-Port-Of: odoo/odoo#193528
Original PR description
Forward-Port-Of: odoo/odoo#197054 Forward-Port-Of: odoo/odoo#193528
hen email provider rewrites message_id of odoo generated emails we lose trace of original message and/or trace in Odoo. Crafting references as already containing the original message_id ensure to keep a trace even if message_id is rewritten. Continuation of https://github.com/odoo/odoo/pull/81901 but this time for mailing generated mail records. Task-3927616 Forward-Port-Of: odoo/odoo#196764 Forward-Port-Of: odoo/odoo#189195
Original PR description
hen email provider rewrites message_id of odoo generated emails we lose trace of original message and/or trace in Odoo. Crafting references as already containing the original message_id ensure to keep a trace even if message_id is rewritten. Continuation of https://github.com/odoo/odoo/pull/81901 but this time for mailing generated mail records. Task-3927616 Forward-Port-Of: odoo/odoo#196764 Forward-Port-Of: odoo/odoo#189195
Repro steps: - Add `Tax String` to `Product Page Extra Fields` for one of your websites - Add taxes from a company that isn't linked to that website for one of your products - Open that product's product page in eCommerce - You get an access error The issue is that we try to read the taxes for all companies when opening the product page. Instead, we should only read the taxes for the current company. opw-4435721 Forward-Port-Of: odoo/odoo#194881
Original PR description
Repro steps: - Add `Tax String` to `Product Page Extra Fields` for one of your websites - Add taxes from a company that isn't linked to that website for one of your products - Open that product's product page in eCommerce - You get an access error The issue is that we try to read the taxes for all companies when opening the product page. Instead, we should only read the taxes for the current company. opw-4435721 Forward-Port-Of: odoo/odoo#194881
This error occurs when a user does not enter a Webhook Secret. As a result, when processing the payment, the missing secret causes the verification to fail, leading to a payment failure. - Install the `eCommerce` module without demo data and with Indian localization. - Install `Razorpay payment provider` and activate `developer mode`. - Add `Key ID` and `Key Secret` in Razorpay payment `provider`. - Set up webhook in Razorpay dashboard with a random `Webhook Secret`. - Go to the `website`
Original PR description
This error occurs when a user does not enter a Webhook Secret. As a result, when processing the payment, the missing secret causes the verification to fail, leading to a payment failure. - Install…
This error occurs when a user does not enter a Webhook Secret. As a result, when processing the payment, the missing secret causes the verification to fail, leading to a payment failure. - Install the `eCommerce` module without demo data and with Indian localization. - Install `Razorpay payment provider` and activate `developer mode`. - Add `Key ID` and `Key Secret` in Razorpay payment `provider`. - Set up webhook in Razorpay dashboard with a random `Webhook Secret`. - Go to the `website`, add the product to the cart, and proceed to payment using `UPI`.` `Error: 'bool' object has no attribute 'encode'` This issue occurs because the Webhook Secret is missing, returning False and causing payment verification to fail. This commit solves the error by handling missing `Webhook Secret` values by logging a warning and skipping the signature check instead of returning a False. Sentry: 6208134651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196984 Forward-Port-Of: odoo/odoo#196125
Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-orde
Original PR description
Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-ordering is active. However, it was still automatically enabling the preparation display even when self-ordering was disabled. opw-4225668 (This pr was merged but introduced an error with the test which was fixed in a separate pr: https://github.com/odoo/odoo/pull/186539) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186174 Forward-Port-Of: odoo/odoo#183601
Version: - 17.0 Steps to Reproduce: - Install the Calendar app. - Create an event and enable the "All Day" option. - Duplicate the event. Issue: - When duplicating an All Day event, a traceback error occurs because the start_date and stop_date values are missing. Solution: - The start_date and stop_date are now properly set when duplicating an event resolving the traceback error. task-4353039 Forward-Port-Of: odoo/odoo#196884 Forward-Port-Of: odoo/odoo#188171
Original PR description
Version: - 17.0 Steps to Reproduce: - Install the Calendar app. - Create an event and enable the "All Day" option. - Duplicate the event. Issue: - When duplicating an All Day event, a traceback error occurs because the start_date and stop_date values are missing. Solution: - The start_date and stop_date are now properly set when duplicating an event resolving the traceback error. task-4353039 Forward-Port-Of: odoo/odoo#196884 Forward-Port-Of: odoo/odoo#188171
Refactor the `_run_manufacture` method in the `stock.rule` model to have a separate method to build the domain used to find an existing manufacturing order that can handle the procurement request. Having a separate method provides an easier way to extend the domain in other modules. A similar approach is already used in the `_run_buy` method. Description of the issue/feature this PR addresses: Patching the entire `_run_manufacture` method is required to change the MO domain. Current behav
Original PR description
Refactor the `_run_manufacture` method in the `stock.rule` model to have a separate method to build the domain used to find an existing manufacturing order that can handle the procurement request. Having a separate method provides an easier way to extend the domain in other modules. A similar approach is already used in the `_run_buy` method. Description of the issue/feature this PR addresses: Patching the entire `_run_manufacture` method is required to change the MO domain. Current behavior before PR: The domain is built inside the `_run_manufacture` method Desired behavior after PR is merged: The domain is built in a dedicated method that can be easily overwritten in custom modules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196156
When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services Task-4354482 Forward-Port-Of: odoo/odoo#188309
Original PR description
When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services Task-4354482 Forward-Port-Of: odoo/odoo#188309
### Steps to reproduce: - Create a storable product FP tracked by SN with a BOM: - 1 Operation: - instruction: Register Production type (per product) - 1 x Comp (storable product in stock) - Create and confirm an MO for one unit of FP. - Go to the shopfoor app > open the instruction of your operation - Type a non-existing serial number in the search bar > Create "new_sn" > This opens a form view of the stock.lot model - Save and close the new stock.lot > Invalid operation: You
Original PR description
### Steps to reproduce: - Create a storable product FP tracked by SN with a BOM: - 1 Operation: - instruction: Register Production type (per product) - 1 x Comp (storable product in stock) - Create…
### Steps to reproduce:
- Create a storable product FP tracked by SN with a BOM:
- 1 Operation: - instruction: Register Production type (per product)
- 1 x Comp (storable product in stock)
- Create and confirm an MO for one unit of FP.
- Go to the shopfoor app > open the instruction of your operation
- Type a non-existing serial number in the search bar > Create "new_sn"
> This opens a form view of the stock.lot model
- Save and close the new stock.lot
> Invalid operation: You are not allowed to create or edit a lot or serial number for the components with the operation type
> "Manufacturing". To change this, go on the operation type and tick the box "Create New Lots/Serial Numbers for
> Components"
#### Expected behavior:
The invalid operation should not be raised as the "required" option concerns only componenets and not final products.
### Cause of the issue:
Creating a stock lot will first launch a call of the `_check_create`: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/stock/models/stock_lot.py#L150-L153 However, since this check does not verifies that the product for which we create the lot is indeed related to a component of the MO it will raise the invalid operation even for final products: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/mrp/models/stock_lot.py#L11-L17
### Issue 2:
Currently, the `quickCreate` ("Create *sn_name*") option of the lot field of te "register production" dialog calls a `name_create` that will set an error message in the logs as the product_id required field can not be provided neither in the vals or the context of the `name_create`. You then fall back on the same form dialog than the "Create and edit". The `quickCreate` option should therefore just be disabled.
Enterprise: https://github.com/odoo/enterprise/pull/77265
opw-4452747
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#193965GroupingCategory and GroupingCode nodes have changed from optional to mandatory in SAF-T V1.3. For the category, we use RF-1167 for now as it's the most common value. task-4374014 Forward-Port-Of: odoo/enterprise#78778 Forward-Port-Of: odoo/enterprise#77423
Original PR description
GroupingCategory and GroupingCode nodes have changed from optional to mandatory in SAF-T V1.3. For the category, we use RF-1167 for now as it's the most common value. task-4374014 Forward-Port-Of: odoo/enterprise#78778 Forward-Port-Of: odoo/enterprise#77423
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further versions like 18.0. The changes made in that particular view in 18.0 will not be loaded and will cause errors since its inherited view's will not be compatible enough. For ex: If we make changes in a "Purchase Order"(i.e; purchase.report_purchaseorder) report then after saving the changes the n
Original PR description
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further…
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further versions like 18.0. The changes made in that particular view in 18.0 will not be loaded and will cause errors since its inherited view's will not be compatible enough. For ex: If we make changes in a "Purchase Order"(i.e; purchase.report_purchaseorder) report then after saving the changes the noupdate of that report view which is "purchase.report_purchaseorder_document" will be updated to 'true'. And the action record i.e; "purchase.action_report_purchase_order" noupdate will be updated to 'true'.   If the customer makes changes using studio then those changes will be recorded in the studio view and there is no point of making the standard view's noupdate to 'true'. Solution: ----------- Remove redundant code to overcome updating noupdate to 'true'. Steps to reproduce: ------------------------ 1. Create a database in version 17.0. 2. Make changes in any report using studio and save. 3. Migrate the database and try opening that report. 4. You'll encounter issues due to incompatibilty of views. Since, the changes made in the standard will not be loaded because it's noupdate is true. REF PRS: Enterprise PR: 1.https://github.com/odoo/enterprise/commit/2ae63d9a43ba973d905232105201d88e423a8245#diff-cf8f46a54f86279b4d773f0d39b23d22f046eb6d33a39c851f2a86dcd2b5b202R463 Forward-Port-Of: odoo/enterprise#78582
The computation for the cars bik has changed in belgium for 2025. This adds rule parameters and changes the computation to reflect those changes. Task: 4409219 Forward-Port-Of: odoo/enterprise#77557
Original PR description
The computation for the cars bik has changed in belgium for 2025. This adds rule parameters and changes the computation to reflect those changes. Task: 4409219 Forward-Port-Of: odoo/enterprise#77557
A standard such as RiBa that everyone calls RiBA should not have any invented translation like Payment Receipt (IT). Followup for the Ri.Ba. task: odoo/enterprise#74097 Documentation PR: odoo/documentation#11847 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749 Forward-Port-Of: odoo/enterprise#78886 Forward-Port-Of: odoo/enterprise#77991
Original PR description
A standard such as RiBa that everyone calls RiBA should not have any invented translation like Payment Receipt (IT). Followup for the Ri.Ba. task: odoo/enterprise#74097 Documentation PR: odoo/documentation#11847 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749 Forward-Port-Of: odoo/enterprise#78886 Forward-Port-Of: odoo/enterprise#77991
…on display option Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is
Original PR description
…on display option Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-ordering is active. However, it was still automatically enabling the preparation display even when self-ordering was disabled. (forward port of https://github.com/odoo/enterprise/commit/d3606d5a99ba7328cce164c0c16ff594d7639f4a) opw-4225668 X-original-commit: https://github.com/odoo/odoo/commit/2d753a90d0612b35d9d012574915d2e6bb754b1f Forward-Port-Of: odoo/enterprise#74256
Bug introduced by this commit: https://github.com/odoo/enterprise/commit/4b312d56e7fa01ab4e8f534a1e62ef59e1421f77 Steps to reproduce the bug: - Create a storable product “P1” - Create two different MOs: - First MO: 1 unit of P1 - Second MO: 2 units of P1 - Confirm and mark them as done - Go to the manufacturing list view - Select both MOs - Print Cost Analysis Problem: The mo_qty is 2 units instead of 3; only the quantity of the last MO is taken into account. This is beca
Original PR description
Bug introduced by this commit: https://github.com/odoo/enterprise/commit/4b312d56e7fa01ab4e8f534a1e62ef59e1421f77
Steps to reproduce the bug:
- Create a storable product “P1”
- Create two different MOs:
- First MO: 1 unit of P1
- Second MO: 2 units of P1
- Confirm and mark them as done
- Go to the manufacturing list view
- Select both MOs
- Print Cost Analysis
Problem:
The mo_qty is 2 units instead of 3;
only the quantity of the last MO is taken into account. This is because, to calculate the total quantity of all MOs, we use a variable mo_qty, but it is initialized twice, once before the loop and again within the MO loop, so for each MO, the counter is reset to 0.
opw-4529333
Forward-Port-Of: odoo/enterprise#78731During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view. This request actually reach the server even if Chrome is already closed and the test is cleaning itself (rollbacking the changes made in the database), resulting into a "release savepoint" mismatch on an already aborted transaction (example build's error [1]). This commit is kind of
Original PR description
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view. This request actually reach the server even if Chrome is already closed and the test is cleaning itself (rollbacking the changes made in the database), resulting into a "release savepoint" mismatch on an already aborted transaction (example build's error [1]). This commit is kind of a follow-up of a previous PR [2] where a last step allowing for the spreadsheet to unload was added and adding one more to actually wait to be back on the Document app. [1] https://runbot.odoo.com/runbot/build/74602509 [2] https://github.com/odoo/enterprise/pull/51795 Forward-Port-Of: odoo/enterprise#78797
Steps to Reproduce: - create a helpdesk ticket from the website form without attachments. - creation message in the chatter is missing. Cause: - subtype_id for helpdesk ticket messages was explicitly set in the bridge module's insert_attachment method. When no attachments were present, this prevented the _creation_subtype logic in the helpdesk.ticket model from executing, resulting in the missing creation message. Solution: - Added a condition in the insert_attachment method to skip mo
Original PR description
Steps to Reproduce: - create a helpdesk ticket from the website form without attachments. - creation message in the chatter is missing. Cause: - subtype_id for helpdesk ticket messages was explicitly set in the bridge module's insert_attachment method. When no attachments were present, this prevented the _creation_subtype logic in the helpdesk.ticket model from executing, resulting in the missing creation message. Solution: - Added a condition in the insert_attachment method to skip modifying messages when no attachments are present. It ensures that the default _creation_subtype logic handles subtype assignment, maintaining consistent and accurate creation message logging in the chatter. task-4397661 Forward-Port-Of: odoo/enterprise#78777 Forward-Port-Of: odoo/enterprise#76111
When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services Task-4354482 Forward-Port-Of: odoo/enterprise#74412
Original PR description
When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services Task-4354482 Forward-Port-Of: odoo/enterprise#74412
### Steps to reproduce: - Create a storable product FP tracked by SN with a BOM: - 1 Operation: - instruction: Register Production type (per product) - 1 x Comp (storable product in stock) - Create and confirm an MO for one unit of FP. - Go to the shopfoor app > open the instruction of your operation - Type a non-existing serial number in the search bar > Create "new_sn" > This opens a form view of the stock.lot model - Save and close the new stock.lot > Invalid operation: You
Original PR description
### Steps to reproduce: - Create a storable product FP tracked by SN with a BOM: - 1 Operation: - instruction: Register Production type (per product) - 1 x Comp (storable product in stock) - Create…
### Steps to reproduce:
- Create a storable product FP tracked by SN with a BOM:
- 1 Operation: - instruction: Register Production type (per product)
- 1 x Comp (storable product in stock)
- Create and confirm an MO for one unit of FP.
- Go to the shopfoor app > open the instruction of your operation
- Type a non-existing serial number in the search bar > Create "new_sn"
> This opens a form view of the stock.lot model
- Save and close the new stock.lot
> Invalid operation: You are not allowed to create or edit a lot or serial number for the components with the operation type
> "Manufacturing". To change this, go on the operation type and tick the box "Create New Lots/Serial Numbers for
> Components"
#### Expected behavior:
The invalid operation should not be raised as the "required" option concerns only componenets and not final products.
### Cause of the issue:
Creating a stock lot will first launch a call of the `_check_create`: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/stock/models/stock_lot.py#L150-L153 However, since this check does not verifies that the product for which we create the lot is indeed related to a component of the MO it will raise the invalid operation even for final products: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/mrp/models/stock_lot.py#L11-L17
### Issue 2:
Currently, the `quickCreate` ("Create *sn_name*") option of the lot field of te "register production" dialog calls a `name_create` that will set an error message in the logs as the product_id required field can not be provided neither in the vals or the context of the `name_create`. You then fall back on the same form dialog than the "Create and edit". The `quickCreate` option should therefore just be disabled.
Community: https://github.com/odoo/odoo/pull/193965
opw-4452747
---
Forward-Port-Of: odoo/enterprise#77265When the user claims the document and there is no valid token Odoo tries to re-generate the token, and instead of recalling to try to claim the document the code is wrongly calling the method to accept the document This logic was added in this https://github.com/odoo/enterprise/commit/3e906a93b91b5f66a4da850acc2b5ff2f43dd267 but for reason when the methods for accept/claim were merged into one method (_l10n_cl_action_response) -- Adhoc Ticket 86396 Forward-Port-Of: odoo/enterprise#782
Original PR description
When the user claims the document and there is no valid token Odoo tries to re-generate the token, and instead of recalling to try to claim the document the code is wrongly calling the method to accept the document This logic was added in this https://github.com/odoo/enterprise/commit/3e906a93b91b5f66a4da850acc2b5ff2f43dd267 but for reason when the methods for accept/claim were merged into one method (_l10n_cl_action_response) -- Adhoc Ticket 86396 Forward-Port-Of: odoo/enterprise#78248