Tuesday, February 20, 2024
28 changes · saas-17.1
Resolved issues and error corrections
Opening page properties in debug mode no longer triggers an error caused by internal validation of the page form component. This keeps website page administration working smoothly for users and developers using debug mode.
Original PR description
Since [1], the clonePage and deletePage callbacks are props. This commit addresses the validation of component props specifically in development mode. It specializes the FormController component to be utilized by the PagePropertiesDialog component, resolving the issue. Steps to Reproduce: - Enter debug mode. - Navigate to any website page in the backend. - Click on page properties. Result: A traceback appears stating "Invalid props for component 'FormController'." [1]: https://github.com/odoo/odoo/commit/3242abc4bdb51e24dff8069cedb762677da611d9 task-3746498
Resending a signature document now works without triggering an error. This prevents interruptions for users who need to resend documents for signing and keeps the signing workflow reliable.
Original PR description
After the conversion of the user service to a simple module, a traceback started happening when trying to resend a document. This was due to the missing conversion of the user service paradigm to the module one for that specific flow. This commit fixes this by using the user module instead of the user service. task-3710633
This update resolves an issue where Odoo was displaying error messages from external pages when the live chat was embedded. The change removes a problematic error service that was incorrectly catching errors, leading to disruptive popups. This improves the user experience for live chat embeds.
Original PR description
Before this commit, an Odoo dialog would open to show errors that occurred in the pages embedding the live chat. We should not display errors originating from outside the embedded script. Moreover, the error service listens to the error event on the window object. Thus, errors occurring in the shadow DOM won't be caught. As a result, the error service disrupts the site that embeds it and is entirely useless for the live chat. This PR removes the error service from the embedded live chat. OPW-3699040 Forward-Port-Of: odoo/odoo#154102 Forward-Port-Of: odoo/odoo#154012
This update resolves a visual issue where tables within task descriptions would sometimes overflow the designated field, particularly when a new row was added above. The fix ensures that table widths are only set on the initial row, allowing for scrollable tables and preventing layout problems. This improves the user experience when creating and viewing task descriptions.
Original PR description
Reproduction: 1. In project -> task, create a new task 2. In the description, make a table of 1 row 2 columns, type two line long string in the second cell 3. Create a row above, type anything short, save 4. Add the portal user as follower, e.g. search user joel 5. In an incognito tab log in with portal portal, check the task and the table is out of the field Fix: Only set the width of the cells when it’s the first row and there’s other preset style of width for existing cells task-3559104 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154569 Forward-Port-Of: odoo/odoo#139016
This update resolves a bug where cursor movement near zero-width spaces in the editor caused the cursor to jump to the wrong block. The fix ensures accurate navigation within the editor, preventing users from unintentionally bypassing sections of text. This improves the overall editing experience.
Original PR description
Description of the issue this PR addresses: In cases where the cursor is at the end of the current block and the next block begins with a zero-width space, the mechanism that skips these characters while using arrow keys should not traverse all the way to the end of the zero-width space in the next block. Because this mechanism operates before the browser applies its own behavior for arrow keys, potentially causing the cursor to jump to the start of the third block when second block only contains a zero-width space, completely bypassing the second block. Conversely true for the arrow left keys. This commit ensures that the navigation does not extend beyond the current block when searching for a `newFocusNode` when moving with arrow keys near zero-width space. task-3653307 Forward-Port-Of: odoo/odoo#154676 Forward-Port-Of: odoo/odoo#153217
This update resolves an issue where clicking a document multiple times in the Documents activity view would open multiple 'Schedule Activity' wizards. The fix ensures that the wizard opens only once, streamlining the scheduling process and preventing user frustration with lingering windows.
Original PR description
**Steps to reproduce:** - Go to Documents activity view. - Click on Schedule activity. - Perform multiple clicks on any document. **Issue:** The 'Schedule Activity' wizard opened as many times as the document was clicked. As a result, even after successfully scheduling an activity on that document, the user still faced multiple open wizards remaining and had to manually close each one of them. **Fix:** This PR introduces a method `executeOnceAndClose` which makes use of a flag 'busy' to ensure that the `onSelected` function is called only once and hence exactly one `Schedule Activity` wizard is opened, despite clicking a record more than once. Task: [3721404](https://www.odoo.com/web#id=3721404&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#154442 Forward-Port-Of: odoo/odoo#153869
This update corrects a bug where a purchase bill automatically assigned the salesperson from the original purchase order, even when a different user (the purchase representative) created the bill. This ensures bills are correctly associated with the intended buyer, preventing unnecessary notifications and streamlining the billing process. This change improves data accuracy and user experience.
Original PR description
Steps to reproduce: - Install Accounting and Purchase - Create a PO with Purchase Representative different from current user (e.g. Marc Demo) 1) - Mark the product as received - Create a bill from PO 2) - Go to Accounting - Create a bill - Select the PO in Auto-Complete field - Save the bill Issue: The Purchase Representative of the PO is set as Salesperson (hidden field) of the bill. He should not. The default user (i.e. the current user) should be the Salesperson. In the second case, by adding the purchase representative as Salesperson of the bill, he is also added as a follower of the bill and he receives a notification about being assigned to the bill. opw-3677713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154356 Forward-Port-Of: odoo/odoo#151814
This update resolves an issue where the spreadsheet's share button dropdown menu displayed a scroll bar in certain languages. The fix adjusts the dropdown's height to automatically fit the content, ensuring a clean and consistent user experience across all languages. This improves usability for all users.
Original PR description
## Description: Previously, an issue was observed where the dropdown menu of the spreadsheet's share button displayed a scroll bar when users had selected a different language, such as French (BE). This PR addresses the problem by setting the height of the dropdown menu to auto, thereby resolving the issue of unnecessary scroll bar. Task ID: [3742260](https://www.odoo.com/web#id=3742260&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#154561 Forward-Port-Of: odoo/odoo#153834
This update corrects a bug where inactive tax settings incorrectly continued to influence fiscal position mappings. Now, when a tax is marked as inactive, it no longer affects related fiscal positions, ensuring accurate reporting and compliance. This improves data integrity within the accounting system.
Original PR description
When a tax is set to inactive, the fiscal positions mapping other taxes to it continued to apply, disregarding the fact that it shouldn't be used anymore. Not anymore with this fix. task-3751224 Forward-Port-Of: odoo/odoo#154464 Forward-Port-Of: odoo/odoo#154246
This update resolves an issue where the website editor's mobile order feature was limited to a maximum of 12 columns. The team decided to switch to inline styling to remove this restriction and ensure a more flexible layout for users. This change improves the usability of the website editor.
Original PR description
Commit [1] introduced mobile orders for columns in flex containers snippets. This was later amended with commit [2] to use Bootstrap's `order-X` classes. Finally, to be complete, commit [3] also added some manipulations around mobile orders. Those classes are limited to 12 possible orders, which means the feature stops working for any column over that threshold: a column with `order-13` will appear as if it didn't have any order. In the end, it has been decided that the trade-off of being capped at 12 mobile orders (and so 12 columns) and the behavior it causes isn't worth using the classes: we will use inline style instead. [1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba [2]: https://github.com/odoo/odoo/commit/143bdfa13d331b93b88e207f181840d91796cdce [3]: https://github.com/odoo/odoo/commit/7b27385dba36c2e741d96e76ad5d847d09f2b084 task-3666688 Forward-Port-Of: odoo/odoo#152024
Miscellaneous changes
This commit resolves a bug related to zero-width spaces within the inner content of a link. The bug led to a systematic test failure in 17.0 link_tools when comparing the input value with the expected value. The bug originated from [1] that manipulates zero-width spaces to allow users to select the edges of the link. Steps to reproduce: - Navigate to the Project app and open a random task (create one if none exists). - Select the "Description" tab. - Enter "/link" and press "Enter"
Original PR description
This commit resolves a bug related to zero-width spaces within the inner content of a link. The bug led to a systematic test failure in 17.0 link_tools when comparing the input value with the…
This commit resolves a bug related to zero-width spaces within the inner content of a link. The bug led to a systematic test failure in 17.0 link_tools when comparing the input value with the expected value. The bug originated from [1] that manipulates zero-width spaces to allow users to select the edges of the link. Steps to reproduce: - Navigate to the Project app and open a random task (create one if none exists). - Select the "Description" tab. - Enter "/link" and press "Enter" to activate the link tools dialog box. - In the link label field, input "The Website". - In the URL or email field, input "localhost:8069". - Save the changes. - A new div is generated with the class "note-editable". - Click on the newly created link. - Edit the link by clicking on the edit icon in the popover. - Direct the focus to the link label field at the end of the string "The Website". - Press the "Backspace" key — observe that nothing happens. It's maybe just a complement to this [PR] The test added in [2] eliminates zero-width-spaces prior to asserting the equality of values. This was appropriately addresses and handled in this commit. [PR]: https://github.com/odoo/odoo/pull/142135 [1]: https://github.com/odoo/odoo/commit/ab40f48 [2]: https://github.com/odoo/odoo/commit/a56586119845969e9d867a220f5330a6c7daa5c2 runbot-44779 Forward-Port-Of: odoo/odoo#153911 Forward-Port-Of: odoo/odoo#144321
Description of the issue/feature this PR addresses: Depending on user rights or customization, "Print" or "Action" menu can equals to "undefined". This causes a client error when selecting lines in the tree view. Current behavior before PR: javascript error " TypeError: print/action is undefined" is raised when selecting lines in the inventory list tree view. Desired behavior after PR is merged: No error raised if user has no print/action menu available. --- I confirm I have s
Original PR description
Description of the issue/feature this PR addresses: Depending on user rights or customization, "Print" or "Action" menu can equals to "undefined". This causes a client error when selecting lines in the tree view. Current behavior before PR: javascript error " TypeError: print/action is undefined" is raised when selecting lines in the inventory list tree view. Desired behavior after PR is merged: No error raised if user has no print/action menu available. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154254 Forward-Port-Of: odoo/odoo#152301
- Simplify and clean up formatLang code. - Adds the possibility to give formatLang() a 'rounding_mode' (any Decimal rounding mode) and an amount_rounding ('decimals', 'units', 'thousands', 'millions' and 'lakhs'). 'amount_rounding' will display the amount in the given unit. For example, 10456 in 'thousands' will be 10. task-3626894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151314
Original PR description
- Simplify and clean up formatLang code.
- Adds the possibility to give formatLang() a 'rounding_mode' (any Decimal rounding mode)
and an amount_rounding ('decimals', 'units', 'thousands', 'millions' and 'lakhs').
'amount_rounding' will display the amount in the given unit. For example, 10456 in 'thousands' will be 10.
task-3626894
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#151314According the SRI documentation, we should consider the accounting date (field date) on the search filters Forward-Port-Of: odoo/enterprise#55547
Original PR description
According the SRI documentation, we should consider the accounting date (field date) on the search filters Forward-Port-Of: odoo/enterprise#55547
When we unselect the mandatory benefit, the dependent benefit should be unset and disabled. But before this commit this is not a case. The explanation of an issue: The issue only happens if dependent benefit has value different from 0, so the value should be unset first before disabling the dependent benefit. When the dependent benefit should be unset, it calls the asynchronous function, which prevents the lines that disable the dependent benefit to be reached. task-3749171 Forward-
Original PR description
When we unselect the mandatory benefit, the dependent benefit should be unset and disabled. But before this commit this is not a case. The explanation of an issue: The issue only happens if dependent benefit has value different from 0, so the value should be unset first before disabling the dependent benefit. When the dependent benefit should be unset, it calls the asynchronous function, which prevents the lines that disable the dependent benefit to be reached. task-3749171 Forward-Port-Of: odoo/enterprise#56824 Forward-Port-Of: odoo/enterprise#56714
Steps to reproduce: - In Sequences > Sale order: change the prefix with `%(year)s` - create a SO; mark quotation as sent - create a bank statement with the same label as the SO's name - try to match Issue: No "sale orders" tab will ne displayed Cause: ``` > [x.lower() for x in text_tokens if x.lower().startswith(sequence_prefix)] [] ``` Since `sequence_prefix` would be `%(year)s` and the the label `202400022` Solution: Simplify everything with an orm search opw-3663266 Fo
Original PR description
Steps to reproduce: - In Sequences > Sale order: change the prefix with `%(year)s` - create a SO; mark quotation as sent - create a bank statement with the same label as the SO's name - try to match Issue: No "sale orders" tab will ne displayed Cause: ``` > [x.lower() for x in text_tokens if x.lower().startswith(sequence_prefix)] [] ``` Since `sequence_prefix` would be `%(year)s` and the the label `202400022` Solution: Simplify everything with an orm search opw-3663266 Forward-Port-Of: odoo/enterprise#56904 Forward-Port-Of: odoo/enterprise#55450
Current behavior: When the websocket connection is lost, the webworker will attempt to reconnect. However, the messages that were sent in the meantime are lost. The fix: The websocket webworker attempts reconnection indefinetely, so we do know that at some point it will indeed reconnect. To solve this, we listen to the reconnect event and retrieve the orders that were sent in the meantime. opw-3701020 Forward-Port-Of: odoo/enterprise#56163
Original PR description
Current behavior: When the websocket connection is lost, the webworker will attempt to reconnect. However, the messages that were sent in the meantime are lost. The fix: The websocket webworker attempts reconnection indefinetely, so we do know that at some point it will indeed reconnect. To solve this, we listen to the reconnect event and retrieve the orders that were sent in the meantime. opw-3701020 Forward-Port-Of: odoo/enterprise#56163
The current flow: - Create a MO with 2 operations - Select the shopfloor workcenters - Use an employee - Do the steps for the first operation - Try the otpion on the second operation (move to another wc, add component) - Close the production order Forward-Port-Of: odoo/enterprise#55433
Original PR description
The current flow: - Create a MO with 2 operations - Select the shopfloor workcenters - Use an employee - Do the steps for the first operation - Try the otpion on the second operation (move to another wc, add component) - Close the production order Forward-Port-Of: odoo/enterprise#55433
https://github.com/odoo/enterprise/pull/40112 allowed resending documents in mass, however it does not check for shared sign requests. Since shared sign requests are targetted at public users, it is not possible to resend them. This PR fixes this by ignoring the shared sign requests. It was chosen to ignore them because we still want to allow selecting all documents and resending only the ones that can be resent. task-3721338 Forward-Port-Of: odoo/enterprise#55824
Original PR description
https://github.com/odoo/enterprise/pull/40112 allowed resending documents in mass, however it does not check for shared sign requests. Since shared sign requests are targetted at public users, it is not possible to resend them. This PR fixes this by ignoring the shared sign requests. It was chosen to ignore them because we still want to allow selecting all documents and resending only the ones that can be resent. task-3721338 Forward-Port-Of: odoo/enterprise#55824
Steps: - Create a PO, confirm and receive the product - Create the bill from the PO - On the bill form add a section/note - Go to Other Infos tab -> "Should be paid" is set to "Exceptions", it should be "Yes" This is because we don't exclude section and note from the line when computing the field `release_to_pay` opw-3724937 Forward-Port-Of: odoo/enterprise#56622
Original PR description
Steps: - Create a PO, confirm and receive the product - Create the bill from the PO - On the bill form add a section/note - Go to Other Infos tab -> "Should be paid" is set to "Exceptions", it should be "Yes" This is because we don't exclude section and note from the line when computing the field `release_to_pay` opw-3724937 Forward-Port-Of: odoo/enterprise#56622
The `parent_line_id` parameter and value was missing from the generic line id. Forward-Port-Of: odoo/enterprise#56807 Forward-Port-Of: odoo/enterprise#56725
Original PR description
The `parent_line_id` parameter and value was missing from the generic line id. Forward-Port-Of: odoo/enterprise#56807 Forward-Port-Of: odoo/enterprise#56725
- Adds an option/filter to display amount in different units, i.e, 'decimals', 'units', 'thousands', 'lakhs' and 'millions'. - Makes 'format_value' a private python method and creates a new public 'format_value' method that should be called from the client. This change was made because we can not pass records from the client to the server. For example for currency, we can pass the currency_id to the server, but then we need to fetch the currency before continuing. task-3626894 Forwar
Original PR description
- Adds an option/filter to display amount in different units, i.e, 'decimals', 'units', 'thousands', 'lakhs' and 'millions'. - Makes 'format_value' a private python method and creates a new public 'format_value' method that should be called from the client. This change was made because we can not pass records from the client to the server. For example for currency, we can pass the currency_id to the server, but then we need to fetch the currency before continuing. task-3626894 Forward-Port-Of: odoo/enterprise#55218
**Performance Improvement on Referral Link Generation** --------------------------------------------------------------------------------------- Current State ------------------- Currently in the `hr.referral` module when you want to generate a new referral link for a user it takes more or less a second. State After this commit --------------------------------- The generation of the link is in average way under the 10ms mark Tests ordered by performance uplift ascending -------
Original PR description
**Performance Improvement on Referral Link Generation** --------------------------------------------------------------------------------------- Current State ------------------- Currently in the…
**Performance Improvement on Referral Link Generation**
---------------------------------------------------------------------------------------
Current State
-------------------
Currently in the `hr.referral` module when you want to generate a new referral link for a user it takes more or less a second.
State After this commit
---------------------------------
The generation of the link is in average way under the 10ms mark
Tests ordered by performance uplift ascending
-------------------------------------------------------------------
Note: All the tests have been made 3times and I took the less advantageous one for this commit every time.
Note2: As explained after the result are probably underestimated since with the current behavior we litterally make a request and get the full web page of the job position when generating a referral link which is extremely dependent on the load of the server and the db. (We can even have timeout) The time it takes currently is also directly dependant of the size of the job page so it could be theoretically speaking arbitrary long to get the job page.
Note3: All the tests are realized on 15.0
**Full response (+- 18x)**
**On runbot including the time of response before**

