Monday, April 22, 2024
39 changes · saas-17.1
Miscellaneous changes
task-3877841 ------------------ This PR fixes an issue occurring in the `web_editor` when multiple users edit some content. Prior to this commit, the user avatar was not using any aspect-ratio rule, resulting in a stretch avatar if the uploaded image wasn't square. This commit fixes this issue by adding the `o_object_fit_cover` class to the image, ensuring a correct ratio no matter the format of the uploaded image. | 16.0 | 16.0-fix-editor-avatar-ratio-chgo | |--------|--------|
Original PR description
task-3877841 ------------------ This PR fixes an issue occurring in the `web_editor` when multiple users edit some content. Prior to this commit, the user avatar was not using any aspect-ratio rule, resulting in a stretch avatar if the uploaded image wasn't square. This commit fixes this issue by adding the `o_object_fit_cover` class to the image, ensuring a correct ratio no matter the format of the uploaded image. | 16.0 | 16.0-fix-editor-avatar-ratio-chgo | |--------|--------| | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/4de8281f-3469-4e29-b0fa-286f31483d5e"> | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/eeea593a-090c-4c97-bc07-4d89bbdfa67f"> | Forward-Port-Of: odoo/odoo#162810 Forward-Port-Of: odoo/odoo#162743
This commit add a new tax call VAT exemption, read more at https://taxsummaries.pwc.com/vietnam/corporate/other-taxes to understand its usage 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#161457
Original PR description
This commit add a new tax call VAT exemption, read more at https://taxsummaries.pwc.com/vietnam/corporate/other-taxes to understand its usage 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#161457
using sudo().is_kits to account for user not having access to the bom module and boms in different companies Forward-Port-Of: odoo/odoo#161124
Original PR description
using sudo().is_kits to account for user not having access to the bom module and boms in different companies Forward-Port-Of: odoo/odoo#161124
PR odoo/odoo#157918 has a bug on commit 8bd8d4a3eaf. We cannot do `int(x) in Command` as it's TypeError. Forward-Port-Of: odoo/odoo#162786
Original PR description
PR odoo/odoo#157918 has a bug on commit 8bd8d4a3eaf. We cannot do `int(x) in Command` as it's TypeError. Forward-Port-Of: odoo/odoo#162786
Current Behavior: Tasks with or without dependent tasks and a state not in closed states have their state changed to `01_in_progress` when duplicated. previous PR that changed this logic: #139249 Purpose of this PR: To retain the state of the original task when duplicated. Steps to Reproduce in Runbot: 1) Enable Task Dependencies in Settings 2) Create a Project with Task A 3) Set state of Task A to 'Approved' 4) Duplicate Task A > Task A will now have a state of 'In Progress' N
Original PR description
Current Behavior: Tasks with or without dependent tasks and a state not in closed states have their state changed to `01_in_progress` when duplicated. previous PR that changed this logic: #139249 Purpose of this PR: To retain the state of the original task when duplicated. Steps to Reproduce in Runbot: 1) Enable Task Dependencies in Settings 2) Create a Project with Task A 3) Set state of Task A to 'Approved' 4) Duplicate Task A > Task A will now have a state of 'In Progress' Note: This PR does not remove the changes of duplicating projects. opw-3836251 Forward-Port-Of: odoo/odoo#161778
Previously, if a product had `price < list_price` and `price < compare_list_price`, but `website_sale.group_product_price_comparison` unset, no strikethrough price was shown. However, in that case, we should show `list_price` as the strikethrough price. Previously, in the search dropdown, `compare_list_price` was only shown as the strikethrough price if `price < list_price` (which is unrelated). This change make it consistent with the product page. opw-3845926 Forward-Port-Of: odoo/odoo#1
Original PR description
Previously, if a product had `price < list_price` and `price < compare_list_price`, but `website_sale.group_product_price_comparison` unset, no strikethrough price was shown. However, in that case, we should show `list_price` as the strikethrough price. Previously, in the search dropdown, `compare_list_price` was only shown as the strikethrough price if `price < list_price` (which is unrelated). This change make it consistent with the product page. opw-3845926 Forward-Port-Of: odoo/odoo#162611 Forward-Port-Of: odoo/odoo#161473
Issue: Discounts are not displayed in DDT Steps to reproduce: - create a quotation with a sale line having a discount - smart button delivery > set qty > validate - Print Ticket link: [odoo/task#3745866](https://www.odoo.com/web#model=project.task&id=3745866) opw-3745866 Forward-Port-Of: odoo/odoo#162287 Forward-Port-Of: odoo/odoo#159325
Original PR description
Issue: Discounts are not displayed in DDT Steps to reproduce: - create a quotation with a sale line having a discount - smart button delivery > set qty > validate - Print Ticket link: [odoo/task#3745866](https://www.odoo.com/web#model=project.task&id=3745866) opw-3745866 Forward-Port-Of: odoo/odoo#162287 Forward-Port-Of: odoo/odoo#159325
task-3870118 -------------------- This PR aims to fix an issue on forum posts, about comments being placed directly next to each other without having a gap between them, making it harder to visually recognize items at first glance. To handle this issue, we simply add a `d-flex gap-x` utility classes to ensure these elements receive some spacing between them. | 17.0 | 17.0-fix-forum-comment-spacing-chgo | |--------|--------| | <img alt="image" src="https://github.com/odoo/odoo/as
Original PR description
task-3870118 -------------------- This PR aims to fix an issue on forum posts, about comments being placed directly next to each other without having a gap between them, making it harder to visually recognize items at first glance. To handle this issue, we simply add a `d-flex gap-x` utility classes to ensure these elements receive some spacing between them. | 17.0 | 17.0-fix-forum-comment-spacing-chgo | |--------|--------| | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/a86dd9d7-37e4-4783-8d7f-73bdc6605edf"> | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/f253452a-3b52-499f-a7c2-4d3e102ab5a4"> | Forward-Port-Of: odoo/odoo#155364
Access rights on ir.attachment depend on the record it is linked to. steps to reproduce: - log as admin - create a calendar event and invite marc demo - log as marc demo - check discuss notifications and try to download "invite.ics" before this commit: - file can not be downloaded from the webclient (access error appear in logs) after this commit: - file can be downloaded from the webclient opw-3754798 --- I confirm I have signed the CLA and read the PR guidelines at www.od
Original PR description
Access rights on ir.attachment depend on the record it is linked to. steps to reproduce: - log as admin - create a calendar event and invite marc demo - log as marc demo - check discuss notifications and try to download "invite.ics" before this commit: - file can not be downloaded from the webclient (access error appear in logs) after this commit: - file can be downloaded from the webclient opw-3754798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162502 Forward-Port-Of: odoo/odoo#160811
**Description of the issue/feature this PR addresses:** Before this PR initial balance include line with a null balance. In database with lot of partner (e-commerce), the initial balance balance are huge. - Create e-commerce - Sale and invoice to 100 000 different customer in 2023, all invoice are paid - In 2024 extract a FEC --> Issue : in the initial balance there are 100 000 lines with a zero balance. This lines don't need to be included in the FEC. --- I confirm I have signe
Original PR description
**Description of the issue/feature this PR addresses:** Before this PR initial balance include line with a null balance. In database with lot of partner (e-commerce), the initial balance balance are huge. - Create e-commerce - Sale and invoice to 100 000 different customer in 2023, all invoice are paid - In 2024 extract a FEC --> Issue : in the initial balance there are 100 000 lines with a zero balance. This lines don't need to be included in the FEC. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160639 Forward-Port-Of: odoo/odoo#141321
Since 17.0, the tag `apps` of ir.action.client was removed with the legacy code of javascript. This commit removes the only usage in `res.config.installer` (not used in standard) to avoid a traceback at install. Fixes #160293 Forward-Port-Of: odoo/odoo#162228
Original PR description
Since 17.0, the tag `apps` of ir.action.client was removed with the legacy code of javascript. This commit removes the only usage in `res.config.installer` (not used in standard) to avoid a traceback at install. Fixes #160293 Forward-Port-Of: odoo/odoo#162228
Description of the issue/feature this PR addresses: Without sudo, an user in a company can change the type even if somes not done stock.move.line exists. @amoyaux --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160856
Original PR description
Description of the issue/feature this PR addresses: Without sudo, an user in a company can change the type even if somes not done stock.move.line exists. @amoyaux --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160856
This reverts commit 8a5541d16caa793c7549d78c082f7879d3aba233. It's a too big change for stable. It breaks the flow for poeple that want to be in just in time but want to consider the future deliveries to order all at once. Due to reverted commit they see their reorder in advance. The fixed use case, could be achieve with the security days or the global lead days system parameter. opw-crl Forward-Port-Of: odoo/odoo#157218
Original PR description
This reverts commit 8a5541d16caa793c7549d78c082f7879d3aba233. It's a too big change for stable. It breaks the flow for poeple that want to be in just in time but want to consider the future deliveries to order all at once. Due to reverted commit they see their reorder in advance. The fixed use case, could be achieve with the security days or the global lead days system parameter. opw-crl Forward-Port-Of: odoo/odoo#157218
Current behavior: When entering a lot name that doesn't exist in the PoS, the lot is being created. But the lot is not being assigned to the stock move line. Steps to reproduce: - Create a product with tracking by lot - Open PoS and make an order for this product - Enter a lot name that doesn't exist - Validate the order - Close the session - Go to the order picking in the inventory app - The lot is not assigned to the stock move line opw-3710125 --- I confirm I have signed the C
Original PR description
Current behavior: When entering a lot name that doesn't exist in the PoS, the lot is being created. But the lot is not being assigned to the stock move line. Steps to reproduce: - Create a product with tracking by lot - Open PoS and make an order for this product - Enter a lot name that doesn't exist - Validate the order - Close the session - Go to the order picking in the inventory app - The lot is not assigned to the stock move line opw-3710125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160533
### Steps to reproduce: - Install **E-commerce** app - Go to **Website** > **Shop**, and open a product - Click on **edit** on the upper right corner. - Double click the product image to change it. A popup is shown. - In the popup, click on Add URL and place this URL [1] - Click **Save**. The image disappears! ### Investigation: - The issue was introduced here [2] - As URL now starts with `/web/image/` which will be later used here [3] - The condition to enter this line is `url_objec
Original PR description
### Steps to reproduce: - Install **E-commerce** app - Go to **Website** > **Shop**, and open a product - Click on **edit** on the upper right corner. - Double click the product image to change it. A…
### Steps to reproduce:
- Install **E-commerce** app
- Go to **Website** > **Shop**, and open a product
- Click on **edit** on the upper right corner.
- Double click the product image to change it. A popup is shown.
- In the popup, click on Add URL and place this URL [1]
- Click **Save**. The image disappears!
### Investigation:
- The issue was introduced here [2]
- As URL now starts with `/web/image/` which will be later used here [3]
- The condition to enter this line is `url_object.path.startswith('/web/image')`
- `item[field]` is used which equals to `attachment[datas]`
- But actually `datas` is empty as the image upload fails because of **CORS**
- `add_url` is called [4] saving attachment without `datas` but with type URL
### Fix
- The commit solves the issue by fetching the remote data from the server if the url is a remote redirection, which still happens when the image data cannot be fetched by the client browser at upload time.
[1]: https://lowendbox.com/wp-content/uploads/2022/09/odoo_logo_1200.png
[2]: https://github.com/odoo/odoo/commit/943944dd249c15de870d6800d89e48d54a422e5a#diff-0897c80484208197b0aff67f2b06509e864c3976de1589e3cebad2788eef008fR49
[3]: https://github.com/odoo/odoo/blob/f72968561acec164697a7a9ee0965ec304854dd5/addons/web_editor/models/ir_qweb_fields.py#L473
[4]: https://github.com/odoo/odoo/blob/f72968561acec164697a7a9ee0965ec304854dd5/addons/web_editor/controllers/main.py#L268
opw-3746245
Forward-Port-Of: odoo/odoo#160085Description of the issue/feature this PR addresses: After the portal redesign, messages for no quotations or sale orders were moved before the portal_table template, which is called when there are entries of quotations or sale orders. However, the previous version of the message for sale orders was left after the template call. This commit removes the previous version of the message to avoid having duplicated messages. Current behavior before PR: Two similar messages are displayed in
Original PR description
Description of the issue/feature this PR addresses: After the portal redesign, messages for no quotations or sale orders were moved before the portal_table template, which is called when there are entries of quotations or sale orders. However, the previous version of the message for sale orders was left after the template call. This commit removes the previous version of the message to avoid having duplicated messages. Current behavior before PR: Two similar messages are displayed in the portal when there are no sale orders. - There are currently no sales orders for your account. - There are currently no orders for your account. Desired behavior after PR is merged: Only one message is shown in the portal when there are no sale orders, as it happens for the quotations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162546
Current behavior: If you create a user that only have access to a branch of a company. If this user try to access the QR Menu of any PoS he will get an access error. Steps to reproduce: - Create a branch B for company A - Change access of user U to only have access to branch B - Login with user U, and try to open any PoS QR Menu - You get an access error opw-3745256 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1
Original PR description
Current behavior: If you create a user that only have access to a branch of a company. If this user try to access the QR Menu of any PoS he will get an access error. Steps to reproduce: - Create a branch B for company A - Change access of user U to only have access to branch B - Login with user U, and try to open any PoS QR Menu - You get an access error opw-3745256 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162222
Before this commit an error appeared if a block had been set at the top of the /blog page and the user wished to re-enable the 'Top banner - Name / Latest Post' option. This commit resolves the issue by giving higher priority to the activated view. Steps to reproduce the fixed bug: - Go on /blog page - Disable the customize option "Top banner - Name / Latest Post" - Enter in edit mode - Add a snippet to the top (in the oe_structure) - Save the page - Enable the customize option "Top
Original PR description
Before this commit an error appeared if a block had been set at the top of the /blog page and the user wished to re-enable the 'Top banner - Name / Latest Post' option. This commit resolves the issue by giving higher priority to the activated view. Steps to reproduce the fixed bug: - Go on /blog page - Disable the customize option "Top banner - Name / Latest Post" - Enter in edit mode - Add a snippet to the top (in the oe_structure) - Save the page - Enable the customize option "Top banner - Name / Latest Post" => An error happens. task-2774944 Forward-Port-Of: odoo/odoo#162519 Forward-Port-Of: odoo/odoo#92022
How to reproduce: 1. Go to any course 2. Click on the button 'Add attendees' 3. Type the recipients name "Create and edit ..." should be displayed but is not. To reenable this feature, we remove the option no_create_edit on partner_ids of the slide_channel_invite_view_form form to enable the creation of partner when adding attendee to a course. As the support for the force_email context has been discontinued, we don't reenable the quick_create as it can create partner without ema
Original PR description
How to reproduce: 1. Go to any course 2. Click on the button 'Add attendees' 3. Type the recipients name "Create and edit ..." should be displayed but is not. To reenable this feature, we remove the option no_create_edit on partner_ids of the slide_channel_invite_view_form form to enable the creation of partner when adding attendee to a course. As the support for the force_email context has been discontinued, we don't reenable the quick_create as it can create partner without email (if the user enter a non-valid email). But we reenable the "create edit" option with a view that force the user to enter an email: base.view_partner_simple_form (like done on some views in odoo/odoo#149806). Task-3868824 Forward-Port-Of: odoo/odoo#162190
Given the changes in [1] and subsequently in [2], which in some way counteract the RTL adjustment, it is necessary to eliminate the rtlcss directive from the carousel CSS to ensure the correct behavior. Steps to reproduce: - Enter in edit mode. - Drag and drop an image gallery and a carousel snippet. - Navigate to the theme tab. - Add an RTL language (Arabic, for instance). Bug : - The images slide in incorrectly during transitions. In RTL mode, when clicking on the left chev
Original PR description
Given the changes in [1] and subsequently in [2], which in some way counteract the RTL adjustment, it is necessary to eliminate the rtlcss directive from the carousel CSS to ensure the correct…
Given the changes in [1] and subsequently in [2], which in some way counteract the RTL adjustment, it is necessary to eliminate the rtlcss directive from the carousel CSS to ensure the correct behavior. Steps to reproduce: - Enter in edit mode. - Drag and drop an image gallery and a carousel snippet. - Navigate to the theme tab. - Add an RTL language (Arabic, for instance). Bug : - The images slide in incorrectly during transitions. In RTL mode, when clicking on the left chevron, the next image should appear, not the previous one. If we have three slides numbered 1, 2, and 3 - In RTL mode: Clicking left should navigate from 1 to 2 to 3 and then back to 1. - In non-RTL mode: Clicking left should navigate from 1 to 3 to 2 and then back to 1. The directional Font Awesome icons (classes starting with `fa-` and ending with `-right` or `-left`) are not flipped in the mobile viewport as a result of [3]. Necessary adjustments have been implemented to prevent this behavior. Upon investigation, a more significant bug was discovered regarding the 'oi-...-[right/left]' icons. These icons were not flipped appropriately in the frontend when the webpage context was set to an RTL language. A pull request has been created and merged to address this issue [4]. More info on rtlcss [here] [1]: https://github.com/odoo/odoo/commit/ebb61753bf3d3dd8d3f53db088112b9e4beb813d [2]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3 [3]: https://github.com/odoo/odoo/commit/be375bb2a886edd002f042355455a71fcac4daf5 [4]: https://github.com/odoo/odoo/pull/157214 [here]: https://rtlcss.com/learn/usage-guide/value-directives/#tip opw-3747848 Forward-Port-Of: odoo/odoo#162202 Forward-Port-Of: odoo/odoo#154734
__Current behavior before commit:__ The `color` attribute of `hr` is set to `$hr-color`[1]. `$hr-color` is equal to `$border-color`[2] which itself is equal to `--o-border-color`[3]. Finally `--o-border-color` is set using `fade-currentColor()`[4] which uses the `color-mix` css function on `currentColor`[5]. In short, the `color` of `hr` depends on itself. This creates a circular reference that makes Safari 16.5 crash. This bug is caused by WebKit. There seems to be a commit to fix[6] th
Original PR description
__Current behavior before commit:__ The `color` attribute of `hr` is set to `$hr-color`[1]. `$hr-color` is equal to `$border-color`[2] which itself is equal to `--o-border-color`[3]. Finally…
__Current behavior before commit:__ The `color` attribute of `hr` is set to `$hr-color`[1]. `$hr-color` is equal to `$border-color`[2] which itself is equal to `--o-border-color`[3]. Finally `--o-border-color` is set using `fade-currentColor()`[4] which uses the `color-mix` css function on `currentColor`[5]. In short, the `color` of `hr` depends on itself. This creates a circular reference that makes Safari 16.5 crash. This bug is caused by WebKit. There seems to be a commit to fix[6] this bug but it looks like it was not backported to this version of Safari. __Description of the fix:__ Set `$hr-color` to a fixed value by introducing `--o-hr-color` which is set to the same value of the already existing fallback of `--o-border-color`. __Steps to reproduce the issue on runbot:__ 1. Go to the website shop using Safari 16.5 2. Add an item to the cart 3. Open the cart view 4. Safari crashes opw-3806725 [1]: https://github.com/odoo/odoo/blob/1154556/addons/web/static/lib/bootstrap/scss/_reboot.scss#L71 [2]: https://github.com/odoo/odoo/blob/1154556/addons/website/static/src/scss/bootstrap_overridden.scss#L333 [3]: https://github.com/odoo/odoo/blob/1154556/addons/website/static/src/scss/bootstrap_overridden.scss#L91 [4]: https://github.com/odoo/odoo/blob/1154556/addons/website/static/src/scss/website.scss#L35 [5]: https://github.com/odoo/odoo/blob/1154556/addons/website/static/src/scss/primary_variables.scss#L2219 [6]: https://github.com/WebKit/WebKit/commit/0d0b884 Forward-Port-Of: odoo/odoo#160495
Description of the issue/feature this PR addresses: In systems were POs can have multiple open pickings, updating the Purchase quantities can lead to errors due to the current behaviour. Current behavior before PR: Before the fix, the picking used to create the new stock moves resulting from changes in the purchased quantity is simply taking the first available picking of the Purchase. This causes problems when you handle Purchase Orders with multiple open pickings, as the correct picki
Original PR description
Description of the issue/feature this PR addresses: In systems were POs can have multiple open pickings, updating the Purchase quantities can lead to errors due to the current behaviour. Current behavior before PR: Before the fix, the picking used to create the new stock moves resulting from changes in the purchased quantity is simply taking the first available picking of the Purchase. This causes problems when you handle Purchase Orders with multiple open pickings, as the correct picking to use when the quantity is updated is not always taken. Desired behavior after PR is merged: After the fix we give priority to evaluate open pickings already related to the line we are updating. We fallback to the same behaviour as before is none is available. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161452
Before this PR, trying to get an available operator could result in an error. When a live chat is created, an operator is selected based on various criteria such as language, country, number of ongoing chats and availability for calls. This selection process involves the `_get_less_active_operator` method, which receives the status of all operators and a list of operators to choose from. Prior to this fix, an operator not included in the list of operators to choose from could still b
Original PR description
Before this PR, trying to get an available operator could result in an error. When a live chat is created, an operator is selected based on various criteria such as language, country, number of ongoing chats and availability for calls. This selection process involves the `_get_less_active_operator` method, which receives the status of all operators and a list of operators to choose from. Prior to this fix, an operator not included in the list of operators to choose from could still be selected, resulting in errors when trying to locate them in the operator list. This PR resolves the issue by ensuring that operators are only selected from the provided list. opw-3874872 Forward-Port-Of: odoo/odoo#162357
While updating the checkout page an element was changed from div to t To handle the intermediate value used by users who installed this version a new selector was added to the xpath to account for both cases Previous commit that was fixing the same issue 12e5296c1d4dbfe202ad2dcb2690c2e60828f6e1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162064
Original PR description
While updating the checkout page an element was changed from div to t To handle the intermediate value used by users who installed this version a new selector was added to the xpath to account for both cases Previous commit that was fixing the same issue 12e5296c1d4dbfe202ad2dcb2690c2e60828f6e1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162064
Most e-mail clients apply some padding around their e-mails, like mass_mailing does in its editor. So for the plain text email template, we mostly don't want to transfer that padding, but for Apple Mail we do want some padding lest the e-mail be crammed in a corner. The editor's padding was lost in conversion because the padding was applied to a table with `border-collapse: collapse` so it was not applied (see [mdn]). Since we can't change that property (or layouts will be broken), our remain
Original PR description
Most e-mail clients apply some padding around their e-mails, like mass_mailing does in its editor. So for the plain text email template, we mostly don't want to transfer that padding, but for Apple…
Most e-mail clients apply some padding around their e-mails, like mass_mailing does in its editor. So for the plain text email template, we mostly don't want to transfer that padding, but for Apple Mail we do want some padding lest the e-mail be crammed in a corner. The editor's padding was lost in conversion because the padding was applied to a table with `border-collapse: collapse` so it was not applied (see [mdn]). Since we can't change that property (or layouts will be broken), our remaining option is to wrap the layout table's contents in a `div` and apply the padding to it instead. Since we only want this for Apple Mail, we apply it in a nested media query, which Apple Mail is currently the only client to support. This is the only known way to target Apple Mail specifically but since e-mail clients tend to be remarkably slow at adopting new technologies, this should be safe for a while. [mdn]: https://developer.mozilla.org/en-US/docs/Web/CSS/border-collapse task-3062027 Co-authored-by: David Monjoie <dmo@odoo.com> Forward-Port-Of: odoo/odoo#105661
Steps to reproduce: ------------------- 1. Install the resource module without demo data (or install any module which depends on it, again without demo data). 2. Login with the administrator user for the first time. 3. The default resource calendar (e.g. "Standard 40 hours/week") timezone will be set to 'UTC' by default while it should be set to the timezone of the administrator. Fix: ------------------- When there is no demo data, no resource_calendar_id is linked to the admin. In this
Original PR description
Steps to reproduce: ------------------- 1. Install the resource module without demo data (or install any module which depends on it, again without demo data). 2. Login with the administrator user for the first time. 3. The default resource calendar (e.g. "Standard 40 hours/week") timezone will be set to 'UTC' by default while it should be set to the timezone of the administrator. Fix: ------------------- When there is no demo data, no resource_calendar_id is linked to the admin. In this case, we need to retrieve the record of the default working calendar and set its timezone to the one of the admin user on the first login. This is a follow-up of this fix: https://github.com/odoo/odoo/pull/84258 task-3793313 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157583
### Steps to reproduce: - Create a project with a task with a sub-task - Assign manually the sub-task to the project - Create a product that creates a project based on this product template - Create an SO with that product #### > A copy of your project template will be created and assigned to the SO ### Expected Behavior: Just as in 16.4, the copy of the subtask created during this process should be associated with the copy of your project template. ### Current Behavior: The
Original PR description
### Steps to reproduce: - Create a project with a task with a sub-task - Assign manually the sub-task to the project - Create a product that creates a project based on this product template - Create…
### Steps to reproduce: - Create a project with a task with a sub-task - Assign manually the sub-task to the project - Create a product that creates a project based on this product template - Create an SO with that product #### > A copy of your project template will be created and assigned to the SO ### Expected Behavior: Just as in 16.4, the copy of the subtask created during this process should be associated with the copy of your project template. ### Current Behavior: The subtask is associated with the original project template. ### Cause of the issue/Fix: Confirming the SO will call the copy method on your project template. During this call copies of its task and sub-task will be created and should then be remapped to the correct project/task using by the `map_tasks` method call: https://github.com/odoo/odoo/blob/f31174e02157e612650e77ebba3ed1fe54b96776/addons/project/models/project_project.py#L436-L437 This use to do the job correctly in 16.4 because of these lines: https://github.com/odoo/odoo/blob/ce28edbaae5a9af0a8c6e1f2addf4285ec56e9e1/addons/project/models/project_project.py#L415-L419 However, these were removed by commit 6303a3e probably because the new write method of the "project.project" model introduced by this commit sometimes relies on the "project_id" of these tasks and this information should be consistent with the future value of the "project_id" of these tasks. However, the "project_id" of these tasks should still be remapped to the copied project at some point and in my opinion this should be done before the new write method is called, so that this method can be used correctly. opw-3823013 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160625
Prior to this commit, if a product had multiple attributes, each attribute would be displayed multiple times in the order line. This commit resolves this issue by ensuring that each attribute line is displayed only once.  opw-3849701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162258
Original PR description
Prior to this commit, if a product had multiple attributes, each attribute would be displayed multiple times in the order line. This commit resolves this issue by ensuring that each attribute line is displayed only once.  opw-3849701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162258
In this commit: =============== printer icon will visible based on printer configuration task - 3869678 Forward-Port-Of: odoo/odoo#162056
Original PR description
In this commit: =============== printer icon will visible based on printer configuration task - 3869678 Forward-Port-Of: odoo/odoo#162056
Steps to reproduce: - Install account_sepa_direct_debit - Create another company - Go to "Invoicing / Configuration / Accounting / Journals" - Configure a journal (e.g. Bank) by adding an IBAN bank account number - Go to "Invoicing / Customers / Direct Debit Mandates" - Create a Direct Debit Mandate (DD Mandate): * Customer: [any customer with an IBAN bank account] (e.g. Gemini Furniture) * IBAN: [IBAN bank account of customer] * Journal: Bank * Start Date: [any] * Company:
Original PR description
Steps to reproduce: - Install account_sepa_direct_debit - Create another company - Go to "Invoicing / Configuration / Accounting / Journals" - Configure a journal (e.g. Bank) by adding an IBAN bank account number - Go to "Invoicing / Customers / Direct Debit Mandates" - Create a Direct Debit Mandate (DD Mandate): * Customer: [any customer with an IBAN bank account] (e.g. Gemini Furniture) * IBAN: [IBAN bank account of customer] * Journal: Bank * Start Date: [any] * Company: [the current company] - Save and validate the DD mandate - Switch to another company - Open Direct Debit Mandate list view Issue: The DD mandate from the other company is displayed. Any user who has access to DD mandates will view the DD mandates from all companies, even those from the companies he has no access. Cause: There is no multi-company rule for "sdd.mandate" model. opw-3769026 Forward-Port-Of: odoo/enterprise#59233
Issue: ------ If we remove the sale order line from a helpdesk ticket, and modify the partner (modify the `is_company` field), the sale order line will be added back to the ticket. Solution: --------- Assuming that this behaviour is due to a limitation in the ORM, it is necessary to modify the dependency of the compute method. This fix performs the same correction on the helpdesk side as the commit: https://github.com/odoo/odoo/commit/5faf5a0dcf4c06716d6a29686d49409b22b05565 opw-387
Original PR description
Issue: ------ If we remove the sale order line from a helpdesk ticket, and modify the partner (modify the `is_company` field), the sale order line will be added back to the ticket. Solution: --------- Assuming that this behaviour is due to a limitation in the ORM, it is necessary to modify the dependency of the compute method. This fix performs the same correction on the helpdesk side as the commit: https://github.com/odoo/odoo/commit/5faf5a0dcf4c06716d6a29686d49409b22b05565 opw-3879079 Forward-Port-Of: odoo/enterprise#61125
Currently, when downloading/loading Worldline lib at the start of Odoo, after doing so we are restarting Odoo at the end of "load_worldline_library.sh" script. This is unnecessary as Odoo is capable of detecting the terminals and communicating with them straight away when it has the library and the linker set up. More annoyingly, this leads to a very tricky bug: Odoo service is being restarted in a subshell. Since Odoo is already running this 2nd service will be blocked, but as soon as t
Original PR description
Currently, when downloading/loading Worldline lib at the start of Odoo, after doing so we are restarting Odoo at the end of "load_worldline_library.sh" script. This is unnecessary as Odoo is capable of detecting the terminals and communicating with them straight away when it has the library and the linker set up. More annoyingly, this leads to a very tricky bug: Odoo service is being restarted in a subshell. Since Odoo is already running this 2nd service will be blocked, but as soon as the primary Odoo service stops, the 2nd one takes the lead. So when restarting Odoo we can get error like "Adress already in use", duplicate code executed and even more dangerousely, duplicate C++/C code running with Worldline and Six, which can lead to race conditions and crashes. task-3873045 Forward-Port-Of: odoo/enterprise#60865
This commit removes the unnecessary "-" (minus) that was mistakenly added before `inputs['ATTACH_SALARY'].name`. This addition was causing a traceback error. task-3794116 Forward-Port-Of: odoo/enterprise#58566
Original PR description
This commit removes the unnecessary "-" (minus) that was mistakenly added before `inputs['ATTACH_SALARY'].name`. This addition was causing a traceback error. task-3794116 Forward-Port-Of: odoo/enterprise#58566
This commit addresses a computed asset failure caused by the inclusion of 'web.editor.frontend.scss' in the 'sign' module manifest since [1] (OWL conversion). A scss variable added in 'fontawesome_overriden.scss' by a related community PR is used in 'web.editor.frontend.scss', leading to a crash during asset computation. This file is now added in the manifest. Related community PR: - https://github.com/odoo/odoo/pull/161770 opw-3747848 [1]:https://github.com/odoo/enterprise/commit/5fa
Original PR description
This commit addresses a computed asset failure caused by the inclusion of 'web.editor.frontend.scss' in the 'sign' module manifest since [1] (OWL conversion). A scss variable added in 'fontawesome_overriden.scss' by a related community PR is used in 'web.editor.frontend.scss', leading to a crash during asset computation. This file is now added in the manifest. Related community PR: - https://github.com/odoo/odoo/pull/161770 opw-3747848 [1]:https://github.com/odoo/enterprise/commit/5fa63a2f284fe93acc0c4d8dc12ee47646703247 Forward-Port-Of: odoo/enterprise#60922 Forward-Port-Of: odoo/enterprise#60894
With FR localization installed and FR company setup Create an invoice to an EU partner Check the intrastat report Issue: "Codes" filter is visible but it is only supported in some localizations. Currently: - Selecting 'Goods' will toggle on/off all lines as all taxes are grouped under that section - 'Triangular' and 'Services' are no use This occurs because we always show the 'Codes' filter while we should display it only when relevant opw-3777753 Forward-Port-Of: odoo/enterp
Original PR description
With FR localization installed and FR company setup Create an invoice to an EU partner Check the intrastat report Issue: "Codes" filter is visible but it is only supported in some localizations. Currently: - Selecting 'Goods' will toggle on/off all lines as all taxes are grouped under that section - 'Triangular' and 'Services' are no use This occurs because we always show the 'Codes' filter while we should display it only when relevant opw-3777753 Forward-Port-Of: odoo/enterprise#60416
Before this commit, there was an issue with the line's buttons for the Inventory Adjustment in the Barcode app. The -1/+1 buttons were placed above/below each other instead of being on the same line, causing the edit button and the set button to be misplaced on the left. This commit fixes that, now these buttons will be placed correctly: - On the same height if there is only two buttons; - On two lines if there is four buttons. #### On Desktop - Before:  - After:  #### On mobile - Before:  - After:  Forward-Port-Of: odoo/enterprise#60769
## Description Validating invoices that have a lot of lines that needs to be deferred is taking extremely long time. Most of the bottleneck is from `_generate_deferred_entries`. We've batched some of the ORM calls to avoid repetitive calls to slow methods in `account_move` like `create`, `__set__`, `_post`. ## Benchmark Tested on a saas-16.4 DB: validating an invoice with deferred lines generating on average 12 periods per line | Lines | Before (Timing / Queries) | After (Timing / Qu
Original PR description
## Description Validating invoices that have a lot of lines that needs to be deferred is taking extremely long time. Most of the bottleneck is from `_generate_deferred_entries`. We've batched some of the ORM calls to avoid repetitive calls to slow methods in `account_move` like `create`, `__set__`, `_post`. ## Benchmark Tested on a saas-16.4 DB: validating an invoice with deferred lines generating on average 12 periods per line | Lines | Before (Timing / Queries) | After (Timing / Queries) | % Speed up | |-------|-------------------------------|--------------------------|------------| | 50 | 1 min / 23216 | 33.4 sec / 16713 | 44.3% | | 100 | 3 min / 46736 | 1.3 min / 33557 | 56.7% | | 230 | 17.7 min (timed-out) / 111196 | 3.4 min / 79777 | 80.7% | ## Reference opw-3815242 Forward-Port-Of: odoo/enterprise#59448
Steps to reproduce: ------------------- - create a product with: - recurring - prepaid - create task on order - in the settings, enable "Recurring Tasks" - add "Use Recurring Tasks" to the current user - create a sale order with a recurring plan and the recurring product - confirm the sale order --> the created task is recurring - duplicate the sale order - validate it with a portal user Issue: ------ The task created is not recurring. The two tasks should be recurrent because the
Original PR description
Steps to reproduce: ------------------- - create a product with: - recurring - prepaid - create task on order - in the settings, enable "Recurring Tasks" - add "Use Recurring Tasks" to the current user - create a sale order with a recurring plan and the recurring product - confirm the sale order --> the created task is recurring - duplicate the sale order - validate it with a portal user Issue: ------ The task created is not recurring. The two tasks should be recurrent because the sale order is the same. The user who confirms the sale order must not affect the status of the task. Cause: ------ We check that the user belongs to the `group_project_recurring_tasks` group, which will never be the case for a portal user. Solution: --------- Authorise the creation of the recurring task if the setting is activated. opw-3823250 Forward-Port-Of: odoo/enterprise#60807
Steps to reproduce: In field service, have a project on which you have to sell 3 of item A. Item a is tracked by serial number and the delivery route is in 2 steps. From stock to output and from output to customer. On the sale order make sure you have 3 separate lines of 1 quantity of product A separated or not by sections. Confirm this one. This will create two pickings. One picking linked to a global stock move for 3 units from stock to output. A second picking linked to 3 stock moves
Original PR description
Steps to reproduce: In field service, have a project on which you have to sell 3 of item A. Item a is tracked by serial number and the delivery route is in 2 steps. From stock to output and from output to customer. On the sale order make sure you have 3 separate lines of 1 quantity of product A separated or not by sections. Confirm this one. This will create two pickings. One picking linked to a global stock move for 3 units from stock to output. A second picking linked to 3 stock moves each linked to a sale line id. Prioritise the first one by starring it. Now go back to the project and mark is as done. OPW-3792527 Forward-Port-Of: odoo/enterprise#60083 Forward-Port-Of: odoo/enterprise#59163