Monday, December 2, 2024
9 changes · 18.0
Resolved issues and error corrections
When tasks or applicants are created by email, stage update messages now include the original sender instead of incorrectly excluding them as the message author. This ensures customers, portal users, or applicants receive expected status notifications after their email creates a record.
Original PR description
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) opw-3941928
This fix stops embedded action data from carrying over when users open a normal action from an embedded one. It prevents the wrong action bar from appearing and avoids crashes caused by using records from the wrong business object.
Original PR description
Before this commit, when executing a regular action from an embedded one, the context wasn't cleared, so all the embedded action feature related keys were propagated to the regular action. As a consequence, the embedded actions bar was displayed on that action as well. Clicking on an item most certainly led to a crash, because a wrong active id (referring to anothe res_model) would be used. For instance 1) Go to Project 2) Open "AGR - S00080 - Sales Order" 3) Add Sales order embedded action 4) Click Sales order 5) Enter a sales order that has tasks or a service product 6) Click the Tasks smart button 7) The embedded actions bar is displayed and, it crashes if an item is clicked opw~4253958 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
OAuth login routes are no longer treated as read-only because they may need to create a user account or record a login event. This prevents failed sign-ins caused by the system blocking required database updates during authentication.
Original PR description
Follow-up of #186319 and #186786 These routes are auth=none but aren't technically read-only, as they can create the user record and need to record the login event anyway. The signin one even as a broad catch for Exception, which would prevent the readonly->read-write fallback to work, leading to a failed login.
This fix prevents payment post-processing from failing when a journal has more than one payment method line. It helps ensure online or point-of-sale payments can complete reliably instead of being blocked by a configuration-related error.
Original PR description
Currently, an exception is generated at the time of the post-processing payment transaction. error: ``` ValueError: Expected singleton: account.payment.method.line(11, 12) File…
Currently, an exception is generated at the time of the post-processing payment transaction.
error:
```
ValueError: Expected singleton: account.payment.method.line(11, 12)
File "addons/payment/models/payment_transaction.py", line 852, in _cron_post_process
tx._post_process()
File "addons/pos_online_payment/models/payment_transaction.py", line 29, in _post_process
super()._post_process()
File "addons/website_payment/models/payment_transaction.py", line 14, in _post_process
super()._post_process()
File "addons/sale/models/payment_transaction.py", line 91, in _post_process
super(PaymentTransaction, done_tx)._post_process() # Post the invoices.
File "addons/account_payment/models/payment_transaction.py", line 122, in _post_process
tx.with_company(tx.company_id)._create_payment()
File "addons/account_payment/models/payment_transaction.py", line 163, in _create_payment
'payment_method_line_id': payment_method_line.id,
File "odoo/fields.py", line 5287, in __get__
raise ValueError("Expected singleton: %s" % record)
```
The above exception was generated because we got multiple payment method lines in a single journal.
This commit fixes the above issue by accessing the first payment method line.
sentry-6007333118New databases now include a second default follow-up reminder level, so overdue invoices can receive a gradual sequence of reminders instead of only one. Demo cleanup also prevents deleted snailmail follow-up records from being recreated during module updates.
Original PR description
The second level already configured in demo has been moved in data because having only one follow-up level in a new database is a bit weird. Not only does it look weird, but in practice it also leads to a weird situation that by default the invoices will only be reminded once and never after. + we're failing to convey the usefuleness of the feature of building gradually harded reminders for the partner. Also added forcecreate="False" in snailmail demo data, because we don't waznt to recreate the missing xml ids (if people deleted it) in every module's update. task-4334758
Project managers can now create document folders from project settings without hitting an access error in demo scenarios. Project document links also open the more useful folder document view, making it easier to manage centralized project documents.
Original PR description
Commit 1: Reproduce: 1. Open a project's settings as Admin/Demo (project managers) 2. Make sure "Use Documents" is checked 3. Try quick creating a folder 4. Access Error This occurs because you are not allowed to create in the restricted "Projects" folder. This commit adapts demo data so that flows can easily be demonstrated and tested without requiring extra configuration steps for a common flow. Commit 2: Quick create folders instead of requests to centralize projects' documents. Also, the `documents_folder_many2one` widgets links to the documents kanban view of the folder instead of the less useful form view, as it is done in the other apps and bridges. Task-4344434
This update fixes several issues in Documents, including preventing employees from being automatically granted access to employee-related documents, improving the My Documents and Shared With Me filters, and avoiding crashes when shortcuts point to inaccessible files. It also reduces clutter from frozen spreadsheet folders in Home, making document navigation faster and clearer for users.
The point of sale quantity control now correctly changes a product quantity to a negative value when the +/- button is pressed. This prevents unexpected zero quantities and supports more accurate adjustments such as returns or corrections.
Original PR description
Before this commit ------------------------ Previously, when adding a product and clicking the "+/-" button, the quantity would change to "0" instead of becoming negative. After this commit ---------------------- After implementing this commit, pressing the +/- button now results in the quantity value changing to negative instead of changing it to 0. task- 4281516 Related PR: https://github.com/odoo/odoo/pull/185441/
WhatsApp conversations that have been inactive are now automatically unpinned after 5 days instead of 2 weeks. This helps prevent teams with high WhatsApp message volumes from hitting conversation limits that can slow down Discuss.
Original PR description
Follow-up of https://github.com/odoo/enterprise/pull/74131 PR above attempts to solve an issue of every-growing unpinned whatsapp conversations that make it harder to use Discuss for performance reasons, due to reaching the technical limit of around 2000 pinned conversations. To do so, it automatically forces unpinning whatsapp conversation after 2 weeks of inactivity, even if the conversation was unread. While this is an improvement, if there are around 150 whatsapp new whatsapp conversations made every day, then the 2 week force unpin is not enough, because the 2000 pinned conversation limit is reached. This commit fixes the problem by reducing the force unpin of whatsapp conversation to 5 days. The architecture of Discuss should scale better, but this is hardly achievable in short manner, hence why the current solution to this problem is prevent reaching a high amount of pinned conversations. opw-4330847