Daily updates from Odoo
Navigate
Branch
Tuesday, March 7, 2023
33 changes
New functionality added to Odoo
Adds Dutch payroll localization so companies in the Netherlands can configure payroll structures, salary rules, contracts, payslips, reports, and accounting links in Odoo. This helps Dutch employers run payroll with localized rules and reporting, while also protecting an existing French payroll category setting from unwanted renaming.
A new preparation display module lets restaurant teams send point-of-sale orders to a dedicated bar or kitchen screen. This helps staff track and prepare orders more efficiently, improving coordination between front-of-house and preparation areas.
Original PR description
*:pos_preparation_display This module is dependent on `pos_restaurant` and `point_of_sale` modules. Adding the `pos_preparation_display` module. This allows `pos_restaurant` users to send orders to a preparation screen in a bar or kitchen. Overrides on the following modules have been done: - `pos_restaurant` - `point_of_sale` **TaskId: 3046045** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This updates internal performance test expectations for enterprise email activities after related improvements in message composition, attachments, and search handling. It helps keep automated checks aligned with current behavior so future performance issues can be detected reliably.
Original PR description
Followup (notably) of odoo/odoo#107356 (composer, template, attachments management cleaning) and odoo/odoo#112126 (core search/read cleaning and performance improvements).
Project users can now use quick-create shortcuts more smoothly when adding tasks from kanban views. This improves task entry consistency across Project and Field Service, helping teams create work items with less friction.
Original PR description
**[IMP] project: add task quick create shortcuts** In this commit, We did the needed changes related to replacing name field in project.task quick create kanban box by display_name field, more details about the changes in the related Community PR. Related Prs: - Community: https://github.com/odoo/odoo/pull/112821 task-3145203
Belgian payroll now warns users when the company car linked to an employee contract does not match the one used on the payslip. This helps payroll teams spot inconsistencies earlier and avoid incorrect benefit calculations or payroll records.
Original PR description
also adds fix for _compute_car_id method https://www.odoo.com/web#id=3184804&menu_id=4720&cids=1&action=333&active_id=1251&model=project.task&view_type=form
The Argentina electronic invoicing module was simplified by relying on an existing database safeguard instead of an extra locking option. This reduces internal complexity while preserving protections around invoice numbering and compliance processes.
Original PR description
No need for the lock parameter anymore since it is now locked by a SQL constraint
The non-resident employee setting is now managed in the main Payroll app instead of being duplicated in Belgian and Lithuanian payroll. This makes payroll localization easier to maintain and helps ensure consistent employee data across countries.
Original PR description
Purpose ======= This field is commonly used in different localisations. Move this field into hr_payroll before having duplicates for all countries. TaskID: 3082471
This update aligns SEPA credit transfer handling with a change that automatically uses the partner name as the bank account holder name by default. It helps keep payment validation tests consistent with stronger safeguards against payment scams.
Original PR description
With the change on res.partner.bank taking the partner_name as a default value for acc_holder_name, a test in sepa credit transfer need to be adapted. Task id # 3210415
Account reconciliation can now process many matching entries together instead of one pair at a time. This significantly reduces waiting time for large payment or invoice reconciliation batches, improving productivity for accounting teams.
Original PR description
Allow to perform multiple reconciliation at once in order to: - ...batch the creation of records as much as possible. Creating an account.partial.reconcile force the orm to search for amls in order…
Allow to perform multiple reconciliation at once in order to: - ...batch the creation of records as much as possible. Creating an account.partial.reconcile force the orm to search for amls in order to invalidate the reconciliation fields like amount_residual/amount_residual_currency. - ...reduce the number of flush inside the orm and batch the compute. Each call to reconcile is looking for the payment's state of invoices before/after the reconciliation. This step is costly because this will flush all the reconciliation data and then call the computes to get the fresh value of payment_state. - ...modify more easily the way the lines are matched together. Before this commit, the lines were split into two batches sorted by some criteria including the currency: debit and credit. Then, we were matching them together sequentially. Now, we make the same things except we do that first for each batch of amls sharing the same currency in order to reduce the number of cross-currencies reconciliation. - ...allow the orm to prefetch all the partials in the reconciliation chain all at once. The full reconcile needs to be creating on the full reconciliation graph starting on the current amls so we need to travel the matched_debit_ids/matched_credit_ids in order to find all the involved amls. Fetching all this data at once is also reducing the number of queries made by the orm. Let's take an example: Suppose 10 amls: a1, a2, ..., a10 Suppose 10 amls: b1, b2, ..., b10 You want to reconcile respectively a1 with b1, ... , a10 with b10. Before this commit, each reconciliation was done as follow: - Check the payment_state of invoice (on 2 amls) - Create a partial reconcile (single record) - Create a full reconcile (single record) - Compute the reconciliation data to compute payment_state (on 2 amls) All of that, 10 times sequentially. With the new '_reconcile_plan' method, we are able to give a list of recordset [a1 + b1, ..., a10 + b10]: - Check the payment_state of invoice (on 20 amls) - Create a partial reconcile (10 records) - Create a full reconcile (10 records) - Compute the reconciliation data to compute payment_state (on 20 amls) For a reconciliation using 2000 records (a1, ..., a1000 & b1, ..., b1000), the time to reconcile it was about +-34 seconds. Now, it's about +- 3 seconds.
Invoice PDFs now only show the origin column when at least one invoice line uses it. This keeps invoice documents cleaner and avoids showing an empty column to customers or staff.
Original PR description
The origin column in the invoice pdf report is always shown, even when not used in any line. This will ensure that it is only there when at least one line is using it. Task id #3184476
The 1099 configuration now requires a name before a box record can be saved. This prevents blank setup records, helping keep tax reporting data cleaner and easier to manage.
Original PR description
before this commit, the name field is not required in the model level/view level and empty records can be created in this table without filling any data. after this commit, the name field will be required at the model level and without filling the name (the single field in the model), records cannot be created.
Appraisal feedback templates can now be translated, helping companies tailor employee review content for different languages and cultures. The templates also benefit from updated editor capabilities, making them easier to manage and present.
Original PR description
Make the feedback templates translatable to adapt to multi-cultural companies. Make use of new fancy stuff in the web editor. task-3060715
This update makes online bank synchronization easier to find and use by moving the main experience into the accounting dashboard. It also reorganizes supporting screens and background reminders so the feature is cleaner to maintain and more straightforward for accounting users.
Original PR description
WIP
Manufacturing teams can now see work center occupancy directly in the Gantt view and find work orders more easily by typing searches from the work order screen. Planning settings such as manufacturing lead time and preparation days are managed at the bill of materials level, helping teams plan production more accurately by product configuration.
Mongolian accounting report labels are now managed in English first, with Mongolian provided through the translation files. This improves consistency with Odoo localization practices and makes future translation maintenance easier.
Original PR description
Before this PR, all this localisation was written in Mongolian, but all the localisation have to be written in english and then translated back in the native language. This PR correct that. task-id: 3166094
Resolved issues and error corrections
A payroll-related employee screen had an invalid setting that could affect how a field is displayed. This fix removes that faulty configuration, helping the payroll interface behave more reliably for users.
The salary simulation link wizard now calculates final yearly costs automatically when a contract is selected, without requiring users to reset the contract first. Users can still manually adjust the value when needed, reducing confusion and ensuring more reliable salary simulations.
Original PR description
In the generate_simulation_link wizard, the final_yearly_costs field was computed through an onchange on contract_id. However, this did not seem to be trigger without manually resetting contract_id. With this change this field is converted into a computed field (which doesn't have this issue) that is non-read-only, so it can be manually overridden. task-3177146
Fixed an issue where permissions could be incorrectly inherited when sharing Knowledge articles based on untitled pages. This prevents parent or child article access rights from changing unexpectedly when a member's permission is updated.
Original PR description
This commit fixes a bug where if an article is Untitled, when you invite partners to the article, all the permission inheritance is badly computed and when modifying the permission for a member there…
This commit fixes a bug where if an article is Untitled, when you invite partners to the article, all the permission inheritance is badly computed and when modifying the permission for a member there is inconsistencies.
Before when modifying the permission for a member the modification could be propagated to the parent of the article and none of the child articles would have its permissions set as inherited.
Which results in inconsistencies with the original behavior.
Now when you have an article that is based on an Untitled article we correctly set for the member the correct value for the inheritance.
Steps to Reproduce on a Runbot
-----------------------------------------------
* Create a tree with a depth of minimum 3
* Invite Demo as a reader on the Root
* Change the permission for Demo on one of the children to Write or None
* You will see that the parent of the article you modified will have a
different permission than before (which shouldn't happen).
task-3220909This update fixes an occasional automated test failure in the Gantt view caused by random sample data. It helps keep quality checks reliable without changing the product experience for users.
Original PR description
The test "position of no content help in sample mode" did wrongly assume that the first row is always associated with the user_id 1. But this might not be the case. Actually the rows in that tests are constructed in the following way: - In _populateModels, the sample server creates a given number of records each with a random value between 1 and 5 for the field user_id. - in _mockReadGroup, the records with same ids are gathered to construct the groups that will be returned. - in _generateRows, the gantt model generates its rows on the basis of the groups it has received from read_group (mocked via _mockReadGroup). One sees that if no records is associated with user_id 1 in the first step (that happens rarely), no row has 1 as associated resId. This was the root cause for the test failing: all the rows had the class o_sample_data_disabled in that situation. Actually, that situation had probability (4/5)^16 ~ 0.028 to occur. Fixes runbot issue 17818
A spreadsheet revision list view was moved to the module that owns the related spreadsheet revision data. This helps keep the spreadsheet feature correctly organized and reduces the risk of errors when using or installing related apps.
Original PR description
…rrect module Before this revision, the view for the list of spreadsheet.revision was in the documents_spreadsheet module. However, the model is defined in the spreadsheet_edition module since 2cd6bd81051bb064a5f7d5f8d08bfdee4afce76d Task-id 3199033
Code cleanup and technical improvements
Events that coordinate data changes now stay tied to the specific model instance that created them, instead of being broadcast more broadly. This prevents separate views or record components from accidentally reacting to each other's save or field-change signals, improving reliability when users work with multiple views at once.
Original PR description
In the model, we trigger events RELATIONAL_MODEL:NEED_LOCAL_CHANGES and RELATIONAL_MODEL:WILL_SAVE_URGENTLY on env.bus. That means that if we have two instances of the model in // (e.g. two views, or two Record components, or a mix...), their fields would listen and react to events triggered for another model. Trigger those events on the model instead, as it is an EventBus. Part of task: 3179751
This update streamlines how field values are read inside several Odoo apps, making the underlying interface simpler and more consistent. The change is internal and should help future maintenance without introducing visible changes for business users.
Original PR description
This commit, is part of a series of commits that aim to simplifie the concrete fields API. In this commit we will remove value prop from concrete fields. Now each field will directly use this.props.record.data[this.props.name] to access their value, As a consequence of this, the name props need to be mandatory. task-id 3179751
Miscellaneous changes
Deposits and Payments filters are inverted in reconciiliation widget. Steps: - Open reconciliation widget - Filter to show Deposits -> Payments are displayed - Filter to show Payments -> Deposits are displayed opw-3189681 Forward-Port-Of: odoo/enterprise#37856
Original PR description
Deposits and Payments filters are inverted in reconciiliation widget. Steps: - Open reconciliation widget - Filter to show Deposits -> Payments are displayed - Filter to show Payments -> Deposits are displayed opw-3189681 Forward-Port-Of: odoo/enterprise#37856
Before v16, only the updated values were being given to the `write` method of the pos_config. In v16, the pos_config settings have been moved to the general settings which then keep calling the pos_config `write` method with all existing values. Thus it tries to send a request to the create a new TSS which is a wrong behavior. Forward-Port-Of: odoo/enterprise#37820
Original PR description
Before v16, only the updated values were being given to the `write` method of the pos_config. In v16, the pos_config settings have been moved to the general settings which then keep calling the pos_config `write` method with all existing values. Thus it tries to send a request to the create a new TSS which is a wrong behavior. Forward-Port-Of: odoo/enterprise#37820
Some report are unusable by the billing group but are visible by it in the menu. With this change, we will hide them if possible to avoid the frustration of clicking for nothing. Task id #3168634 Forward-Port-Of: odoo/enterprise#37283
Original PR description
Some report are unusable by the billing group but are visible by it in the menu. With this change, we will hide them if possible to avoid the frustration of clicking for nothing. Task id #3168634 Forward-Port-Of: odoo/enterprise#37283
### Steps to reproduce * create an asset and confirm it * sell that asset using an invoice that has a currency different from the company currency You should see that the newly created journal entry does not take that currency difference into account. opw-3055810 Forward-Port-Of: odoo/enterprise#37010 Forward-Port-Of: odoo/enterprise#36885
Original PR description
### Steps to reproduce * create an asset and confirm it * sell that asset using an invoice that has a currency different from the company currency You should see that the newly created journal entry does not take that currency difference into account. opw-3055810 Forward-Port-Of: odoo/enterprise#37010 Forward-Port-Of: odoo/enterprise#36885
Before this commit, the domain of form_account_id having a "or" operand that shouldn't be there. This fix removes it. Forward-Port-Of: odoo/enterprise#37623
Original PR description
Before this commit, the domain of form_account_id having a "or" operand that shouldn't be there. This fix removes it. Forward-Port-Of: odoo/enterprise#37623
Instead of having one shared payroll folder between companies, create a specific one for each company, so that a payroll officer from a given company cannot access to PDF reports of another one. TaskID: 3211684 Forward-Port-Of: odoo/enterprise#37819 Forward-Port-Of: odoo/enterprise#37664
Original PR description
Instead of having one shared payroll folder between companies, create a specific one for each company, so that a payroll officer from a given company cannot access to PDF reports of another one. TaskID: 3211684 Forward-Port-Of: odoo/enterprise#37819 Forward-Port-Of: odoo/enterprise#37664
The date parser introduced with commit 9e677ea115c1494d029513428e3919f54d24b27f does not allow parsing of some local dates (for example: 'févr.'). A solution is to change the language in the context with the code `en_US`. (we are sure that this language is installed because it is the default). Moreover, the language of the date format is not important in this case, because it will be converted into a `datetime` object. opw-3182713 Forward-Port-Of: odoo/enterprise#37708
Original PR description
The date parser introduced with commit 9e677ea115c1494d029513428e3919f54d24b27f does not allow parsing of some local dates (for example: 'févr.'). A solution is to change the language in the context with the code `en_US`. (we are sure that this language is installed because it is the default). Moreover, the language of the date format is not important in this case, because it will be converted into a `datetime` object. opw-3182713 Forward-Port-Of: odoo/enterprise#37708
The `boolean_confirm` toggle was no longer updating the state of the field, thus it was no longer possible to set the employee's feedback visible to the manager. task-3217622 Forward-Port-Of: odoo/enterprise#37798
Original PR description
The `boolean_confirm` toggle was no longer updating the state of the field, thus it was no longer possible to set the employee's feedback visible to the manager. task-3217622 Forward-Port-Of: odoo/enterprise#37798
When the duration of the product becomes Zero the server throws the Zero Division Error, the product rental duration cannot be zero as anything divide by zero is infinite.  Ex. In the 'sale.temporal.recurrence' we can improve the duration is setting as zero or greater than zero in daily field. sentry-3932724540 Forward-Port-Of: odoo/enterprise#37507
Original PR description
When the duration of the product becomes Zero the server throws the Zero Division Error, the product rental duration cannot be zero as anything divide by zero is infinite.  Ex. In the 'sale.temporal.recurrence' we can improve the duration is setting as zero or greater than zero in daily field. sentry-3932724540 Forward-Port-Of: odoo/enterprise#37507
# Steps to reproduce - set up a database in such a way that a partner `P` has more than 80 posted invoices/bills - go to the Partner Ledger and export it (to either PDF or XLSX) You should see that not all lines of `P` are exported (there's a 'load more' line). opw-3175010 opw-3168697 Forward-Port-Of: odoo/enterprise#37552
Original PR description
# Steps to reproduce - set up a database in such a way that a partner `P` has more than 80 posted invoices/bills - go to the Partner Ledger and export it (to either PDF or XLSX) You should see that not all lines of `P` are exported (there's a 'load more' line). opw-3175010 opw-3168697 Forward-Port-Of: odoo/enterprise#37552
Now the record is auto saved so we don't need to manually save the record. Forward-Port-Of: odoo/enterprise#37786
Original PR description
Now the record is auto saved so we don't need to manually save the record. Forward-Port-Of: odoo/enterprise#37786