**On runbot including the time of response after**

We are in the golden bracket of 50-150ms latency
**Create (+- 100x)**
**On runbot before**
Note: Don't hesitate to click on the photos to zoom in it
cropped

full

**On runbot after**
cropped

full

**Note for master**
In master the `create` method is taking most of the time 3.8ms to execute with no real changes for the `search_or_create` so you'll get an uplift of arround 250x with this commit
Explaination
------------------
Currently when you generate a referral link in the referral app you'll call the the `search_or_create` method of the `link.tracker` model.
``` python
@api.model
def search_or_create(self, vals):
if 'url' not in vals:
raise ValueError(_('Creating a Link Tracker without URL is not possible'))
if vals['url'].startswith(('?', '#')):
raise UserError(_("%r is not a valid link, links cannot redirect to the current page.", vals['url']))
vals['url'] = tools.validate_url(vals['url'])
search_domain = [
(fname, '=', value)
for fname, value in vals.items()
if fname in ['url', 'campaign_id', 'medium_id', 'source_id']
]
result = self.search(search_domain, limit=1)
if result:
return result
return self.create(vals)
```
And if we don't have a hit during the search we will create the `link.tracker` record that is created this way:
```python
@api.model_create_multi
def create(self, vals_list):
vals_list = [vals.copy() for vals in vals_list]
for vals in vals_list:
if 'url' not in vals:
raise ValueError(_('Creating a Link Tracker without URL is not possible'))
if vals['url'].startswith(('?', '#')):
raise UserError(_("%r is not a valid link, links cannot redirect to the current page.", vals['url']))
vals['url'] = tools.validate_url(vals['url'])
if not vals.get('title'):
vals['title'] = self._get_title_from_url(vals['url'])
# Prevent the UTMs to be set by the values of UTM cookies
for (__, fname, __) in self.env['utm.mixin'].tracking_fields():
if fname not in vals:
vals[fname] = False
```
As we can see here if no **title** is given to the `search_or_create` method we will call the `_get_title_from_url` method of `link.tracker`
```python
@api.model
@api.depends('url')
def _get_title_from_url(self, url):
preview = link_preview.get_link_preview_from_url(url)
if preview and preview.get('og_title'):
return preview['og_title']
return url
```
If you time this method it takes around .9 seconds to do it's job. (In local it represent more than 99 percent of the time that take the `create` method)
On the runbot

