Friday, May 30, 2025
13 changes · master
Enhancements to existing features
Studio exports now exclude inactive records, so exported data better reflects what users actively work with. This reduces clutter and helps teams avoid sharing or importing outdated inactive entries.
Original PR description
**Purpose:** - Exported data from the studio includes inactive records. **Specifications:** - Only active records should be exported. task-4285741
Miscellaneous changes
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice Lines: [a line with an amount higher than 10000 and a tax] - Confirm the bill - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "VAT Control Statement (CZ)" as Report - Select a period covering the bill date The bill should appear in the report under "B.2. R
Original PR description
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice…
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice Lines: [a line with an amount higher than 10000 and a tax] - Confirm the bill - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "VAT Control Statement (CZ)" as Report - Select a period covering the bill date The bill should appear in the report under "B.2. Received taxable supplies and provided payments above CZK 10,000" section. **Issue:** The "Tax document registration number" (i.e. "c_evid_dd" in the exported XML) value for the bill is the name of the bill. According to the documentation: https://financnisprava.gov.cz/en/taxes/VAT-Control-Statement https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 For purchase-type documents, this field should have the bill reference as value. It should identify the original reference coming from the vendor. If there is no bill reference, the field should be empty. opw-4737630 Forward-Port-Of: odoo/enterprise#85005
**Steps to reproduce:** - Install Planning app - Set the type of view to Gantt - (Create a shift if there is none) - Click on `Publish` button - The period end date doesn't take the last day into account (time is 00:00) **Issue:** Gantt model default `_buildMetaData` computation behavior was changed multiple times during previous refactoring: Previously used: ``` export function computeRange(scale, date) { let start = date; let end = date; if (scale === "week") {
Original PR description
**Steps to reproduce:** - Install Planning app - Set the type of view to Gantt - (Create a shift if there is none) - Click on `Publish` button - The period end date doesn't take the last day into…
**Steps to reproduce:**
- Install Planning app
- Set the type of view to Gantt
- (Create a shift if there is none)
- Click on `Publish` button
- The period end date doesn't take the last day into account (time is 00:00)
**Issue:**
Gantt model default `_buildMetaData` computation behavior was changed multiple times during previous refactoring:
Previously used:
```
export function computeRange(scale, date) {
let start = date;
let end = date;
if (scale === "week") {
// startOf("week") does not depend on locale and will always give the
// "Monday" of the week... (ISO standard)
const { weekStart } = localization;
const weekday = start.weekday < weekStart ? weekStart - 7 : weekStart;
start = start.set({ weekday }).startOf("day");
end = start.plus({ weeks: 1, days: -1 }).endOf("day");
} else {
start = start.startOf(scale);
end = end.endOf(scale);
}
return { start, end };
}
```
Which became:
```
export function getRangeFromDate(rangeId, date) {
const startDate = localStartOf(date, rangeId);
const stopDate = startDate.plus({ [rangeId]: 1 }).minus({ day: 1 });
return { focusDate: date, startDate, stopDate, rangeId };
}
```
**Fix:**
Added `localStartOf` function in the context setup of PlanningGanttModel.
To avoid overwriting current changes for other modules (which could be intended), this was done instead of :
```
export function getRangeFromDate(rangeId, date) {
const startDate = localStartOf(date, rangeId);
const stopDate = localEndOf(startDate, rangeId);
return { focusDate: date, startDate, stopDate, rangeId };
}
```
related commits:
https://github.com/odoo/enterprise/commit/d18639785e622d97102227103d62ddb3a2716be6 https://github.com/odoo/enterprise/commit/c175a848369057cc69596737dcd9d21dd24c9d5c
opw-4580458
Forward-Port-Of: odoo/enterprise#86437
Forward-Port-Of: odoo/enterprise#85608pos_self_* = pos_self_order_preparation_display Before this commit, orders made on the kiosk were no longer sent to the preparation display. This commit restores the expected behavior by ensuring that kiosk orders are correctly sent to the preparation display. Step to reproduce: - Install pos_restaurant. - Enable Kiosk as self-ordering mode - Configure a preparation display for the kiosk configuration. - Place an order and proceed to the confirmation page. - The order is not sent to
Original PR description
pos_self_* = pos_self_order_preparation_display Before this commit, orders made on the kiosk were no longer sent to the preparation display. This commit restores the expected behavior by ensuring that kiosk orders are correctly sent to the preparation display. Step to reproduce: - Install pos_restaurant. - Enable Kiosk as self-ordering mode - Configure a preparation display for the kiosk configuration. - Place an order and proceed to the confirmation page. - The order is not sent to the preparation display opw-4754522 Forward-Port-Of: odoo/enterprise#84943 Forward-Port-Of: odoo/enterprise#84870
*: account_sepa_direct_debit --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's manifest.
Original PR description
*: account_sepa_direct_debit --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's manifest. --- task-4822341 Forward-Port-Of: odoo/enterprise#86609 Forward-Port-Of: odoo/enterprise#86397
After 233c75ae6aaac4b7109483cab8fbfc4253a6dd42 computation of residual amounts is wrong when the payment is linked to a journal entry no-opw Forward-Port-Of: odoo/enterprise#86434
Original PR description
After 233c75ae6aaac4b7109483cab8fbfc4253a6dd42 computation of residual amounts is wrong when the payment is linked to a journal entry no-opw Forward-Port-Of: odoo/enterprise#86434
If you try to remove the Valid Until date to make the sign request valid without expiration, you get an rpc error. Steps to reproduce: ------------------- * Head to the sign app. * Upload a document or use pre-existing document * Click on the 3 dots and click on details. * Add a validity date save and then attempt to remove it. > Observation: TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date' Why the fix: ------------ When removing the date, `write(
Original PR description
If you try to remove the Valid Until date to make the sign request valid without expiration, you get an rpc error.
Steps to reproduce:
-------------------
* Head to the sign app.
* Upload a document or use pre-existing document
* Click on the 3 dots and click on details.
* Add a validity date save and then attempt to remove it.
> Observation:
TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date'
Why the fix:
------------
When removing the date, `write()` gets `vals{'validity': False}` `fields.Date.from_string(False)` returns `<class 'NoneType'>` which can not be compared with the operator `<`
opw-4795212
Forward-Port-Of: odoo/enterprise#86532
Forward-Port-Of: odoo/enterprise#85891Purpose: Splitting QR codes should not be done in documents. They are unusable if broken and some of them have legal impications. Problem Cause: If the QR code is contained in `<div>` that has class `row`, the css property `display: flex;` would cause it to be split among pages when needed. All EDI modules with QR codes were visited, but the problem was only spotted in Mexico and Peru. Solution: `<div>` containing QR codes and having `row` class should also have class `avoid-pa
Original PR description
Purpose: Splitting QR codes should not be done in documents. They are unusable if broken and some of them have legal impications. Problem Cause: If the QR code is contained in `<div>` that has class `row`, the css property `display: flex;` would cause it to be split among pages when needed. All EDI modules with QR codes were visited, but the problem was only spotted in Mexico and Peru. Solution: `<div>` containing QR codes and having `row` class should also have class `avoid-page-break-inside` task-4756331 Forward-Port-Of: odoo/enterprise#85038
odoo/odoo#211391 Forward-Port-Of: odoo/enterprise#86666 Forward-Port-Of: odoo/enterprise#86275
Original PR description
odoo/odoo#211391 Forward-Port-Of: odoo/enterprise#86666 Forward-Port-Of: odoo/enterprise#86275
In this PR: - Added Bank of Slovenia to the list of currency providers. - Fetches exchange rates using the official API and updates the rates. Task-4794271 Forward-Port-Of: odoo/enterprise#85575
Original PR description
In this PR: - Added Bank of Slovenia to the list of currency providers. - Fetches exchange rates using the official API and updates the rates. Task-4794271 Forward-Port-Of: odoo/enterprise#85575
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display Cause: Since the call of syncAllOrders is not awaited in the preparation_display, the calls to the orm needed for the blackbox are executed and make the call of syncAllOrders from the submitOrder -> floorPlan -> .... -> unsetTable go first. since the second call to syncAllOrders doesn't have the
Original PR description
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display Cause: Since the call of syncAllOrders is not awaited in the preparation_display, the calls to the orm needed for the blackbox are executed and make the call of syncAllOrders from the submitOrder -> floorPlan -> .... -> unsetTable go first. since the second call to syncAllOrders doesn't have the context preparation the preparation_display doesn't process the order. Fix: Make the call to syncAllOrders from preparation_display await. Move the call for sendOrderInPreparationUpdateLastChange after addPendingOrder since addPendingOrder adds the order again to the pending orders that causes the syncAllOrders from the floor_plan to make the sync_from_ui call again. Task-4812830 Forward-Port-Of: odoo/enterprise#86119
Issue Before This Commit: ============================ In MO barcode interface, the by-products section displays the source location instead of the destination location for each by-product line. This is misleading, as by-products are outputs of a production process and should reference a destination location. Steps to Reproduce: ============================ - Install the stock_barcode_mrp module. - Activate multi-step routes and By-Products. - Create a Manufacturing Order with by
Original PR description
Issue Before This Commit: ============================ In MO barcode interface, the by-products section displays the source location instead of the destination location for each by-product line. This…
Issue Before This Commit:
============================
In MO barcode interface, the by-products section displays the
source location instead of the destination location for each by-product line.
This is misleading, as by-products are outputs of a production
process and should reference a destination location.
Steps to Reproduce:
============================
- Install the stock_barcode_mrp module.
- Activate multi-step routes and By-Products.
- Create a Manufacturing Order with by-products.
- Open the MO using the barcode app.
- In the by-product section notice that:
- The lines are grouped by Source Location.
- If you edit by-product line then user has option to edit source location.
- If the MO operation type has Source Location scan as mandatory,
user can't edit by-product line.
With This Commit:
============================
- By-product lines are now grouped by their destination location.
- The destination location is displayed for each by-product line.
- The source location field is hidden when editing by-product lines.
- Even if the MO operation type has Source Location scan as mandatory,
users can still edit by-product lines.
This fix improves clarity and usability for production operators by ensuring
that the appropriate location context is accurately displayed and
can be edited when necessary.
task - [4654161](https://www.odoo.com/odoo/my-tasks/4654161)
Forward-Port-Of: odoo/enterprise#86608
Forward-Port-Of: odoo/enterprise#83617Forward-Port-Of: odoo/enterprise#86179
Original PR description
Forward-Port-Of: odoo/enterprise#86179