Friday, June 4, 2021
27 changes · master
Enhancements to existing features
This change improves how Odoo prepares its internal business models by processing model inheritance more efficiently. It is aimed at reducing memory pressure and improving reliability during large database setup operations, especially in enterprise environments.
Original PR description
Test case: `env.registry.setup_models(env.cr)` on a full enterprise database.
The mail activity menu now presents its empty-state helper message centered vertically and uses clearer congratulatory wording. This makes the systray experience feel more polished when users have completed all activities.
Original PR description
PURPOSE - A helper should be aligned vertically in the systray menu. - A sentence should also be changed by "Congratulations, you're done with your activities." SPECIFICATION - no activity statement should be changed and also it should be appear in the middle of the dropdown task- 2525928 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mail notification timestamps now stay gray instead of turning green when a thread is unread or needs action. This creates a more consistent and less distracting systray notification view for users.
Original PR description
The timestamp color should be gray instead of primary green even when the thread is unread or needs action. Task id: 2383054
The mail app now uses a shared way to prepare attachment information, making it easier to reuse the same logic in other places. This is an internal improvement that helps keep attachment handling more consistent and easier to maintain.
Original PR description
This allows to reuse this formatter. Part of task-2365881
Resolved issues and error corrections
This fixes a frontend error that could occur when using Odoo in debug mode with certain template customizations. It improves reliability for users and developers working with customized web screens, without changing normal business workflows.
Original PR description
Owl 1 has some issues handling comments. So when people were in odoo debug mode, inheriting in extension mode a t template, the comment added from the server would throw a frontend error. For now, we comment it, waiting for better comment handling in owl.
Miscellaneous changes
987fc1190abaef33666620957fec42f6d011f148 had added a rule that made empty fields non-editable so that a snippetless website would not be editable. This makes empty t-fields non-editable as well which is - to say the least - not welcome. This commit fixes that problem by making the rule more restrictive: what we don't want to be able to edit are empty _arch_ field specifically. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo
Original PR description
987fc1190abaef33666620957fec42f6d011f148 had added a rule that made empty fields non-editable so that a snippetless website would not be editable. This makes empty t-fields non-editable as well which is - to say the least - not welcome. This commit fixes that problem by making the rule more restrictive: what we don't want to be able to edit are empty _arch_ field specifically. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71666
The portal task search now handles searches submitted with the Enter key more reliably. This prevents occasional mismatched results when users search within a selected category, improving consistency in the customer portal experience.
Original PR description
Before this commit, trying to search for elements in a given category in the searchbar of the tasks portal sometimes lead to an issue when using the enter key, if the form was submitted before trigger the search for the data. This commit adds a way to get rid of the form submission to avoid getting this issue. # Steps to reproduce 1. Go to the portal and open the tasks 2. Select "Project" in the searchbar dropdown 3. Search for anything, such as "Office", by using the enter key instead of clicking on the search button 4. See that, at times, the output received does not match what was expected Linked to task-2508883 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When l10n_latam_invoice_document is installed and the current company does not have a custom header (in stable, only Chile and Argentina with their localization installed use custom header), printing multiple invoice at once, one out of two had no header or footer. This is because `<div class="header"/>` and `<div class="footer"/>` should be unique per record being printed, and when a custom header was not used they were duplicated with the duplicate empty. As an example, if we had 3
Original PR description
When l10n_latam_invoice_document is installed and the current company does not have a custom header (in stable, only Chile and Argentina with their localization installed use custom header), printing…
When l10n_latam_invoice_document is installed and the current company does not have a custom header (in stable, only Chile and Argentina with their localization installed use custom header), printing multiple invoice at once, one out of two had no header or footer. This is because `<div class="header"/>` and `<div class="footer"/>` should be unique per record being printed, and when a custom header was not used they were duplicated with the duplicate empty. As an example, if we had 3 documents: - record 1 : good header - record 1 : empty header - record 1 : body - record 1 : good footer - record 1 : empty footer - record 2 : good header - record 2 : empty header - record 2 : body - record 2 : good footer - record 2 : empty footer - record 3 : good header - record 3 : empty header - record 3 : body - record 3 : good footer - record 3 : empty footer When we give them to wkhtmltopdf, it would be mismatched: - headers: - record 1 : good header - record 1 : empty header - record 2 : good header - bodies: - record 1 : body - record 2 : body - record 3 : body - footers: - record 1 : good footer - record 1 : empty footer - record 2 : good footer so record 2 will have empty header/footer, and record 3 will get those of record 2. opw-2507137 Forward-Port-Of: odoo/odoo#69686
If a payment request is made from a cron (e.g., Subscriptions' cron for recurring payments), the worker is not bound to an HTTP request and therefore the value of `request.httprequest.remote_addr` is an instance of the 'LocalProxy' object, which is not serializable. If we're in this scenario, don't send the customer's IP address. task-2494916 Co-authored-by: Toufik Ben Jaa <tbe@odoo.com> Forward-Port-Of: odoo/odoo#71683
Original PR description
If a payment request is made from a cron (e.g., Subscriptions' cron for recurring payments), the worker is not bound to an HTTP request and therefore the value of `request.httprequest.remote_addr` is an instance of the 'LocalProxy' object, which is not serializable. If we're in this scenario, don't send the customer's IP address. task-2494916 Co-authored-by: Toufik Ben Jaa <tbe@odoo.com> Forward-Port-Of: odoo/odoo#71683
This commit allows not to display the popover where we don't need it. Like on the next or prev buttons of the carousel for example. task-2537840 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#71198
Original PR description
This commit allows not to display the popover where we don't need it. Like on the next or prev buttons of the carousel for example. task-2537840 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#71198
- Create a Product Category: (i.e. Category X) * Costing Method: Average Cost (AVCO) * Inventory Valuation: Automated - Create a Consumable Product with Category X (i.e. Product X) - Create PO with Product X and receive products - On Product X form, update Cost - In debug mode, go to Accounting > Accounting > Journal Items Account move lines have been created for stock valuation on cost change, but it shouldn't for a consumable product. opw-2510315 Description of the issue/feat
Original PR description
- Create a Product Category: (i.e. Category X) * Costing Method: Average Cost (AVCO) * Inventory Valuation: Automated - Create a Consumable Product with Category X (i.e. Product X) - Create PO with Product X and receive products - On Product X form, update Cost - In debug mode, go to Accounting > Accounting > Journal Items Account move lines have been created for stock valuation on cost change, but it shouldn't for a consumable product. opw-2510315 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#71646
When the selected payment line is updated but is in state 'paid', it adds a new line with the first payment method. Since we load more payment methods than the ones in the pos config, we should only take the ones that are on the pos config 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#71695
Original PR description
When the selected payment line is updated but is in state 'paid', it adds a new line with the first payment method. Since we load more payment methods than the ones in the pos config, we should only take the ones that are on the pos config 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#71695
Currently, when go to project > settings > enable 'sub-tasks', create a task >> add a sub-task and archive the sub-task then the archived sub-task is still displayed in the sub-tasks list so in this commit, removed the active_test context from the field to hide the archived sub-task. PS: revert of the commit: https://github.com/odoo/odoo/commit/7a2cba3c8934064b311da4312ef2fbd07c6329ec As we would deduct archived tasks from the count and the number of planning hours, and keep them included
Original PR description
Currently, when go to project > settings > enable 'sub-tasks', create a task >> add a sub-task and archive the sub-task then the archived sub-task is still displayed in the sub-tasks list so in this commit, removed the active_test context from the field to hide the archived sub-task. PS: revert of the commit: https://github.com/odoo/odoo/commit/7a2cba3c8934064b311da4312ef2fbd07c6329ec As we would deduct archived tasks from the count and the number of planning hours, and keep them included in the timesheets. TaskID: 2534898 Forward-Port-Of: odoo/odoo#71407
- added test case for click on author name and on author avatar. task-2391179 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71698 Forward-Port-Of: odoo/odoo#70741
Original PR description
- added test case for click on author name and on author avatar. task-2391179 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71698 Forward-Port-Of: odoo/odoo#70741
Steps to reproduce the bug: - Go to elearning app > Courses > content - Create new slide > Upload a PDF file with faulty content Problem : Pypdf2 throws errors because it does not support some content or syntax. In our case we are just trying to get the number of pages in the PDF, so if we put `strict = false` we just determine that the user should not be informed of all the errors that pypdf2 encounters, the flag `strict` is not a security indicator. FYI: https://pythonhosted.org/Py
Original PR description
Steps to reproduce the bug: - Go to elearning app > Courses > content - Create new slide > Upload a PDF file with faulty content Problem : Pypdf2 throws errors because it does not support some content or syntax. In our case we are just trying to get the number of pages in the PDF, so if we put `strict = false` we just determine that the user should not be informed of all the errors that pypdf2 encounters, the flag `strict` is not a security indicator. FYI: https://pythonhosted.org/PyPDF2/PdfFileReader.html ``` strict (bool) - Determines whether user should be warned of all problems and also causes some correctable problems to be fatal. Defaults to True.``` opw-2530829 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71210
Steps: - Go to Point of Sale - Open a new session - Add an item to the cart - Click [+/-], [1] to get a negative price - Reload the page - Click Payment - Click Cash - Validate - Close the UI and go back to the backend - Click the three dots on the POS - Click View / Orders - Open the last order Bug: The order is still in "New" state and two payments of the same amount have been registered. This results in the order not being fully paid. Explanation: `get_change()` returns t
Original PR description
Steps: - Go to Point of Sale - Open a new session - Add an item to the cart - Click [+/-], [1] to get a negative price - Reload the page - Click Payment - Click Cash - Validate - Close the UI and go…
Steps: - Go to Point of Sale - Open a new session - Add an item to the cart - Click [+/-], [1] to get a negative price - Reload the page - Click Payment - Click Cash - Validate - Close the UI and go back to the backend - Click the three dots on the POS - Click View / Orders - Open the last order Bug: The order is still in "New" state and two payments of the same amount have been registered. This results in the order not being fully paid. Explanation: `get_change()` returns the amount to be given back to the customer. It's usually set back to 0 when the payment lines are created (e.g. when clicking "Cash"). `amount_return` is then sent to the backend with the order. However, when reloading the page before clicking "Cash", no payment lines are made and `amount_return` has been saved in LocalStorage with the result of `get_change()`. `amount_return`, which is usually undefined is now set back to its old value when reloading from the saved JSON. Because `amount_return` is not undefined in this case, it doesn't change the result sent in the JSON when clicking "Cash"; it's not updated with 0 from `get_change()`. This results in two payments being recorded in the order after validating and sending it to the backend. This commit always uses the result of `get_change()` when sending the order to the backend. opw:2446563 Forward-Port-Of: odoo/odoo#71733
When you are opening a POS session, a number corresponding to count of connection to this session is incremented, to be sure to have a unique identifier on receipts. In recent browsers, when you are reopening a recent tab (Ctrl+Shift+t) the browser will load the response of last request and won't perform the request. So the count of login won't be incremented, and this will result of duplication of receipt number. To avoid this behavior, we are explicitly say to the browser (through
Original PR description
When you are opening a POS session, a number corresponding to count of connection to this session is incremented, to be sure to have a unique identifier on receipts. In recent browsers, when you are reopening a recent tab (Ctrl+Shift+t) the browser will load the response of last request and won't perform the request. So the count of login won't be incremented, and this will result of duplication of receipt number. To avoid this behavior, we are explicitly say to the browser (through the response header) that we don't want to cache the request result. 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#71506
This commit updates owl to the latest release. It contains an improvement: the support for the t-tag directive, which allow us to have dynamic tagname in templates Release on github: https://github.com/odoo/owl/releases/tag/v1.3.0 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#71752
Original PR description
This commit updates owl to the latest release. It contains an improvement: the support for the t-tag directive, which allow us to have dynamic tagname in templates Release on github: https://github.com/odoo/owl/releases/tag/v1.3.0 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#71752
This is computed automatically since 04522f01e6fdbf82a657b32b312449fd7d756f79 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71755
Original PR description
This is computed automatically since 04522f01e6fdbf82a657b32b312449fd7d756f79 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71755
rounding_line_vals is invoked directly with a .create(), so the "currency_id" key's value should be an integer. See line 843. This is hard to catch, i use Sentry on my servers and i found this bug. I cannot provide steps to reproduce, as i just see this bug report in Sentry. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71641
Original PR description
rounding_line_vals is invoked directly with a .create(), so the "currency_id" key's value should be an integer. See line 843. This is hard to catch, i use Sentry on my servers and i found this bug. I cannot provide steps to reproduce, as i just see this bug report in Sentry. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71641
It doesn't make sense to try to get the padding from journal entries without a number (yet). Forward-Port-Of: odoo/enterprise#18716
Original PR description
It doesn't make sense to try to get the padding from journal entries without a number (yet). Forward-Port-Of: odoo/enterprise#18716
The social_facebook module is still using old API (v3.3) endpoints that are deprecated and will soon not be supported anymore by Facebook. This commit updates the various endpoints to use the latest version (10.0). Most of the changes just imply updating the URL from 3.3 to 10.0. Here are a couple exceptions: - The permissions were reviewed in API v7.0 and were split for more granularity See https://developers.facebook.com/docs/graph-api/changelog/version7.0/ This doesn't change m
Original PR description
The social_facebook module is still using old API (v3.3) endpoints that are deprecated and will soon not be supported anymore by Facebook. This commit updates the various endpoints to use the latest version (10.0). Most of the changes just imply updating the URL from 3.3 to 10.0. Here are a couple exceptions: - The permissions were reviewed in API v7.0 and were split for more granularity See https://developers.facebook.com/docs/graph-api/changelog/version7.0/ This doesn't change much for us, we just ask the new permissions names instead. - The '/photos' endpoint incorrectly saved the facebook_post_id Task-2551155 Forward-Port-Of: odoo/enterprise#18742 Forward-Port-Of: odoo/enterprise#18639
What are the steps to reproduce your issue ? 1. Go to timesheets/Timesheets to Validate 2. Go to month: May 3. Filter to month: March What is currently happening ? The data for the month of may are still present despite the filter What are you expecting to happen ? Only the data corresponding to the filter should remain How to fix the bug ? Add the missing filter domain to section grid opw-2497994 Forward-Port-Of: odoo/enterprise#18613
Original PR description
What are the steps to reproduce your issue ?
1. Go to timesheets/Timesheets to Validate
2. Go to month: May
3. Filter to month: March
What is currently happening ?
The data for the month of may are still present despite the filter
What are you expecting to happen ?
Only the data corresponding to the filter should remain
How to fix the bug ?
Add the missing filter domain to section grid
opw-2497994
Forward-Port-Of: odoo/enterprise#18613Forward-Port-Of: odoo/enterprise#18667
Original PR description
Forward-Port-Of: odoo/enterprise#18667
- The line feeds are not strictly necessary in Spain, but they are needed for certain regions (per LANDOO: Navarra, Gipuzkoa and possibly Euskadi) It is not mandatory in Spain (AEAT) but it is nonetheless permitted. - As well, the previous_report_number field was corrected to output as a numeric field, per the AEAT documentation (https://www.agenciatributaria.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_20/DR_Anexo_349.pdf) opw-2300236 Forward-Port-Of: odoo/enterprise#15362
Original PR description
- The line feeds are not strictly necessary in Spain, but they are needed for certain regions (per LANDOO: Navarra, Gipuzkoa and possibly Euskadi) It is not mandatory in Spain (AEAT) but it is nonetheless permitted. - As well, the previous_report_number field was corrected to output as a numeric field, per the AEAT documentation (https://www.agenciatributaria.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_20/DR_Anexo_349.pdf) opw-2300236 Forward-Port-Of: odoo/enterprise#15362
Purpose of the commit is to include the timesheet of archived subtask while computing the effective_hours of slot. Related Community PR: https://github.com/odoo/odoo/pull/71407 TaskID: 2534898 Forward-Port-Of: odoo/enterprise#18678
Original PR description
Purpose of the commit is to include the timesheet of archived subtask while computing the effective_hours of slot. Related Community PR: https://github.com/odoo/odoo/pull/71407 TaskID: 2534898 Forward-Port-Of: odoo/enterprise#18678
If a tax has been predicted based on the description of an invoice line, we shouldn't add the tax detected by the OCR if they match. We keep the predicted tax in priority. We also need to remove any predicted tax that wasn't found by the OCR. opw: 2526617 Forward-Port-Of: odoo/enterprise#18674
Original PR description
If a tax has been predicted based on the description of an invoice line, we shouldn't add the tax detected by the OCR if they match. We keep the predicted tax in priority. We also need to remove any predicted tax that wasn't found by the OCR. opw: 2526617 Forward-Port-Of: odoo/enterprise#18674