Tuesday, October 27, 2020
27 changes · master
Enhancements to existing features
This update cleans up unused website editor code and improves related test guidance. It helps keep the website editing experience easier to maintain with no expected change for everyday users.
Code cleanup and technical improvements
This change removes obsolete internal code from the Base module that has not been used since older Odoo versions. It helps keep the system easier to maintain without changing day-to-day user functionality.
Original PR description
WHY: it's not used anymore. Last usage was in Odoo 11: https://github.com/odoo/odoo/blob/e771ebf153ecf822694b45ab1c8281997c5f9bb6/odoo/addons/base/ir/ir_translation.py#L161-L176
Miscellaneous changes
This commit updates the description_picking on stock moves once the picking type is changed. This is needed to merge stock moves at confirmation. The description_picking field chosen on the merged move is the 'minimum one'. Empty string will always be chosen that way, so we lose the information. 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 a
Original PR description
This commit updates the description_picking on stock moves once the picking type is changed. This is needed to merge stock moves at confirmation. The description_picking field chosen on the merged move is the 'minimum one'. Empty string will always be chosen that way, so we lose the information. 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#60711
This commit fixes few of the strings / layout for the settings related to CRM and makes it less technical and thus more understandable. TaskID - 2351582 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60687
Original PR description
This commit fixes few of the strings / layout for the settings related to CRM and makes it less technical and thus more understandable. TaskID - 2351582 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60687
Before this commit,Widget "qty_at_date_widget" was only displayed on Sales order line form view. Now we are showing Widget "qty_at_date_widget" on Sales order line form view as well. (https://prnt.sc/v5inaw) 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#60664
Original PR description
Before this commit,Widget "qty_at_date_widget" was only displayed on Sales order line form view. Now we are showing Widget "qty_at_date_widget" on Sales order line form view as well. (https://prnt.sc/v5inaw) 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#60664
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#60778 Forward-Port-Of: odoo/odoo#60741
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#60778 Forward-Port-Of: odoo/odoo#60741
If you don't install website_event_meet_quiz or website_event_meet_quiz, the route will not have sitemap defined. Now we force the sitemap to False by default. And let the override choose the presence or not into the sitemap. It will remove the warning, if your are running test only on website_event No Sitemap value provided for controller <bound method EventCommunityController.community of <odoo.addons.website_event.controllers.community.EventCommunityController object at 0x7ff889bd36
Original PR description
If you don't install website_event_meet_quiz or website_event_meet_quiz,
the route will not have sitemap defined.
Now we force the sitemap to False by default.
And let the override choose the presence or not into the sitemap.
It will remove the warning, if your are running test only on website_event
No Sitemap value provided for controller <bound method EventCommunityController.community of
<odoo.addons.website_event.controllers.community.EventCommunityController object at 0x7ff889bd3668>>
(/event/<model("event.event"):event>/community)
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#60767365 * 24 * 60 is not a year, but year/60 ;) While we fix it, it is the good time to change and use the dedicated http.STATIC_CACHE_LONG that exists for it. 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#60768
Original PR description
365 * 24 * 60 is not a year, but year/60 ;) While we fix it, it is the good time to change and use the dedicated http.STATIC_CACHE_LONG that exists for it. 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#60768
Each time the function is called, we append to the same persistent object. 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#60795
Original PR description
Each time the function is called, we append to the same persistent object. 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#60795
User is not allowed to save an empty name for the customer details. If tried, an error message is shown. This feature has been accidentally dropped after the pos-owl-refactoring. We are restoring this behavior in this commit. TASK-ID: 2371318 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60793
Original PR description
User is not allowed to save an empty name for the customer details. If tried, an error message is shown. This feature has been accidentally dropped after the pos-owl-refactoring. We are restoring this behavior in this commit. TASK-ID: 2371318 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60793
To reproduce: 1. Start with empty instance with point_of_sale (no demo). 2. Install Indian localization from Invoicing. 3. Start a pos session with that config. 4. Sell a product. 5. Assign a customer to the order. 6. Invoice the order during payment. 7. Validate. [BUG] Empty receipt is shown in the receipt screen. This is because of empty country field of the pos.config's company. We modify the check for country code in the receipt template to account for empty country as fix.
Original PR description
To reproduce: 1. Start with empty instance with point_of_sale (no demo). 2. Install Indian localization from Invoicing. 3. Start a pos session with that config. 4. Sell a product. 5. Assign a customer to the order. 6. Invoice the order during payment. 7. Validate. [BUG] Empty receipt is shown in the receipt screen. This is because of empty country field of the pos.config's company. We modify the check for country code in the receipt template to account for empty country as fix. TASK-ID: 2371318 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60801
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60738
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#60738
Before this patch, adding a field on a custom model discards all automated actions on that model. The explanation is relatively simple. When models are set up in the registry, the classes of custom models are dropped then recreated. Given that automated actions are implemented as monkey-patches on model classes, the setup of models simply loses those monkey-patches, which explains why they stop working on custom models. The fix introduces an `_unregister_hook()` method, that is expecte
Original PR description
Before this patch, adding a field on a custom model discards all automated actions on that model. The explanation is relatively simple. When models are set up in the registry, the classes of custom models are dropped then recreated. Given that automated actions are implemented as monkey-patches on model classes, the setup of models simply loses those monkey-patches, which explains why they stop working on custom models. The fix introduces an `_unregister_hook()` method, that is expected to clean up what has been done in `_register_hook()`. When the registry is ready (i.e., not being loaded), the setup of models first invokes `_unregister_hook()` on models, proceeds with the setup, and finally invokes `_register_hook()` to reinstall the hooks. OPW 2362308 Forward-Port-Of: odoo/odoo#60818 Forward-Port-Of: odoo/odoo#60764
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#60783 Forward-Port-Of: odoo/odoo#60752
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#60783 Forward-Port-Of: odoo/odoo#60752
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#60824 Forward-Port-Of: odoo/odoo#60718
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#60824 Forward-Port-Of: odoo/odoo#60718
Description of the issue/feature this PR addresses: The argument _action_ from method _verify_request_recaptcha_token was actually not in use Current behavior before PR: Always give 'website_form' as the argument _action_ to google recaptcha service, which is only specific for module website_form Desired behavior after PR is merged: The argument _action_ from method _verify_request_recaptcha_token will be in use, and will not leads to failure when another modules reference google_recapt
Original PR description
Description of the issue/feature this PR addresses: The argument _action_ from method _verify_request_recaptcha_token was actually not in use Current behavior before PR: Always give 'website_form' as the argument _action_ to google recaptcha service, which is only specific for module website_form Desired behavior after PR is merged: The argument _action_ from method _verify_request_recaptcha_token will be in use, and will not leads to failure when another modules reference google_recaptcha. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60684
Issue - Install "CRM" - Create new lead - Set X to customer - Send a log note X receives log notes by mail Reproducible on Project and CRM Cause The customer sends a list of partners who will receive an email even when it is a log note Solution Send the list of partners only when it is an email and not a log note opw-2369280 Forward-Port-Of: odoo/odoo#60836
Original PR description
Issue
- Install "CRM"
- Create new lead
- Set X to customer
- Send a log note
X receives log notes by mail
Reproducible on Project and CRM
Cause
The customer sends a list of partners who will receive an email
even when it is a log note
Solution
Send the list of partners only when it is an email and not a log note
opw-2369280
Forward-Port-Of: odoo/odoo#60836task-2346862 Forward-Port-Of: odoo/odoo#60080
Original PR description
task-2346862 Forward-Port-Of: odoo/odoo#60080
The custom vat index name matched the name that the system uses for automatic indexes (when a field has `index=True`). But the `vat` field was created with `index=False`, and this means that the ORM would execute a `DROP INDEX IF EXISTS res_partner_vat_index` when updating any addon that touches the `res.partner` model. Since this model is so ubiquitous, this resulted in a ton of unnecessary `DROP INDEX` + `CREATE INDEX` queries when updating any database. What's even worse is that dropp
Original PR description
The custom vat index name matched the name that the system uses for automatic indexes (when a field has `index=True`). But the `vat` field was created with `index=False`, and this means that the ORM…
The custom vat index name matched the name that the system uses for automatic indexes (when a field has `index=True`). But the `vat` field was created with `index=False`, and this means that the ORM would execute a `DROP INDEX IF EXISTS res_partner_vat_index` when updating any addon that touches the `res.partner` model. Since this model is so ubiquitous, this resulted in a ton of unnecessary `DROP INDEX` + `CREATE INDEX` queries when updating any database. What's even worse is that dropping or creating an index needs a complete semaphore lock of the whole table, so if you're updating a high-traffic HA production instance while it is running, you have a very high rate of concurrency failures, because almost everybody is going to be using the `res.partner` model in some way almost all the time. A deeper investigation reveals that the index itself was useless. It was added in a6e1eb9 and apparently meant to be used for optimizing name_search(). But even though a6e1eb9 modified name_search(), it did the substitution in Python[1], so in practice the database had no way to recognize the pattern and never used the index. The specificity of that index makes it useless for other cases too, so it can simply be dropped to save space. Further, considering that the `vat` field is a common search criterion, it actually makes sense to enable a normal index on that field, by setting `index=True`. Neither dropping the index nor creating the default one has any impact on existing databases, so it's safe in a stable series. A new installation or a forced update will be necessary to benefit from the changes. Finally, because the bad custom index had the same name as the regular one, an upgrade script is foreseen to drop the old one before letting the ORM re-create it properly. 1: https://github.com/odoo/odoo/blob/a6e1eb9f0ad285fac7d0ca0b9f89f046d78ec9c7/odoo/addons/base/models/res_partner.py#L710 @Tecnativa TT26303 Closes #60346 Forward-Port-Of: odoo/odoo#60769 Forward-Port-Of: odoo/odoo#60476
Closing the Authorize.net popup with the little "x" doesn't call the responseHandler. Looking at the documentation (and source) of AcceptUI.js it seems there's no clean way to detect this. Because of this the "Pay & Confirm" button remains disabled, requiring the user to refresh the page. To solve this don't disable the button at all. Presumably it was added to avoid issues when spamming the button with clicks on a slow connection. But simulating this with a slow connection doesn't ca
Original PR description
Closing the Authorize.net popup with the little "x" doesn't call the responseHandler. Looking at the documentation (and source) of AcceptUI.js it seems there's no clean way to detect this. Because of this the "Pay & Confirm" button remains disabled, requiring the user to refresh the page. To solve this don't disable the button at all. Presumably it was added to avoid issues when spamming the button with clicks on a slow connection. But simulating this with a slow connection doesn't cause any issues. When AcceptJS is not yet loaded it's loaded with web.ajax.loadJS(). It correctly handles parallel calls before loading is finished and returns the same promise. AcceptJS correctly ignores subsequent click events on the button, because it immediately blocks all clicks on the body (and grays it out). Using a MutationObserver was also considered but this approach is much less messy. opw-2367166 Forward-Port-Of: odoo/odoo#60571
The method that generates the journal entry for the payroll is many complex, and is not easy to inherit to change some values if it´s necessary. Now, were split in 2 new methods: - To get the data to set on the journal items, to en sure that could be added any other value in the line if is caller from other module. - To allow change the way as verify if the debit/credit line exists. With this, is more easy extends the module, and avoid overwrite all the method if it´s necessary. For
Original PR description
The method that generates the journal entry for the payroll is many complex, and is not easy to inherit to change some values if it´s necessary. Now, were split in 2 new methods: - To get the data to set on the journal items, to en sure that could be added any other value in the line if is caller from other module. - To allow change the way as verify if the debit/credit line exists. With this, is more easy extends the module, and avoid overwrite all the method if it´s necessary. Forward-Port-Of: odoo/enterprise#13823
- Install helpdesk / sale_subscription - Ceate an internal user without any access rights - Go to `/my` A 500 error is raised because of an AccessError. When the user has no access rights to any of the mentioned applications, the `search` call returns an AccessError. We prevent the access error and return 0 as a fallback. opw-2367559 Forward-Port-Of: odoo/enterprise#14416 Forward-Port-Of: odoo/enterprise#14393
Original PR description
- Install helpdesk / sale_subscription - Ceate an internal user without any access rights - Go to `/my` A 500 error is raised because of an AccessError. When the user has no access rights to any of the mentioned applications, the `search` call returns an AccessError. We prevent the access error and return 0 as a fallback. opw-2367559 Forward-Port-Of: odoo/enterprise#14416 Forward-Port-Of: odoo/enterprise#14393
Steps to reproduce the bug: - Let's consider a service product P with price = 100€ - Create a customer invoice I with P on account 705000 - Post I - Go in the Compte de résultats Bug: The line 700-707 Ventes et prestations de services had a sub total at 0€ but the account 705000 Services rendered in Belgium was displayed below with 100€ opw:2365963 Forward-Port-Of: odoo/enterprise#14407
Original PR description
Steps to reproduce the bug: - Let's consider a service product P with price = 100€ - Create a customer invoice I with P on account 705000 - Post I - Go in the Compte de résultats Bug: The line 700-707 Ventes et prestations de services had a sub total at 0€ but the account 705000 Services rendered in Belgium was displayed below with 100€ opw:2365963 Forward-Port-Of: odoo/enterprise#14407
Steps to reproduce the bug: In 12.0, in the partner ledger report, the amls displayed for each partner were ordered by date In 13.0 , in the partner ledger report, the amls displayed for each partner are ordered by id To keep the consistancy, we still order the amls by date. opw:2352285 Forward-Port-Of: odoo/enterprise#14094 Forward-Port-Of: odoo/enterprise#13873
Original PR description
Steps to reproduce the bug: In 12.0, in the partner ledger report, the amls displayed for each partner were ordered by date In 13.0 , in the partner ledger report, the amls displayed for each partner are ordered by id To keep the consistancy, we still order the amls by date. opw:2352285 Forward-Port-Of: odoo/enterprise#14094 Forward-Port-Of: odoo/enterprise#13873
When we cancel an EDI invoice or payment, we are extracting relevant data from the CFDI in method _l10n_mx_edi_decode_cfdi. This method is expecting the cfdi data in argument, and not the signed edi object. opw-2365307 Forward-Port-Of: odoo/enterprise#14398
Original PR description
When we cancel an EDI invoice or payment, we are extracting relevant data from the CFDI in method _l10n_mx_edi_decode_cfdi. This method is expecting the cfdi data in argument, and not the signed edi object. opw-2365307 Forward-Port-Of: odoo/enterprise#14398
- Remove the email templates for the stages; - Create a new ticket; - Edit the ticket, and set the Customer to "Joel Willis" (or another Portal user); - Connect to the portal as the portal user; - Send a message on the ticket. Before this commit, an Error 403 forbidden was raised, this error occurs because the ticket don't have an access token created, this token will be created when an internal user send a message on the task. Now, the access token is created automatically when c
Original PR description
- Remove the email templates for the stages; - Create a new ticket; - Edit the ticket, and set the Customer to "Joel Willis" (or another Portal user); - Connect to the portal as the portal user; - Send a message on the ticket. Before this commit, an Error 403 forbidden was raised, this error occurs because the ticket don't have an access token created, this token will be created when an internal user send a message on the task. Now, the access token is created automatically when creating the ticket. opw-2361819 Forward-Port-Of: odoo/enterprise#14387
- Install account_asset - Accounting > Configuration > Asset Models - Create 2 Asset Models: * Select 2 different "Fixed Asset Account" of the same Type (i.e. "Current Assets" type) - Go to Accounting > Accounting > Assets and create a new Asset - In Asset form, for "Fixed Asset Account" field, select any account whose type is "Current Assets" - All Asset Models whose "Fixed Asset Account" is of type "Current Assets" will appear When a Asset Model is selected, all data of the Asset form
Original PR description
- Install account_asset - Accounting > Configuration > Asset Models - Create 2 Asset Models: * Select 2 different "Fixed Asset Account" of the same Type (i.e. "Current Assets" type) - Go to Accounting > Accounting > Assets and create a new Asset - In Asset form, for "Fixed Asset Account" field, select any account whose type is "Current Assets" - All Asset Models whose "Fixed Asset Account" is of type "Current Assets" will appear When a Asset Model is selected, all data of the Asset form is populated from the model, except "Fixed Asset Account". opw-2359413 Forward-Port-Of: odoo/enterprise#14386