Thursday, February 1, 2024
47 changes · saas-17.1
Resolved issues and error corrections
This change adjusts an internal performance test so it no longer fails unpredictably because of varying database query counts. It helps keep automated checks reliable, reducing noise for developers without changing customer-facing behavior.
Original PR description
No idea where it comes from, let's just get it fixed for now. runbot-55466
Miscellaneous changes
This commit's purpose is to fix the display of the default field when entering studio mode from a task form with no allocated time. Step to reproduce : -open project -open office design -create new task/select a task with 0 allocated hours -open studio the display of the field 'allocated time' is partially hidden by the span 0% Source of the bug: the widget timesheet_uom_no_toggle has a max width of 7CH, which is too little to allow the full display of the default name. Solution:
Original PR description
This commit's purpose is to fix the display of the default field when entering studio mode from a task form with no allocated time. Step to reproduce : -open project -open office design -create new…
This commit's purpose is to fix the display of the default field when entering studio mode from a task form with no allocated time. Step to reproduce : -open project -open office design -create new task/select a task with 0 allocated hours -open studio the display of the field 'allocated time' is partially hidden by the span 0% Source of the bug: the widget timesheet_uom_no_toggle has a max width of 7CH, which is too little to allow the full display of the default name. Solution: Create and add a new scss class which is only active in studio mode. Version affected: saas-16.2 to master task - 3553101 https://www.odoo.com/web#id=3553101&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form 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#152159 Forward-Port-Of: odoo/odoo#139741
Steps: - In mobile install project - Project.project form view - Go to the project settings - In Alias Domain(Custom Email Servers) - The input alignment is not good Issue: - The input should go under the alias domain in project.project form view in mobile Cause: - Here they adding extra bootstrap class so that's why it will be showing in correctly Fix: - By removing the bootstrap class of 'oe_inline' the problem will be solved task-3550702 Forward-Port-Of: odoo/odoo#151829
Original PR description
Steps: - In mobile install project - Project.project form view - Go to the project settings - In Alias Domain(Custom Email Servers) - The input alignment is not good Issue: - The input should go under the alias domain in project.project form view in mobile Cause: - Here they adding extra bootstrap class so that's why it will be showing in correctly Fix: - By removing the bootstrap class of 'oe_inline' the problem will be solved task-3550702 Forward-Port-Of: odoo/odoo#151829 Forward-Port-Of: odoo/odoo#140923
Issue: ====== Discard changes of form having html field doesn't remove the changes applied in the html field. Steps to reproduce the issue: ============================= - Open any mail template - Add modification on the template - Click on discard changes Origin of the issue: ==================== The function `this.props.update` is responsible of updating `_changes` and updating the record which is called for usual input_field using `useInputField` hook, but since this html field
Original PR description
Issue: ====== Discard changes of form having html field doesn't remove the changes applied in the html field. Steps to reproduce the issue: ============================= - Open any mail template - Add modification on the template - Click on discard changes Origin of the issue: ==================== The function `this.props.update` is responsible of updating `_changes` and updating the record which is called for usual input_field using `useInputField` hook, but since this html field isn't of the same format we didn't use it here se we have to call the update also on historystep. Solution: ========= Call `this.updateValue()` in historyStep too since it takes care of parsing the new value and calling `this.props.update` task-3453497 Forward-Port-Of: odoo/odoo#151993 Forward-Port-Of: odoo/odoo#149601
Logo on pdf send to customer after generating coupon code was disorted if it was not in certain ratio. task-2588963 Forward-Port-Of: odoo/odoo#150638 Forward-Port-Of: odoo/odoo#144489
Original PR description
Logo on pdf send to customer after generating coupon code was disorted if it was not in certain ratio. task-2588963 Forward-Port-Of: odoo/odoo#150638 Forward-Port-Of: odoo/odoo#144489
Steps to Reproduce ================== 1). Create an empty quotation and link it to a mass mailing (same medium and source). 2). Open the mailing form, the stat button displays "1 Quotation" 3). Click to open it -> Empty Screen Technical ========== There are no records in this view as it is based on the sales report model. If a quote has no line, there is nothing to display. After this PR ================= Now empty quotes will not be counted. Task-3635429 Forward-Port-Of
Original PR description
Steps to Reproduce
==================
1). Create an empty quotation and link it to a mass mailing
(same medium and source).
2). Open the mailing form, the stat button displays "1 Quotation" 3). Click to open it
-> Empty Screen
Technical
==========
There are no records in this view as it is based on the sales report model. If a quote has no line, there is nothing to display.
After this PR
=================
Now empty quotes will not be counted.
Task-3635429
Forward-Port-Of: odoo/odoo#152045
Forward-Port-Of: odoo/odoo#147674Current behavior before PR: - Some website snippets contained elements with classes like h1, h2, h3, etc. `setTag` function did not remove these classes when changing the tag, resulting in no visual effect. - In commit [[1]](https://github.com/odoo-dev/odoo/commit/b4cf3bcc893e345c25d863c0afaab71bbbfb404c), when fixing the `setTagName` function to avoid adding a `<p>` tag when converting a tag to a `<p>` inside an `<li>`, it missed a scenario where the element was deeply nested within the `<l
Original PR description
Current behavior before PR: - Some website snippets contained elements with classes like h1, h2, h3, etc. `setTag` function did not remove these classes when changing the tag, resulting in no visual…
Current behavior before PR:
- Some website snippets contained elements with classes like h1, h2, h3, etc. `setTag` function did not remove these classes when changing the tag, resulting in no visual effect.
- In commit [[1]](https://github.com/odoo-dev/odoo/commit/b4cf3bcc893e345c25d863c0afaab71bbbfb404c), when fixing the `setTagName` function to avoid adding a `<p>` tag when converting a tag to a `<p>` inside an `<li>`, it missed a scenario where the element was deeply nested within the `<li>` tag. For instance, in a case like `<li><div><h1>abcd</h1></div></li>`, the function failed to replace the `<h1>`with a `<p>` tag.
- Commit [[2]](https://github.com/odoo-dev/odoo/commit/d04e32c6f9da2b2e8709985648786df6f7eb6091) introduces an approach to preserve the cursor in `setTag` when new node is inserted. It used `setStart` at `firstLeaf` of `startContainer` and used offset of the `startContainer` similarly for `endContainer` which is incorrect and would throw traceback regarding no child at that offset.
- `destroyLinkTools` function sets the selection to entire link. However, in case where a website snippet had a structure like
```html
<a>
<div>
<i class=fa-xxx></i>
<div>
<h4>Text</h4>
<font>Text</font>
</div>
</div>
</a>
```
selecting the complete link caused problem. The toolbar couldn't be updated correctly, also one could not change the a tag of a single element within the link.
Desired behavior after PR is merged:
- Classes like h1, h2, h3, etc. are now removed when changing the tag.
- The `setTagName` function has been fixed to correctly replace a tag with a `<p>` tag when deeply nested inside an `<li>`.
- Fixed it by getting the correct `startContainer` and `endContainer` when new node is created.
- `destroyLinkTools` selects the `anchorNode` and the `focusnode` of the selection instead of entire link.
task-3245819
Forward-Port-Of: odoo/odoo#151752
Forward-Port-Of: odoo/odoo#145925After upgrading (specifically following this [upgrade PR]), when editing an element, the editor may be tricked into considering that the page isn't correct even though it is. It causes the "discard" dialog to open. Steps to reproduce after the [upgrade PR]: - Remove the CTA in 16.0 with the bin icon (on the button itself, or from the edit panel, next to the "Block" section). - Upgrade to 17.0. - The button is back. Edit the header and click to hide it. => a dialog opens "Are you sure y
Original PR description
After upgrading (specifically following this [upgrade PR]), when editing an element, the editor may be tricked into considering that the page isn't correct even though it is. It causes the "discard" dialog to open. Steps to reproduce after the [upgrade PR]: - Remove the CTA in 16.0 with the bin icon (on the button itself, or from the edit panel, next to the "Block" section). - Upgrade to 17.0. - The button is back. Edit the header and click to hide it. => a dialog opens "Are you sure you want to discard your changes?". - Click either "yes" or "cancel". => either way, nothing is discarded nor cancelled. [upgrade PR]: https://github.com/odoo/upgrade/pull/5500 Related to opw-3644220 Forward-Port-Of: odoo/odoo#151291
Although the lack of these statuses does not block the flow of a transaction, they create confusing records for the user. The new states are: Authorized: it is returned by Mercadopago when it authorizes payments by bundle. It should behave as a pending payment as it's not yet captured and could still be canceled by timeout. Cancelled: It is returned by Mercadopago when a payment is not made within the expected timeframe. This prevents odoo from leaving payment transactions in draft that can
Original PR description
Although the lack of these statuses does not block the flow of a transaction, they create confusing records for the user. The new states are: Authorized: it is returned by Mercadopago when it authorizes payments by bundle. It should behave as a pending payment as it's not yet captured and could still be canceled by timeout. Cancelled: It is returned by Mercadopago when a payment is not made within the expected timeframe. This prevents odoo from leaving payment transactions in draft that cannot be cancelled by the customer. adhoc ticket = 68407 Forward-Port-Of: odoo/odoo#152064 Forward-Port-Of: odoo/odoo#150435
STEP TO REPRODUCE : 1. create a time off type with alloation_validation_type == 'no' 2. create a batch allocation (with company, department, employee tag or employee mode but with some employees) 3. records will be duplicated Expected behaviour : no duplication task : 3615657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144394
Original PR description
STEP TO REPRODUCE : 1. create a time off type with alloation_validation_type == 'no' 2. create a batch allocation (with company, department, employee tag or employee mode but with some employees) 3. records will be duplicated Expected behaviour : no duplication task : 3615657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144394
Current behaviour: --- When planning more than 88 work orders, there is a recursion error. Steps to reproduce: --- 1. Go to Manufacturing 2. Operations > Manufacturing Orders 3. Create a manufacturing order 4. Add 90 work orders 5. Click on Confirm 6. Click on Plan 7. Recursion error Cause of the issue: --- Maximum depth of the Python interpreter stack The recursion limit being set at 1000 by default (with getrecursionlimit) Fix: --- Upped the limit to ~320 work orders
Original PR description
Current behaviour: --- When planning more than 88 work orders, there is a recursion error. Steps to reproduce: --- 1. Go to Manufacturing 2. Operations > Manufacturing Orders 3. Create a manufacturing order 4. Add 90 work orders 5. Click on Confirm 6. Click on Plan 7. Recursion error Cause of the issue: --- Maximum depth of the Python interpreter stack The recursion limit being set at 1000 by default (with getrecursionlimit) Fix: --- Upped the limit to ~320 work orders opw-3651494 Co-authored-by: Rémy Voet <ryv@odoo.com> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149617
Consider an invoice that was reset to draft. When it is is edited to be '/' (and the record is saved) an additional "Draft" title appears. It should not appear. After this commit the "Draft" title will not be shown on invoices that were posted before. task-3680398 Forward-Port-Of: odoo/odoo#152110 Forward-Port-Of: odoo/odoo#149351
Original PR description
Consider an invoice that was reset to draft. When it is is edited to be '/' (and the record is saved) an additional "Draft" title appears. It should not appear. After this commit the "Draft" title will not be shown on invoices that were posted before. task-3680398 Forward-Port-Of: odoo/odoo#152110 Forward-Port-Of: odoo/odoo#149351
The reCaptcha score was set by default on 0.5. According to [Google's documentation], that score isn't valid by default. It should be one of 0.1, 0.3, 0.7, 0.9. To use other values you must first go through a security review from reCaptcha. [Google's documentation]: https://cloud.google.com/recaptcha-enterprise/docs/interpret-assessment-website#before_you_begin task-3585213 Forward-Port-Of: odoo/odoo#152073 Forward-Port-Of: odoo/odoo#150208
Original PR description
The reCaptcha score was set by default on 0.5. According to [Google's documentation], that score isn't valid by default. It should be one of 0.1, 0.3, 0.7, 0.9. To use other values you must first go through a security review from reCaptcha. [Google's documentation]: https://cloud.google.com/recaptcha-enterprise/docs/interpret-assessment-website#before_you_begin task-3585213 Forward-Port-Of: odoo/odoo#152073 Forward-Port-Of: odoo/odoo#150208
[FIX] project: task date_deadline not copied Steps to reproduce: - create a project and a task inside - set date_deadline on the task - copy the project => the copied task has date_deadline = False Source: - date_deadline copy property wasn't changed to True when the field was merged with planned_date_end in 17.0 Fix: - copy was removed as its default value is True X-original-commit: https://github.com/odoo/odoo/commit/56073896a69d9f68ce7e7938d9dec7ef094e19b3 Forward-Port-Of: o
Original PR description
[FIX] project: task date_deadline not copied Steps to reproduce: - create a project and a task inside - set date_deadline on the task - copy the project => the copied task has date_deadline = False Source: - date_deadline copy property wasn't changed to True when the field was merged with planned_date_end in 17.0 Fix: - copy was removed as its default value is True X-original-commit: https://github.com/odoo/odoo/commit/56073896a69d9f68ce7e7938d9dec7ef094e19b3 Forward-Port-Of: odoo/odoo#152006
A recent feature in accounting (odoo#139225) introduces cross analytics, which allows submitting multiple accounts per line (one account per plan). This is not done, as would be assumed, by changing the `account_id` field from a Many2One to a Many2Many, but by adding fields to `account.analytic.line` every time a new root analytic plan is created. This approach has certain advantages, but a particular disadvantage is that it becomes harder to update existing lines. For MRP, updating rather un
Original PR description
A recent feature in accounting (odoo#139225) introduces cross analytics, which allows submitting multiple accounts per line (one account per plan). This is not done, as would be assumed, by changing…
A recent feature in accounting (odoo#139225) introduces cross analytics, which allows submitting multiple accounts per line (one account per plan). This is not done, as would be assumed, by changing the `account_id` field from a Many2One to a Many2Many, but by adding fields to `account.analytic.line` every time a new root analytic plan is created. This approach has certain advantages, but a particular disadvantage is that it becomes harder to update existing lines. For MRP, updating rather unlink-recreating lines is important for employee time tracking, where the analytic line will be updated every time the time worked is updated, and the employee's wage can change between updates. In this edge case, the accumulated cost must remain calculated at the old wage, and newer costs must accumulate at the new, actual wage. Concurrent closing line edge case ================================ An analytic distribution assigns divides an expense into smaller expenses for analytic accounting. Typically, every fractional expense is credited to a different analytic account, and they total to 100% of the original expense. With multiple analytic plans, dividing that expense can happen different ways. For example, one analytic plan may track expenses per department, while another keeps track of expenses per region. This means that an analytic distribution may contain accounts belonging to different plans, with every plan dividing the original expense in different ways across its own accounts. For cross accounting, fractional expenses can be assigned simultaneously (i.e. on one line) to multiple accounts (up to one per analytic plan). In our example, this would mean that this fraction was spent by a specific department in a specific region. For an analytic distribution to be accurate, we must ensure that for every plan, the sum of all accounts come out to the total percentage (usually 100%) that was distributed in the first place. Because multiplying large numbers with small percentages can introduce rounding errors, we need to correct for any discrepancies. With one account per line, this is easy; when a line closes out one of the plans in an analytic distribution, we assign the exact outstanding amount for that plan to that line, ensuring that the sum across all accounts adds up to the exact total percentage of the expense that was divided in the first place. Since every plan closes out on a different line, we can apply this correction every time and the amounts are always correct across the entire analytic distribution. The problem with cross analytics, and thus multiple accounts per line, is that a line can now sometimes close out two different plans, with slightly different outstanding amounts. This means we can no longer guarantee that every plan in an analytic distribution sums out to the original expense. Luckily, only certain analytic distributions are vulnerable to this edge case: they must distribute across multiple plans, and must have at least one line where not all participating plans are credited. There exists no trivial way to fix this. The current implementation follows the approach of the accounting module, which takes no special precautions against this edge case. Previously odoo#144941 [Task-3621105](https://www.odoo.com/web#id=3621105&cids=1&menu_id=4720&action=4043&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#146114
Steps to reproduce: - Enable Automated Valuation. - Set the cost of Acoustic Bloc Screens to 287.33. - Set the Product Category on the product to have AVCO automated valuation. - Enable Cash Rounding. - Create a Cash Rounding (see tests). - Make an invoice selling one Acoustic Bloc Screen and remove the tax. - Set the Cash Rounding on the invoice under "Other Info". - Confirm the invoice. Bug: when summing the amount of all the lines the result is slightly off (float accuracy) this w
Original PR description
Steps to reproduce: - Enable Automated Valuation. - Set the cost of Acoustic Bloc Screens to 287.33. - Set the Product Category on the product to have AVCO automated valuation. - Enable Cash Rounding. - Create a Cash Rounding (see tests). - Make an invoice selling one Acoustic Bloc Screen and remove the tax. - Set the Cash Rounding on the invoice under "Other Info". - Confirm the invoice. Bug: when summing the amount of all the lines the result is slightly off (float accuracy) this will create an unnecessary cash rounding to compensate Fix: round the sum to the currency precision before checking for the cash rounding opw-3681307 Forward-Port-Of: odoo/odoo#151833 Forward-Port-Of: odoo/odoo#151547
1. [TECHNICAL] Move send & print files into wizard folder when it's not the case 2. [TECHNICAL] More testing: test cron + cron in multicompany setup 3. Make 'invoices.zip' translatable 4. Use the bus to notify when cron starts or is done task-id: 3568549 Forward-Port-Of: odoo/odoo#149717
Original PR description
1. [TECHNICAL] Move send & print files into wizard folder when it's not the case 2. [TECHNICAL] More testing: test cron + cron in multicompany setup 3. Make 'invoices.zip' translatable 4. Use the bus to notify when cron starts or is done task-id: 3568549 Forward-Port-Of: odoo/odoo#149717
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#149543 Forward-Port-Of: odoo/odoo#149230
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#149543 Forward-Port-Of: odoo/odoo#149230
Steps to reproduce: ------------------- On the Time Off dashboard, click on a public holiday. Issue: ------ The duration is 1 Day instead of zero day. Cause: ------ To ignore the current holiday, the domain for finding holidays adds the condition: ```py ('holiday_id', '!=', self.id) ``` Unfortunately, if we have a `NewId`, in postgresql, `NULL != NULL` condition always returns NULL. As a result, public holidays (which do not have a `holiday_id`) will not be taken into accoun
Original PR description
Steps to reproduce:
-------------------
On the Time Off dashboard, click on a public holiday.
Issue:
------
The duration is 1 Day instead of zero day.
Cause:
------
To ignore the current holiday, the domain for finding holidays adds the condition:
```py
('holiday_id', '!=', self.id)
```
Unfortunately, if we have a `NewId`, in postgresql, `NULL != NULL` condition always returns NULL.
As a result, public holidays (which do not have a `holiday_id`) will not be taken into account.
Note:
This does not happen when you save because the id exists.
Solution:
---------
Accept `holiday_id` equal to `False` in the domain.
opw-3635949
Forward-Port-Of: odoo/odoo#151534Before this commit: The website selected in the website selector of the search view in the website.page list/kanban view was always set to the first one found in the DB and was never: 1. the one you visited in the website preview 2. or the one matching the URL of your backend. But 1. was working fine before commit [1] from the frameworkjs which introduced a way to "reset" the screen between apps/menu switch. Despite 1. working before commit [1], it was not ideally coded and worked "by c
Original PR description
Before this commit: The website selected in the website selector of the search view in the website.page list/kanban view was always set to the first one found in the DB and was never: 1. the one you…
Before this commit: The website selected in the website selector of the search view in the website.page list/kanban view was always set to the first one found in the DB and was never: 1. the one you visited in the website preview 2. or the one matching the URL of your backend. But 1. was working fine before commit [1] from the frameworkjs which introduced a way to "reset" the screen between apps/menu switch. Despite 1. working before commit [1], it was not ideally coded and worked "by chance", see below for a few facts and explication. ------------------ Fact 1: When you have multiple websites and you are on a website, the website served is result of 2 possibilities: 1. All websites have a specific domain, then you can only see a given website on its own domain. Attempting to select another website in the website switcher will redirect you to that other website domain. 2. You have one or more websites without any domain, then you can see those ones from any domain by using the website switcher. It will force the website in session, and despite being on a domain which should serve a given website (the one which has its domain set that domain if there is one), it will serve you the one you selected in the website switcher. Fact 2: - It is the `website_preview` which is setting the currentWebsite property of the `website_service`. - But the `website_service` can be used on its own, without any `website_preview` being involved in the process. - When the website preview is unmounted, the currentWebsite from the website service is reset to null. - The website page list component is reading the currentWebsite from the website service. - When switching from the website preview to another menu like the website pages list, the page list component (PageControllerMixin) is actually initialized/created before the website preview is unmounted. In the end, the follow happen: 1. Go to website preview -> it sets the website service current website 2. Go to website page list 3. The website page list component reads the current website from the website service which is set 4. The website preview is unmounted, emptying the current website from the website service 5. The website page list is shown to the user 6. Any call from the page list component to the current website will now be "wrong" / not return the same as during its `onWillStart`, as website preview was unmounted just after that, emptying the website set in the website service. Fact 3: Commit [1] changed the order listed above, now 4 occurs before 3, so when the page list component reads the website from the website service, the unmount of the website preview already kicked in, emptying that website service website. ----------------- This commit is simply finding the current website_id by asking it to the server. It will fix point 1. listed at the very beginning of the commit message, but will also make point 2. work. ---------------- Steps to reproduce 1: - Without any domain set, go to your DB in the website preview of your website in the backend - Switch to the website 2 in the navbar website switcher - You are now viewing website 2 in the website preview - Click on "Pages" in the "Site" menu to go to the page list view - The website selected in the search view is the first one, not the website 2. Also, the page shown are from the website 1, not the website 2. - This was working before commit [1] and this commit is fixing that. But this commit is also fixing/improving flows which never worked: - Before commit [1] (or in Odoo 16 to be simpler), do the same 4 first steps as above. - You will see that the listed pages are the ones from website 2 and that the selected website is the second one, correct. - Now just reload the page, it will show website 1, despite the website 2 being forced (if you did reload the page on the preview, it would still show website 2). - This is because the website_preview was never involved after the reload since you reached the list view / website service without going through the website preview. - The same can be seen if you go to the Pages list view directly through CTRL+K, in which case you won't go through the preview. [1]: https://github.com/odoo/odoo/commit/9f6ed9f6d1ef7ec1870980498480cae0ffc729d8 Related to task-3676124 opw-3658648 Forward-Port-Of: odoo/odoo#151269 Forward-Port-Of: odoo/odoo#149070
Steps to reproduce: - Create a branch for a company (e.g. Branch X) - Go to "Website / Configuration / Websites" - Create or configure a website on Branch X (e.g. Website X) - Go to "Website / Configuration / Settings" - Select Website X - Set "Display Product Prices" to "Tax Included" - Create a product for a price of $100 and a tax from parent company (e.g. 15%) - Go Website X - Edit Home page and add Products snippet Issue: On the Products snippet, the price of the product should
Original PR description
Steps to reproduce: - Create a branch for a company (e.g. Branch X) - Go to "Website / Configuration / Websites" - Create or configure a website on Branch X (e.g. Website X) - Go to "Website / Configuration / Settings" - Select Website X - Set "Display Product Prices" to "Tax Included" - Create a product for a price of $100 and a tax from parent company (e.g. 15%) - Go Website X - Edit Home page and add Products snippet Issue: On the Products snippet, the price of the product should be "Tax Included" ($115), but it is not. The displayed price is $100. Cause: When computing the prices, taxes from parent companies are not taken into account. This fix is a complement to https://github.com/odoo/odoo/pull/151223 opw-3660156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152105 Forward-Port-Of: odoo/odoo#152012
Before this commit, the website of the industry module ends with `/False`. This is because the website of the module requires the name of the module. It is therefore added in the `_get_modules_from_apps` method. Forward-Port-Of: odoo/odoo#152078
Original PR description
Before this commit, the website of the industry module ends with `/False`. This is because the website of the module requires the name of the module. It is therefore added in the `_get_modules_from_apps` method. Forward-Port-Of: odoo/odoo#152078
Description of the issue/feature this PR addresses: Escape HTML whenever a field is sent through email such as in the contact us form. Current behavior before PR: HTML was supported when an email was sent through the contact us form. Desired behavior after PR is merged: HTML is now escaped. Forward-Port-Of: odoo/odoo#151396 Forward-Port-Of: odoo/odoo#149968
Original PR description
Description of the issue/feature this PR addresses: Escape HTML whenever a field is sent through email such as in the contact us form. Current behavior before PR: HTML was supported when an email was sent through the contact us form. Desired behavior after PR is merged: HTML is now escaped. Forward-Port-Of: odoo/odoo#151396 Forward-Port-Of: odoo/odoo#149968
Install Studio Activate form view of journal items and disable readonly flag on Analytic distribution field. Create a journal entry adding analytic distribution to a line and post. Now open the journal item in form view and try to change the analytic distribution Action will be blocked by error This is caused by the onchange in _inverse_analytic_distribution. As the method take care of unlinking and creating new lines no more actions are required by the orm opw-3690346 Forward-Po
Original PR description
Install Studio Activate form view of journal items and disable readonly flag on Analytic distribution field. Create a journal entry adding analytic distribution to a line and post. Now open the journal item in form view and try to change the analytic distribution Action will be blocked by error This is caused by the onchange in _inverse_analytic_distribution. As the method take care of unlinking and creating new lines no more actions are required by the orm opw-3690346 Forward-Port-Of: odoo/odoo#151740
HOW TO REPRODUCE ================ Don't sign in and go to front-end > Courses > Trees, Wood and Gardens > Main Trees Categories. '< Prev' and 'Next >' are not centered vertically. HOW TO FIX ========== Slides navigation buttons are <a> HTML elements. Add them bootstrap class 'my-auto' to handle their height properly. task-3633452 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146154
Original PR description
HOW TO REPRODUCE ================ Don't sign in and go to front-end > Courses > Trees, Wood and Gardens > Main Trees Categories. '< Prev' and 'Next >' are not centered vertically. HOW TO FIX ========== Slides navigation buttons are <a> HTML elements. Add them bootstrap class 'my-auto' to handle their height properly. task-3633452 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146154
**Current behavior before PR:** if you have p within li,sometimes removing the p will result in the loss of all classes. **Desired behavior after PR is merged:** Replace p inside li with span while preserving classes. task-3546209 opw-3602047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151894 Forward-Port-Of: odoo/odoo#138973
Original PR description
**Current behavior before PR:** if you have p within li,sometimes removing the p will result in the loss of all classes. **Desired behavior after PR is merged:** Replace p inside li with span while preserving classes. task-3546209 opw-3602047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151894 Forward-Port-Of: odoo/odoo#138973
**Typo in HEAD tag of mail notification template** Impacted versions: - 16.0 - 17.0 Steps to reproduce: The `<HEAD>` tag in the mail notification templates was typo'd as `<HEADER>`. Current behavior before PR: No specific errors observed, but the `meta` tag for `Content-Type` may have been ignored. Desired behavior after PR is merged: The mail template displays as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
**Typo in HEAD tag of mail notification template** Impacted versions: - 16.0 - 17.0 Steps to reproduce: The `<HEAD>` tag in the mail notification templates was typo'd as `<HEADER>`. Current behavior before PR: No specific errors observed, but the `meta` tag for `Content-Type` may have been ignored. Desired behavior after PR is merged: The mail template displays as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148889
**[FIX] web, web_editor: fix text color of modals if dark body background** Before this commit, if the text color of the body was light (e.g., due to a dark body background), the text in certain modals (for example, in the "Alternative products" modal displayed when adding a product to a cart on a product page) was also light, making it not visible on the white modal background. Steps to reproduce the bug: - Install the e-commerce on your website. - In Settings, enable the "Optional
Original PR description
**[FIX] web, web_editor: fix text color of modals if dark body background** Before this commit, if the text color of the body was light (e.g., due to a dark body background), the text in certain…
**[FIX] web, web_editor: fix text color of modals if dark body background**
Before this commit, if the text color of the body was light (e.g., due
to a dark body background), the text in certain modals (for example, in
the "Alternative products" modal displayed when adding a product to a
cart on a product page) was also light, making it not visible on the
white modal background.
Steps to reproduce the bug:
- Install the e-commerce on your website.
- In Settings, enable the "Optional Products" option.
- Go to the "Customizable Desk" product page.
- Click on "Edit" to go in edit mode.
- Click on the "Theme" tab.
- Click on the 4th color of the theme colors and choose "black".
- Save the page to leave edit mode.
- Click on the "Add to cart" button.
- Bug: The text in the the modal is not visible because both text and
background are white and the input elements have their background the
same color as the body.
After this commit, we now verify that there is sufficient contrast
between the text color of the body and the background color of the
modals. If this condition is not met, we apply an alternative color
("$yiq-text-dark" or "$yiq-text-light") to the text of the modal to
ensure visibility.
opw-3570774
Forward-Port-Of: odoo/odoo#151346
Forward-Port-Of: odoo/odoo#147347Since searches in the home screen are now handled by the command palette, some ARIA attributes are required for assistive technologies to know what is the currently-selected result. That because the actual focus is always on the search box, while the actually-selected result is highlighted by toggling classes, which makes not possible anymore to know what is the selected result for e.g. screen reader users. For more info, see original implementation on enterprise's home menu on [1]. This comm
Original PR description
Since searches in the home screen are now handled by the command palette, some ARIA attributes are required for assistive technologies to know what is the currently-selected result. That because the actual focus is always on the search box, while the actually-selected result is highlighted by toggling classes, which makes not possible anymore to know what is the selected result for e.g. screen reader users. For more info, see original implementation on enterprise's home menu on [1]. This commit is just re-applying such changes here. [1] odoo/enterprise#14511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145872
Steps to reproduce: - first install bridge module 'project_account_budget' - open any project and go to project updates - in right side panel you see 'Profitability' button - click the profitability and switch to mobile view Issues: - heading of table are not vertically centered Solution: - Add style to vertically align center of heading Task: 3633405 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Original PR description
Steps to reproduce: - first install bridge module 'project_account_budget' - open any project and go to project updates - in right side panel you see 'Profitability' button - click the profitability and switch to mobile view Issues: - heading of table are not vertically centered Solution: - Add style to vertically align center of heading Task: 3633405 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#151839 Forward-Port-Of: odoo/odoo#148425
This commit corrects commit https://github.com/odoo/odoo/commit/7a78839ca6cf45ddec7adb59051da132e0ebceb4 that split the move_orig_ids for new stock moves created in backorder. The issue is this should only happens in case of subcontracting, not for every backorders --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151179 Forward-Port-Of: odoo/odoo#150843
Original PR description
This commit corrects commit https://github.com/odoo/odoo/commit/7a78839ca6cf45ddec7adb59051da132e0ebceb4 that split the move_orig_ids for new stock moves created in backorder. The issue is this should only happens in case of subcontracting, not for every backorders --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151179 Forward-Port-Of: odoo/odoo#150843
### Steps - Go to Invoicing, list view. - Select two records with the same partner. - Send receipt by mail. ### Issue Just one mail is sent. ### Reason ``mailing_document_based`` parameter which is used to enable sending multiple records to the same recipient is not passed in the context. opw-3552562 Forward-Port-Of: odoo/odoo#143754
Original PR description
### Steps - Go to Invoicing, list view. - Select two records with the same partner. - Send receipt by mail. ### Issue Just one mail is sent. ### Reason ``mailing_document_based`` parameter which is used to enable sending multiple records to the same recipient is not passed in the context. opw-3552562 Forward-Port-Of: odoo/odoo#143754
Revert of commit https://github.com/odoo/odoo/commit/da251b757d3bec9b663d7b5ad4d43929f2575a4f Problem --------- In said commit, tests were failing due to 1. the new restrictions on tax (related PR https://github.com/odoo/odoo/pull/130403) 3. default creation of repartition lines. However, updating the way chart_template._get_chart_template_data is patched in those tests was not the way to go. Because of that, some fixes due to migration error to 17.0 failed - PR https://github.com/od
Original PR description
Revert of commit https://github.com/odoo/odoo/commit/da251b757d3bec9b663d7b5ad4d43929f2575a4f Problem --------- In said commit, tests were failing due to 1. the new restrictions on tax (related PR https://github.com/odoo/odoo/pull/130403) 3. default creation of repartition lines. However, updating the way chart_template._get_chart_template_data is patched in those tests was not the way to go. Because of that, some fixes due to migration error to 17.0 failed - PR https://github.com/odoo/odoo/pull/149733. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151189
To reproduce on runbot: - edit the access rights of internal user 'lauriepoiret' and grant she the group "Sales / User: own document only" (and ensure she does not have the group "Purchase / User") - as 'lauriepoiret', create a sale order for a product without 'service subcontracting' (ex. Bacon Burger) and confirm it - click on "Cancel" button In the wizard and warning is shown: ``` There are active purchase orders linked to this sale order that are not cancelled automatically
Original PR description
To reproduce on runbot: - edit the access rights of internal user 'lauriepoiret' and grant she the group "Sales / User: own document only" (and ensure she does not have the group "Purchase / User") -…
To reproduce on runbot: - edit the access rights of internal user 'lauriepoiret' and grant she the group "Sales / User: own document only" (and ensure she does not have the group "Purchase / User") - as 'lauriepoiret', create a sale order for a product without 'service subcontracting' (ex. Bacon Burger) and confirm it - click on "Cancel" button In the wizard and warning is shown: ``` There are active purchase orders linked to this sale order that are not cancelled automatically! ``` As the user is not a member of `Purchase / User`, he has no right to read the `display_purchase_orders_alert` field which prevent the invisible attrs to be correctly evaluated, showing the warning in all cases even when there is no purchase order linked This commit restrict the PO warning to the same `Purchase / User` group to ensure that warning information is coherent --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151968 Forward-Port-Of: odoo/odoo#149785
**Steps to reproduce:** 1. Configuration > Projects 2. Open any project 3. Setting tab 4. Document field 5. Create and edit a new workspace. 6. Inspect mobile view 7. Save it or discard it -> traceback occurs **Technical Reason** The dialog values are prepared based on the desktop view, which results in the scrollToOrigin function is not being prepared when the condition is not met. Consequently, when the view is switched to mobile and inside the onWillDestroy, the scrollToOrigin i
Original PR description
**Steps to reproduce:** 1. Configuration > Projects 2. Open any project 3. Setting tab 4. Document field 5. Create and edit a new workspace. 6. Inspect mobile view 7. Save it or discard it -> traceback occurs **Technical Reason** The dialog values are prepared based on the desktop view, which results in the scrollToOrigin function is not being prepared when the condition is not met. Consequently, when the view is switched to mobile and inside the onWillDestroy, the scrollToOrigin is called but it is not prepared so traceback occurs. **After this PR** Now the function will be prepared even if we are not in the mobile view and traceback will not occur. Task-3573747 Forward-Port-Of: odoo/odoo#151954 Forward-Port-Of: odoo/odoo#142457
The tour ended with a class no always present, meaning it can fail in stock specific cases. This commit replace the last step by a new one searching the notification success to click on. Forward-Port-Of: odoo/enterprise#55239
Original PR description
The tour ended with a class no always present, meaning it can fail in stock specific cases. This commit replace the last step by a new one searching the notification success to click on. Forward-Port-Of: odoo/enterprise#55239
*: industry_fsm, industry_fsm_report Previously, the industry_fsm_tour would sometimes fail, it would appear that after transitioning between the webclient and the portal, the tour step would be incorrect when industry_fsm_sale or industry_fsm_report was installed. This is because the modules that define and patch the tour are implicitly asychronous because they import web.legacy_translations_loaded (directly or indirectly). This can cause the module loader to apply these patches after the to
Original PR description
*: industry_fsm, industry_fsm_report Previously, the industry_fsm_tour would sometimes fail, it would appear that after transitioning between the webclient and the portal, the tour step would be…
*: industry_fsm, industry_fsm_report Previously, the industry_fsm_tour would sometimes fail, it would appear that after transitioning between the webclient and the portal, the tour step would be incorrect when industry_fsm_sale or industry_fsm_report was installed. This is because the modules that define and patch the tour are implicitly asychronous because they import web.legacy_translations_loaded (directly or indirectly). This can cause the module loader to apply these patches after the tour_service has been started, and cause the tour to be started without the patches in some circumstances, causing the current step to be inconsistent between the frontend and backend. This commit fixes that by removing the import of web.legacy_translations_loaded, which makes the modules synchronous and guarantees that the patches are applied before the tour service starts. This import is no longer necessary since the tour steps is now a function that's only invoked by the tour service after the translations are known to be loaded. Forward-Port-Of: odoo/enterprise#55358 Forward-Port-Of: odoo/enterprise#55319
This commit fixes some issues that prevented the user from generating a return label in UPS REST module. To reproduce: Create a new shipping method with UPS. Enable "generate return label" toggle, and attempt to validate a delivery. There are a few issues as `ups_rest_get_return_label` was not adapted when forward porting from 15 to 16: + `_prepare_shipping_data` is changed, so it does not return `package_names` + `label_binary_data` from `_send_shipping` is changed from a dictionary
Original PR description
This commit fixes some issues that prevented the user from generating a return label in UPS REST module. To reproduce: Create a new shipping method with UPS. Enable "generate return label" toggle, and attempt to validate a delivery. There are a few issues as `ups_rest_get_return_label` was not adapted when forward porting from 15 to 16: + `_prepare_shipping_data` is changed, so it does not return `package_names` + `label_binary_data` from `_send_shipping` is changed from a dictionary to a list + as `package_names` no longer is there, the log message needs to be adapted. This PR fixes these issues, so that the return label could be generated. opw-3689861 Forward-Port-Of: odoo/enterprise#55328
Added new module l10n_in_reports_gstr_documents_spreadsheet it allows us to generate a spreadsheet report for gstr1 before sending the json to the portal task-3293298 Forward-Port-Of: odoo/enterprise#55467 Forward-Port-Of: odoo/enterprise#40589
Original PR description
Added new module l10n_in_reports_gstr_documents_spreadsheet it allows us to generate a spreadsheet report for gstr1 before sending the json to the portal task-3293298 Forward-Port-Of: odoo/enterprise#55467 Forward-Port-Of: odoo/enterprise#40589
Problem --------- With the integration of Codabox in l10n_be_codabox, we need to managed the automatic import of SODA. This is currently done but can be improved. Objective --------- Adapt the following point: 1. Put the date from <GenDate> by default in the date of document 2. Add the period linked to the document in the ref of the document. This info is store in the field <AccountPeriod> 3. In the matching form between SODA account and Account in the company: Merge the account and
Original PR description
Problem --------- With the integration of Codabox in l10n_be_codabox, we need to managed the automatic import of SODA. This is currently done but can be improved. Objective --------- Adapt the…
Problem --------- With the integration of Codabox in l10n_be_codabox, we need to managed the automatic import of SODA. This is currently done but can be improved. Objective --------- Adapt the following point: 1. Put the date from <GenDate> by default in the date of document 2. Add the period linked to the document in the ref of the document. This info is store in the field <AccountPeriod> 3. In the matching form between SODA account and Account in the company: Merge the account and the name from SODA (to be consistante with the column in which the user should add account) Solution --------- 1. Simply add the date data from the XML in the dictionary that will be passed to the wizard creating the account move and make sure the wizard gives that value in the move create method. 2. Concatenate the formatted <AccountPeriod> text to the ref. 3. Add a compute method to computes the display_name for the current model as it is done in account_account. Use the display name in the wizard view in readonly instead of the SODA account codes and names. task-3615994 Forward-Port-Of: odoo/enterprise#53204
With PR odoo/odoo#149543, we call dialog.closeAll when the action service executes an action. As a consequence, there was a crash in studio because that function doesn't exist on the override of the dialog service inside Studio. This commit fixes the issue. Forward-Port-Of: odoo/enterprise#55257
Original PR description
With PR odoo/odoo#149543, we call dialog.closeAll when the action service executes an action. As a consequence, there was a crash in studio because that function doesn't exist on the override of the dialog service inside Studio. This commit fixes the issue. Forward-Port-Of: odoo/enterprise#55257
Steps to reproduce: [account_accountant, sale_subscription] - create two quotations/subscriptions (sales) yearly: one with an analytic account, one without - confirm - create invoice - confirm - Go on Deferred Revenue - Filter Analytic with the one used in your quotation Issue: The analytic filter does not work Solution: We want to make sure to use `_query_get` to be consistent with other report generation and to make the retrieval of lines more easily maintainable opw-3603096 F
Original PR description
Steps to reproduce: [account_accountant, sale_subscription] - create two quotations/subscriptions (sales) yearly: one with an analytic account, one without - confirm - create invoice - confirm - Go on Deferred Revenue - Filter Analytic with the one used in your quotation Issue: The analytic filter does not work Solution: We want to make sure to use `_query_get` to be consistent with other report generation and to make the retrieval of lines more easily maintainable opw-3603096 Forward-Port-Of: odoo/enterprise#55254 Forward-Port-Of: odoo/enterprise#52622
1. When the user scan a product from the byProduct registration page, add it as a by product, not a component. 2. Add 'To Close' to the default active filters when opening MOs in the barcode app. 3. When I produce a serial, and I specify a serial number manually, the components are consumed. 4. Remove Traceback when cancel transfer action is discarded. 5. Renamed the 'Cancel Transfer' into 'Cancel Manufacturing Order' and its notification to 'The manufacturing order has been cancelled.' 6.
Original PR description
1. When the user scan a product from the byProduct registration page, add it as a by product, not a component. 2. Add 'To Close' to the default active filters when opening MOs in the barcode app. 3. When I produce a serial, and I specify a serial number manually, the components are consumed. 4. Remove Traceback when cancel transfer action is discarded. 5. Renamed the 'Cancel Transfer' into 'Cancel Manufacturing Order' and its notification to 'The manufacturing order has been cancelled.' 6. Do not allow to add a component/byProduct that is the same as the final product. 7. Allow production of product without BoM 8. Scanning a Manufacturing Operation Type triggers the creation of a MO rather than the creation of a Picking 9. Scanning O-BTN.scrap should open scrap view with digipad rather than scrap form dialog Task 3612790 Forward-Port-Of: odoo/enterprise#52149
When the home menu was modified to use the command palette on 2a518bc6, some ARIA attributes were lost that are still required. Such attributes are intended to indicate what is the focused app when no search is performed, i.e. the command palette has not been opened yet. Forward-Port-Of: odoo/enterprise#52570
Original PR description
When the home menu was modified to use the command palette on 2a518bc6, some ARIA attributes were lost that are still required. Such attributes are intended to indicate what is the focused app when no search is performed, i.e. the command palette has not been opened yet. Forward-Port-Of: odoo/enterprise#52570
Steps to reproduce: - first install bridge module 'project_account_budget' - open any project and go to project updates - in right side panel you see 'Add Budget' button - add some budget plan and switch to mobile Issues: - heading of table are not vertically centered Solution: - Add style to vertically align center of heading Task: 3633405 Forward-Port-Of: odoo/enterprise#55460 Forward-Port-Of: odoo/enterprise#52525
Original PR description
Steps to reproduce: - first install bridge module 'project_account_budget' - open any project and go to project updates - in right side panel you see 'Add Budget' button - add some budget plan and switch to mobile Issues: - heading of table are not vertically centered Solution: - Add style to vertically align center of heading Task: 3633405 Forward-Port-Of: odoo/enterprise#55460 Forward-Port-Of: odoo/enterprise#52525
Issue: ====== When having a product with duration variant and they have different temporal units, it will only display the temporal unit of the first selected variant in ecommerce product page. Steps to reproduce the issue: ============================== - Create a recurring product , add duration variant - Add pricing for each variant using different periods - Go to the product page in website and change the current variant , the temporal unit doesn't change. Origin of the issue: =
Original PR description
Issue: ====== When having a product with duration variant and they have different temporal units, it will only display the temporal unit of the first selected variant in ecommerce product page. Steps to reproduce the issue: ============================== - Create a recurring product , add duration variant - Add pricing for each variant using different periods - Go to the product page in website and change the current variant , the temporal unit doesn't change. Origin of the issue: ==================== It seems that the current code isn't reachable , and the function isn't updated. While debugging , this override of the function is never called but the website_sale_stock one is called. Solution: ========= I copied the same format of code done in website_sale_stock/static/src/js/variant_mixin.js and it solved the issue. opw-3618345 Forward-Port-Of: odoo/enterprise#52154
Follow up to 8c4445fc63dc01ea0cf359066e3cd21fbac23a7b. The field that was changed in that commit is computed, which is means it's readonly by default. opw-3635484 Forward-Port-Of: odoo/enterprise#55500
Original PR description
Follow up to 8c4445fc63dc01ea0cf359066e3cd21fbac23a7b. The field that was changed in that commit is computed, which is means it's readonly by default. opw-3635484 Forward-Port-Of: odoo/enterprise#55500