If we go to `odoo.addons.mail.tools.link_preview` we can clearly see why it takes time
```python
def get_link_preview_from_url(url, request_session=None):
# Some websites are blocking non browser user agent.
user_agent = {'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0'}
try:
if request_session:
response = request_session.get(url, timeout=3, headers=user_agent, allow_redirects=True, stream=True)
else:
response = requests.get(url, timeout=3, headers=user_agent, allow_redirects=True, stream=True)
except requests.exceptions.RequestException:
return False
if not response.ok or not response.headers.get('Content-Type'):
return False
# Content-Type header can return a charset, but we just need the
# mimetype (eg: image/jpeg;charset=ISO-8859-1)
content_type = response.headers['Content-Type'].split(';')
if response.headers['Content-Type'].startswith('image/'):
return {
'image_mimetype': content_type[0],
'og_image': url, # If the url mimetype is already an image type, set url as preview image
'source_url': url,
}
elif response.headers['Content-Type'].startswith('text/html'):
return get_link_preview_from_html(url, response)
return False
def get_link_preview_from_html(url, response):
content = b""
for chunk in response.iter_content(chunk_size=8192):
content += chunk
pos = content.find(b'</head>', -8196 * 2)
# Stop reading once all the <head> data is found
if pos != -1:
content = content[:pos + 7]
break
if not content:
return False
tree = html.fromstring(content)
og_title = tree.xpath('//meta[@property="og:title"]/@content')
if og_title:
og_title = og_title[0]
elif tree.find('.//title') is not None:
# Fallback on the <title> tag if it exists
og_title = tree.find('.//title').text
else:
return False
og_description = tree.xpath('//meta[@property="og:description"]/@content')
og_type = tree.xpath('//meta[@property="og:type"]/@content')
og_site_name = tree.xpath('//meta[@property="og:site_name"]/@content')
og_image = tree.xpath('//meta[@property="og:image"]/@content')
og_mimetype = tree.xpath('//meta[@property="og:image:type"]/@content')
return {
'og_description': og_description[0] if og_description else None,
'og_image': og_image[0] if og_image else None,
'og_mimetype': og_mimetype[0] if og_mimetype else None,
'og_title': og_title,
'og_type': og_type[0] if og_type else None,
'og_site_name': og_site_name[0] if og_site_name else None,
'source_url': url,
}
```
As we can see it clearly makes a request to the server (in this case itself) that will take in most cases something like a second. (It can be longer and **timeout after 3 seconds and thus not even giving us a title at all and then give you the url as a title**)
[BTW In this case, doing that is probably sub optimal because we could probably just used some internal methods to accelerate the process instead of using `get`]
So we make a request to the server that will need to actually render the view with all the fields and then analyzing it to retrieve infos.
**In conclusion**
By giving a title to the link that we want to generate it will be way faster and since the title is not taken into account during the search part of the `search_or_create`, we basically have no change in behavior and even getting more consistency in the titles that will be displayed on base_url/r.
Other benefits
----------------------
1. Before the links title where generated using the meta of the web page. This can lead to basically random titles because if no one has visited the page before, the title will be the link (same if the request timeout) and if it has been visited it will be the title that you can see in your tabs.
2. You can basically reduce the number of requests to the server which in this case is even better because the more user you have the more likely you will overload it and increase the probability of a request timeout.
3. Before the multi db on read mode all the activity on website are tracked and since you literally visit the web page of the job title you'll get some bias on the website activity. This commit solve this issue as well because we'll not visit the job url anymore.
4. Consistency in the time needed to generated a link.
Performance impact for big companies like odoo
----------------------------------------------------------------------
**Today**
we have 35 different jobs opened for referral
We are 4k employees
if you want to generate all referral links even when taking advantage of batch it will take you more or less 35hours of computations
(in the near future we will include the possibility to generate all the links and send them to all employees and with this it's possible to do it in less than a minute by taking advantage of the batch create)
For the near future
----------------------------
2 tasks are including to generate a bunch of referral links at the same time (with a company of the size of odoo)
- 3418434 (more than a minute just to open the jobs page)
- 3607159 (with current state more than 2hours to send the mails)
task-3707478
Forward-Port-Of: odoo/enterprise#56907
Forward-Port-Of: odoo/enterprise#55349Several improvements and issues correction on switzerland payroll : name correction, column alignment task : 3644541 Forward-Port-Of: odoo/enterprise#53551
Original PR description
Several improvements and issues correction on switzerland payroll : name correction, column alignment task : 3644541 Forward-Port-Of: odoo/enterprise#53551
Before this commit, the ticket is set to a random helpdesk team with the id equals to 2 which is surely the id of a demo data (VIP Support). This commit makes sure the ticket created inside the test will be linked to a helpdesk team created in the test and not a helpdesk team linked to the demo data. runbot-57412 Forward-Port-Of: odoo/enterprise#56944
Original PR description
Before this commit, the ticket is set to a random helpdesk team with the id equals to 2 which is surely the id of a demo data (VIP Support). This commit makes sure the ticket created inside the test will be linked to a helpdesk team created in the test and not a helpdesk team linked to the demo data. runbot-57412 Forward-Port-Of: odoo/enterprise#56944
Before this commit, when the demo data adds a public leave for the current day, the test `test_adjust_grid_holidays` could fail because we could fetch the timesheet generating the public leave instead of the one created. This commit adds a freeze_time on the test to be sure the current date is not the current one but `2018-06-02`. runbot-57194 Forward-Port-Of: odoo/enterprise#56884 Forward-Port-Of: odoo/enterprise#56524
Original PR description
Before this commit, when the demo data adds a public leave for the current day, the test `test_adjust_grid_holidays` could fail because we could fetch the timesheet generating the public leave instead of the one created. This commit adds a freeze_time on the test to be sure the current date is not the current one but `2018-06-02`. runbot-57194 Forward-Port-Of: odoo/enterprise#56884 Forward-Port-Of: odoo/enterprise#56524
### Steps to reproduce: - Create a sale order with a service - Create a task in field service. - Link the sale order with the task - Duplicate the sale order. - Assign the new sale order to the task. - The smart buttons in this case aren't being updated and they remain linked to the previous sale. You can see this in the following video. ### Investigation: - The smart button is related to the `sale_order_id` - the method `_compute_sale_order_id` tends to set the sale_order_id to the o
Original PR description
### Steps to reproduce: - Create a sale order with a service - Create a task in field service. - Link the sale order with the task - Duplicate the sale order. - Assign the new sale order to the task. - The smart buttons in this case aren't being updated and they remain linked to the previous sale. You can see this in the following video. ### Investigation: - The smart button is related to the `sale_order_id` - the method `_compute_sale_order_id` tends to set the sale_order_id to the old value saved in `fsm_task_to_sale_order` before calling the parent `_compute_sale_order_id` even if the new value is not False -which is the purpose of the override- https://github.com/odoo/enterprise/blob/d9e66635dd3c2e9b994280b5e81fd53decbbf9d2/industry_fsm_sale/models/project_task.py#L168-L169 opw-3700469 Forward-Port-Of: odoo/enterprise#56115
- Create an asset - Add a related purchase in tab Bills. - Click on the related purchase. => You have the horrible form view of an aml, which is something we want to avoid at all costs. We instead prevent the opening and add a clickable name of the move, as it is what people would want to see. task-3749634 Forward-Port-Of: odoo/enterprise#56899
Original PR description
- Create an asset - Add a related purchase in tab Bills. - Click on the related purchase. => You have the horrible form view of an aml, which is something we want to avoid at all costs. We instead prevent the opening and add a clickable name of the move, as it is what people would want to see. task-3749634 Forward-Port-Of: odoo/enterprise#56899