Monday, October 4, 2021
48 changes · master
Security fixes and vulnerability patches
Event booth registration now shows the success page through an in-page update instead of redirecting to a reusable link. This improves privacy by preventing others from opening a previous success link to see renter details, while also making the registration flow slightly faster and more polished.
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
Enhancements to existing features
This change makes it easier for country-specific or custom modules to adjust information when creating stock return transfers. It helps businesses adapt return workflows to local or specialized requirements with less custom development effort.
Original PR description
Description of the issue/feature this PR addresses: On some country or custom modules is need pass values before create picking, this PR has as objective facilite inheritance 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
Resolved issues and error corrections
When an employee or applicant signs a contract through the salary simulation link, their job title and department are now carried over correctly. This keeps employee and contract records aligned automatically, reducing manual HR follow-up and data inconsistencies.
Original PR description
[FIX] hr_contract_salary: Update of the job title and department once the contract is signed This fix adds job_id and department_id to the wizard "Generate Simulation Link". Both fields are many2one fields respectively linked to hr.job and hr.department Once the applicant/employee clicks on Review Contract & Sign via the Generate Simulation Link, the department_id is updated on the employee form (hr.employee) and contract form (hr.contract). The job_id is also updated on the employee form (hr.employee) in the HR Settings tab Task-26164446
Miscellaneous changes
Facturx expects line price to be subtotal, not unit price. Odoo parser is also dividing the gross price by quantity. So before this commit, importing PDF invoice rendered by Odoo, results in: unit price / quantity. The bug was introduced in odoo/odoo#53894 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76988 Forward-Port-Of: odoo/odoo#70785
Original PR description
Facturx expects line price to be subtotal, not unit price. Odoo parser is also dividing the gross price by quantity. So before this commit, importing PDF invoice rendered by Odoo, results in: unit price / quantity. The bug was introduced in odoo/odoo#53894 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76988 Forward-Port-Of: odoo/odoo#70785
This change makes the expense payment process easier for developers to extend when creating payments from expenses. It helps businesses adapt expense payment workflows to specific needs with lower customization effort and reduced maintenance risk.
Original PR description
Description of the issue/feature this PR addresses: similar to payment create on https://github.com/odoo/odoo/blob/master/addons/hr_expense/wizard/hr_expense_sheet_register_payment.py#L112 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
Website editors can now choose how steps are visually connected in process step snippets, including no connector, lines, straight arrows, or curved arrows. They can also set connector colors, making it easier to match page designs and improve visual clarity.
Original PR description
Currently, step snippets' connector is a line. Even if simplicity is the key to beauty, we wanted to add more options : - No connector; - Line - Straight Arrows - Curved Arrows Moreover, an option has been added to select the color of the connector itself. _OLD PR : https://github.com/odoo/odoo/pull/69127/files_
The Time Off dashboard now lets users delete a leave request directly from the year-view popup, alongside saving or discarding changes. This restores an action that was available in the previous month view and reduces extra navigation for HR users and employees.
Original PR description
Description of the issue/feature this PR addresses: In the previous version, the hr_holidays had the month view by default. It was possible to edit/delete a time off directly by clicking on the time off. Now the landing page is year view. The popup form for the leave has a save and discard button but no delete. Current behavior before PR: The popup form on the year view has a save and discard button but no delete button Desired behavior after PR is merged: The popup form on the year view has save, discard and delete buttons task-2638305 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds automated validation to ensure recurring project subtasks are copied correctly. It helps protect future changes to task recurrence logic by confirming deep subtask structures and recurrence settings behave as expected.
Original PR description
This commit adds a test in order to strengthen the behaviour of recurring subtasks. This test asserts that child with depth > 3 are not copied in a recurrence, that recurrent subtask are well copied with the recurrence correctly set. This commit prepares the recurrence refactoring. task-2660756 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
The employee car report has been improved so the Cars button now opens the vehicle assignment history for the selected driver. This helps HR and fleet teams quickly see who had which company car and when, reducing confusion from an unreliable report action.
Original PR description
The "Claim Car Report" action was not working as expected. Now the statbutton "Cars" will show the car history of a specific driver. TaskID: 2646113 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
The payment form now supports receipt payments where no customer or vendor is selected. This prevents an error when opening payment details or related statistics, making the accounting workflow more flexible for cases where a partner is not needed.
Original PR description
- Create a payment without a partner for a receipt - Go to the form view - Click on the stats button. => Error, 'partner_id' is required In some cases, having the partner not required on the view is needed. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The CRM lead form now shows the Customer field when a customer is already linked, while keeping it hidden for typical unassigned leads unless debug mode is active. This helps users understand when lead contact details may also update the linked customer record, reducing confusion during lead management.
Original PR description
PURPOSE To display partner_id when it has value in lead form view. SPECIFICATION Current: It show partner_id in debug mode only. To be: It should display partner_id when its value is set and also display in debug mode if value is not set. Task id: 2596955 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website accordion snippet now offers additional visual styles and more control over where the expand or collapse icon appears. This gives website editors more flexibility to match accordion sections, such as FAQs, to their page design without custom development.
Original PR description
task-2457232
Users now receive clear explanations when they try to delete event questions or answer options that attendees have already used. This helps prevent confusion while protecting historical attendee response data from becoming incomplete.
Original PR description
PURPOSE If we try to delete an answer which is already been selected by attendees, odoo will throw a validation error "There must be suggested value or text value", it is because the attendees with those answers are "broken" by this change since their answer disappears. Same thing happens if we try to delete a question which is already answered. SPECIFICATION There is no way we could let the user do delete that because all "historic" attendees need to refer to this answer/question record (or they would be empty) , But we should at the very least catch this and provide a clearer error message. So in this commit we will updated the error message as "You cannot delete an answer that has already been selected by attendees." if they try to delete answer and "You cannot delete a question that has already been answered by attendees." if they try to delete questions. LINKS PR #76265 Task 2635599
This update fixes issues affecting electronic invoicing services for Peru and invoice cancellation flows for Mexico. It helps ensure local compliance processes work correctly and improves test coverage for these country-specific workflows.
Related: https://github.com/odoo/enterprise/pull/21035 (initial PR from sri : #75302) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76892
Original PR description
Related: https://github.com/odoo/enterprise/pull/21035 (initial PR from sri : #75302) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76892
Before this commit, in the search bar menu, an item did not expanded if you moved the mouse or navigated with the arrows before it was expanded. This is the steps to reproduce the problem: 1. Click on the caret of an item 2. Move the mouse before the menu is expanded 3. The item did not expand. 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
Original PR description
Before this commit, in the search bar menu, an item did not expanded if you moved the mouse or navigated with the arrows before it was expanded. This is the steps to reproduce the problem: 1. Click on the caret of an item 2. Move the mouse before the menu is expanded 3. The item did not expand. 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#77502
"Rounded" and "Flat" buttons didn't have their proper styling if the website module was not installed. Styles for rounded and flat buttons have been added to theme_default.scss -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#77612
Original PR description
"Rounded" and "Flat" buttons didn't have their proper styling if the website module was not installed. Styles for rounded and flat buttons have been added to theme_default.scss -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#77612
No menu allowed viewing all tax groups at once before. With the new subtotals features, it could become painful for the user if he wanted to change the groups' sequence in order reorder subtotals on his invoices (he had to change the sequence manually on each group, accessing their form view through taxes using them). It is now possible in the tree view opened by our new menu, with the sequence widget. Forward-Port-Of: odoo/odoo#77629
Original PR description
No menu allowed viewing all tax groups at once before. With the new subtotals features, it could become painful for the user if he wanted to change the groups' sequence in order reorder subtotals on his invoices (he had to change the sequence manually on each group, accessing their form view through taxes using them). It is now possible in the tree view opened by our new menu, with the sequence widget. Forward-Port-Of: odoo/odoo#77629
Steps to reproduce the bug: - Create a promotional program P with 'Fixed amount' discount of $50 and 'Automatically applied' on current order - Create SO and cancel it Bug: P was applied on the canceled SO opw:2579344 Forward-Port-Of: odoo/odoo#77364
Original PR description
Steps to reproduce the bug: - Create a promotional program P with 'Fixed amount' discount of $50 and 'Automatically applied' on current order - Create SO and cancel it Bug: P was applied on the canceled SO opw:2579344 Forward-Port-Of: odoo/odoo#77364
When invoicing via POS delivery address is missing on the invoice. This value is needed in some localizations (i.e. l10n_co) to correctly validate the invoice opw-2653661 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#77393
Original PR description
When invoicing via POS delivery address is missing on the invoice. This value is needed in some localizations (i.e. l10n_co) to correctly validate the invoice opw-2653661 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#77393
Issue: With margin enabled and avco for stock valuation, after confirming a SO with a product variant which is a bom kit, when we try to change the variant, there is a traceback Steps to reproduce : 1) Install Stock, Accounting, MRP, Sale, 2) Enable Margins in settings 3) Configure a Product Category with costing method AVCO 4) Configure a Product with 2 variants and that product category 5) [Important: KIT] Create 2 BoM, one for each variant and set those BoM to KIT 6) Create a SO
Original PR description
Issue: With margin enabled and avco for stock valuation, after confirming a SO with a product variant which is a bom kit, when we try to change the variant, there is a traceback Steps to reproduce :…
Issue: With margin enabled and avco for stock valuation, after confirming a SO with a product variant which is a bom kit, when we try to change the variant, there is a traceback Steps to reproduce : 1) Install Stock, Accounting, MRP, Sale, 2) Enable Margins in settings 3) Configure a Product Category with costing method AVCO 4) Configure a Product with 2 variants and that product category 5) [Important: KIT] Create 2 BoM, one for each variant and set those BoM to KIT 6) Create a SO for that product and one variant 7) Confirm the SO, cancel it, and set to quotation 8) Edit the SO and change the variant, save -> Traceback Side-Note: This issue is due to the fact that we iterate over the stock_moves to find the quantity of the BoM, but that stock_move correspond to confirming at step 7, when we change the variant at step 8, the stock move has not changed, so still contains the previous bom_line_id with the quantity, but this doesn't reflect with the new state of the SO which is for a different variant. For me since the stock move is canceled, it should be taken into consideration when computing the average price but I might be wrong, it's up to the reviewer to decide if it makes sense opw-2639093 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#76723
* = test_discuss_full Before this commit if 2 persons are joining the call at the exact same time, the join RPC of each will return the list of RTC sessions without the other person included. In more general terms, the server should actually rarely send the full state to the JS (in this case "use the replace command") because there is no guarantee that a concurrent transaction is not changing the data at the same time. In other words, even the python is actually working with partial k
Original PR description
* = test_discuss_full Before this commit if 2 persons are joining the call at the exact same time, the join RPC of each will return the list of RTC sessions without the other person included. In more general terms, the server should actually rarely send the full state to the JS (in this case "use the replace command") because there is no guarantee that a concurrent transaction is not changing the data at the same time. In other words, even the python is actually working with partial knowledge relatively to the database. Using a DB lock would guarantee it, but we don't want to lock tables and wait on locks if there are alternatives. In this case it is acceptable to keep obsolete sessions for a little bit longer, as long as they are cleared eventually. Forward-Port-Of: odoo/odoo#77514
[IMP] account: improve fiscal positions' form view The 'Country Group' field should be displayed under the 'foreign VAT' one, so that it its grouped together with 'Country' and 'Federal states'. [IMP] account: forbid creating multiple foreign VAT fiscal positions for the same region Having the same VAT fiscal position for the same region multiple times doesn't make sense and is not supported by the report enfinge. We should prevent that. Forward-Port-Of: odoo/odoo#77637
Original PR description
[IMP] account: improve fiscal positions' form view The 'Country Group' field should be displayed under the 'foreign VAT' one, so that it its grouped together with 'Country' and 'Federal states'. [IMP] account: forbid creating multiple foreign VAT fiscal positions for the same region Having the same VAT fiscal position for the same region multiple times doesn't make sense and is not supported by the report enfinge. We should prevent that. Forward-Port-Of: odoo/odoo#77637
This brings a series of improvements to the mechanism in place to convert the output html of mass mailing into html that is more compliant with the main mail clients' requirements. The biggest change is the automatic conversion of Bootstrap grids into table structures. Currently all templates in `mass_mailing` are designed with tables so they work in mailings as is. That has limitations though as it makes it less easy to edit with snippets such as those used in the website builder. This new a
Original PR description
This brings a series of improvements to the mechanism in place to convert the output html of mass mailing into html that is more compliant with the main mail clients' requirements. The biggest change…
This brings a series of improvements to the mechanism in place to convert the output html of mass mailing into html that is more compliant with the main mail clients' requirements.
The biggest change is the automatic conversion of Bootstrap grids into table structures. Currently all templates in `mass_mailing` are designed with tables so they work in mailings as is. That has limitations though as it makes it less easy to edit with snippets such as those used in the website builder. This new automatic conversion from Bootstrap grid will allow us to adapt the mailing and snippet templates and be more free within `mass_mailing`.
Note: Because of the limited support of media queries in emails, this doesn't support the mixing and matching of column options (e.g., `"col-4 col-sm-6"` and `"col col-4"` aren't supported).
Other changes include:
- The conversion of Bootstrap cards to table structures
- The conversion of Bootstrap list-groups to table structures
- The conversion of snippets (.o_mail_snippet_general) and mailings
(.o_layout) into table structures
- The conversion of all rgb colors to hexadecimal
- The conversion of all "rem" sizes to "px"
- Various small corrections to the output styles
The new automatic conversion from Bootstrap grid to tables allows us to convert `mass_mailing` templates from their old table structures to Bootstrap grid (as the reverse conversion will now be applied on save).
General heuristic for the conversion of templates:
| **Table** | **Bootstrap** |
|:-------------------:|:------------------------------------------:|
| `<table>` | `<div class="container">` |
| `<thead>` | _(removed)_ |
| `<tbody>` | _(removed)_ |
| `<tfoot>` | _(removed)_ |
| `<tr>` | `<div class="row">` |
| `<th>` | `<div class="col o_col_head">` |
| `<td>` | `<div class="col">` |
| `<td width="_n_%">` | `<div class="col-_o_">` where o ~= 12n/100 |
| `cellspacing` | _(removed but always added back to table)_ |
| `cellpadding` | _(removed but always added back to table)_ |
| `border` | _(removed but always added back to table)_ |
Some styles had to be changed to account for the difference in the HTML.
Mailings were limited to 600px width by default. This removes that limit in order to give snippets control over the margins.
The following snippets (and their relevant options) were added to `mass_mailing`, mostly duplicated from the website builder:
- s_cover
- s_title
- s_text_block
- s_comparisons
- s_color_blocks_2
- s_three_columns
- s_image_text
- s_text_image
- s_picture
- s_features
- s_numbers
- s_masonry_block
- s_media_list
- s_showcase
- s_company_team
- s_call_to_action
- s_references
- s_product_list
- s_features_grid
- s_alert
- s_rating
- s_blockquote
- s_hr
- s_text_highlight
The following snippets were removed to make way for the new:
- s_mail_block_banner
- s_mail_block_title_sub
- s_mail_block_paragraph
- s_mail_block_comparison_table
- s_mail_block_two_cols
- s_mail_block_three_cols
- s_mail_block_image_text
- s_mail_block_text_image
- s_mail_block_image
- s_mail_block_footer_separator
- s_mail_block_footer_tag_line
- s_mail_block_steps
The following standalone snippet options were added, mostly duplicated from the website builder:
- Box
- layout_column
- SnippetMove
- snippet_options_text_align (via web_editor)
- snippet_options_width (via web_editor)
- snippet_options_block_align (via web_editor)
- BodyWidth (based on ContainerWidth but only for the mailing's body)
- minHeight
- so_snippet_addition
- so_content_addition
- sizing_x
- vAlignment
Styles and selectors were adapted to the specifics of `mass_mailing`.
`mass_mailing_table_item` was charged with ensuring proper cloning and removing of table elements precisely because `mass_mailing` relied so heavily on them. Since it doesn't anymore, there is no need for that option. This removes it.
Prior to this PR, it was possible to drop snippets out of the confines of the mailing's body and into its editable parent instead. This makes that impossible.
The feature to drop snippets to the nearest allowed position was broken in iframes because of a reference to a JQuery contained in a different document than the editable area. This restores the feature in all cases.
`we-button`s, `we-toggler`s and `we-select-items` with no text content don't properly take up their full height in iframes. This solves that issue by ensuring a text content at all time, albeit an invisible one. This is a bit of hacky solution perhaps but one that consistently works across browsers.
Transparency is not supported in several leading mail clients. This adds the option to completely remove transparent colors from the palette, and uses that option in `mass_mailing`.
A new, empty template to `mass_mailing` was created, in which snippets can be dropped, to start an HTML mailing from scratch.
A default background color is applied to all HTML mailings in order to emphasize the separation between the mailing itself and its body.
A series of CSS styles were added to the `<head>` of mailings in order to ensure better mail client compatibility.
task-2554899
Enterprise PR: https://github.com/odoo/enterprise/pull/21215
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#77312The body of a mailing is saved in two fields: body_arch without modifications, and body_html with conversion for email client compatibility. Prior to this commit, we were showing body_html when opening the form view of a saved mailing in readonly. This was pretty strange and confusing as it's a sort of intermediary version that doesn't mean much: an in-browser rendering of html that is compiled for email clients. With this commit, we change the view to always show body_arch instead. A new tab
Original PR description
The body of a mailing is saved in two fields: body_arch without modifications, and body_html with conversion for email client compatibility. Prior to this commit, we were showing body_html when…
The body of a mailing is saved in two fields: body_arch without modifications, and body_html with conversion for email client compatibility. Prior to this commit, we were showing body_html when opening the form view of a saved mailing in readonly. This was pretty strange and confusing as it's a sort of intermediary version that doesn't mean much: an in-browser rendering of html that is compiled for email clients. With this commit, we change the view to always show body_arch instead. A new tab is introduced in order to show body_html for debugging, which is therefore only visible in debug mode. This made a pre-existing bug more visible, where the iframe glitches on load: when loading a field html iframe, there are sometimes display glitches due to the iframe's contents and assets loading lazily. This prevents those glitches by hiding the iframe until it is fully loaded, creating a better user experience. A couple of obvious bad behaviors of the transpiler were also fixed. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#77592
These encode/decode shenanigans seem to be unnecessary since we are not using summernote anymore. Moreover, the encode process was destroying the html structure of nodes contained in the link, only making a special case to maintain images. This is not sufficient anymore because the Cards option of website mega menu does make use of custom html content inside a link. This content was therefore destroyed on edition and replaced by its textContent because of the encode
Original PR description
These encode/decode shenanigans seem to be unnecessary since we are not
using summernote anymore. Moreover, the encode process was destroying
the html structure of nodes contained in the link, only making a special
case to maintain images. This is not sufficient anymore because the
Cards option of website mega menu does make use of custom html content
inside a link. This content was therefore destroyed on edition and
replaced by its textContent because of the encode function.
Forward-Port-Of: odoo/odoo#77497The exists method (of BaseModel) doesn't work with model without SQL table but with a table query (see f2ceef0) This method is call when we try to read a forbidden record (`forbidden = missing.exists()` in `_read`) - Fix it by using a Query object (which able the case). - Also use a partition method instead of duplicate it in the method. - Fix the CRM Lead Report which can return a Falsy id task-2633558 Forward-Port-Of: odoo/odoo#77618 Forward-Port-Of: odoo/odoo#77473
Original PR description
The exists method (of BaseModel) doesn't work with model without SQL table but with a table query (see f2ceef0) This method is call when we try to read a forbidden record (`forbidden = missing.exists()` in `_read`) - Fix it by using a Query object (which able the case). - Also use a partition method instead of duplicate it in the method. - Fix the CRM Lead Report which can return a Falsy id task-2633558 Forward-Port-Of: odoo/odoo#77618 Forward-Port-Of: odoo/odoo#77473
The img nodes where being wrongly considered empty by isShrunkNode because the image was not loaded yet. Forward-Port-Of: odoo/odoo#77588
Original PR description
The img nodes where being wrongly considered empty by isShrunkNode because the image was not loaded yet. Forward-Port-Of: odoo/odoo#77588
Description of the issue/feature this PR addresses: Ugly usage of self inside a for loop. Current behavior before PR: `_get_batches` is called on `self` Desired behavior after PR is merged: `_get_batches` is called on `wizard` -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#77583
Original PR description
Description of the issue/feature this PR addresses: Ugly usage of self inside a for loop. Current behavior before PR: `_get_batches` is called on `self` Desired behavior after PR is merged: `_get_batches` is called on `wizard` -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#77583
- Create 3 websites and set a website domain for each - Install the website_links module - Go to Website > Configuration > Settings - Select the website 3 - Go to website - Menu Promote > Link tracking The URL field uses the domain you are logged into the database rather than the domain of the active website opw-2638494 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the
Original PR description
- Create 3 websites and set a website domain for each - Install the website_links module - Go to Website > Configuration > Settings - Select the website 3 - Go to website - Menu Promote > Link tracking The URL field uses the domain you are logged into the database rather than the domain of the active website opw-2638494 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#77245 Forward-Port-Of: odoo/odoo#76551
Step to follow: - Create an Asset Models - Set up the Fixed Asset Account: Automate Asset -> Create in draft or Create and validate Asset Model -> The one you have just created - Create a Vendor bill Account -> the Fixed Asset Account of the asset model created Label -> insert a newline Price -> (do not forget to set a price) - Validate - Go to the asset automatically created - @ mention a user in the chatter Cause of the issue: The generated email subject comes from t
Original PR description
Step to follow: - Create an Asset Models - Set up the Fixed Asset Account: Automate Asset -> Create in draft or Create and validate Asset Model -> The one you have just created - Create a Vendor bill Account -> the Fixed Asset Account of the asset model created Label -> insert a newline Price -> (do not forget to set a price) - Validate - Go to the asset automatically created - @ mention a user in the chatter Cause of the issue: The generated email subject comes from the record_name and it can contain newlines Email headers don't allow newlines and an exception is thrown here https://github.com/python/cpython/blob/60b93d9e4922eeae25052bc15909d1f4152babde/Lib/email/policy.py#L143 Solution Replace newlines by spaces in the email subject opw-2522055 Forward-Port-Of: odoo/odoo#77611 Forward-Port-Of: odoo/odoo#75394
opw-2654793 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#77628
Original PR description
opw-2654793 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#77628
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#77415
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#77415
This brings a series of improvements to the mechanism in place to convert the output html of mass mailing into html that is more compliant with the main mail clients' requirements. The biggest change is the automatic conversion of Bootstrap grids into table structures. Currently all templates in `mass_mailing` are designed with tables so they work in mailings as is. That has limitations though as it makes it less easy to edit with snippets such as those used in the website builder. This new a
Original PR description
This brings a series of improvements to the mechanism in place to convert the output html of mass mailing into html that is more compliant with the main mail clients' requirements. The biggest change…
This brings a series of improvements to the mechanism in place to convert the output html of mass mailing into html that is more compliant with the main mail clients' requirements.
The biggest change is the automatic conversion of Bootstrap grids into table structures. Currently all templates in `mass_mailing` are designed with tables so they work in mailings as is. That has limitations though as it makes it less easy to edit with snippets such as those used in the website builder. This new automatic conversion from Bootstrap grid will allow us to adapt the mailing and snippet templates and be more free within `mass_mailing`.
Note: Because of the limited support of media queries in emails, this doesn't support the mixing and matching of column options (e.g., `"col-4 col-sm-6"` and `"col col-4"` aren't supported).
Other changes include:
- The conversion of Bootstrap cards to table structures
- The conversion of Bootstrap list-groups to table structures
- The conversion of snippets (.o_mail_snippet_general) and mailings
(.o_layout) into table structures
- The conversion of all rgb colors to hexadecimal
- The conversion of all "rem" sizes to "px"
- Various small corrections to the output styles
The new automatic conversion from Bootstrap grid to tables allows us to convert `mass_mailing` templates from their old table structures to Bootstrap grid (as the reverse conversion will now be applied on save).
General heuristic for the conversion of templates:
| **Table** | **Bootstrap** |
|:-------------------:|:------------------------------------------:|
| `<table>` | `<div class="container">` |
| `<thead>` | _(removed)_ |
| `<tbody>` | _(removed)_ |
| `<tfoot>` | _(removed)_ |
| `<tr>` | `<div class="row">` |
| `<th>` | `<div class="col o_col_head">` |
| `<td>` | `<div class="col">` |
| `<td width="_n_%">` | `<div class="col-_o_">` where o ~= 12n/100 |
| `cellspacing` | _(removed but always added back to table)_ |
| `cellpadding` | _(removed but always added back to table)_ |
| `border` | _(removed but always added back to table)_ |
Some styles had to be changed to account for the difference in the HTML.
Mailings were limited to 600px width by default. This removes that limit in order to give snippets control over the margins.
The following snippets (and their relevant options) were added to `mass_mailing`, mostly duplicated from the website builder:
- s_cover
- s_title
- s_text_block
- s_comparisons
- s_color_blocks_2
- s_three_columns
- s_image_text
- s_text_image
- s_picture
- s_features
- s_numbers
- s_masonry_block
- s_media_list
- s_showcase
- s_company_team
- s_call_to_action
- s_references
- s_product_list
- s_features_grid
- s_alert
- s_rating
- s_blockquote
- s_hr
- s_text_highlight
The following snippets were removed to make way for the new:
- s_mail_block_banner
- s_mail_block_title_sub
- s_mail_block_paragraph
- s_mail_block_comparison_table
- s_mail_block_two_cols
- s_mail_block_three_cols
- s_mail_block_image_text
- s_mail_block_text_image
- s_mail_block_image
- s_mail_block_footer_separator
- s_mail_block_footer_tag_line
- s_mail_block_steps
The following standalone snippet options were added, mostly duplicated from the website builder:
- Box
- layout_column
- SnippetMove
- snippet_options_text_align (via web_editor)
- snippet_options_width (via web_editor)
- snippet_options_block_align (via web_editor)
- BodyWidth (based on ContainerWidth but only for the mailing's body)
- minHeight
- so_snippet_addition
- so_content_addition
- sizing_x
- vAlignment
Styles and selectors were adapted to the specifics of `mass_mailing`.
`mass_mailing_table_item` was charged with ensuring proper cloning and removing of table elements precisely because `mass_mailing` relied so heavily on them. Since it doesn't anymore, there is no need for that option. This removes it.
Prior to this PR, it was possible to drop snippets out of the confines of the mailing's body and into its editable parent instead. This makes that impossible.
The feature to drop snippets to the nearest allowed position was broken in iframes because of a reference to a JQuery contained in a different document than the editable area. This restores the feature in all cases.
`we-button`s, `we-toggler`s and `we-select-items` with no text content don't properly take up their full height in iframes. This solves that issue by ensuring a text content at all time, albeit an invisible one. This is a bit of hacky solution perhaps but one that consistently works across browsers.
Transparency is not supported in several leading mail clients. This adds the option to completely remove transparent colors from the palette, and uses that option in `mass_mailing`.
A new, empty template to `mass_mailing` was created, in which snippets can be dropped, to start an HTML mailing from scratch.
A default background color is applied to all HTML mailings in order to emphasize the separation between the mailing itself and its body.
A series of CSS styles were added to the `<head>` of mailings in order to ensure better mail client compatibility.
task-2554899
Enterprise PR: https://github.com/odoo/enterprise/pull/21215
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#77312 and odoo/odoo#77634 and odoo/odoo##77592The `callback_hash` and `callback_is_done` fields are not accessible for non-admin users, so it will cause an access error whenever trying to verify the hash inside `_execute_callback()`, and when marking the callback execution successful. Accessing it as `sudo` like other restricted transaction fields solves the problem, and is safe, as the value is never leaked outside the function. Introduced in 573ed74c121c1572b3fab6f9553ed7f93f7b3f99. Forward-Port-Of: odoo/odoo#77698
Original PR description
The `callback_hash` and `callback_is_done` fields are not accessible for non-admin users, so it will cause an access error whenever trying to verify the hash inside `_execute_callback()`, and when marking the callback execution successful. Accessing it as `sudo` like other restricted transaction fields solves the problem, and is safe, as the value is never leaked outside the function. Introduced in 573ed74c121c1572b3fab6f9553ed7f93f7b3f99. Forward-Port-Of: odoo/odoo#77698
[FIX] project: improve performances of has any so to invoice compute Before this commit, the compute _compute_has_any_so_to_invoice was not triggered in case of user change, which means that it could take incorrect values depending on the value of the group as it was missing the proper decorator. Also, performances were not optimal and have been improved. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#77590
Original PR description
[FIX] project: improve performances of has any so to invoice compute Before this commit, the compute _compute_has_any_so_to_invoice was not triggered in case of user change, which means that it could take incorrect values depending on the value of the group as it was missing the proper decorator. Also, performances were not optimal and have been improved. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#77590
The context was missing from multiple RPC calls in the attendance's kiosk modes resulting in the wrong employee being fetched for the attendnace creation, all RPC calls related to attendances are now given the context explicitely. TaskId-2660772 Forward-Port-Of: odoo/odoo#77672
Original PR description
The context was missing from multiple RPC calls in the attendance's kiosk modes resulting in the wrong employee being fetched for the attendnace creation, all RPC calls related to attendances are now given the context explicitely. TaskId-2660772 Forward-Port-Of: odoo/odoo#77672
The context key `'validation_views'` is used by `ir.ui.view` to determine what parts of a view `arch` must be validated. Its associated value is either `True` or a recordset, and having those types leads to unexpected warnings when creating environments. Before creating a new environment, the class `Environment` looks for an existing environment with the given parameters: `cr`, `uid`, `context`, `su`. The comparison of a context where `'validation_views'` is a recordset with another co
Original PR description
The context key `'validation_views'` is used by `ir.ui.view` to determine what parts of a view `arch` must be validated. Its associated value is either `True` or a recordset, and having those types leads to unexpected warnings when creating environments. Before creating a new environment, the class `Environment` looks for an existing environment with the given parameters: `cr`, `uid`, `context`, `su`. The comparison of a context where `'validation_views'` is a recordset with another context where `'validation_views'` is `True`, generates the warning "unsupported operand type(s)"... We avoid this situation by using ids instead of a recordset for the value of the validation context key. Forward-Port-Of: odoo/odoo#77505
Steps to reproduce : - Install Sales - Modify the report, use the theme "Clean" and the font "Open Sans" - Modify the company phone to: +41 26 322 01 02 - Print a quotation Issue : Company phone is on 2 lines Cause : CSS issue with wkhtmltopdf. Solution : Replace css display value `inline-block` by `inline`. opw-2567836 Forward-Port-Of: odoo/odoo#75515
Original PR description
Steps to reproduce : - Install Sales - Modify the report, use the theme "Clean" and the font "Open Sans" - Modify the company phone to: +41 26 322 01 02 - Print a quotation Issue : Company phone is on 2 lines Cause : CSS issue with wkhtmltopdf. Solution : Replace css display value `inline-block` by `inline`. opw-2567836 Forward-Port-Of: odoo/odoo#75515
When manually adding a customs number in draft invoices the value is saved, but then overridden when the invoice is posted (confimed) with the first value retrieved from the database. The system should respect user choice as some clients require this manual selection regardless the FIFO or FEFO strategy. opw-2616269 Forward-Port-Of: odoo/enterprise#21339
Original PR description
When manually adding a customs number in draft invoices the value is saved, but then overridden when the invoice is posted (confimed) with the first value retrieved from the database. The system should respect user choice as some clients require this manual selection regardless the FIFO or FEFO strategy. opw-2616269 Forward-Port-Of: odoo/enterprise#21339
The payment.acquirer model is only accessible for admins, so non-admin users were facing a permission error during reconciliation, due to the search() targeting the acquirer. TODO: switch the test to non-admin and verify that it still works Forward-Port-Of: odoo/enterprise#21091
Original PR description
The payment.acquirer model is only accessible for admins, so non-admin users were facing a permission error during reconciliation, due to the search() targeting the acquirer. TODO: switch the test to non-admin and verify that it still works Forward-Port-Of: odoo/enterprise#21091
This adapts all templates of mass_mailing and marketing_automation so they use Bootstrap grids instead of tables, since the transpiler is now able to convert it back automatically. General heuristic for the conversion of templates: | **Table** | **Bootstrap** | |:-------------------:|:------------------------------------------:| | `<table>` | `<div class="container">` | | `<thead>` | _(removed)_
Original PR description
This adapts all templates of mass_mailing and marketing_automation so they use Bootstrap grids instead of tables, since the transpiler is now able to convert it back automatically. General heuristic…
This adapts all templates of mass_mailing and marketing_automation so they use Bootstrap grids instead of tables, since the transpiler is now able to convert it back automatically. General heuristic for the conversion of templates: | **Table** | **Bootstrap** | |:-------------------:|:------------------------------------------:| | `<table>` | `<div class="container">` | | `<thead>` | _(removed)_ | | `<tbody>` | _(removed)_ | | `<tfoot>` | _(removed)_ | | `<tr>` | `<div class="row">` | | `<th>` | `<div class="col o_col_head">` | | `<td>` | `<div class="col">` | | `<td width="_n_%">` | `<div class="col-_o_">` where o ~= 12n/100 | | `cellspacing` | _(removed but always added back to table)_ | | `cellpadding` | _(removed but always added back to table)_ | | `border` | _(removed but always added back to table)_ | Task: 2554899 Community PR: https://github.com/odoo/odoo/pull/77312 Forward-Port-Of: odoo/enterprise#21215 and odoo/enterprise#21364
When writing the invoice lines found by the OCR, the default journal was always used, even when it had been manually changed prior to the OCR update. opw #2638309 Forward-Port-Of: odoo/enterprise#21259 Forward-Port-Of: odoo/enterprise#21134
Original PR description
When writing the invoice lines found by the OCR, the default journal was always used, even when it had been manually changed prior to the OCR update. opw #2638309 Forward-Port-Of: odoo/enterprise#21259 Forward-Port-Of: odoo/enterprise#21134
Before this commit, the incriminated test crashed indeterministically. To avoid blocking runbot, we fix the test temporarily. After this commit, there is no indeterministic crash on that test. Forward-Port-Of: odoo/enterprise#21382
Original PR description
Before this commit, the incriminated test crashed indeterministically. To avoid blocking runbot, we fix the test temporarily. After this commit, there is no indeterministic crash on that test. Forward-Port-Of: odoo/enterprise#21382
This adapts all templates of mass_mailing and marketing_automation so they use Bootstrap grids instead of tables, since the transpiler is now able to convert it back automatically. General heuristic for the conversion of templates: | **Table** | **Bootstrap** | |:-------------------:|:------------------------------------------:| | `<table>` | `<div class="container">` | | `<thead>` | _(removed)_
Original PR description
This adapts all templates of mass_mailing and marketing_automation so they use Bootstrap grids instead of tables, since the transpiler is now able to convert it back automatically. General heuristic…
This adapts all templates of mass_mailing and marketing_automation so they use Bootstrap grids instead of tables, since the transpiler is now able to convert it back automatically. General heuristic for the conversion of templates: | **Table** | **Bootstrap** | |:-------------------:|:------------------------------------------:| | `<table>` | `<div class="container">` | | `<thead>` | _(removed)_ | | `<tbody>` | _(removed)_ | | `<tfoot>` | _(removed)_ | | `<tr>` | `<div class="row">` | | `<th>` | `<div class="col o_col_head">` | | `<td>` | `<div class="col">` | | `<td width="_n_%">` | `<div class="col-_o_">` where o ~= 12n/100 | | `cellspacing` | _(removed but always added back to table)_ | | `cellpadding` | _(removed but always added back to table)_ | | `border` | _(removed but always added back to table)_ | Task: 2554899 Community PR: https://github.com/odoo/odoo/pull/77312 Forward-Port-Of: odoo/enterprise#21215
https://github.com/odoo/odoo/pull/76892 Forward-Port-Of: odoo/enterprise#21035
Original PR description
https://github.com/odoo/odoo/pull/76892 Forward-Port-Of: odoo/enterprise#21035
The user doesn't have always the possibility to define the payment way, for example using a payment.transaction. Forward-Port-Of: odoo/enterprise#20627
Original PR description
The user doesn't have always the possibility to define the payment way, for example using a payment.transaction. Forward-Port-Of: odoo/enterprise#20627
There should be no slot when a slot is present in a futur monday and that monday is also present in the first week of the next month. Indeed we should check only the day for the month we display. Forward-Port-Of: odoo/enterprise#21123
Original PR description
There should be no slot when a slot is present in a futur monday and that monday is also present in the first week of the next month. Indeed we should check only the day for the month we display. Forward-Port-Of: odoo/enterprise#21123