Friday, November 27, 2020
39 changes · master
Enhancements to existing features
Customers can now see timesheet details in the portal for both sales orders and invoices, regardless of whether billing is based on ordered or delivered quantities. This improves transparency for service work and helps customers review time spent before or after invoicing.
Original PR description
Prior to this commit:
* The portal timesheet section was only visible in invoices when
invoicing policy was set to delivery.
* The portal timesheet section was not visible on orders.
After this commit:
* The portal timesheet section will be displayed for both delivery and order invoicing
policies.
* The portal timesheet section will be available for orders.
task-2388500
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-prOdoo now better protects important built-in records such as units of measure, currencies, payment methods, and decimal precision settings from accidental deletion or unsafe edits. This helps prevent configuration changes that could break accounting, sales, timesheets, or other day-to-day operations, while still allowing exceptional changes by administrators when truly needed.
Original PR description
Restrict deletion & modification for specific models to avoid breaking your database. Case by case solution POC trying to avoid generic nodelete solution (#56805) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Financial report journal filters now show a scroll bar when many journals are available. This makes the filter easier to use and keeps the report interface tidy for companies with large numbers of journals.
Original PR description
Task [2377638](https://www.odoo.com/web#id=2377638&action=333&active_id=967&model=project.task&view_type=form&cids=1&menu_id=4720) Add a scroll bar for when we have a lot of journals in the journal filter of reports.
Resolved issues and error corrections
Saving a CRM lead without changes no longer repeatedly shows a warning about updating the customer's phone number. This avoids confusion for users and keeps CRM contact information formatting consistent.
Original PR description
in crm while editing lead demo data and saving without any changes a warning which says that the customer phone number will be updated shows like a loop. This commit fixes this issue by preventing the lead partner phone number from having mismatching format. Task-id: 2390287
Miscellaneous changes
Due to 14cb0693b7dec7a8d8eb46a3d34eae2af63cfb70, some fields are not passed in parameters. Fixes https://github.com/odoo/odoo/pull/58974 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62438
Original PR description
Due to 14cb0693b7dec7a8d8eb46a3d34eae2af63cfb70, some fields are not passed in parameters. Fixes https://github.com/odoo/odoo/pull/58974 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62438
The website sales order filters have been aligned so the Confirmed and Unpaid views apply website-related filtering consistently. This helps users see predictable sales order lists and avoids confusion when comparing order statuses.
Original PR description
Before this commit, Filter `Confirmed` was showing all Sales order irrespective of `website_id` while filter `Unpaid` was showing order having `website_id`. Now, we have are showing all the sales order on `Unpaid` filter as we already have default filter "From Website" applied on action. So Both filters `Confirmed` and `Unpaid` will have no effect of `website_id` field. 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
Odoo removed an outdated module setup field that no longer worked and could mislead users configuring modules. This cleanup makes module definitions and documentation clearer, reducing confusion without changing active business features.
Original PR description
The "active" field is a non-working deprecated alias to "auto_install", it does not work and was confusing users (see #59850). It has been removed. Task: 2361729
This fix prevents megamenu building blocks from showing up during general snippet filtering. Website editors will now only see megamenu options when they have selected a megamenu element, reducing confusion and keeping the editor focused.
Original PR description
Description of the issue/feature this PR addresses: Megamenu snippet should appear in the snippet editor "block" section ONLY if a megamenu element is selected. Current behavior before PR: In the current version, trying to filter snippets would make the megamenu snippet block appear. Desired behavior after PR is merged: Megamenu snippets do not appear unless a megamenu element is selected. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where the editing overlay could fail to reappear after users scrolled between page sections and selected an element again. The change makes the website editor behave more predictably, reducing confusion while editing page content.
Original PR description
Description of the issue/feature this PR addresses: In some situation, the overlay does not reappear after disappearing. Current behavior before PR: Steps to reproduce: 1. add a title 2. add a few elements between title and footer so you can scroll title out of view 3. click title 4. scroll it out of view 5. click footer 6. scroll back up 7. click title -> overlay is not reappearing Desired behavior after PR is merged: Now overlay should appear when expected. JW feedback -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
task-2292595 Forward-Port-Of: odoo/odoo#62454
Original PR description
task-2292595 Forward-Port-Of: odoo/odoo#62454
Steps: - Install Contacts - Have Multi-Companies enabled - Go to a Contact of type "Company" - Click "Sales & Purchases" - Assign it the company you're on - Save and Edit again - Remove the assigned company - Go to a contact of type "Individual" linked to this company - Click "Sales & Purchases" Bug: The company has not been deleted on the linked Individual Explanation: When we delete the company of a contact, the value of `vals.get('company_id')` is `False`. This is why it did
Original PR description
Steps:
- Install Contacts
- Have Multi-Companies enabled
- Go to a Contact of type "Company"
- Click "Sales & Purchases"
- Assign it the company you're on
- Save and Edit again
- Remove the assigned company
- Go to a contact of type "Individual" linked to this company
- Click "Sales & Purchases"
Bug:
The company has not been deleted on the linked Individual
Explanation:
When we delete the company of a contact, the value of `vals.get('company_id')` is `False`.
This is why it didn't enter the propagation process.
opw:2391464
Forward-Port-Of: odoo/odoo#62418Fixes #62214 Forward-Port-Of: odoo/odoo#62451
Original PR description
Fixes #62214 Forward-Port-Of: odoo/odoo#62451
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62137
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62137
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 Forward-Port-Of: odoo/odoo#62459
Original PR description
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 Forward-Port-Of: odoo/odoo#62459
The mock implementation of `name_get` does not fully reflect the real server implementation. The real implementation is described in tests added in this commit. This was spotted with https://github.com/odoo/enterprise/pull/14990 where the qunit test failed to have the same behavior as a real world test. Note: in my wildest dreams, the mock server tests would be run against the real *and* the mock implementation to ensure they do not diverge. -- I confirm I have signed the CLA
Original PR description
The mock implementation of `name_get` does not fully reflect the real server implementation. The real implementation is described in tests added in this commit. This was spotted with https://github.com/odoo/enterprise/pull/14990 where the qunit test failed to have the same behavior as a real world test. Note: in my wildest dreams, the mock server tests would be run against the real *and* the mock implementation to ensure they do not diverge. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62347
- Install website_slides - Connect with an user (i.e. Mitchell Admin) - Go to Website and open a Course quiz for the first time (i.e. "Test Yourself" from "Basics of Furniture Creation" Course) - Answer correctly The number of won karma is the one from the last attempt reward and is not saved in user's total xp. When submitting the quiz, quiz_attempts_count is incremented via a SQL query, but its value is not updated in cache directly. When the karma gain is computed from the attempts
Original PR description
- Install website_slides - Connect with an user (i.e. Mitchell Admin) - Go to Website and open a Course quiz for the first time (i.e. "Test Yourself" from "Basics of Furniture Creation" Course) - Answer correctly The number of won karma is the one from the last attempt reward and is not saved in user's total xp. When submitting the quiz, quiz_attempts_count is incremented via a SQL query, but its value is not updated in cache directly. When the karma gain is computed from the attempts count, the value used is the old one in cache. opw-2389969 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 Forward-Port-Of: odoo/odoo#62421
@nim-odoo We did it too fast :-( -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62481 Forward-Port-Of: odoo/odoo#62467
Original PR description
@nim-odoo We did it too fast :-( -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62481 Forward-Port-Of: odoo/odoo#62467
Create a sale order for a stored product, save and confirm. Validate delivery Return and validate. Return (the return, so delivery again) and validate. Try return again. The quantity to return in the widget will be 0. Attempting to fix manually will worsen the situation creating negative quantities on further action. This occur because when creating the return the system tries to identity other sibling return moves to set the correct quantity This commit fine tunes 73de0645b730e1f1
Original PR description
Create a sale order for a stored product, save and confirm. Validate delivery Return and validate. Return (the return, so delivery again) and validate. Try return again. The quantity to return in the widget will be 0. Attempting to fix manually will worsen the situation creating negative quantities on further action. This occur because when creating the return the system tries to identity other sibling return moves to set the correct quantity This commit fine tunes 73de0645b730e1f1183b7c770e878b4c4ff1e0f1 aiming to collect quantities only on actual sibling returns (moves sharing the same parent) opw-2379663 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 Forward-Port-Of: odoo/odoo#61996
Steps to reproduce: Create a new local Odoo DB Create another company on the DB install the CRM module Create an opportunity on the CRM app for each company. Execute This server action (CHANGE THE res_id TO THE IDs OF THE OPPORTUNITY CREATED): ``` for _ in range(0, 300): for _ in range (0, 75): env['ir.attachment'].sudo().create({'name': 'test','res_model': 'crm.lead', 'res_id': 31, 'type': 'binary'}) for _ in range (0, 75): env['ir.attachment'].sudo().create({'name': 't
Original PR description
Steps to reproduce: Create a new local Odoo DB Create another company on the DB install the CRM module Create an opportunity on the CRM app for each company. Execute This server action (CHANGE THE…
Steps to reproduce:
Create a new local Odoo DB
Create another company on the DB
install the CRM module
Create an opportunity on the CRM app for each company.
Execute This server action (CHANGE THE res_id TO THE IDs OF THE OPPORTUNITY CREATED):
```
for _ in range(0, 300):
for _ in range (0, 75):
env['ir.attachment'].sudo().create({'name': 'test','res_model': 'crm.lead', 'res_id': 31, 'type': 'binary'})
for _ in range (0, 75):
env['ir.attachment'].sudo().create({'name': 'test','res_model': 'crm.lead', 'res_id': 45, 'type': 'binary'})
```
go to the Settings / Technical / Database Structure / Attachments.
Server will look in endless call because the search try to retrieve
`limit` records, but after applying company record rule we have
`limit - e`, so it begin a second search for e records.
Even the second search will look for limit and possibly will find less,
starting a third...
If the sub call is aware of how much records we actually need after
checking permission, we can return the recordset if we have collected
enough
opw-2369722
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
Forward-Port-Of: odoo/odoo#62293Only updates outdated requirements which actively cause issues: * freezegun broken in 3.8 (removal of time.clock) * xlrd broken in 3.8 (removal of time.clock) * also monkeypatches xlrd.xlsx for 3.9 (removal of Element.getiterator, breaks because of defusedxml) * jinja triggers DeprecationWarning in 3.8 * pillow triggers warning in 3.9 * lxml, greenlet don't compile in 3.9 * reportlab doesn't work in 3.9 New versions try to match those of Debian Bullseye. Also adds a script to m
Original PR description
Only updates outdated requirements which actively cause issues: * freezegun broken in 3.8 (removal of time.clock) * xlrd broken in 3.8 (removal of time.clock) * also monkeypatches xlrd.xlsx for 3.9 (removal of Element.getiterator, breaks because of defusedxml) * jinja triggers DeprecationWarning in 3.8 * pillow triggers warning in 3.9 * lxml, greenlet don't compile in 3.9 * reportlab doesn't work in 3.9 New versions try to match those of Debian Bullseye. Also adds a script to more easily compare dependency versions between the requirements files and what's in various distributions (currently supports checking against debian and ubuntu). See #59980 Closes #61103 Forward-Port-Of: odoo/odoo#62380
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 Forward-Port-Of: odoo/odoo#62399
Original PR description
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 Forward-Port-Of: odoo/odoo#62399
Behavior prior to this commit: - when the warehouse uses a 3-step manufacturing process, if I create a Sales Order, the MO generated does not show the SO# as "Source", instead it shows the MO# Behavior after this commit: - the MO source shows the SO# (similar to how it works when using the 2-step or the 1-step manufacturing process) Implementation note: - the `origin` gets overwritten when the group is generated in `_run_pull`, because the group name is used as default origin in t
Original PR description
Behavior prior to this commit: - when the warehouse uses a 3-step manufacturing process, if I create a Sales Order, the MO generated does not show the SO# as "Source", instead it shows the MO# Behavior after this commit: - the MO source shows the SO# (similar to how it works when using the 2-step or the 1-step manufacturing process) Implementation note: - the `origin` gets overwritten when the group is generated in `_run_pull`, because the group name is used as default origin in the [base `StockMove` model](https://github.com/odoo/odoo/blob/a8224115d8254b4200416f552fc86f6e9e68223c/addons/stock/models/stock_move.py#L1030). But we need that group to correctly tie the moves to the MO. So instead we go back to look at the dest move on the MO to get its origin. opw-2380717 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62432 Forward-Port-Of: odoo/odoo#62201
There is a situation in pos_restaurant such that when an order is deleted from the ticket screen, it persists to show when the table is opened. To reproduce: 1. Create an order in T1 then add items to it. 2. Get out of the table (back to floor). 3. Open ticket screen. 4. Delete the order in T1. 5. Close the ticket screen. 6. Open T1, the order is still there (bug). This commit fixes this behavior such that in step 6, new order should show and not the deleted order. Note that we
Original PR description
There is a situation in pos_restaurant such that when an order is deleted from the ticket screen, it persists to show when the table is opened. To reproduce: 1. Create an order in T1 then add items to it. 2. Get out of the table (back to floor). 3. Open ticket screen. 4. Delete the order in T1. 5. Close the ticket screen. 6. Open T1, the order is still there (bug). This commit fixes this behavior such that in step 6, new order should show and not the deleted order. Note that we also made a change in the template in order to allow checking the number of synced orders during testing. We want to make sure that the table is clicked when the sync finishes to prevent concurrency issue during testing. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62403
Without this commit, when the compare/reset view feature was reading the arch, it would translate it. 2 issues : - When reading from file (hard reset), it would translate the file version - When reading current arch, it would translate it Forward-Port-Of: odoo/odoo#62433 Forward-Port-Of: odoo/odoo#62342
Original PR description
Without this commit, when the compare/reset view feature was reading the arch, it would translate it. 2 issues : - When reading from file (hard reset), it would translate the file version - When reading current arch, it would translate it Forward-Port-Of: odoo/odoo#62433 Forward-Port-Of: odoo/odoo#62342
This reverts commit 80902bee453cf485906bb07be6af9072aee2e76f as the backport to 12.0 did not apply. Related: https://github.com/odoo/odoo/pull/62418 Forward-Port-Of: odoo/odoo#62489
Original PR description
This reverts commit 80902bee453cf485906bb07be6af9072aee2e76f as the backport to 12.0 did not apply. Related: https://github.com/odoo/odoo/pull/62418 Forward-Port-Of: odoo/odoo#62489
What are the steps to reproduce your issue ? 1. Install "website_sale_comparison" 2. Create a product with only one variant with one attribut 3. Click on "Go to website" smart button 4. Enable "Customize/List View Variant" 5. Click on "Compare" button What is currently happening ? Nothing What are you expecting to happen ? Add product to the comparison list Why is this happening ? Because the product has just one variant and attribut so od
Original PR description
What are the steps to reproduce your issue ?
1. Install "website_sale_comparison"
2. Create a product with only one variant with one attribut
3. Click on "Go to website" smart button
4. Enable "Customize/List View Variant"
5. Click on "Compare" button
What is currently happening ?
Nothing
What are you expecting to happen ?
Add product to the comparison list
Why is this happening ?
Because the product has just one variant and attribut so odoo don't
display it on the product page. The system cannot find the ids as
they are not on the page
How to fix the bug ?
Specify the product id in this case
opw-2377711
https://www.odoo.com/web#id=2377711&action=4043&model=project.task&view_type=form&cids=1&menu_id=4720
Forward-Port-Of: odoo/odoo#62285…datory from 2021/01/01 Task ID : 2390526 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 Forward-Port-Of: odoo/odoo#62340
Original PR description
…datory from 2021/01/01 Task ID : 2390526 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 Forward-Port-Of: odoo/odoo#62340
Forward-Port-Of: odoo/odoo#61987
Original PR description
Forward-Port-Of: odoo/odoo#61987
- Create Product A with UOM of type Unit - Create Product B with UOM of type Unit - Create BOM of type Kit on Product A with Product B as a component with UOM of type Unit - After saving BOM, change the UOM of Product B with UOM from another categories (e.g. kg) and save the product - Try to access product list A warning appears and prevent showing the products in any way. It is caused by the call to `_compute_quantities`. In this case, it is ok to skip the error. Indeed, it w
Original PR description
- Create Product A with UOM of type Unit - Create Product B with UOM of type Unit - Create BOM of type Kit on Product A with Product B as a component with UOM of type Unit - After saving BOM, change the UOM of Product B with UOM from another categories (e.g. kg) and save the product - Try to access product list A warning appears and prevent showing the products in any way. It is caused by the call to `_compute_quantities`. In this case, it is ok to skip the error. Indeed, it will raise later on when trying to use the kit. But at least, it gives the possibility to the user to access the product list. opw-2393711 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 Forward-Port-Of: odoo/odoo#62513
This PR decreases the opacity of dark squares and remove the white background of the logo in the certification templates to make it look better <details> <summary>Before</summary>  </details> <details> <summary>After</summary>  </details> <details> <summary>After</summary>  </details> opw-2387563 https://www.odoo.com/web#id=2387563&action=4043&model=project.task&view_type=form&cids=1&menu_id=4720 Forward-Port-Of: odoo/odoo#62507
When generating an efaktur, an error is raised To reproduce the error: (Use empty DB) 1. Set the company's country to Indonesia 2. Install Accounting (account_accountant) 3. Accounting > Customers > e-Faktur 4. Create & Save 5. Accounting > Customers > Customers 6. Create a customer - Set country to Indonesia - Add a TVA number 7. Accounting > Customers > Invoices 8. Create one for this customer - Add a product 9. Save & Confirm 10. In Action, "Download e-faktur" => An err
Original PR description
When generating an efaktur, an error is raised To reproduce the error: (Use empty DB) 1. Set the company's country to Indonesia 2. Install Accounting (account_accountant) 3. Accounting > Customers > e-Faktur 4. Create & Save 5. Accounting > Customers > Customers 6. Create a customer - Set country to Indonesia - Add a TVA number 7. Accounting > Customers > Invoices 8. Create one for this customer - Add a product 9. Save & Confirm 10. In Action, "Download e-faktur" => An error is raised. OPW-2387843 Forward-Port-Of: odoo/odoo#62435
related to opw-2339906 Forward-Port-Of: odoo/odoo#62527
Original PR description
related to opw-2339906 Forward-Port-Of: odoo/odoo#62527
Reproduce: * On a fresh db, create a payment * Change the date to another month * Validate Issue: * The name is computed before creation because it is the first of journal/period. * It is not visible * It is given to the create vals of the move_id, so it is not correctly recomputed * The sequence/name are not in sync. opw-2390747 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62297
Original PR description
Reproduce: * On a fresh db, create a payment * Change the date to another month * Validate Issue: * The name is computed before creation because it is the first of journal/period. * It is not visible * It is given to the create vals of the move_id, so it is not correctly recomputed * The sequence/name are not in sync. opw-2390747 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62297
What are the steps to reproduce your issue ? 1. Install "website_sale_comparison" 2. Create a product with only one variant with one attribut 3. Click on "Go to website" smart button 4. Enable "Customize/List View Variant" 5. Click on "Compare" button What is currently happening ? Nothing What are you expecting to happen ? Add product to the comparison list Why is this happening ? Because the product has just one variant and attribut so od
Original PR description
What are the steps to reproduce your issue ?
1. Install "website_sale_comparison"
2. Create a product with only one variant with one attribut
3. Click on "Go to website" smart button
4. Enable "Customize/List View Variant"
5. Click on "Compare" button
What is currently happening ?
Nothing
What are you expecting to happen ?
Add product to the comparison list
Why is this happening ?
Because the product has just one variant and attribut so odoo don't
display it on the product page. The system cannot find the ids as
they are not on the page
How to fix the bug ?
Specify the product id in this case
opw-2377711
https://www.odoo.com/web#id=2377711&action=4043&model=project.task&view_type=form&cids=1&menu_id=4720
Forward-Port-Of: odoo/odoo#62419
Forward-Port-Of: odoo/odoo#62285This commit fixes two bugs, the first one is a reinstall bug that happens whenever the modules `payment` or `payment_test` are uninstalled then reinstalled and the second one is a bug in which for some payment acquirers, a journal is never created. For the first bug, the problem is that when uninstalling the aforementioned modules, the journals linked to each provider are not deleted (which is ok from a business POV) and thus when reinstalling said modules we simply recreate new journal
Original PR description
This commit fixes two bugs, the first one is a reinstall bug that happens whenever the modules `payment` or `payment_test` are uninstalled then reinstalled and the second one is a bug in which for…
This commit fixes two bugs, the first one is a reinstall bug that happens whenever the modules `payment` or `payment_test` are uninstalled then reinstalled and the second one is a bug in which for some payment acquirers, a journal is never created. For the first bug, the problem is that when uninstalling the aforementioned modules, the journals linked to each provider are not deleted (which is ok from a business POV) and thus when reinstalling said modules we simply recreate new journals, but journals have a unicity constraint on (name, code, company_id), therefore the re-creation of these journals will most likely fail. This bug doesn't happen with other payment_* modules because all *main* acquirers are defined in the payment module, except for payment_test that defines its own acquirer (thus the fact that it fails to reinstall too). The solution chosen is to try to force the creation of the journals, even if it may fail, within a try/except block: if it does fail, we simply do a lookup for matching (name, code, company_id) and assign whatever we find to the acquirer's journal_id. This approach was chosen because the most common case is that of an install (journal creation), so checking for existing journals first would make the most common case less performant. For the second bug, the part of the code that creates journals for providers being installed made a false assumption: To find the acquirers for which to create journals, it would gather the name of the acquirer/provider from the module name of the modules being installed (or that were already installed) and would compare them to existing acquirers whose provider would match the names extracted from the module name. However, not all payment_ modules contain the actual name of the provider in the module name! payment_ingenico is one such case, while the module name contains ingenico, the technical name for the provider is 'ogone', meaning that the heuristic would never find an existing acquirer with provider set to 'ingenico', therefore no journal would be created for that specific payment provider. The fix is trivial, payment.acquirer has related fields that point to the modules that implement each provider, meaning that one can simply check for all payment.acquirer whose module_state is 'to_install' or 'installed'. This bug does not happen in v12 because when v12 was released ogone was still ogone and not ingenico, and all payment acquirers actually followed the convention of module name == provider name, but for simplicity's sake we keep this change for v12 too since it's in the same scope as for the first bug and the code is cleaner anyway. Forward-Port-Of: odoo/odoo#62535 Forward-Port-Of: odoo/odoo#62522
Behavior prior to the fix: - the non recurring revenue stat on the dashboard includes a negative amount from the subscription invoice, and does not include any amount for the non-subscription invoice. - this happens because some invoice lines, marked with the exclude_from_invoice_tab flag, should be excluded from the report Behavior after the fix: - calculation is excluding the incorrect amount, correctly calculating as 0 for subscription invoice and including the amount from non-
Original PR description
Behavior prior to the fix: - the non recurring revenue stat on the dashboard includes a negative amount from the subscription invoice, and does not include any amount for the non-subscription invoice. - this happens because some invoice lines, marked with the exclude_from_invoice_tab flag, should be excluded from the report Behavior after the fix: - calculation is excluding the incorrect amount, correctly calculating as 0 for subscription invoice and including the amount from non-subscription invoices Note: This fix is a partial port of commit 50d854039bd from version 14.0 (in addition to that fix, a unit test was added) opw-2379585 Forward-Port-Of: odoo/enterprise#15022 Forward-Port-Of: odoo/enterprise#14810
Steps to reproduce the bug: - Create a deferred expense model DEM - Create a deferred expense account DEA with automated deferred expense = 'Create and validate' - Create a credit note of a vendor bill CN with one line L of 1000€ set to DEA - Validate CN Bug: All the created journal items were reversed. opw:2263604 X-original-commit: fa5b9ffdf9728a6bd69b8a9f6cf5f81726ebb46b Co-authored-by: wan <wan@odoo.com> Forward-Port-Of: odoo/enterprise#15010
Original PR description
Steps to reproduce the bug: - Create a deferred expense model DEM - Create a deferred expense account DEA with automated deferred expense = 'Create and validate' - Create a credit note of a vendor bill CN with one line L of 1000€ set to DEA - Validate CN Bug: All the created journal items were reversed. opw:2263604 X-original-commit: fa5b9ffdf9728a6bd69b8a9f6cf5f81726ebb46b Co-authored-by: wan <wan@odoo.com> Forward-Port-Of: odoo/enterprise#15010
The formula `=PIVOT.HEADER("1", "product_id", A2)` would crash if A2 is empty. The result is now an empty string. This is the same behavior as the PIVOT formula (this can be challenged, an #ERROR would probably be meaningfull). Note that an id that does not exist formula will have an #ERROR. e.g consider the same formula as above, with A2=99 and the product_id with id=99 does not exists. This behavior seems inconsistent with what is stated above. Also the error is wrongly displayed as "
Original PR description
The formula `=PIVOT.HEADER("1", "product_id", A2)` would crash if
A2 is empty.
The result is now an empty string. This is the same behavior as the PIVOT
formula (this can be challenged, an #ERROR would probably be meaningfull).
Note that an id that does not exist formula will have an #ERROR.
e.g consider the same formula as above, with A2=99 and the product_id with
id=99 does not exists. This behavior seems inconsistent with what is stated
above. Also the error is wrongly displayed as "[object Object]". Task 2393876
should handle that.
opw 2376306
Forward-Port-Of: odoo/enterprise#14990According to Swiss specification, we need to adapt our code to be compliant with QR-IBAN accounts and not only for postal accounts. Some SCT files were rejected because we need to use a structured communication with the ISR reference and not unstructured communication. opw-2383137 Forward-Port-Of: odoo/enterprise#15023 Forward-Port-Of: odoo/enterprise#14924
Original PR description
According to Swiss specification, we need to adapt our code to be compliant with QR-IBAN accounts and not only for postal accounts. Some SCT files were rejected because we need to use a structured communication with the ISR reference and not unstructured communication. opw-2383137 Forward-Port-Of: odoo/enterprise#15023 Forward-Port-Of: odoo/enterprise#14924