Monday, May 27, 2024
21 changes · master
Enhancements to existing features
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
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
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
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.
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
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