Daily updates from Odoo
Navigate
Branch
Wednesday, February 28, 2018
12 changes
New functionality added to Odoo
This change updates and expands the German accounting localization, including the SKR03 and SKR04 chart of accounts, tax tags, fiscal positions, and DATEV-related setup. German companies get a more complete and accurate accounting configuration out of the box, reducing manual setup and reporting errors.
Original PR description
Task: 31826
Enhancements to existing features
This update avoids clearing the selected task on a timesheet entry when the chosen project is still the same as the task's project. It also ensures a default employee passed into the timesheet form is saved properly, reducing unnecessary re-entry and preventing missing employee information.
Original PR description
…t task_id.project_id Task: https://www.odoo.com/web?#id=35414&view_type=form&model=project.task&action=333&active_id=131&menu_id=4720 Pad: https://pad.odoo.com/p/r.b1dc522b35958704f06bb1fa664bed91 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The status stage button is adjusted so it appears in a clearer position on smaller screens, making stage changes easier for users. Notes also now receive a default first stage when none is set, preventing confusing “undefined” status options and keeping workflows cleaner.
Original PR description
TASK :- https://www.odoo.com/web#id=35309&view_type=form&model=project.task&action=333&active_id=131&menu_id=4720 PAD :- https://pad.odoo.com/p/r.1112e693c1ed0458ae1f5118f46bc13e Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Accounting fiscal positions can now replace a tax with multiple taxes instead of only one. This helps businesses model cases such as imports or withholding taxes without relying on more complex grouped tax setups.
Original PR description
In several (not so) corner cases, one might want to configure one tax to be complemented by another. A typical example could be import, where you would complement the regular VAT tax by a tax item representing the payment due to the fiscal authorities. Another example is withholding, where you would want to complement a VAT tax by a withholding corresponding to itself. If approved needs to be complemented by (at least) an adjustment to xml files and tests, for sure... /cc @qdp-odoo EDIT: This is able to reduce the need for (complex) group taxes, as it probably was the main driver of group tax constructs in some cases... -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When users create a new record from a grid cell, the system now carries over the relevant grid column and grouping information automatically. This reduces manual data entry and helps new records open with more accurate default values.
Original PR description
…d from cell We will pass field which is used as col in grid as well as current group fields in context for default value Task: https://www.odoo.com/web?#id=35414&view_type=form&model=project.task&action=333&active_id=131&menu_id=4720 Pad: https://pad.odoo.com/p/r.b1dc522b35958704f06bb1fa664bed91
Resolved issues and error corrections
Demo customers and selected products are no longer automatically tied to the main company, so they can be used correctly in multi-company demo and test scenarios. This helps prevent incorrect warehouse and product combinations and keeps automated checks reliable in multi-company setups.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes demo data to have the tests executed correctly as it should if having multicompany in mind. For example, tests that use the…
**Description of the issue/feature this PR addresses:** This PR fixes demo data to have the tests executed correctly as it should if having multicompany in mind. For example, tests that use the Chicago company and Chicago Warehouse doing pickings with products that have the main company should not be possible, just with products without company (or with Chicago company). **Current behavior before PR:** When creating the demo partners, they have the main company by default. When creating demo products, they have the main company by default. **Desired behavior after PR is merged:** When creating the demo partners, they won't have any company by default. When creating some demo products, they won't have any company by default. Note: I didn't put `company_id = False` to all demo products, just I did to the products used in `stock` by Chicago company. I know that some of you may not bother about demo data, but if merged this PR, it will make the travis green in a multicompany environment that have all multicompany constrains like the explained [here](https://github.com/odoo/odoo/pull/20508). Please, be considerate. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Odoo's logging setup from failing when running in environments that do not fully support terminal checks, such as notebook-style consoles. Instead of stopping with an error, the system safely treats those outputs as non-terminal and continues initialization.
Original PR description
The current method checks if the handler stream has a `fileno()` method and assumes that it is callable if exists. This may not true as the stream may actually has `fileno()` method which raises an exception. For example, iPython Notebook default handler has a `fileno()` method that raises `io.UnsupportedOperation` exception. With this fix, `is_a_tty()` will return `False` instead of propagating the exception.
This fix reduces unnecessary processing in the web editor so the web client responds more quickly during common actions like clicks, typing, and content changes. It improves test execution time and should make editing website content feel smoother without changing visible features.
Original PR description
Time for the unit test: Without this fix: 177 seconds With this fix: 127 seconds
This fixes how manufacturing bill of materials details are returned so the correct product information is included for each line. It helps ensure manufacturing processes and related reports use accurate component data.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: bom product in bom_lines, it should be bom_line product Desired behavior after PR is merged: ## I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr should return bom data, and bom lines data
Accounting reports now consistently use the company chosen in the report wizard, regardless of the user's current active company. This ensures report headers, report content, and available journals match the selected company in multi-company setups.
Original PR description
Independently of which company has the user at the moment, the user should have the option to choose what company wants for the reports if the multicompany option is activated. And also this means that the `journal_ids` should be restricted by the chosen company. Moreover, if the user choose X company in the wizard of the reports, then the reports should have X company in the report's header and also X company in the full report's body, and not the user's company. In addition, this PR fixes some issues in some reports. For example, it doesn't make sense, in the partner ledger report, in its header, to have the partner's company instead of the user's company (or the chosen company). -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Mexican electronic invoicing module now fills in the required fiscal position code during setup. This prevents invoice validation from failing with a missing tax regime message, helping users issue compliant invoices more reliably.
Original PR description
Set the code field (l10n_mx_edi_code) in account.fiscal.position model, to avoid the message: `The attribute 'RegimenFiscal' is required but missing when validating and invoice.`
Code cleanup and technical improvements
Odoo’s internal handling of hierarchical records was redesigned to make parent-child searches faster and easier to maintain. This improves reliability during concurrent updates and affects business areas that rely on structured records such as products, stock locations, accounts, menus, partners, and website content.
Original PR description
This replaces the former modified preorder tree traversal (MPTT) with the
fields `parent_left`/`parent_right`. Each record is associated to a string
`parent_path`, that represents the path from its root node to itself. The path
is made of the node ids suffixed with a slash:
a node | id | parent_path
/ \ a | 42 | 42/
... b b | 63 | 42/63/
/ \ c | 84 | 42/63/84/
c d d | 85 | 42/63/85/
This field provides an efficient implementation for parent_of/child_of queries:
the nodes in the subtree of record are the ones where `parent_path` starts with
the `parent_path` of record. It is also more efficient to maintain than the
MPTT fields, and less sensitive to concurrent updates, because the value of
`parent_path` does not depend on sibling nodes.