Daily updates from Odoo
Wednesday, February 28, 2018
6 changes · master
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.`