Wednesday, January 29, 2020
19 changes · master
Enhancements to existing features
The website editor’s left panel has been adjusted so its items line up more consistently and avoid being cut off. This makes the editing experience clearer and more reliable while preparing for a deeper design review later.
Users now see a brief confirmation message when they publish website content from the top bar toggle. This gives clearer feedback that a blog, course, or related website record has been made public.
Original PR description
This commit shows a toaster when publishing a record through the toggle in the topbar. The `_description` field is used to do that, as it is supposed to contains a 'business oriented' descriptive name, see task-37311. task-2183051
Resolved issues and error corrections
Collaborative Pad sessions now show each editor's proper full name instead of an undefined or login-based label. This makes it easier for users to identify who is editing shared notes and reduces confusion during collaboration.
Original PR description
Task: https://www.odoo.com/web#id=2154331&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.f9c119c6725985b33681500e5119ce69
Miscellaneous changes
match_total_amount_param on account.reconciliation.model is not respected when paying a vendor bill through bank statement because the amounts from both the statement line and the move line will be negative. Description of the issue/feature this PR addresses: Auto-reconciliation between bank statement and vendor bills is done without ref matching or amount matching Current behavior before PR: 1. On runbot, mark ‘Show full accounting features’ for you user. 2. Create a new Vendo
Original PR description
match_total_amount_param on account.reconciliation.model is not respected when paying a vendor bill through bank statement because the amounts from both the statement line and the move line will be…
match_total_amount_param on account.reconciliation.model is not respected when paying a vendor bill through bank statement because the amounts from both the statement line and the move line will be negative. Description of the issue/feature this PR addresses: Auto-reconciliation between bank statement and vendor bills is done without ref matching or amount matching Current behavior before PR: 1. On runbot, mark ‘Show full accounting features’ for you user. 2. Create a new Vendor bill using a new partner with an invoice line: 3. Validate the vendor bill, such an account move will be created: Note that we don’t set any ref nor a label on the payable move line. 4. Check the reconciliation models, there must be only one looking as follows:Note that amount matching is marked with 100% and we use auto-validate. 5. Create a new bank statement with a to pay the vendor bill: Note that the amount is LOWER than the vendor bill total and that the label (Dummy Label) does NOT match the reference of the vendor bill nor the name on the move line. 6. Click on Reconcile and you will see the rainbowman....So reconciliation is done although the amount DOES NOT MATCH and the ref DOES NOT MATCH. Therefore, vendor bill is set as paid although it has NOT been paid completely. Desired behavior after PR is merged: Click on Reconcile and no reconciliation is done since the amount DOES NOT MATCH and the ref DOES NOT MATCH. The vendor bill has to stay open as it's not completely paid. The problem lies on account.reconcile.model in _check_rule_propositions function: https://github.com/odoo/odoo/blob/12.0/addons/account/models/ account_reconcile_model.py#L572-L578 As we’re paying a vendor bill (and not a customer invoice), both line_residual and total_residual are negative, so the check must use absolute values in order to respect the Amount Matching % parameter from the reconciliation model. OPW-2179739 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44195 Forward-Port-Of: odoo/odoo#43767
This fixes an issue where the visual stacking of pop-up windows could incorrectly affect website or custom pop-ups. The change limits that behavior to Odoo’s own technical dialogs, helping prevent display problems for front-end users and customizations.
Original PR description
Before, the CSS rule handling the "activity" of the modals (their z-index compared to the one of their backdrop) was global and would interfere with front-end or custom modals which do not use the static Dialog methods giving them the "active" class.
Now, the rule has been restricted to technical modals (back-end only), and all technical front-end modals now have the "active" class by default and do not participate in the Dialog's class toggling system.This update makes automated checks for the Documents area wait until the side panel is fully shown before continuing. It helps prevent false test failures, making development and releases more reliable without changing the user experience.
Original PR description
This commit forces the test to wait for the inspector to be painted into the DOM. The bug was introduced in #7911
Description of the issue/feature this PR addresses: Attribute `active` of `__manifest__.py` exists and is not documented. Current behavior before PR: Attribute `active` of `__manifest__.py` exists and is not documented. Desired behavior after PR is merged: Attribute `active` of `__manifest__.py` exists and is documented. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44074
Original PR description
Description of the issue/feature this PR addresses: Attribute `active` of `__manifest__.py` exists and is not documented. Current behavior before PR: Attribute `active` of `__manifest__.py` exists and is not documented. Desired behavior after PR is merged: Attribute `active` of `__manifest__.py` exists and is documented. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44074
Before this commit, when typing something in the search view in Japanese, and then clicking on a suggestion from the IME dropdown menu, the search view menu did not update with selection. Steps to reproduce: - Enable Japanese IME in hiragana mode; - Type "test" in search view; - Soft-select another suggestion item, e.g. "テスト"; - Double-click on suggestion item "test"; => The search view menu still detects "テスト". As a result, clicking on any of these search view suggested filters
Original PR description
Before this commit, when typing something in the search view in Japanese, and then clicking on a suggestion from the IME dropdown menu, the search view menu did not update with selection. Steps to reproduce: - Enable Japanese IME in hiragana mode; - Type "test" in search view; - Soft-select another suggestion item, e.g. "テスト"; - Double-click on suggestion item "test"; => The search view menu still detects "テスト". As a result, clicking on any of these search view suggested filters picks "テスト" instead of "test". This commit fixes the issue by updating search menu when clicking in a suggestion in the IME menu. opw-2061590 Forward-Port-Of: odoo/odoo#44094 Forward-Port-Of: odoo/odoo#43723
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#43977
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#43977
When having an invoice in foreign currency and a partial payment in domestic currency (in a different date with a different exchange rate), the computed amount due is incorrect. When computing the amount_residual_currency the payment (in domestic currency) is converted to the foreign currency using the exchange rate of the invoice date, and not the one of the payment date (see 56d92213b82d417e48cb5a3432eb57dcba706b6e). If the account.partial.reconcile line will have a currency_id and a
Original PR description
When having an invoice in foreign currency and a partial payment in domestic currency (in a different date with a different exchange rate), the computed amount due is incorrect. When computing the amount_residual_currency the payment (in domestic currency) is converted to the foreign currency using the exchange rate of the invoice date, and not the one of the payment date (see 56d92213b82d417e48cb5a3432eb57dcba706b6e). If the account.partial.reconcile line will have a currency_id and a amount_currency the amount_residual_currency will not be converted but simply added. This behaviour was introduced with e1306066026649acd388b49d7429337d87cf819a and backported to version 11.0 with 3363d7235137f286458c734a1a0417beeb1f66bb. In version 12.0 this behaviour was partially reverted in d3d26120614139fd7d7e888bd66d21de5158a034. opw-2156001 Forward-Port-Of: odoo/odoo#44132 Forward-Port-Of: odoo/odoo#42524
Avoid display errors with special characters when copying the href attribute of links in the web editor. opw-2078313 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44163
Original PR description
Avoid display errors with special characters when copying the href attribute of links in the web editor. opw-2078313 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44163
psycopg2 2.7 not be installed on python 3.8, needs at least psycopg2 2.8 use the same version as windows to avoid complicated rules if windows AND python 3.8 Note that psycopg2 3.8.4 is currently the only one released after the release of python 3.8 but reported compatibilty issued seems to be fixed since 3.8 at psycopg/psycopg2#854 Fixes odoo/odoo#42660 To be backported? Forward-Port-Of: odoo/odoo#42705
Original PR description
psycopg2 2.7 not be installed on python 3.8, needs at least psycopg2 2.8 use the same version as windows to avoid complicated rules if windows AND python 3.8 Note that psycopg2 3.8.4 is currently the only one released after the release of python 3.8 but reported compatibilty issued seems to be fixed since 3.8 at psycopg/psycopg2#854 Fixes odoo/odoo#42660 To be backported? Forward-Port-Of: odoo/odoo#42705
When we name_search a res.user, we have a special hack so we will firstly perform an exact search on the res.users login, if none is found we will search over res.users name. This is intended but in the case of negative search since 660cebb4faaeb, for example operator='not ilike' and name='test' would probably just return all user that do not have a login that is exactly test. This is not the intended behavior, in this instance we should just return user that do not have "test" in their names.
Original PR description
When we name_search a res.user, we have a special hack so we will
firstly perform an exact search on the res.users login, if none is found
we will search over res.users name.
This is intended but in the case of negative search since 660cebb4faaeb,
for example operator='not ilike' and name='test' would probably just
return all user that do not have a login that is exactly test.
This is not the intended behavior, in this instance we should just
return user that do not have "test" in their names.
Without fix, added test would fail on:
- .name_search('vlad', operator='not ilike') => finding everyone but
user with exactly login vlad instead of user not containing vlad in
their name
- .name_search('', operator='not ilike') => find all users instead of
finding no user
opw-2170517
Forward-Port-Of: odoo/odoo#44040Login in into a database Access the database manager Duplicate a database Internal server error will occur and display user. This should not happen (even if the database is duplicated just fine), and occur because after the duplication the connection is dropped but the cursor will still hold the old reference and then, in the response generation it will crash. Invalidating cursor right after the duplication, like what is done after a 'drop' operation fix the issue opw-2170974
Original PR description
Login in into a database Access the database manager Duplicate a database Internal server error will occur and display user. This should not happen (even if the database is duplicated just fine), and occur because after the duplication the connection is dropped but the cursor will still hold the old reference and then, in the response generation it will crash. Invalidating cursor right after the duplication, like what is done after a 'drop' operation fix the issue opw-2170974 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44119
…rface PURPOSE There has been a few changes in the accounting module since the version 12.4. The field 'invoice_ids' in the 'sale.order' model is now related to the 'account.move' model instead of the 'account.invoice' model. The field that contain the payment state is now called 'invoice_payment_state'. This field changed name again in master into 'payment_state'. SPECIFICATION Change the call from 'invoice.state' into 'invoice.invoice_payment_state'. LINKS Task ID : 21801
Original PR description
…rface PURPOSE There has been a few changes in the accounting module since the version 12.4. The field 'invoice_ids' in the 'sale.order' model is now related to the 'account.move' model instead of the 'account.invoice' model. The field that contain the payment state is now called 'invoice_payment_state'. This field changed name again in master into 'payment_state'. SPECIFICATION Change the call from 'invoice.state' into 'invoice.invoice_payment_state'. LINKS Task ID : 2180184 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#43823
Task:https://www.odoo.com/web#id=2177266&action=333&active_id=1251&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.de231db97f6a986fcea777386be39078 Forward-Port-Of: odoo/enterprise#7923 Forward-Port-Of: odoo/enterprise#7832
Original PR description
Task:https://www.odoo.com/web#id=2177266&action=333&active_id=1251&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.de231db97f6a986fcea777386be39078 Forward-Port-Of: odoo/enterprise#7923 Forward-Port-Of: odoo/enterprise#7832
### Issue - Install Projects - Enable Forecast and Timesheets - Planning > Reports > Planning analysis - Group by Project > Employee Traceback ### Cause In 5262914, we override the read_group method to make open shifts always visible on Gantt view. It create a fake record with all fields to False but when you use group by it removes the fields from the fields variable and it put it in groupby variables. So when you are in Gantt
Original PR description
### Issue
- Install Projects
- Enable Forecast and Timesheets
- Planning > Reports > Planning analysis
- Group by Project > Employee
Traceback
### Cause
In 5262914, we override the read_group method to make
open shifts always visible on Gantt view.
It create a fake record with all fields to False but
when you use group by it removes the fields from the fields variable
and it put it in groupby variables.
So when you are in Gantt view it works fine but when you
group by in report analysis (pivot view) it crashes because
it doesn't have a record with all fields.
### Solution
merge group by and fields when creating the fake record.
**OPW-2179747**
Forward-Port-Of: odoo/enterprise#8004Before this commit, the journal was missing in the info button of the reconciliation lines. Now, the journal is correctly shown. opw-2177804 X-original-commit: odoo/odoo@0ebd5b7bae3249b19982f92f10855b21c0e6689d Forward-Port-Of: odoo/enterprise#7993
Original PR description
Before this commit, the journal was missing in the info button of the reconciliation lines. Now, the journal is correctly shown. opw-2177804 X-original-commit: odoo/odoo@0ebd5b7bae3249b19982f92f10855b21c0e6689d Forward-Port-Of: odoo/enterprise#7993
Improved version of bbf0afe23a87892502992825e50e29fa67e03002 to make it work on new records. Forward-Port-Of: odoo/enterprise#7996
Original PR description
Improved version of bbf0afe23a87892502992825e50e29fa67e03002 to make it work on new records. Forward-Port-Of: odoo/enterprise#7996