Wednesday, November 10, 2021
25 changes · master
Enhancements to existing features
Notification emails using the lighter layout now include a clear link to view the related document, matching the standard email experience. The update also standardizes how email layouts are selected across apps, making notifications more consistent and easier to maintain.
Original PR description
PURPOSE Display "View document" link on notification emails using the 'light' layout as done in standard layout. Cleanup layout xml id propagation through composer or email sending in mail and…
PURPOSE Display "View document" link on notification emails using the 'light' layout as done in standard layout. Cleanup layout xml id propagation through composer or email sending in mail and various applications. SPECIFICATIONS: LAYOUT XML ID USAGE Get rid of context usage and use a real field on mail.compose.message model. Support old context key in composer for backward compatibility, working like a default value for the field itself. On template model: rename ``notif_layout`` parameter of ``send_mail`` to ``email_layout_xmlid`` to be coherent with naming used in other parts of the code. Moreover it better indicates we expect an xml id. On rating model: rename ``notif_layout`` parameter of ``rating_send_request`` to ``email_layout_xmlid``, for the same reasons as above. In various wizards: support ``email_layout_xmlid`` context key when no field is available, notably because this is still done manually in some wizards like survey invite. Keep a fallback on ``notif_layout`` but remove support of ``custom_layout`` deprecated since quite a long time. SPECIFICATIONS: ACCESS LINK Light template is used is several notification processes as an alternate layout to the classic one. It currently lacks any link to the document that generated the notifications. We add this behavior in this commit. Behavior is the same as the classic notification email, aka a link to mail/view that chooses what to do based on access rights and user status (internal, portal, ...). SPECIFICATIONS: MISC Remove ``mail_notification_borders`` as it is not used anymore. LINKS Task-2621326 (Mail: add 'view' button in 'light notification template') Task-2647302 (Mail: add layout field in composer
Gamification challenge pages now load more efficiently for companies with many users by showing participant counts instead of large user lists. The module files were also reorganized to make future maintenance easier, without changing the core business workflow.
Original PR description
PURPOSE
Gamification display is slow when being heavily used. Indeed the m2m towards
users is used in kanban and form views, leading to a huge data fetch when
being used in production environment with lots of users.
SPECIFICATIONS
Remove user_ids m2m from views. Indeed in some heavily used DBs you may have
more than 10K records in user_ids, leading to a huge m2m tags to display.
Replace it by an optimized count, used in
* form view: as a stat button redirecting to participants of a challenge;
* kanban view: a line (replacing the 11 first avatars) redirecting to
participants of a challenge;
Also of this commit is to rename and reorder views, data and models by main
model. It allows to better understand module organization and find views
one may have to update.
Task-2678295The SMS Marketing module icon was refreshed so it displays correctly in Odoo. This is a small visual cleanup that improves presentation without changing functionality.
Original PR description
mass_mailing_sms: text in svg icon wasn't flattened -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Timesheet Grid app icon has been updated so its image formats now match consistently. This improves visual consistency in the app listing and avoids confusion from mismatched branding.
Original PR description
timesheet_grid had a different icon for .png and .svg
Email notification layouts can now be selected and carried consistently through the message composer, reducing reliance on hidden context settings. This helps HR, payroll, planning, and signing workflows send clearer notification emails while preserving compatibility with existing behavior.
The Helpdesk dashboard has been reorganized to fit more naturally within the app layout, similar to the Lunch app. This improves usability and ensures the dashboard works better on mobile devices.
Original PR description
Purpose of the task is to refactor the helpdesk dashboard in order to have it as sibling element like in lunch app. also insure that it works well in mobile view too. TaskID: 2523259
Miscellaneous changes
This pull request does not include enough detail or changed file information to identify a specific business change. Based on the provided title, body, and commit message, it appears to be a placeholder or test submission with no clear user-facing impact.
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
Only purchaseable products are not searchable in the lines of debit notes and credit notes if this account moves are created from their tree view with the CREATE button. This changes make that this behavieour were also if we create this account moves from the buttons in the invoices "ADD CREDIT NOTE" and "ADD DEBIT NOTE". TASK: https://www.odoo.com/my/task/2543493 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Original PR description
Only purchaseable products are not searchable in the lines of debit notes and credit notes if this account moves are created from their tree view with the CREATE button. This changes make that this behavieour were also if we create this account moves from the buttons in the invoices "ADD CREDIT NOTE" and "ADD DEBIT NOTE". TASK: https://www.odoo.com/my/task/2543493 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#75610 Forward-Port-Of: odoo/odoo#75402
Forward-Port-Of: odoo/odoo#79461
Original PR description
Forward-Port-Of: odoo/odoo#79461
- Configure a Receipt Printer for POS - Create a Product with a long name (> 20 chars) and a big price (i.e. PRODUCT BCDEFGHMWPGHHH - price: 9999.00) - Create a Product with a short name (i.e. PRODUCT Z - price: 12.00) - Make a POS sale with long product first and short as second On the receipt, the line containing long product is too small to contain also its price. So the price will be on another line justified on the right. But the following product will be stacked on the same line, m
Original PR description
- Configure a Receipt Printer for POS - Create a Product with a long name (> 20 chars) and a big price (i.e. PRODUCT BCDEFGHMWPGHHH - price: 9999.00) - Create a Product with a short name (i.e. PRODUCT Z - price: 12.00) - Make a POS sale with long product first and short as second On the receipt, the line containing long product is too small to contain also its price. So the price will be on another line justified on the right. But the following product will be stacked on the same line, making the price on the receipt unreadable. Someting like this: PRODUCT BCDEFGHMWPGHHH PRODUCT Z 12.009999.00 The issue also appears for taxes lines and on the report of all sales of current POS session. This is due to a css style (float: right) applied to the price part. opw-2639120 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79583 Forward-Port-Of: odoo/odoo#79521
### Expected Behavior The _total amount_ and _total taxes amount_ in invoice, purchase order and offer should be formated with the correct formating options (related to the client's location), and with the correct currency symbol, as it was the case in V14 ### Observed behaviour In V15, these amount are written as pure numerical values (eg : 1452.24 instead of $1.452,24). This is the case in every generated pdf, as well as in the user portal preview(s), but not in classical form view(s).
Original PR description
### Expected Behavior The _total amount_ and _total taxes amount_ in invoice, purchase order and offer should be formated with the correct formating options (related to the client's location), and…
### Expected Behavior The _total amount_ and _total taxes amount_ in invoice, purchase order and offer should be formated with the correct formating options (related to the client's location), and with the correct currency symbol, as it was the case in V14 ### Observed behaviour In V15, these amount are written as pure numerical values (eg : 1452.24 instead of $1.452,24). This is the case in every generated pdf, as well as in the user portal preview(s), but not in classical form view(s). ### Reproducibility This bug can be reproduced following these steps: 1. Create a new invoice 2. Validate it 3. Preview it in the user portal of download the printable .pdf This can also be done with a purchase order, following the same steps. ### Problem Root Cause The problem comes from the fact we read the wrong fields, using `account.tax_totals.amount_total` and `account.tax_totals[subtotals].amount` instead of `account.tax_totals.formatted_amount_total` and `account.tax_totals[subtotals].formatted_amount`. ### Validation Cf attached files : - wrong_*.pdf : bugged version of invoice, order, ... printable PDF - valid_*.pdf : corrected version of invoice, order, ... printable PDF opw-2666924 opw-2666553 opw-2665130 [valid_bill.pdf](https://github.com/odoo/odoo/files/7346056/valid_bill.pdf) [valid_invoice.pdf](https://github.com/odoo/odoo/files/7346057/valid_invoice.pdf) [valid_order.pdf](https://github.com/odoo/odoo/files/7346058/valid_order.pdf) [wrong_invoice.pdf](https://github.com/odoo/odoo/files/7346059/wrong_invoice.pdf) [wrong_order.pdf](https://github.com/odoo/odoo/files/7346060/wrong_order.pdf) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78372
_Description of the issue/feature this PR addresses:_ If a concurrency error occurs, a request is retried up to 5 times with the same arguments. Retries are executed without the original context, leading to multi company errors and other errors _Current behavior before PR:_ kwargs is modified in-place _Desired behavior after PR is merged:_ kwargs is intact for reuse on retry. To demonstrate the problem, I altered a method to force a concurrency error. When first passing through http
Original PR description
_Description of the issue/feature this PR addresses:_ If a concurrency error occurs, a request is retried up to 5 times with the same arguments. Retries are executed without the original context,…
_Description of the issue/feature this PR addresses:_
If a concurrency error occurs, a request is retried up to 5 times with the same arguments. Retries are executed without the original context, leading to multi company errors and other errors
_Current behavior before PR:_
kwargs is modified in-place
_Desired behavior after PR is merged:_
kwargs is intact for reuse on retry.
To demonstrate the problem, I altered a method to force a concurrency error.
When first passing through https://github.com/odoo/odoo/blob/14.0/odoo/service/model.py#L94, here are the values of the arguments:
args: ()
kwargs: {'args': [[2]], 'kwargs': {'context': {'lang': 'en_US', 'tz': 'Europe/Amsterdam', 'uid': 2, 'allowed_company_ids': [2, 1]}}, 'method': 'update_module', 'model': 'base.module.update'}
The concurrency error occurs:
```
odoo.service.model: bla, retry 1/5 in 0.7940 sec...
```
At this point, the call is retried with the following values. Note the missing context:
args: ()
kwargs: {'args': [[2]], 'kwargs': {}, 'method': 'update_module', 'model': 'base.module.update'}
Retrying a call with a different context can lead to a different result in many cases.
opw-2679805
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#79566
Forward-Port-Of: odoo/odoo#79136The constrains on orderpoint location being related to the warehouseview location was too restrictiv especially in a complexe subcontracting flow with dropship. Thic commit change the constrains into a warning triggered at picking type onchange on the purchase order. 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 F
Original PR description
The constrains on orderpoint location being related to the warehouseview location was too restrictiv especially in a complexe subcontracting flow with dropship. Thic commit change the constrains into a warning triggered at picking type onchange on the purchase order. 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#79245 Forward-Port-Of: odoo/odoo#79126
Before this commit, automated actions could not raise "normal" errors anymore (e.g. UserError). Indeed, since the wowl refactoring, it always shows the custom BaseAutomationErrorDialog when an error is thrown in an automated action, even if it is a standard error well-known by the framework. Before the wowl refactoring, those errors were handled normally if possible, and when it wasn't the case, the custom BaseAutomationErrorDialog was used. This commit restores that behavior. Comple
Original PR description
Before this commit, automated actions could not raise "normal" errors anymore (e.g. UserError). Indeed, since the wowl refactoring, it always shows the custom BaseAutomationErrorDialog when an error…
Before this commit, automated actions could not raise "normal"
errors anymore (e.g. UserError). Indeed, since the wowl refactoring,
it always shows the custom BaseAutomationErrorDialog when an error
is thrown in an automated action, even if it is a standard error
well-known by the framework. Before the wowl refactoring, those
errors were handled normally if possible, and when it wasn't the
case, the custom BaseAutomationErrorDialog was used.
This commit restores that behavior.
Complete steps to reproduce:
- Install base_automation module
- Install an app for the base_automation to trigger (e.g. Sales)
- Turn on debug mode
- Go to Automated Actions
- Create an action with Action To Do is Execute Python Code and the Trigger is On Creation & Update
- Set the model to your app (e.g. SalesOrder)
- Put `raise UserError('Test')` in Python Code section
- Go back to the app, try to create a new record in the model you set for the automated action to trigger
- Compare the result with 14.0
Current behavior before PR:
- It will show an error dialog which show a message with RPC error
Desired behavior after PR is merged:
- It should show an User Warning like 14.0 version
Forward-Port-Of: odoo/odoo#79476Delete obsolete suggested_recipient_info with isCausal and ensure thread is required on it. This is intended to prevent crashing when creating a new partner from a lead. Task-2654859 Forward-Port-Of: odoo/odoo#77142
Original PR description
Delete obsolete suggested_recipient_info with isCausal and ensure thread is required on it. This is intended to prevent crashing when creating a new partner from a lead. Task-2654859 Forward-Port-Of: odoo/odoo#77142
Steps to reproduce : - Install website module - Activate (and translate website) French language - Go to translated terms and fetch for "Discard" in website module - Replace the translated value by "Ne pas sauvegarder" - Go to Website -> Configuration -> Websites - Select main website and change language to french then save - Go to Website and edit homepage - Add any block Issues : On top of editor sidebar, buttons are not displayed correctly. Solutions :
Original PR description
Steps to reproduce : - Install website module - Activate (and translate website) French language - Go to translated terms and fetch for "Discard" in website module - Replace the translated value by "Ne pas sauvegarder" - Go to Website -> Configuration -> Websites - Select main website and change language to french then save - Go to Website and edit homepage - Add any block Issues : On top of editor sidebar, buttons are not displayed correctly. Solutions : Add css class `d-flex` to the div around the buttons. opw-2683602 Forward-Port-Of: odoo/odoo#79570 Forward-Port-Of: odoo/odoo#79515
Steps to reproduce: - On a company with multi currency - Set the company currency rate to 1, and the foreign currency to 0.273748 - Create a vendor bill - Set first the foreign currency, then select a product with a tax to 21% and a price unit of 155.32 - Go to 'Journal Items', the 'tax paid' line debit is computed to 119.15 - Reselect the foreign currency on form. - Now the 'tax paid' line debit is computed to 119.16 The total is also impacted as the tax changed. Explanatio
Original PR description
Steps to reproduce: - On a company with multi currency - Set the company currency rate to 1, and the foreign currency to 0.273748 - Create a vendor bill - Set first the foreign currency, then select…
Steps to reproduce: - On a company with multi currency - Set the company currency rate to 1, and the foreign currency to 0.273748 - Create a vendor bill - Set first the foreign currency, then select a product with a tax to 21% and a price unit of 155.32 - Go to 'Journal Items', the 'tax paid' line debit is computed to 119.15 - Reselect the foreign currency on form. - Now the 'tax paid' line debit is computed to 119.16 The total is also impacted as the tax changed. Explanation: Before this commit, the taxes was both computed in foreign currency and company currency. However, when setting a new currency or changing the date, the taxes wasn't recomputed but the new conversion rate was applied. This commit is fixing the issue by applying the same logic as in 14.0: the taxes are always computed only the foreign currency, then the conversion rate is applied to get the accounting balance. opw-2569668 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79489 Forward-Port-Of: odoo/odoo#79065
closes https://github.com/odoo/odoo/issues/79229 Forward-Port-Of: odoo/odoo#79623 Forward-Port-Of: odoo/odoo#79606
Original PR description
closes https://github.com/odoo/odoo/issues/79229 Forward-Port-Of: odoo/odoo#79623 Forward-Port-Of: odoo/odoo#79606
Issue: When test sending a mail in Marketing Automation Mailings, there is a traceback because we try to set the state of the mail to done, even though there is no done in mail_mail.state Steps to reproduce : 1) Install Marketing Automation 2) Create/select a campaign 3) Access the templates of that campaign 4) Create/select a template 5) Click Test 6) Send Sample Email -> Traceback opw-2568210 Forward-Port-Of: odoo/odoo#79051 Forward-Port-Of: odoo/odoo#77299
Original PR description
Issue: When test sending a mail in Marketing Automation Mailings, there is a traceback because we try to set the state of the mail to done, even though there is no done in mail_mail.state Steps to reproduce : 1) Install Marketing Automation 2) Create/select a campaign 3) Access the templates of that campaign 4) Create/select a template 5) Click Test 6) Send Sample Email -> Traceback opw-2568210 Forward-Port-Of: odoo/odoo#79051 Forward-Port-Of: odoo/odoo#77299
…lds for inheritance purposes Before, when installing stock_picking_batch after l10n_it_stock_ddt, it would give a traceback because the header was replaced in a view in stock_picking_batch and that removed the invisible field that was used in an attrs in another place. So we add the field again in that other place. 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 an
Original PR description
…lds for inheritance purposes Before, when installing stock_picking_batch after l10n_it_stock_ddt, it would give a traceback because the header was replaced in a view in stock_picking_batch and that removed the invisible field that was used in an attrs in another place. So we add the field again in that other place. 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#79637
When the parent_financial_report is not present, options got overwritten anyway with the `account.financial.html.report()` defaults. A test has been added. There was also a bug in `_check_line_consistency`. While looping on records, it checked the `group_by` on the entire set instead of that of the specific record and that made the creation of multiple financial report line fail. Ticket link: https://www.odoo.com/web#id=2669650&model=project.task opw-2669650 Forward-Port-Of: odoo/ente
Original PR description
When the parent_financial_report is not present, options got overwritten anyway with the `account.financial.html.report()` defaults. A test has been added. There was also a bug in `_check_line_consistency`. While looping on records, it checked the `group_by` on the entire set instead of that of the specific record and that made the creation of multiple financial report line fail. Ticket link: https://www.odoo.com/web#id=2669650&model=project.task opw-2669650 Forward-Port-Of: odoo/enterprise#22191 Forward-Port-Of: odoo/enterprise#22058
Improve and clarify the link view by removing the readonly "action" field from the link journal lines. Also force to user to always either select or create journals for each account by himself. Forward-Port-Of: odoo/enterprise#22210 Forward-Port-Of: odoo/enterprise#21233
Original PR description
Improve and clarify the link view by removing the readonly "action" field from the link journal lines. Also force to user to always either select or create journals for each account by himself. Forward-Port-Of: odoo/enterprise#22210 Forward-Port-Of: odoo/enterprise#21233
Issue : the report "Partner VAT Intra" takes into account the account move lines without partner Reproduction : - create a journal entry without partner and with the tag +46L - open the report "Partner VAT Intra" -- > a line with an empty partner Note : It is also possible to create the entry via the POS like the client of this ticket did in this ticket 2604163 : - create or edit a product to use the tax "0% EU M. " (because it uses the tag +46L) - open a POS session, add th
Original PR description
Issue : the report "Partner VAT Intra" takes into account the account move lines without partner Reproduction : - create a journal entry without partner and with the tag +46L - open the report "Partner VAT Intra" -- > a line with an empty partner Note : It is also possible to create the entry via the POS like the client of this ticket did in this ticket 2604163 : - create or edit a product to use the tax "0% EU M. " (because it uses the tag +46L) - open a POS session, add this product, pay, close the session and post the journal entry Forward-Port-Of: odoo/enterprise#22148 Forward-Port-Of: odoo/enterprise#21360
Forward-Port-Of: odoo/enterprise#22150
Original PR description
Forward-Port-Of: odoo/enterprise#22150
Prior to this fix: When all team members were archived, the team was no more visible to Helpdesk users. After this fix: When archiving a user, it is removed from teams he belongs prior to archiving it. At the end, if the team has no members, the team will become visible to all users. We know that there could be cases in production database where there are already archived users in teams, which may lead to situations where the team won't be visible and this has been assessed as accep
Original PR description
Prior to this fix: When all team members were archived, the team was no more visible to Helpdesk users. After this fix: When archiving a user, it is removed from teams he belongs prior to archiving it. At the end, if the team has no members, the team will become visible to all users. We know that there could be cases in production database where there are already archived users in teams, which may lead to situations where the team won't be visible and this has been assessed as acceptable. task-2679855 Forward-Port-Of: odoo/enterprise#22187 Forward-Port-Of: odoo/enterprise#21953