Friday, September 27, 2024
33 changes
1 change
Resolved issues and error corrections
Sales orders now correctly count delivered quantities when goods move through an intercompany transit location. This helps businesses using intercompany sales see accurate delivery progress and avoid confusion in order fulfillment.
Original PR description
Currently, we only check delivered quantities in a Sale Order based on the `usage` of the destination location of the related delivery. This means that in the case of Inter-company transactions, we won't consider them as deliveries, as its delivery location will be 'Inter-Company Transit', which itself is a 'transit' location. Test in odoo/enterprise#70663 Task-4207132 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
When appraisal automation is enabled, changing the company appraisal plan now recalculates the next appraisal date for employees. The settings warning is also shown only when this recalculation will actually happen, reducing confusion for HR users.
Original PR description
There is an *Appraisal Plan* section in the setting that allows setting the global plan for the company. If *Appraisal Automation* is enabled and the plan is changed, we want to recompute the next appraisal date based on it for all the company employees. we also display the warning that this update will be triggered only if it actually will be -- i.e. if *Aprraisal Automation* is enabled and one of the plan durations were changed. (previously the warning would always be displayed, but the update would not happen) task-4167727
17 changes
New functionality added to Odoo
This update adds support for Swiggy delivery orders through UrbanPiper in Odoo Point of Sale. It also improves order tracking by using consistent platform IDs and sequence numbers, making delivery order handling clearer for staff.
Original PR description
After this commit: ----------------------- - A sequence number has been introduced to manage floating orders. - We display the platform ID instead of the order OTP because the platform ID is consistent across all providers, while the OTP information may vary depending on the provider. - A new pos_urban_piper_swiggy module added to support Swiggy integration with Urbanpiper. Task-4195863
5 changes
Resolved issues and error corrections
This fix allows tasks to be automatically created when adding non-recurring service products to subscription upsells. Previously, task creation was blocked for all upsell products due to pricing proration limitations. Since non-recurring products are not prorated, they can now safely create tasks without technical issues.
Original PR description
The referral dashboard now opens referral-related views without triggering an error. This restores normal navigation for users checking referral, ongoing, or successful applicant lists.
Original PR description
Steps: - Install hr_referral - click on referrals on dashboard Description of the issue/feature this PR addresses: In the referral module, clicking on any options like referrals, ongoing, or successful results in a traceback. Cause The issue arises due to the name field, which was removed from the hr_applicant model (as per https://github.com/odoo/odoo/pull/173288). The system still attempts to retrieve this field, causing the error. Fix: This PR resolves the issue by removing the unnecessary name field from the kanban template task-4159856
Enhancements to existing features
Users can now include property fields when importing and exporting records, making these flexible custom data points easier to manage in bulk. This improves data migration and reporting workflows while keeping property definitions controlled by the related parent record.
Original PR description
https://github.com/odoo/enterprise/pull/69287 task-4027103
Event reminder and follow-up messages now send in smaller batches instead of trying to process every registration at once. This reduces the risk of failed scheduled jobs, duplicate messages, and performance issues for large events using email or SMS communications.
Original PR description
RATIONALE When invoked through cron, event schedulers currently run on all available registrations. This can lead to Memory or Time errors when dealing with big events. We should instead move towards…
RATIONALE
When invoked through cron, event schedulers currently run on all available
registrations. This can lead to Memory or Time errors when dealing with
big events. We should instead move towards an interactive sending, committing
after each batch, to gradually send communications without errors and without
sending multiple times mails, sms, whatsapp messages, ...
SPECIFICATIONS
Global approach for this PR
* rewrite schedulers execution code, notably to have more control on
input / output of each type: event-based or attendee-based schedulers,
give registrations to contact as input, ... ;
* introduce more performance oriented code: avoid filters on all attendees,
search for batches instead; find once attendees to contact then;
delegate the sending only to sub modules;
* make communications iterative
* event-based: use recently introduced "last_registration_id" field to know
at which point process was stopped, and resume communication sending;
* attendee-based: contact by batches;
* make code more defensive against ill defined templates and issues during
communication sending;
* add / improve tests;
See sub commits for more details.
Task-3814592: Event: Limit scheduler in cron mode
Task-3084943: Event: Improve communication scheduler scalabilityThe shop floor view no longer applies the default “This Station” filter, so teams can see manufacturing orders beyond the current workstation by default. This change is possible because prior performance improvements now keep the view responsive without needing that restriction.
Original PR description
The 'This Station' default filter was introduced in [1] as a stopgap solution for limiting the amount of MOs loaded simultaneously in the view, to avoid performance bottlenecks. Since the introduction of a limit (also in [1]), as well as later performance improvements from [2], the performance of the shop floor is now acceptable without this filter, so we proceed with removing it completely in this PR. [1] https://github.com/odoo/enterprise/pull/64551 [2] https://github.com/odoo/enterprise/pull/66898
Event-related automated messages now run in smaller batches and can resume where they stopped, reducing failures for large events. This helps prevent duplicate emails, SMS, WhatsApp messages, and social posts while improving reliability and performance.
Original PR description
RATIONALE When invoked through cron, event schedulers currently run on all available registrations. This can lead to Memory or Time errors when dealing with big events. We should instead move towards…
RATIONALE
When invoked through cron, event schedulers currently run on all available
registrations. This can lead to Memory or Time errors when dealing with
big events. We should instead move towards an interactive sending, committing
after each batch, to gradually send communications without errors and without
sending multiple times mails, sms, whatsapp messages, ...
SPECIFICATIONS
Global approach for this PR
* rewrite schedulers execution code, notably to have more control on
input / output of each type: event-based or attendee-based schedulers,
give registrations to contact as input, ... ;
* introduce more performance oriented code: avoid filters on all attendees,
search for batches instead; find once attendees to contact then;
delegate the sending only to sub modules;
* make communications iterative
* event-based: use recently introduced "last_registration_id" field to know
at which point process was stopped, and resume communication sending;
* attendee-based: contact by batches;
* make code more defensive against ill defined templates and issues during
communication sending;
* add / improve tests;
See sub commits and linked community PR for more details.
Task-3814592: Event: Limit scheduler in cron mode
Task-3084943: Event: Improve communication scheduler scalabilityAppointment manual confirmation now depends on the selected booking slot rather than the scheduled day, giving administrators better control during busy periods. Customer confirmation emails are clearer because accept and decline actions are reserved for admins, and cancelled appointment records are labeled more accurately.
Original PR description
### Purpose Currently, manual confirmation was inconveniently triggered based on scheduled booking days, causing users inconvenience. The purpose of this PR is to Change the Manual Confirmation Trigger conditions and Change Mail Template when Manual Confirmation is enabled. ### Specs **1. Update Trigger Conditions for Manual Confirmation** - Change trigger conditions to be based on booking slots instead of scheduled days. This allows admins to verify bookings manually before confirmation, especially during peak times. **2. Revise Mail Template for Confirmation** - Update mail template context for users receiving confirmation notifications. - Remove 'Accept' and 'Decline' buttons, as only admins can now accept or decline bookings. **3. Appointment Booking Form View Improvements** - Changed 'Archived' ribbon to 'Cancelled', when an appointment type is set. Task-3918889
Resolved issues and error corrections
This fixes an issue where paid orders created while the point of sale was offline could remain unsynced after the session was restarted. Businesses can rely on offline sales being uploaded once connectivity returns, reducing the risk of missing orders or revenue records.
Original PR description
Before this commit, orders created in offline mode would not sync upon restarting the session once back online. opw-4213314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes several issues in return and exchange workflows, including incorrect quantity handling, duplicate procurement creation, and sale order updates during multi-step returns. It helps businesses process returns more accurately, especially when products use lots, different units of measure, or exchange shipments.
Original PR description
This commit unpack the keys and values of `layers_by_lot` correctly + use the uom of the product's move not the lot Task :4210510 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
Fixes an issue in the restaurant point of sale demo data where paid demo orders could remain stuck on the floor plan, and one demo table could not accept new orders. This helps users testing or demonstrating restaurant workflows complete payments and continue ordering normally.
Original PR description
Steps to reproduce : --------------------------- - Install the pos_restaurant module. - Open any demo orders, let's say table 1 - Make the payment, then go to the receipt screen then the floor plan - [ISSUE] Order is still there. - In Table 6, can't even place the order Cause : --------- 1. Demo orders case was not handled in the "sync_from_ui" method leading to this issue 2. Uuid was not given for the Table 6 order line, causing this misbehavior. Fix : ------ 1. Handled the case for demo orders in the "sync_from_ui" method 2. Provide uuid for table 6 order line at the time of creation Task: 4212901
This fix corrects how amounts are calculated for the accounting dashboard so the displayed figures better match the underlying journal entries. It helps finance users rely on dashboard totals for quicker, more accurate day-to-day review.
Original PR description
It's hard to describe in words, hope you understand through the attached description file  https://github.com/odoo/odoo/blob/b4090cbdc697f92e755e1d2a368e202a5df0f532/addons/account/models/account_move.py#L1079 https://github.com/odoo/odoo/blob/b4090cbdc697f92e755e1d2a368e202a5df0f532/addons/account/models/account_move.py#L1083 https://github.com/odoo/odoo/blob/b4090cbdc697f92e755e1d2a368e202a5df0f532/addons/account/models/account_move.py#L1088 [description table.ods](https://github.com/user-attachments/files/17140814/description.table.ods) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Several website building blocks were adjusted so images keep their intended size and layouts remain consistent. The changes remove problematic alignment behavior, improve grid editing options, and fix visual issues on desktop and mobile.
Original PR description
This PR regroups some fixes about snippets with columns wrongly set to `display: flex` in order to have a "Vertical Alignment" option to align the content in it. Indeed, `display: flex` should be avoided, as any element in it tries to fill the available space, making the images not have their real size.
The barcode scanner now waits until the camera is ready before related actions can close it, reducing interruptions during startup. It also stops repeated scan attempts once the camera stream is closed, preventing potential loops and instability when users exit the scanner.
Original PR description
This commit changes two things: 1. Adds `onReady` props to be able to call a method when the video scanner is ready. In the Barcode app for example, this prop will let us to prevent to close the camera during its initialization. 2. Avoids to set a timeout for `detectCode` if there is no more stream. Without this change, it could happens something goes wrong when closing the camera video scanner and then, it will loop infinitly on `detectCode` because the timeout code part is outside of the try/catch and so it is called anyway everytime `detectCode` is run. Enterprise PR: odoo/enterprise#70607
Fixed an issue where validation and export buttons could disappear on batch payments when online payments were installed but not configured for a bank journal. This ensures users can continue validating and exporting relevant payment batches without unnecessary setup changes.
Original PR description
Before this commit, when account_online_payment was installed and no payment initiation was configured on a bank journal, the batch validation and export buttons never appeared on the batch payments made on this journal.
Bookkeepers can now use the Secure Entries wizard as intended. This removes an access-rights blocker so accounting teams can complete secure entry workflows without needing extra help or elevated roles.
Original PR description
Currently bookkeepers do not have the rights to use the Secure Entries wizard. This is fixed in this commit.
When a spreadsheet-based quality check fails, users now remain on the spreadsheet screen so they can read the failure message. This helps operators understand what went wrong before choosing to return to the Shop Floor view.
Original PR description
When a quality check of type 'spreadsheet' fails, we want to show the failure message and stay on the spreadsheet view. That way the user has the time to see what failed. They can still use the 'Shop Floor' link to return to the shopfloor view.
Portal users can now switch to the document list view without encountering a client error. This improves reliability for external users who access and manage shared documents through the portal.
Original PR description
When portal users try to switch to the list view, they get a client error. The error is solved by keeping the studio service accessible to the ListRenderer. task-3373836
The barcode scanner can no longer be closed while the camera is still starting up. This prevents errors and failed scanning sessions for warehouse users who use camera-based barcode scanning.
Original PR description
This commit makes it not possible to close the barcode video scanner during its initialization. It prevents a lot of issue. Community PR: odoo/odoo#181294
Steps to reproduce: - Download 'Project' and 'Subscription' - Create a product with: -- Product type: 'Service' -- Create on order: 'Task' -- Project: Pick any -- Recurring checkbox must not be…
Steps to reproduce: - Download 'Project' and 'Subscription' - Create a product with: -- Product type: 'Service' -- Create on order: 'Task' -- Project: Pick any -- Recurring checkbox must not be ticked - Subscription > New > Add any recurring product > Confirm - Create invoice > Confirm invoice > Back to subscription - Upsell > Add your task creation product > Confirm - The project is linked but no task is created The ability to create tasks from upsell orders was disabled in cbbc70f73e6fe9e29e27dea4415e20a262bbdf82. According to the commit message, this was done because upsell orders prorate the price of subscriptions accoding to the time until next invoice relative to the subscription's recurrence (i.e. if the upsell is created halfway through the recurrence it is discounted by 50% etc...). Since we do not have a way to prorate tasks it is marked as a technical limitation. This however does not need to extend to non-recurring products on subscription sale orders as they are not prorated. opw-4114049
This fix addresses two issues with appraisal feedback deadlines. First, employees can now no longer submit feedback after the deadline has passed. Second, managers can continue to view submitted feedback even after the deadline has expired. These changes ensure that feedback deadlines are properly enforced while still allowing managers to access and review the feedback they've received.
Original PR description
Issue 1: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - the employee can answer after the deadline Problem: -------- the method…
Issue 1: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - the employee can answer after the deadline Problem: -------- the method `_check_validity` was overriden in `hr_appraisal_survey` module to do different checks than the original method in `survey` module in case of `validity_code = answer_wrong_user`, but this override bypasses the other checks in the original method like the deadline check. Solution: --------- call the original method `_check_validity` in the override, to make sure all the checks are done, then if the original method returns `validity_code = answer_wrong_user` we can do our specific checks. Issue 2: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - manager can't see the answers after the deadline Problem: -------- - to display answer in appraisal module we rely on the url of the survey that contains the tokens for suervey/answer - the deadline handling is done in the survey module where the url is dead after the deadline which is not suitable for the appraisal module Solution: --------- - override the method `_get_access_data` and bypass the deadline check in case of appraisal feedback for manager. opw-4128638
Fixed an issue where the expiration date field was incorrectly disabled when receiving lot-tracked products in the barcode app. The date picker now works properly when either "Use Existing" or "Create New" options are enabled for lot/serial number configuration, allowing warehouse staff to accurately record product expiration dates during inventory receipts.
Original PR description
The problem was that the date picker was disabled when we have Use Existing ones only enabled, but it should be enabled when "Use Existing ones" is checked or "Create New" in the config of "Lots/Serial Numbers". Steps to reproduce: - add a product tracked by lots and have also enabled expiration dates - inventory Receipts configuration - in general, check both options "Use Existing ones" and "Create New" under "Lots/Serial Numbers" - now if you receive product in barcode app, you will see expiration date of the lots disbaled opw-4086325 Forward-Port-Of: odoo/enterprise#68008
This update fixes problems that occur when helpdesk tickets are merged together. Previously, merging tickets would create duplicate SLA policy entries and lose follower information. The fix ensures that duplicate SLA policies are removed, followers are properly preserved, and only the most urgent deadline is kept for each policy type when tickets are combined.
Original PR description
Steps to reproduce: - Helpdesk > Configuration > SLA policies - Create one if necessary or use existing - Helpdesk > Tickets > Create - Configure it so that it corresponds to SLA requirements -…
Steps to reproduce: - Helpdesk > Configuration > SLA policies - Create one if necessary or use existing - Helpdesk > Tickets > Create - Configure it so that it corresponds to SLA requirements - Duplicate the ticket and merge them both (data_merge module required) Currently helpdesk ticket uses the default merge fuction, which simply concatenates the values of merged records. This causes a few strange things to happen: 1. sla_ids which registers SLA policy types, has duplicate entries. This recordset should remain a set. 2. Followers of the merged tickets are sometimes not added to the resulting record. The default merge simply swaps the resource id with no regard for a possible duplication of unique key (res_model, res_id, partner_id), which causes the transaction to fail on repeat followers. This is a common problem with every record inheriting mail.thread which does not define its own merge function as well. 3. Keeping every SLA status record is redundant, merging tickets makes it impossbile to keep track of which task each deadline was originally related to anyway. Hence why we only keep those with the shortest deadline for each type. Priority is not a concern here since SLA policies are recomputed according to a ticket's priority rating, so we cannot have 2 SLAs with the same policy and different priorities. opw-4037262
This fix prevents an application error that occurred when users tried to send WhatsApp messages after deleting a contact. The system was attempting to access information about a contact that no longer existed, causing the messaging feature to crash. With this fix, the WhatsApp messaging feature now handles deleted contacts gracefully without interrupting the user experience.
Original PR description
Steps to reproduce the error: - Install "contacts" and "whatsapp" module - Configure WhatsApp Business Account and create a whatsapp template - Go to Contacts > Create a new contact > add mobile…
Steps to reproduce the error:
- Install "contacts" and "whatsapp" module
- Configure WhatsApp Business Account and create a whatsapp template
- Go to Contacts > Create a new contact > add mobile number >
click on whatsapp button > select template > send message
- reply to message from mobile number
- Delete contact
- Go to Discuss > open channel of contact > send message
Traceback:
```
IndexError: tuple index out of range
File "odoo/http.py", line 2256, in __call__
response = request._serve_db()
File "odoo/http.py", line 1832, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1852, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1830, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1837, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2062, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 742, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "home/odoo/src/enterprise/saas-17.2/whatsapp/controller/main.py", line 41, in webhookpost
request.env['whatsapp.message']._process_statuses(value)
File "home/odoo/src/enterprise/saas-17.2/whatsapp/models/whatsapp_message.py", line 413, in _process_statuses
whatsapp_message_id._update_message_fetched_seen()
File "home/odoo/src/enterprise/saas-17.2/whatsapp/models/whatsapp_message.py", line 426, in _update_message_fetched_seen
channel_member = channel.channel_member_ids.filtered(lambda cm: cm.partner_id == channel.whatsapp_partner_id)[0]
File "odoo/models.py", line 6580, in __getitem__
return self.browse((self._ids[key],))
```
https://github.com/odoo/enterprise/blob/a134bea9c6fa1a0806c5501046e358c82d7a3fe5/whatsapp/models/whatsapp_message.py#L428
Here, when user deletes the contact, channel.whatsapp_partner_id will be False,
and channel_member will become an empty tuple,
So when it tries to access the index of an empty tuple,
It will lead to the above traceback.
sentry-5314291061