Tuesday, April 16, 2024
27 changes
6 changes
Enhancements to existing features
Adds ready-to-use Indian payroll sample data so salespeople and business analysts can demonstrate payroll workflows more easily. The demo setup includes employees, users, contracts, leave allocations, bank details, payslips, and payslip batches for an Indian company.
Original PR description
The purpose of these demo data is for our salesperson or business analyst to give a demo to customers/partners. This PR includes the following demo data: --------- - Addition of Indian employees - Creation of users for the Indian company - Generation of contracts for all employees - Allocation of leaves for these employees - Inclusion of partners and their bank account details - Generation of payslips for all employees with varying structures - Creation of payslips batch task-3491700
Users can now enable a Merge option on selected business records and send them directly to the deduplication screen as one merge group. This makes it easier to clean up duplicate or noisy data on supported models without relying only on automated rules.
Original PR description
Purpose ======= Introduce a "manual" merge mode. Indeed, while the current rules introduced some "ongoing hygiene", one may wants to take manual action to "clean up one's database". For example,…
Purpose ======= Introduce a "manual" merge mode. Indeed, while the current rules introduced some "ongoing hygiene", one may wants to take manual action to "clean up one's database". For example, because one is working on a report (pivot table, o-spreadsheet, ...). Or because one is able to take a more drastic approach (merge records that aren't technically the same to reduce the amount of noise, ...). The objective is to allow the user to select multiple records on a model to open the data_merge deduplicate view with the records them selected to merge them quickly. Specification ============= Add a button on ir.model view that allow the user to enable the Merge contextual action on the current model. Once the merge action is enable, the user is able to select multiple records and open the data_merge deduplicate view targetting only the records them selected. The selected records are placed in the same merge group. In Data_merge/configuration, user can find the list of models in which the merge action has been activated. By default, display the "Merge" option in the action menu for the following models: crm.lost.reason crm.tag event.tag.category product.category project.tags project.task helpdesk.ticket helpdesk.tag res.country res.country.state res.partner.category res.partner.industry res.partner.title utm.campaign utm.medium utm.source As some models already have custom merge methods, the generic merge action should not be activated on those models, notably: crm.lead res.partner account.analytic.line Link ==== Task ID: 2459416 COM PR: https://github.com/odoo/odoo/pull/67613
Kenyan payroll now lets employees handle their own life insurance contributions while still having the appropriate deduction reflected on their payslip. This gives employees more flexibility and reduces company-managed administration for this benefit, while also cleaning up unused related code.
Original PR description
Add the possibility for employees to manage their life insurance by themselves instead of the company so they can contribute to the life insurance by themselves and still have the deduction on their payslip. Also this PR remove unused code by the same occasion task-3827182
Embedded view links in Knowledge articles now open a popover with clear actions to open, copy, edit, or remove the link. This makes linked views easier to manage directly from the article editor and improves guidance in the Helpdesk Knowledge flow.
Original PR description
*= knowledge website_helpdesk_knowledge With this PR, the behavior for embedded view links is, On the click, it opens a popover that contains the name (same as the body) and three buttons(copy, edit,…
*= knowledge website_helpdesk_knowledge With this PR, the behavior for embedded view links is, On the click, it opens a popover that contains the name (same as the body) and three buttons(copy, edit, remove). - Name in the popover which is a link, on the click, it will redirect to that view. - Copy button: It copies the name (with styling if applied) and prints on the paste as it is with the popover behavior. - Edit button: It opens a dialog box where the name has already been printed and users can edit the name and save it to edit the name in the main body. -> There is styling too, for customizing the link and making it a button. - Remove button: It converts the link into simple text. So, this is a new functionality to click on the link from the popover to redirect to that view, - For that, modified the tour which directs the users on how the flow works. **Task**-3082042 Co-authored-by: Naman Shah <nash@odoo.com> Co-authored-by: Damien Abeloos <abd@odoo.com>
A new digest gives teams regular visibility into social post engagement and clicks over the past day, week, and month. Appointment digest reporting is also enhanced with a linked action for booked meetings, making it easier to review related activity.
Original PR description
This PR will add a new digest for the `social` module. The digest will provide the following statistics: - Engagement on the posts created over the last 24h / 7 days / 30 days. - Number of clicks generated by the posts created over the last 24h / 7 days / 30 days. We will also link an action to the digest "# Meetings Booked" digest added to the community version (see related PR). task-2647241
Shop attribute filters now carry through from the product listing to product pages and remain selected when shoppers return to the shop. This makes browsing more consistent and reduces friction for customers refining products by attributes.
Original PR description
- Attributes filtered on /shop should carry over to the product page - When going back to /shop, the attributes selected should remain task-3067205 See also: - odoo/odoo#157412
19 changes
Resolved issues and error corrections
Fixed an issue where customers ordering through self-service QR menu on their phones encountered errors when validating orders. The problem was that the payment system wasn't properly initialized when the order was created, only when the cashier processed it. This fix ensures the payment system is ready from the moment the customer places their order.
Original PR description
Current behavior: When doing an order from self ordering on phone, there was an error because the fiskaly_uuid was not created directly when the user was creating the order. But it's created when the order is processed by the cashier. Steps to reproduce: - Setup fiskaly on your db (ask me if you need help) - Setup a pos to use QR Menu + payment in a DE company - Create an order from this PoS - Validate the order, you get an error opw-3773777
When creating a new appointment booking from the Gantt view, the system now automatically sets the start time to the current time (rounded to the nearest half-hour) instead of midnight. This makes scheduling more intuitive and saves users time by starting with a realistic default time.
Original PR description
Steps to reproduce =================== - Open Gantt view of any appointment. - Click on "New' to create a new booking. - The default start is set to today's midnight which is not relevant. After this PR ================== The current Time with rounded in half-hour format will be set as a default start while creating a new booking through the Gantt view. eg 10:10 => rounded to 10:30, 10:40 => rounded to 11. Task-3820387
Fixed an issue where subscription invoice previews displayed incorrect untaxed totals in the sidebar instead of the correct tax-included amount. This ensures customers and sales teams see accurate pricing information when previewing subscription invoices from the sales form.
Original PR description
Problem:
When clicking the preview stat button (1) from the sales forms view,
with a subscription product, the total amount displayed in the sidebar of the rendered document is wrong (untaxed),
(1) The amount is the correct total amount if the preview button is clicked from a draft invoice for the same order.
Desired:
The total dispalyed in the sidebar of the preview is **tax-included**.
opw-3822740Payment tokens created during SEPA Direct Debit transactions were not being properly linked to their source transactions. This fix ensures tokens are correctly associated with transactions, allowing subscriptions to save and reuse these tokens as recurring payment methods.
Original PR description
Payment tokens that are created when SEPA Direct Debit transactions are confirmed were not linked to those transactions. This prevented subscriptions from saving the tokens as recurring payment method because they could not be found through the payment transactions. opw-3756773 See also: - https://github.com/odoo/odoo/pull/161561
This update resolves a technical issue affecting the point-of-sale receipt display for companies using Chilean localization. The receipt component was being incorrectly applied to all companies regardless of their location settings, causing system errors. The fix adds proper validation to ensure the Chilean-specific receipt customization only applies to companies that actually use Chilean localization.
Original PR description
The error was caused by the fact that the receipt component was wrongly overridden. There was no any check to see if the company was using the Chilean localization, so the error was raised. This commit fixes: [runbot/error#61720](https://runbot.odoo.com/web#id=61720&model=runbot.build.error), [runbot/error#61722](https://runbot.odoo.com/web#id=61722&model=runbot.build.error), [runbot/error#61723](https://runbot.odoo.com/web#id=61723&model=runbot.build.error), [runbot/error#61724](https://runbot.odoo.com/web#id=61724&model=runbot.build.error)
Fixed an issue in the Gantt chart view where connector arrows could start from incorrect positions when users moved their mouse very quickly during connector creation. The fix ensures connector arrows always begin from the exact point where the user initially clicked, providing a more reliable and predictable user experience. Additionally, corrected the CSS class assignments for right-to-left language layouts.
Original PR description
- Before: when you start the creation of a connector while going super fast (i.e. with a high DPI pointer device when you drank too much coffee or other energizing drink), you may end up with the connector arrow starting from any place.  - After: the arrow starts where you initially clicked, regardless of how fast you could move your pointer afterwards.  Forward-Port-Of: odoo/enterprise#60729 Forward-Port-Of: odoo/enterprise#60629
This fix corrects a bug where automated actions were being triggered when they shouldn't be. Specifically, when manually updating a record using a server action, automated rules that should only run on creation were incorrectly firing. The fix ensures the system properly distinguishes between creating new records and updating existing ones, preventing unwanted automated actions from executing.
Original PR description
Steps to reproduce: ------------------- [A] Create an automated action with: - Model: Tasks (project.task) - Trigger: On save - When updating: ID (to mimic "on_create" trigger) - Execute code: ```py…
Steps to reproduce:
-------------------
[A] Create an automated action with:
- Model: Tasks (project.task)
- Trigger: On save
- When updating: ID (to mimic "on_create" trigger)
- Execute code:
```py
record.message_post(body="This is a message from automated action (fields triggers: ['id'])")
```
[B] Create a server action (contextual action) with:
- Type: execute code
- Model: Tasks (project.task)
- code:
```py
record.write({})
```
[C] Test:
- create a new task --> message has been posted (OK)
- write some values on the task --> no message has been posted (OK)
- run the server action --> message has been posted (KO)
Issue:
------
No message should be posted as the ID field has not been modified.
Cause:
------
`if not self._context.get('old_values')` is considered as `True` because we have an empty dict.
In fact, when we make a write on a record, old_values will be always a dict.
```py
old_values = {
old_vals.pop('id'): old_vals
for old_vals in (records.read(list(vals)) if vals else [])
}
```
Solution:
---------
Old values are not defined in the context during a create. We can compare `self._context.get('old_values')` with `None` to differentiate between creating and writing on records.
opw-3736068This fix ensures that when a project template is copied (such as when creating a sales order with a project-based product), any sub-tasks are correctly assigned to the new copied project instead of remaining linked to the original template. This restores the correct behavior that existed in version 16.4, ensuring project copies maintain their proper task hierarchy and assignments.
Original PR description
### Steps to reproduce: - Create a project with a task with a sub-task - Assign manually the sub-task to the project - Create a product that creates a project based on this product template - Create…
### Steps to reproduce: - Create a project with a task with a sub-task - Assign manually the sub-task to the project - Create a product that creates a project based on this product template - Create an SO with that product #### > A copy of your project template will be created and assigned to the SO ### Expected Behavior: Just as in 16.4, the copy of the subtask created during this process should be associated with the copy of your project template. ### Current Behavior: The subtask is associated with the original project template. ### Cause of the issue/Fix: Confirming the SO will call the copy method on your project template. During this call copies of its task and sub-task will be created and should then be remapped to the correct project/task using by the `map_tasks` method call: https://github.com/odoo/odoo/blob/f31174e02157e612650e77ebba3ed1fe54b96776/addons/project/models/project_project.py#L436-L437 This use to do the job correctly in 16.4 because of these lines: https://github.com/odoo/odoo/blob/ce28edbaae5a9af0a8c6e1f2addf4285ec56e9e1/addons/project/models/project_project.py#L415-L419 However, these were removed by commit 6303a3e probably because the new write method of the "project.project" model introduced by this commit sometimes relies on the "project_id" of these tasks and this information should be consistent with the future value of the "project_id" of these tasks. However, the "project_id" of these tasks should still be remapped to the copied project at some point and in my opinion this should be done before the new write method is called, so that this method can be used correctly. opw-3823013 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed a bug in the Donation snippet where toggling off the "Pre-Filled Options" setting caused the website to crash. The issue occurred because the system tried to loop over an empty value, which is no longer allowed in the updated template system. The fix ensures the system handles empty donation options correctly without errors.
Original PR description
Steps to Reproduce : - Install eCommerce. - Drag and drop the "Donation" snippet. - Click on the prices in the snippet. - Toggle the "Pre-Filled Options" option. - => There is a traceback. This bug is due to the fact that since commit [1], all templates have been added to the OWL app. With OWL, a t-foreach in a template can no longer loop over a 0 number and causes an error if we try to. This is what happens here, as toggling off the "Pre-filled Options" option sets the donationAmounts to 0, which is then used in a loop in the templates. This commit fixes this by replacing the number by an empty array, so the loop cannot fail. [1]: https://github.com/odoo/odoo/commit/4703e4a2efa9213979307e4d3dedeedc61ad0fc3 task-3859207
This fix corrects the SEPA Direct Debit payment method configuration to properly support tokenization. Previously, the payment method was marked as non-tokenizable despite the system creating tokens automatically, which prevented it from appearing in subscription and payment management pages. This change ensures customers can now use SEPA Direct Debit for recurring payments and manage their payment methods through the portal.
Original PR description
The payment method's `support_tokenization` field was incorrectly set to `False` instead to `True`. This didn't prevent the SEPA Direct Debit provider from tokenizing this payment method because it always creates tokens when a payment transaction is confirmed. However, the payment method was not shown in payment contexts where tokenization is required (e.g., Subscriptions' portal page, /my/payment_method page). opw-3756773 See also: - https://github.com/odoo/enterprise/pull/60562
This fix resolves an issue where the Manufacturing Order Overview would crash when viewing orders with backorders in a two-step warehouse setup. The system now properly handles split orders and backorders by improving how it retrieves related purchase and stock information, ensuring a smoother user experience when managing complex manufacturing scenarios.
Original PR description
Steps to reproduce: - Set warehouse to two-steps reception - Create a BoM using a MTO (buy) component - Create a MO for 2 units of that BoM - Produce 1 and create a backorder - Open the Overview Issue: When there is a backorder (or if the MO is splitted), then when browsing the dests through `_rollup_move_dests()`, at some point it will branch into two differents path, related to each backorders. This will raise a traceback, as we only expected a single MO at that point. To avoid this, we made the `_rollup_move_dests()` method batchable, so we can fetch all moves linked to a manufacturing order in a single call, avoiding this issue. Note: For consistency sake, updated the `_rollup_move_origs()` method to be batchable as well, to avoid confusion when using one or the other. opw-3849252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161537
A test has been added to the Point of Sale application to ensure partial refunds of orders work correctly. This protects against regressions in refund functionality and maintains the reliability of the refunding process for retail operations.
Original PR description
This commit adds a test to protect the partial refunding of orders in the point of sale app. This commit is an annex of https://github.com/odoo/odoo/commit/59ffd20113b8d42aa2d7d91511c41804a08e01c6 . opw-3827876 Forward-Port-Of: odoo/odoo#161672 Forward-Port-Of: odoo/odoo#160929
This fix resolves an issue where users couldn't use the optional column feature in the Expense list view. The problem was caused by a code conflict that prevented the system from properly identifying the list view when users tried to customize columns. The fix ensures that custom styling can be applied without breaking the column customization functionality.
Original PR description
Since https://github.com/odoo/odoo/pull/120915 Steps: - Install `web_studio` and `hr_expense` - Open Expense/list view - click on optional column - Traceback The error occurs because the dropdown…
Since https://github.com/odoo/odoo/pull/120915
Steps:
- Install `web_studio` and `hr_expense`
- Open Expense/list view
- click on optional column
- Traceback
The error occurs because the dropdown needs the id of the view list in order to "hook" onto it. This unique id is added via a `t-att-class` here
https://github.com/odoo/odoo/blob/f8ac22e2ad0a8157466b9adeb3dd2746f1f011d9/addons/web/static/src/views/list/list_renderer.xml#L1-L7
and is used by the dropdown here
https://github.com/odoo/odoo/blob/f8ac22e2ad0a8157466b9adeb3dd2746f1f011d9/addons/web/static/src/views/list/list_renderer.xml#L45-L50
The problem here is that the hr_expense module inherits from `web.ListRenderer` to add some classes to `o_list_renderer` with this
```xml
<xpath expr="//div[hasclass('o_list_renderer')]" position="attributes">
<attribute name="t-att-class">'hr_expense h-auto o_forbidden_tooltip_parent'</attribute>
</xpath>
```
but by doing so, the t-att-class of `hr_expense.ListRenderer` overwrites that of `web.ListRenderer`.
One solution was to do as the documents application does
https://github.com/odoo/enterprise/blob/saas-16.3/documents/static/src/views/list/documents_list_renderer.xml#L5
This does not override the `t-att-class`
opw-3858726
Forward-Port-Of: odoo/odoo#161622Fixed a bug where loyalty program discounts were being applied based on total cart amount instead of only counting products that matched the discount's product requirements. Now, when you set a minimum purchase amount for a specific product in a loyalty discount, the system will only count purchases of that product toward meeting the minimum threshold, not the entire cart total.
Original PR description
Product domains were not considered when computing the min amount to reach to get a discount. For example, if you created a discount with a minimum amount of 100 for product "X", the discount would have been applied, even if the amount for "X" was less than 100, as long as the total amount of the SO was at least 100. After this fix, only products that match the domain will be considered when computing the amount that should be compared to the discount's min amount. opw-3626345 Forward-Port-Of: odoo/odoo#161927 Forward-Port-Of: odoo/odoo#155085
This fix resolves an issue where importing XML invoices in a multi-company environment would fail when trying to assign a partner from a different company. The system now correctly filters partners by the invoice's company during import, preventing incompatibility errors and allowing seamless cross-company invoice processing.
Original PR description
Bug: 1. Have at least 2 companies ("A" and "B") 2. Export an xml (Bis 3 for instance) for an invoice with customer "Azure Interior" 3. Set a company on "Azure Interior" (say: A) 4. Import the xml in…
Bug:
1. Have at least 2 companies ("A" and "B")
2. Export an xml (Bis 3 for instance) for an invoice with customer "Azure Interior"
3. Set a company on "Azure Interior" (say: A)
4. Import the xml in multicompany mode, with current company = B The partner "Azure Interior" should be retrieved, but when writing it on the invoice, it will throw a UserError "odoo.exceptions.UserError: Incompatible companies on records: 'Draft Invoice (* 63) (INV/2024/00006)' belongs to company 'B' and 'Partner' (partner_id: 'Azure Interior') belongs to another company."
Cause:
We try to write a partner on an invoice belonging to another company. It only occors when we have several companies selected because there is the global rule `base.res_partner_rule` that will add `('company_id', 'in', company_ids + [False])` to any search domain on the partner (`company_ids` is replaced by `env.companies.ids`, see `_eval_context`).
Fix:
Ensure any search domain contains `env.company.id`, or better: use the `company_id` of the move being created (but both should a priori be equivalent).
opw-3829223
Forward-Port-Of: odoo/odoo#161272
Forward-Port-Of: odoo/odoo#160147This fix corrects how analytic distributions are calculated when transferring accounts. Previously, the system would incorrectly use only the last line's distribution, creating inaccurate analytic balances. Now it properly calculates a proportional distribution across all transferred lines, ensuring accurate financial tracking and reporting.
Original PR description
To reproduce: - Create 2 lines with the same balance but only one has an analytic_distribution (of 100% on an analytic account). - Create a transfer of accounts for these => The counterpart has a distribution of 100% or no distribution. Indeed, we simply put the distribution of the last line. It makes no sense: analytic "balance" is generated and does not reflect the transfer move. We should make a prorata of the distributions of the lines to transfer. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160965
The Greek VAT number format has been corrected to use the proper EL prefix (EL123456783) instead of the incorrect GR prefix. This ensures that Greek company VAT numbers are validated correctly in the system, preventing validation errors for Greek businesses.
Original PR description
According to https://www.easytax.co/en/countries/greece the vat number format for Greece is EL123456783 instead of GR12345670. We also delete the line for country code `el` from `_ref_vat` dict as we use `gr` for Greece. opw-3845662 Forward-Port-Of: odoo/odoo#161278
This update fixes a bug in the accounting system that was causing errors when processing custom taxes. The system now correctly handles tax mapping by focusing only on standard taxes from the core accounting module, preventing crashes when custom taxes don't follow the standard naming format. This resolves upgrade issues for affected customers.
Original PR description
Rewrite the mapping from xmlid to tax to only take into account standard taxes from the 'account' module
Related to blocking upgrade request [upg-1494099](https://upgrade.odoo.com/web#id=1494099&model=upgrade.request)
If there is a custom tax created by the user with a external id that doesn't contain '_', the mapping fails.
Traceback:
```
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 280, in <dictcomp>
xml_id.split('.')[1].split('_', maxsplit=1)[1]: self.env['account.tax'].browse(record)
IndexError: list index out of range
```
Only standard taxes (from `account` module) should be taken into account.
Forward-Port-Of: odoo/odoo#161877Fixed a bug where the powerbox menu (used in the Notes app) would continuously grow in size when navigating with arrow keys in right-to-left languages like Arabic. The fix ensures the powerbox displays at its correct size immediately by properly calculating its width before positioning, improving the user experience when using the editor in RTL languages.
Original PR description
Issue: ====== The powerbox keep increasing in size when you input. Steps to reproduce the issue: ============================= - Install arabic - Go to notes - write `/`, you can see the powerbox is…
Issue: ====== The powerbox keep increasing in size when you input. Steps to reproduce the issue: ============================= - Install arabic - Go to notes - write `/`, you can see the powerbox is a bit smal - use `down/up`arrows to navigate in the powerbox. - The powerbox width increase until finally gets to it's intended position. Origin of the issue: ==================== Since we are providing that `marginRigh` should be equals to `20` in `getRangePosition` we will move the powerbox to the left a bit and then with the style property `max-width=100%` it will increase in size because the current size is a bit small for it. So at every key pressed it will increase by 20px until it gets to a point where everything is set and the `marginRight=20` is finally visible. Soltuion: ========= We set min-width as max-content so we can position correctly the powerbox knowing it's final width. task-3721794 Forward-Port-Of: odoo/odoo#161089 Forward-Port-Of: odoo/odoo#157668