Monday, May 27, 2024
31 changes · master
New functionality added to Odoo
This adds payroll localization for Turkey, including salary structures, payroll rules, and accounting setup. It helps businesses in Turkey run payroll more accurately in Odoo and align payroll accounting with local requirements.
Original PR description
Turkey payroll localization - [Ticket#: 3689866](https://www.odoo.com/odoo/4996/tasks/3689866?cids=14)
Australian payroll users can now register payments for an entire payslip batch instead of processing each payslip one by one. The change creates a batch payment record that supports ABA bank file generation, reducing manual work while keeping the existing single-payslip payment flow.
Original PR description
Currently, `action_register_payment` and the `account.payment.register` wizard depends on the payslip in the context to only register payment for one payslip. This restricts any way of registering payment for a batch of payslips. This PR extends the `hr_payroll_account` module to allow multiple payslips to be registered as a batch. However, it maintains the current flow for single payslip payment. This adds a register payment feature to the payslip batch that generates individual payments on payslips and returns a record of `account.payment.batch` with all the payments. This also simplifies the ABA file generation and moves it entirely to `account.payment.batch` instead of `payslip.run` task #3855817
Enhancements to existing features
Project task screens now provide embedded shortcuts to related Documents and Planning actions, making it easier for users to access supporting project information without leaving their workflow. The update also streamlines project view controls and adjusts related performance test expectations.
Resolved issues and error corrections
This change removes a temporary placeholder and switches Mexican e-invoicing screens to use the shared document status display already available in accounting. It reduces duplicate code and helps keep invoice, payment, POS order, and stock picking views consistent without changing the business workflow.
Original PR description
In a7adb61e41ef17459eb95d9252cd53db37ebe0b2, the document_state component was removed from l10n_mx_edi to be put in account. We had to keep an "empty shell" component in l10n_mx_edi to avoid having to modify the l10n_mx_edi views in stable. But in master, we can remove this "empty shell" and use the generic component from account.
Code cleanup and technical improvements
This draft refactors click interactions across automated tours and tests for accounting, reporting, approvals, documents, and spreadsheet workflows. It is marked as aborted and points to a replacement pull request, so there is no direct business-facing change expected from this draft.
Original PR description
Aborted => refer to https://github.com/odoo/enterprise/pull/63176
Miscellaneous changes
The number of months worked in the previous year was not including previous occupations. Thus, the commissions were not added as the number of months was 0. Forward-Port-Of: odoo/enterprise#63188
Original PR description
The number of months worked in the previous year was not including previous occupations. Thus, the commissions were not added as the number of months was 0. Forward-Port-Of: odoo/enterprise#63188
The invoice attachment viewer now works correctly when opened in a separate tab or window. This ensures visual extraction markers are placed in the right place, improving usability for accounting workflows.
Original PR description
The attachment viewer can now be popped out in another tab/window. We are now targetting the right window to add the boxes where needed. [task-3932781](https://www.odoo.com/web#id=3932781&model=project.task)
The Sign app onboarding has been improved to help users start creating templates more easily. Users can now drag and drop files, while clearer guidance and small usability refinements make the setup flow smoother and more satisfying.
Original PR description
The onboarding process for the sign app has been upgraded to make it easier to use and improve customer satisfaction. This PR allows users to upload templates with ease by simply dragging and dropping files. Additionally, the action helper has been updated to provide a more intuitive and seamless experience. The overall usability has been improved by fine-tuning menu sequences and other minor improvements. task-3764704 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
Report export and filing wizards now use a shared error display that makes blocking issues easier to understand and act on. This improves consistency across accounting, SAF-T, Intrastat, and local reporting flows while keeping important errors sorted reliably for users.
Original PR description
`file_generation_error` has been superseded by `ActionableErrors` in `account` which is more generic. SAF-T and other wizards relying on the `critical` attribute need sorting. jsonb fields don't retain order in PostgreSQL, so we re-sort the actionable_errors field by critical and then by error key. Community PR: [odoo/odoo#159251](https://github.com/odoo/odoo/pull/159251) Upgrade PR: [odoo/upgrade#5917](https://www.github.com/odoo/upgrade/pull/5917) Task link: [odoo/task#3698183](https://www.odoo.com/web#model=project.task&id=3698183) task-3698183
Odoo now supports printing complete US checks in-house instead of requiring pre-printed Checkdepot stationery. Businesses can choose top, middle, or bottom check layouts that automatically include company and payment details, giving them more flexibility and control over check printing.
Original PR description
For the United States, Odoo currently offers the option to print checks using a "pre-printed" format that matches a specific supplier (Checkdepot). We don't cover the use case where checks are printed in-house without a pre-populated page with some static information. Also, if a company would like to change or edit some information from the pre-filled checks, it is impossible. We want to offer users the option to print "blank checks" by having a prepopulated template in Odoo that will adjust to the company's information. This commit adds 3 additional check layout to print: - print_blank_check_top - print_blank_check_middle - print_blank_check_bottom Where each of them are designed meticulously to position the required fields in blank checks, according to Checkdepot's layout. task-id: 3719584
The inventory onboarding flow for barcode operations has been updated to better match the latest business-to-business onboarding specification. This should make it easier for users to get started with inventory barcode workflows and understand the next steps during setup.
Original PR description
Task: 3647839
The subscription sales order logging code has been simplified to make it easier to maintain. This is an internal improvement that should reduce complexity and help future updates without changing day-to-day user workflows.
Original PR description
Simplify sale order log code
The website event social feature has been updated to use standard browser technology instead of an older dependency. This helps keep the platform easier to maintain and supports Odoo's broader effort to reduce reliance on legacy frontend libraries.
Original PR description
This PR aims to refactoring all jQuery code into Vanilla JS in website_event_social, this way we will reduce the dependency of jQuery in Odoo codebase. task-3770362
This update removes outdated scheduling options from many automated background tasks across accounting, payroll, HR, helpdesk, data cleaning, and related services. It keeps scheduled jobs aligned with the latest platform behavior, reducing maintenance risk without changing day-to-day user workflows.
Accountant users can now request and enter OTP codes for GSTR API verification without needing broader settings permissions. This reduces delays in GST return workflows and lets finance teams complete required verification steps with the access they already have.
Original PR description
Before this PR, users with accountant access rights lacking setting permissions could not send and enter OTP for GSTR verification. With this enhancement, users with accountant access rights can now successfully send and input OTP codes, streamlining the verification process. Task ID: 3895351
The website_sale_ups module is being updated to replace older page scripting with modern browser-based code. This reduces reliance on an external library, helping keep the online sales experience easier to maintain without changing the customer-facing workflow.
Original PR description
This PR aim to convert all jQuery code into Vanilla JS in website_sale_ups, this way we will reduce the dependency of jQuery in Odoo codebase. task-3770362
A Planning test scenario now correctly handles cases when the current day is the first day of the week. This prevents false test failures and helps keep Planning updates more reliable.
Original PR description
Before this commit, the tour planning_split_shift_week would crash when the current day is the beginning of the current week. This happened because when today is the first day of the week, the selector used in the step "Select first day of the current week" would be the start of the previous week. Thus the final date range produced, would contain two weeks instead of one, making the tour timeout (waitUntil condition not met).
The spreadsheet pivot side panel now correctly shows the minimum calculation option. This helps users choose the right summary method when analyzing document spreadsheet data.
Original PR description
`min` aggregator was missing in the list of available aggregators in the pivot side panel. This commit adds it. Task: 3942858
This change reverts the addition of deferred start and end dates on invoice PDF reports. The dates were being shown for all customers, which was not intended, so the report is restored while a better approach is assessed.
Original PR description
In this commit https://github.com/odoo/enterprise/commit/84e0edcfc88c3361e1e042e80c82f6c4b950c738, we added the deferred_start_date and end_date in the pdf. This change is applied for everyone and it shouldn't be. A next task will be created to assess this problem but in the meantime we will revert the commit no task-id
Dashboard administrators can now insert items such as pivot views into spreadsheet dashboards without needing full system administrator rights. This restores the expected dashboard editing permissions for users in the Dashboard Admin group, especially when Documents is not installed.
Original PR description
[FIX] spreadsheet_dashboard_edition: allow to insert in dashboard Steps to reproduce: - install CRM (make sure Documents is not installed) - login with a user with "Dashboard Admin" group (but not system admin) - go to CRM and try inserting a pivot view in a spreadsheet => you can't Since odoo/odoo@0c50cbe18ce3f1 a new user group was created allowing to create and edit spreadsheet dashboards. However, members of that group are not able to insert anything because the group was not updated in the registry. Task: 3795574
This refactoring prepares Odoo's automated web tours to use clearer, more consistent test steps. It reduces ambiguity in internal test behavior and helps future maintenance without changing end-user features.
Original PR description
Currently, in tour_compiler, to check that an element is actually present in the DOM in a step, there are 2 possibilities. - `isCheck: true` => Checks that the element is in the DOM. The latter can…
Currently, in tour_compiler, to check that an element is actually
present in the DOM in a step, there are 2 possibilities.
- `isCheck: true` => Checks that the element is in the DOM.
The latter can be disabled.
- `run() {}` => Checks that the element is in the DOM (because this
is what is done by default). However, if the element is disabled,
the step will be aborted.
In the codebase, we can see a lot of `run() {} //it's a check` and
`isCheck:true`. However, the behavior is not exactly the same.
What's more, there are 2 ways to do "the same thing".
In order to clarify the turns API, it was decided to no longer put an
action (step.run) by default. (Previously, the default action was
the "click" action).
From then on, it is no longer necessary to stipulate
`step.isCheck: true` nor `run() {}`.
The corollary is that now, you must explicitly write `run: click`, if
you want the click action to be triggered on the target.
This commit sets the stage for making this change.This change standardizes how self-ordering POS modules share related order data with the frontend. It supports reuse of the same frontend model structure across POS self-order, preparation display, IoT, and online payment flows, reducing future maintenance work with minimal direct user impact.
Original PR description
*:pos_online_payment_self_order_preparation_display, pos_self_order_iot, pos_self_order_preparation_display Like in `point_of_sale` we introduce related_models in `pos_self_order` to handle relation between models in the frontend. This will allow to use the same frontend models in all pos related models. Related: https://github.com/odoo/odoo/pull/164793
Adapt tests to community change See also: - https://github.com/odoo/odoo/pull/166609 Forward-Port-Of: odoo/enterprise#63191
Original PR description
Adapt tests to community change See also: - https://github.com/odoo/odoo/pull/166609 Forward-Port-Of: odoo/enterprise#63191
Steps to reproduce: ------------------- - create a product: - service - based on timesheet - create on order: project & task - create a sale order with this product - confirm the sale order - go on the created task - add timesheets with an employee - go to timesheet - validate created timesheets - go to the project settings - in invoicing tab, change de sale order item for the employee Issue: ------ The sale order item linked to the validated timesheets are mo
Original PR description
Steps to reproduce:
-------------------
- create a product:
- service
- based on timesheet
- create on order: project & task
- create a sale order with this product
- confirm the sale order
- go on the created task
- add timesheets with an employee
- go to timesheet
- validate created timesheets
- go to the project settings
- in invoicing tab, change de sale order item for the employee
Issue:
------
The sale order item linked to the validated timesheets are modified.
This behaviour causes negative side effects.
A validated timesheet should no longer be modified, but the backend logic does, which is not consistent.
Solution:
---------
Make the condition that filters timesheets to update take account of whether the timesheet is validated or not.
opw-3791062
Forward-Port-Of: odoo/enterprise#63163
Forward-Port-Of: odoo/enterprise#61122The tour is failing rarely and undeterministically. It seems like the reason is because 2 steps from the tour are done before a request is done (and so the number of the call to the function). We add a step to enforce that the request is made before the next step of the tour. We also enforce that we don't do the last action before closing the tour. In ulterior versions, the tour can be stuck when adding a product. Our guess is that the button is clicked before the page is fully loaded.
Original PR description
The tour is failing rarely and undeterministically. It seems like the reason is because 2 steps from the tour are done before a request is done (and so the number of the call to the function). We add a step to enforce that the request is made before the next step of the tour. We also enforce that we don't do the last action before closing the tour. In ulterior versions, the tour can be stuck when adding a product. Our guess is that the button is clicked before the page is fully loaded. The tour would then consider it did click the button, while the action didn't happen. We add a check to wait for the page to be fully loaded before clicking. Linked to runbot error 61458, 63532, 59031 (and happened before already). Forward-Port-Of: odoo/enterprise#63019 Forward-Port-Of: odoo/enterprise#61964
The payment acquirer must always be linked to a single journal, one per company. It's currently an hard constraint So after the duplication, both are always linked to the same journal but only one appear on it. This "fix" is improving that allowing the duplication of an existing acquirer and to be able to link them to diffe opw-3704407 Forward-Port-Of: odoo/enterprise#62989 Forward-Port-Of: odoo/enterprise#62744
Original PR description
The payment acquirer must always be linked to a single journal, one per company. It's currently an hard constraint So after the duplication, both are always linked to the same journal but only one appear on it. This "fix" is improving that allowing the duplication of an existing acquirer and to be able to link them to diffe opw-3704407 Forward-Port-Of: odoo/enterprise#62989 Forward-Port-Of: odoo/enterprise#62744
__Current behavior before commit:__ When there is an incoming call, a VoIP provider may give a session description containing an audio sender and a video sender even if the video track is empty. In such case, `track` may be `null`. Therefore the page will crash when we try to set `track.enabled`. __Description of the fix:__ Check if each track is not `null` before setting its `enabled` property. opw-3833811 Forward-Port-Of: odoo/enterprise#62980
Original PR description
__Current behavior before commit:__ When there is an incoming call, a VoIP provider may give a session description containing an audio sender and a video sender even if the video track is empty. In such case, `track` may be `null`. Therefore the page will crash when we try to set `track.enabled`. __Description of the fix:__ Check if each track is not `null` before setting its `enabled` property. opw-3833811 Forward-Port-Of: odoo/enterprise#62980
**Before this PR:** Table 14(a) in the GSTR-1 report was calculating incorrect entries. **After this PR:** Table 14(a) in the GSTR-1 now calculates correct entries. **Technical Reason:** Previously, the calculations were based on incorrect tax_tag_ids and subformula. Now, the calculations are made with the correct tax_tag_ids and subformula, and cess has also been added. **task**-3904018 Forward-Port-Of: odoo/enterprise#62829
Original PR description
**Before this PR:** Table 14(a) in the GSTR-1 report was calculating incorrect entries. **After this PR:** Table 14(a) in the GSTR-1 now calculates correct entries. **Technical Reason:** Previously, the calculations were based on incorrect tax_tag_ids and subformula. Now, the calculations are made with the correct tax_tag_ids and subformula, and cess has also been added. **task**-3904018 Forward-Port-Of: odoo/enterprise#62829
Steps to reproduce: 1. In the contact page for a Mexican-based contact, add a default usage 2. Start a new session in point of sale 3. Select the client with a default usage, add go to payment 4. Select invoice. The usage field shows 'Acquisition of merchandise', despit the default usage selected before Currently, the popup only takes into account the l10n_mx_edi_usage selected in the POS session or the code 'Acquisition of merchandise' if the field is undefined. The same behaviour hap
Original PR description
Steps to reproduce: 1. In the contact page for a Mexican-based contact, add a default usage 2. Start a new session in point of sale 3. Select the client with a default usage, add go to payment 4. Select invoice. The usage field shows 'Acquisition of merchandise', despit the default usage selected before Currently, the popup only takes into account the l10n_mx_edi_usage selected in the POS session or the code 'Acquisition of merchandise' if the field is undefined. The same behaviour happens if an invoice is created for a previous order. This commit adds l10n_mx_edi_usage to the partner fields to be loaded when loading the pos data. Then, the field in the popup can be filled with the default CDFI usage of the partner if it exists. Else, it behaves as before, displaying either the usage code selected in the POS session or code 'Acquisition of merchandise' if the field is undefined. task-3865331 Forward-Port-Of: odoo/enterprise#63022 Forward-Port-Of: odoo/enterprise#62261
To reproduce: Create an asset. Reevaluate, with an increase, last month. => the move of Value Increase has today's date. We decided to instead put the acquisition date of the child asset. (so it won't be the same in 16.0) opw-3922067 Forward-Port-Of: odoo/enterprise#63115 Forward-Port-Of: odoo/enterprise#63097
Original PR description
To reproduce: Create an asset. Reevaluate, with an increase, last month. => the move of Value Increase has today's date. We decided to instead put the acquisition date of the child asset. (so it won't be the same in 16.0) opw-3922067 Forward-Port-Of: odoo/enterprise#63115 Forward-Port-Of: odoo/enterprise#63097
TaskID: 3942303 Forward-Port-Of: odoo/enterprise#62956
Original PR description
TaskID: 3942303 Forward-Port-Of: odoo/enterprise#62956