Monday, April 24, 2023
42 changes · master
Enhancements to existing features
Users can now see a short preview of the message they are replying to directly in the composer header. This makes conversations easier to follow and helps reduce confusion when responding in busy message threads.
Original PR description
**Current behavior before PR:** Show a brief preview of the message which is being replied to. **Desired behavior after PR is merged:** Added a short message preview in composer header. Task-2664825 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo no longer adds a generic placeholder company logo to new databases or email templates by default. This reduces the risk of customers accidentally sending business emails with an unfinished “your logo” image and makes email actions clearer and better styled.
Original PR description
The sales product configurator has been modernized to use Odoo's newer interface framework, making it easier to maintain and improve over time. This change separates sales and e-commerce variant handling, while the e-commerce configurator remains on the older approach for a future update.
Original PR description
Product configurators were migrated to Owl, but some legacy code was kept as not urgent to migrate. This commit introduces the new product configurator in OWL. Some parts of the logic have now been rewritten in OWL, getting a better share between the back end and the front end. The product configurator in e-commerce still uses the old implementation and will be refactored in another task. See also: - https://github.com/odoo/enterprise/pull/39525 - https://github.com/odoo/upgrade/pull/4550 task-3056806
Guests using Odoo Discuss can now change their avatar directly from the chat top bar. This makes guest participation feel more personal and gives external users simple control over how they appear in conversations.
Original PR description
**Current behavior before PR:** The guest should be able to change his avatar. **Desired behavior after PR is merged:** Guest can change his avatar by clicking on his avatar in `ThreadViewTopbar`. Task-2664819 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds an automated test to confirm that users can create a new channel from the Discuss sidebar. It helps protect the messaging experience from future regressions without changing existing user-facing behavior.
Original PR description
**Description of the issue/feature this PR addresses:** Add test case for new Channel creation from Discuss Sidebar. Task-2620829 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The color picker now uses tab labels that better match what users see: theme colors, solid colors, or custom colors. This makes choosing colors in the website editor and toolbar clearer and reduces confusion.
Original PR description
The first tab of the colorpicker can, depending on the context: - display a selection of color combinations for the current **theme** (when launched as a snippet option, for example, in the website builder); or - display a selection of **solid** colors (when lauched from the toolbar). The commit changes the tab's name to conditionally reflect its content: "Theme" or "Solid". The second tab allows the user to pick a **custom** RGBA color. This commit renames it to "Custom", replacing the inaccurate "Solid" name, now in use for the first tab. task-3274225
Spreadsheet dashboards now include a Year-to-Date period filter, making it easier to view results from January 1 through today. This helps business users quickly track current-year performance without manually setting date ranges.
Original PR description
### Description of the issue/feature this PR addresses: This PR adds YTD (year to date) filter to global period filters in dashboard. YTD filter gets the data from Jan 1st of the current year to today (included). The unit of its offset is year. ### Current behavior before PR: Global filters don't have YTD filter. ### Desired behavior after PR is merged: Have now. task [3215947](https://www.odoo.com/web#id=3215947&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds sample data for the recruitment appointment flow, including demo appointment records and email templates. It helps teams better understand, test, and demonstrate how appointment scheduling works in hiring scenarios without manual setup.
Original PR description
task: 3256007
Knowledge now accounts for extra database interactions created when gamification is installed. This keeps gamification challenge progress accurate while reflecting the additional activity tracking needed behind the scenes.
Original PR description
We are now storing users interactions with the DB in order to update gamification challenges. This causes additional queries when gamification is installed. See related COM PR Task-3226408
Documents received by email now automatically use the sender as the contact when no contact was set on the share link. If the sender is not already known, the system creates a new contact, making incoming documents easier to identify and manage.
Original PR description
If not explicitly defined on the documents.share, when receiving a document by email, we set the contact to the partner corresponding to the email sender. If no partner exists with that email, a new one is created. Based on preliminary work of Co-authored-by: ThanhDodeurOdoo <tso@odoo.com> Task-2478266
Email templates now avoid showing the default placeholder company logo when a real company logo has not been set. This helps prevent customers from receiving emails with unfinished-looking branding and keeps outgoing communications more professional.
Original PR description
Many templates use the company logo that is set by default on database creation. As that logo is clearly a placeholder and the user isn't necessarily prompted to update it. It's possible for a user to inadvertently start sending emails with "your logo" placeholders plastered all over. This removes the default logo of the company and removes it from templates conditionally. The logo isn't simply replaced with a transparent PNG as the templates set a fixed height for the logo, which would look weird. task-3067315
Online sales modules now manage their own product variant configuration instead of sharing the standard sales logic. This makes website purchases, rentals, and subscriptions easier to adapt independently and reduces the risk of cross-module behavior conflicts.
Original PR description
Currently, `website_sale` uses the same logic as `sale` to show the product variant configuration. This commit aims to separate this logic and let each module handle its own product variant configuration. See also: - https://github.com/odoo/odoo/pull/106511 - https://github.com/odoo/upgrade/pull/4550 task-3056806
Resolved issues and error corrections
This fixes an internal compatibility issue so Odoo continues to run correctly on Python 3.7, which is still a supported version. The change prevents a crash in core data handling by using an approach that works across supported Python versions.
Original PR description
Our minimal Python version is still Python3.7 `reversed(annoted_groupby.items())` doesn't work in Python3.7 because `dict_items` are not reversible in this version (only available in Python3.8 : https://docs.python.org/3/whatsnew/3.8.html#other-language-changes). Convert into list before `reversed` to be compatible in Python3.7
Code cleanup and technical improvements
The live chat message posting logic was moved into the live chat area because it is only used there. This prepares the product for future separation of messaging components without changing expected customer-facing behavior.
Original PR description
It is only used there. In preparation of splitting discuss and mail modules. Part of task-3265211 ------------- Notes: - [x] this will conflict with https://github.com/odoo/odoo/pull/119301 - [x] this will conflict with https://github.com/odoo/odoo/pull/119302 - [x] the last of these PR merged can remove the file `controllers/bus.py`
Miscellaneous changes
Ease 'dropship' purchase orders for subcontractors. At the moment, it is not possible to dropship a subcontractor with a mix of products, some of which are part of a subcontracting BOM and some of which are not. This becomes possible, but it remains mandatory to choose between - Dropship (for the 'customer' location) - Dropship Subcontractor (for the 'subcontracting' location). Due to the destination location, it is not possible to combine the two streams in a single purchase order. task:
Original PR description
Ease 'dropship' purchase orders for subcontractors. At the moment, it is not possible to dropship a subcontractor with a mix of products, some of which are part of a subcontracting BOM and some of which are not. This becomes possible, but it remains mandatory to choose between - Dropship (for the 'customer' location) - Dropship Subcontractor (for the 'subcontracting' location). Due to the destination location, it is not possible to combine the two streams in a single purchase order. task: 3199595 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#119348 Forward-Port-Of: odoo/odoo#115133
Many templates use the company logo that is set by default on database creation. As that logo is clearly a placeholder and the user isn't necessarily prompted to update it. It's possible for a user to inadvertently start sending emails with "your logo" placeholders plastered all over. This removes the default logo of the company and removes it from templates conditionally. The logo isn't simply replaced with a transparent PNG as the templates set a fixed height for the logo, which would look weird. task - 3067315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Clicking a reply backlink from the starred mailbox now either takes users to the original open conversation or shows a clear warning when it cannot. This prevents confusing dead clicks and helps users follow message context more reliably.
Original PR description
**Current behavior before PR:** Nothing happens when you click on the message backlink in the starred mailbox. **Desired behavior after PR is merged:** If the origin channel is open then the user will be redirected or a warning notification will be displayed. Task-2939118 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes issues that could cause errors or warning notifications when users grouped records in list or reporting views. It improves reliability for grouped calendar views and other reports that group by the same linked field more than once.
Original PR description
### [FIX] core: read_group same relational grouping Before 916c9c4, we could groupby several times on the same relational fields for a `read_group` call. Example: `read_group([], [...],…
### [FIX] core: read_group same relational grouping
Before 916c9c4, we could
groupby several times on the same relational fields for a
`read_group` call. Example:
`read_group([], [...], groupby=['product_id', 'product_id'], ...)`.
Now, it produces a traceback:
File "/data/build/odoo/odoo/models.py", line 2583, in read_group
self._read_group_format_result(rows_dict, lazy_groupby)
File "/data/build/odoo/odoo/models.py", line 2396, in _read_group_format_result
ids = [row[group].id for row in rows_dict if row[group]]
File "/data/build/odoo/odoo/models.py", line 2396, in <listcomp>
ids = [row[group].id for row in rows_dict if row[group]]
AttributeError: 'tuple' object has no attribute 'id'
It is because `_read_group_format_result` try to convert the record
into tuple (id, display_name) twice (one for each groupby).
Fix this issue introduced by the refactor of `_read_group`.
### [FIX] calendar: groupby on calendar.event triggers 'danger' notification
The `read_group` of `calendar.event` sends a danger notification when
the user groups by any field in the list view. It is because the
security reenforcement done in 2c0b3ab
is too strict. It checks all `fields`, even the ones that are filtered
out by the `read_group` (`fields` without aggregation specification
nor `group_operator`).Marketing automation campaigns now correctly record participant values even when a campaign has no grouped activity data. This prevents missing or blank participant information and keeps campaign reporting reliable.
Original PR description
on defaultdict in _compute_participants This solves an issue with _compute_participants not setting any value if a campaign wasn't present in the return of a _read_group. We recently started using a defaultdict when adapting to the improved _read_group method at https://github.com/odoo/enterprise/commit/0a24c01ec178984df032710b81d562366c016ebb defaultdict will not add new entries when using the `get` method. It will instead return None like a regular dict. We just replace .get with directly addressing the element. task-3284558
web === Fix selection widget caret overlap. When the text is long enough to reach the caret, the caret is overlapping the text which hides it and makes it unreadable. Add a gap between the text and the caret. sale_stock ======== Make the picking policy selection field longer to avoid hiding the selected text. Task-3267526 Forward-Port-Of: odoo/odoo#119044 Forward-Port-Of: odoo/odoo#118059
Original PR description
web === Fix selection widget caret overlap. When the text is long enough to reach the caret, the caret is overlapping the text which hides it and makes it unreadable. Add a gap between the text and the caret. sale_stock ======== Make the picking policy selection field longer to avoid hiding the selected text. Task-3267526 Forward-Port-Of: odoo/odoo#119044 Forward-Port-Of: odoo/odoo#118059
Some demo data bill of material have workorder operation. Trying to use them without the workorder setting activated will give an error on some fields not instantiated. This commit activate/deactivate the operations depending on the workorder setting. 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: od
Original PR description
Some demo data bill of material have workorder operation. Trying to use them without the workorder setting activated will give an error on some fields not instantiated. This commit activate/deactivate the operations depending on the workorder setting. 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#115150
Behaviour before commit: If the location is a production or inventory location, you can set an account_id for the valuation. Once this account_id is set, it will still be there if you change the type of location to a view location for example. This may not be the right account_id given the new type of location. Behaviour after commit: Check if the location is of a specific type, if it's not inventory or production, it will take the default valuation account id from the product category. Oth
Original PR description
Behaviour before commit: If the location is a production or inventory location, you can set an account_id for the valuation. Once this account_id is set, it will still be there if you change the type of location to a view location for example. This may not be the right account_id given the new type of location. Behaviour after commit: Check if the location is of a specific type, if it's not inventory or production, it will take the default valuation account id from the product category. Otherwise it will take the one set on the location. OPW-3269584 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#119229
Added the first package for the Tunisian accounting localization. This includes: - Chart of Accounts - Account groups - Taxes - Fiscal Positions - Tax groups - Tax report - Translation in French - A demo company links to documents can be found in the task details task-3093908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117800
Original PR description
Added the first package for the Tunisian accounting localization. This includes: - Chart of Accounts - Account groups - Taxes - Fiscal Positions - Tax groups - Tax report - Translation in French - A demo company links to documents can be found in the task details task-3093908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117800
Currently the POS does not load if a Stripe payment method is configured and there is no internet connection. This commit fixes the loading of Stripe resources to allow the opening of the POS and the display of related errors task 3177045 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#1189
Original PR description
Currently the POS does not load if a Stripe payment method is configured and there is no internet connection. This commit fixes the loading of Stripe resources to allow the opening of the POS and the display of related errors task 3177045 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#118907 Forward-Port-Of: odoo/odoo#114421
The finished move of a production order should be cleared if we change the product but updated if wechange the quantity to produced. Clearing the moves at each production order modification will result of creating new draft stock move not linked to any business document(picking, MO, ... ) 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.o
Original PR description
The finished move of a production order should be cleared if we change the product but updated if wechange the quantity to produced. Clearing the moves at each production order modification will result of creating new draft stock move not linked to any business document(picking, MO, ... ) 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#109792
__Current behavior before PR:__ The size of an image field is guessed using the field name. For instance, an image field with `field_name = "XXXX_123"` is resized to 123 pixels when fetched. This is can be an issue if a user creates an image field using studio in a form view. If the user sets the label of the field as "Image 1", the technical name will become `x_studio_image_1`. Therefore, the image field will be resized to 1 pixel width. __Description of the fix:__ Refactor the `image_gues
Original PR description
__Current behavior before PR:__ The size of an image field is guessed using the field name. For instance, an image field with `field_name = "XXXX_123"` is resized to 123 pixels when fetched. This is can be an issue if a user creates an image field using studio in a form view. If the user sets the label of the field as "Image 1", the technical name will become `x_studio_image_1`. Therefore, the image field will be resized to 1 pixel width. __Description of the fix:__ Refactor the `image_guess_size_from_field_name` method to return `(0, 0)` when the field name starts with `x_studio_`. __Steps to reproduce the issue:__ 1. Open a form view (of any model) 2. Open studio 3. Add an image field with label "Image 1" (notice the technical name becomes in `x_studio_image_1` in debug mode) 4. Close studio 5. Upload an image on the created field 6. Save... The image is resized to 1 pixel width opw-3242084 opw-3249632 opw-3253133 Forward-Port-Of: odoo/odoo#117343
This commit makes sure that fields without widget in kanban are properly formatted using the rawAttrs. Steps to reproduce: create a float kanban field without widget, set the digits to anything other than default and see if the digits attrs are applied to the field. opw-3263583 Forward-Port-Of: odoo/odoo#118978 Forward-Port-Of: odoo/odoo#117796
Original PR description
This commit makes sure that fields without widget in kanban are properly formatted using the rawAttrs. Steps to reproduce: create a float kanban field without widget, set the digits to anything other than default and see if the digits attrs are applied to the field. opw-3263583 Forward-Port-Of: odoo/odoo#118978 Forward-Port-Of: odoo/odoo#117796
This module allows to add secret key to add the turnstile captcha on website_form snippet Widely inspired of google_recaptcha --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#116252
Original PR description
This module allows to add secret key to add the turnstile captcha on website_form snippet Widely inspired of google_recaptcha --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#116252
Before this commit, when hovering the shopping cart in the "Boxed" and "Centered Logo" header templates, the cart popover was not appearing. This happened because the `websiteSaleCartLink` public widget was never started with these templates and so, hovering the cart had no effect. This is due to this widget selector which targeted a cart link located inside an element with id `#top_menu`, which is not the case in these templates where the cart link is located outside of it. This commit fi
Original PR description
Before this commit, when hovering the shopping cart in the "Boxed" and "Centered Logo" header templates, the cart popover was not appearing. This happened because the `websiteSaleCartLink` public widget was never started with these templates and so, hovering the cart had no effect. This is due to this widget selector which targeted a cart link located inside an element with id `#top_menu`, which is not the case in these templates where the cart link is located outside of it. This commit fixes this widget selector, in order for the cart link to be reachable in all header templates. opw-3267114 Forward-Port-Of: odoo/odoo#118822
There was two issues regarding the slides public views counter 1. If the `public_views` is set to `NULL` in database, `increment_fields_skiplock` wasn't properly incrementing the count. Indeed, in SQL, doing NULL + 1 returns NULL ```sql 16.0=# SELECT NULL + 1; ?column? ---------- (1 row) ``` To have the result we expect, COALESCE must be used ```sql 16.0=# SELECT COALESCE(NULL, 0) + 1; ?column? ---------- 1 (1 row) ``` 2. There is a mechanism, using the session, s
Original PR description
There was two issues regarding the slides public views counter
1. If the `public_views` is set to `NULL` in database, `increment_fields_skiplock` wasn't properly incrementing the count. Indeed, in SQL, doing NULL + 1 returns NULL
```sql
16.0=# SELECT NULL + 1;
?column?
----------
(1 row)
```
To have the result we expect, COALESCE must be used
```sql
16.0=# SELECT COALESCE(NULL, 0) + 1;
?column?
----------
1
(1 row)
```
2. There is a mechanism, using the session, supposed to prevent incrementing the public views
counter when a same user visits multiple times the same slide. However, since 84d17e57e8316579ec85c1f6097d97ac6948c785 the visited slide was never actually added in the session, because it was adding the slide id in a copy of the set in session rather than adding in the set from the session. Or, as this commit does, to re-assign the new set in the session.
Forward-Port-Of: odoo/odoo#118372Description of the issue/feature this PR addresses: It prevents the colorpicker from closing when clicked on it when setting a custom color on the "Solid" tab. This is normal behavior on 15.0, but it is broken on 16.0.  (see the commit diff) Since Bootstrap was updagraded to 5.1.3, `ev.clickEvent` is no longer a `JQuery.Event`. Therefore, the `originalEvent` property does not e
Original PR description
Description of the issue/feature this PR addresses: It prevents the colorpicker from closing when clicked on it when setting a custom color on the "Solid" tab. This is normal behavior on 15.0, but it is broken on 16.0.  (see the commit diff) Since Bootstrap was updagraded to 5.1.3, `ev.clickEvent` is no longer a `JQuery.Event`. Therefore, the `originalEvent` property does not exist anymore, and `__isColorpickerClick` can be accessed directly from `ev.ClickEvent`. By checking for the non-existent `originalEvent` property, the mechanism that enables the colorpicker to remain open when clicked was being hindered. Note that this handler's `ev` remains a `JQuery.Event`, and if a handler returns `false`, it will prevent the default action and stop the event propagating. task-3274987 Forward-Port-Of: odoo/odoo#118602
On a model X, where there is a field related `x_related` (`related='y_id.y_translate'`) towards a **translated** field `y_translate` on Model Y. When you unlink at least 1001 records of X (r1, r2, ... , r1000, r1001) (cr.MAX_IN + 1), you get a traceback (`RecursionError: maximum recursion depth exceeded in comparison`). The stack looks like: ``` File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3609, in unlink self.env.flush_all() File "/home/odoo/Documents/dev/odoo/odoo/ap
Original PR description
On a model X, where there is a field related `x_related` (`related='y_id.y_translate'`) towards a **translated** field `y_translate` on Model Y. When you unlink at least 1001 records of X (r1, r2,…
On a model X, where there is a field related `x_related`
(`related='y_id.y_translate'`) towards a **translated** field `y_translate`
on Model Y.
When you unlink at least 1001 records of X
(r1, r2, ... , r1000, r1001) (cr.MAX_IN + 1), you get a traceback
(`RecursionError: maximum recursion depth exceeded in comparison`).
The stack looks like:
```
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3609, in unlink
self.env.flush_all()
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 732, in flush_all
self._recompute_all()
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 728, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6179, in _recompute_field
field.recompute(records)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1348, in recompute
self.compute_value(record)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1368, in compute_value
records._compute_field_value(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4209, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 100, in determine
return needle(records, *args)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5874, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 2771, in __get__
return super().__get__(records, owner)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1186, in __get__
recs._fetch_field(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3162, in _fetch_field
self._read(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3214, in _read
self.flush_recordset(translated_field_names)
```
-> Extra info:
translated_field_names = ['x_related']
`self = X(r1001, r1, r2, ..., r999)`
```
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5585, in flush_recordset
self._recompute_recordset(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6162, in _recompute_recordset
self._recompute_field(field, self._ids)
```
-> Long recursion starts here but first records to be recomputed will be r1, then r2, then r3, ...
But the maximum recursion depth error will be triggered earlier at the
end of the recursion, because the stack limit in Python is 1000
by default.
```
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6179, in _recompute_field
field.recompute(records)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1348, in recompute
self.compute_value(record)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1368, in compute_value
records._compute_field_value(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4209, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 100, in determine
return needle(records, *args)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5874, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 2771, in __get__
return super().__get__(records, owner)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1186, in __get__
recs._fetch_field(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3162, in _fetch_field
self._read(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3214, in _read
self.flush_recordset(translated_field_names)
```
-> Extra info:
translated_field_names = ['x_related']
`self = X(r1, r2, ... , r999)`
```
...
```
The `x_related` is flagged to be recomputed at the end of the delete
loop of `unlink`, but it shouldn't be, because records are deleted now.
The problem is in these lines:
```python
with self.env.protecting(self._fields.values(), records):
self.modified(self._fields, before=True)
```
The `records` are only a part of `self` (batch of 1000), so the
`protecting` call only protects the current batch and not `self`.
Then, the second batch (here with only one record), will flag to recompute
`x_related` of the first batch records. Then, later on, the `flush_all`
will generate the recursion error trying to resolve
these `to_recompute`.
To fix it, only move the modified call (+ protecting) before
the batch loop and executes it on `self`.
This issue shouldn't exist in master, because having a
related translate field triggers a warning (`Translated stored related
field (<field_name>) will not be computed correctly in all languages`).
Also `https://github.com/odoo/odoo/pull/100472` fixes the issue in
master, but it generates one SQL request by record, which isn't great.
Then in master, we should forward this commit (but test will be remove
because it generates the warning message).
Forward-Port-Of: odoo/odoo#119434
Forward-Port-Of: odoo/odoo#119205Reproduction: 1. Install Project, Helpdesk, go to Project -> Configuration -> Activity Types-> Upload Documents 2. Type a super long text in Default Note, the text overlaps the EN button Reproduction 2: 1. Go to Helpdesk -> configuration -> Helpdesk Teams -> Customer Care 2. Type a super long text in the description of the team, the text overlaps the EN button Fix: we set concrete padding to the right to make sure the translation button is not overlapped. The fix needs to be done in en
Original PR description
Reproduction: 1. Install Project, Helpdesk, go to Project -> Configuration -> Activity Types-> Upload Documents 2. Type a super long text in Default Note, the text overlaps the EN button Reproduction…
Reproduction: 1. Install Project, Helpdesk, go to Project -> Configuration -> Activity Types-> Upload Documents 2. Type a super long text in Default Note, the text overlaps the EN button Reproduction 2: 1. Go to Helpdesk -> configuration -> Helpdesk Teams -> Customer Care 2. Type a super long text in the description of the team, the text overlaps the EN button Fix: we set concrete padding to the right to make sure the translation button is not overlapped. The fix needs to be done in enterprise too Note: The reproduction 2 is another sub-issue found when fixing the first one. Reproduction 1 is for the note field with oe-bordered-editor, and reproduction 2 is for the note field without it. Related Previous Commit: Odoo: https://github.com/odoo-dev/odoo/commit/26ecbc16bc8079c7bb08095f1b27b4f68ca0e947 Enterprise: https://github.com/odoo-dev/enterprise/commit/e2ca9d5a113bc3adbe085057eff778b24abf5ddc task-3047773 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#119454 Forward-Port-Of: odoo/odoo#117156
Missing `nextTick` for this `tap` (compared to other similar calls). Forward-Port-Of: odoo/odoo#119242
Original PR description
Missing `nextTick` for this `tap` (compared to other similar calls). Forward-Port-Of: odoo/odoo#119242
Activate Multicurrency (USD company curr, EUR foreign currency, 1 EUR = 2 USD) Have a Bank account in both currencies. Create an expense of 100€, paid by company Create report, set EUR journal as Bank Journal Send To manager > Approve > Post Journal Entries Open created payment Issue: - Payment amount is 200€ - In journal items, amount_currency and balance is 200$ opw-3269009 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior aft
Original PR description
Activate Multicurrency (USD company curr, EUR foreign currency, 1 EUR = 2 USD) Have a Bank account in both currencies. Create an expense of 100€, paid by company Create report, set EUR journal as Bank Journal Send To manager > Approve > Post Journal Entries Open created payment Issue: - Payment amount is 200€ - In journal items, amount_currency and balance is 200$ opw-3269009 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#119421 Forward-Port-Of: odoo/odoo#119259
The reports were not generated using the employee language. task-3284449 Forward-Port-Of: odoo/enterprise#40131
Original PR description
The reports were not generated using the employee language. task-3284449 Forward-Port-Of: odoo/enterprise#40131
Reproduction: 1. Install Project, Helpdesk, go to Project -> Configuration -> Activity Types-> Upload Documents 2. Type a super long text in Default Note, the text overlaps the EN button Reproduction 2: 1. Go to Helpdesk -> configuration -> Helpdesk Teams -> Customer Care 2. Type a super long text in the description of the team, the text overlaps the EN button Fix: we set concrete padding to the right to make sure the translation button is not overlapped. The fix needs to be done in en
Original PR description
Reproduction: 1. Install Project, Helpdesk, go to Project -> Configuration -> Activity Types-> Upload Documents 2. Type a super long text in Default Note, the text overlaps the EN button Reproduction…
Reproduction: 1. Install Project, Helpdesk, go to Project -> Configuration -> Activity Types-> Upload Documents 2. Type a super long text in Default Note, the text overlaps the EN button Reproduction 2: 1. Go to Helpdesk -> configuration -> Helpdesk Teams -> Customer Care 2. Type a super long text in the description of the team, the text overlaps the EN button Fix: we set concrete padding to the right to make sure the translation button is not overlapped. The fix needs to be done in enterprise too Note: The reproduction 2 is another sub-issue found when fixing the first one. Reproduction 1 is for the note field with oe-bordered-editor, and reproduction 2 is for the note field without it. Related fix in Odoo: https://github.com/odoo/odoo/pull/117156 Related Previous Commit: Odoo: https://github.com/odoo-dev/odoo/commit/26ecbc16bc8079c7bb08095f1b27b4f68ca0e947 Enterprise: https://github.com/odoo-dev/enterprise/commit/e2ca9d5a113bc3adbe085057eff778b24abf5ddc task-3047773 Forward-Port-Of: odoo/enterprise#40161 Forward-Port-Of: odoo/enterprise#39038
## Current behaviour Putting a resource on a shift in planning with an employee that has flexible hours, the contribution to the aggregated pill for the day is not the same as the allocated hours on the shift. ## Expected behaviour The allocated hours on the shift with a resource that has flexible hours, should be the same as it's contribution the aggregate pill. ## Steps to reproduce - Install Employee, Planning - Set the flexible_hours on an employee - Add it on an shift from 13h->1
Original PR description
## Current behaviour Putting a resource on a shift in planning with an employee that has flexible hours, the contribution to the aggregated pill for the day is not the same as the allocated hours on…
## Current behaviour Putting a resource on a shift in planning with an employee that has flexible hours, the contribution to the aggregated pill for the day is not the same as the allocated hours on the shift. ## Expected behaviour The allocated hours on the shift with a resource that has flexible hours, should be the same as it's contribution the aggregate pill. ## Steps to reproduce - Install Employee, Planning - Set the flexible_hours on an employee - Add it on an shift from 13h->19h (6hours allocated) - Observe that the aggregate pill is 4 hours, because it takes the resource calendar into account. (13h->17h) ## Reason for the problem There was no handling of users with flexible_hours for the computation of the aggregate pill in the planning for the day. ## Fix Send from the server the `flexible_hours` per resource and calculate the contribution of with the formula `end_time - start_time` capped by the company average hours per day. ## Affected versions - 16.0 - saas-16.1 - master --- opw-3174932 Forward-Port-Of: odoo/enterprise#39659 Forward-Port-Of: odoo/enterprise#37822
To reproduce (V16.2): 1. Install sale_amazon without demo datas (otherwise you will have several companies and the issue won't reproduce) 2. Try to create an amazon account 3. Python Traceback: ``` ... File "odoo/enterprise/sale_amazon/models/amazon_account.py", line 225, in create 'location_id': parent_location_data[0]['view_location_id'][0], IndexError: list index out of range ``` This happen as the `company_id` field is missing from the JS `create` request. The iss
Original PR description
To reproduce (V16.2):
1. Install sale_amazon without demo datas
(otherwise you will have several companies and the issue won't reproduce)
2. Try to create an amazon account
3. Python Traceback:
```
...
File "odoo/enterprise/sale_amazon/models/amazon_account.py", line 225, in create
'location_id': parent_location_data[0]['view_location_id'][0],
IndexError: list index out of range
```
This happen as the `company_id` field is missing from the JS `create` request.
The issue happen as the `company_id` is loaded only when the user is in the group
`base.group_multi_company` (due to JS performance improvements in 16.2).
This is for this reason that the issue won't happen in multi-company.
opw-3268920
Forward-Port-Of: odoo/enterprise#39982Link do not show properly on error message and is thus removed Forward-Port-Of: odoo/enterprise#39357
Original PR description
Link do not show properly on error message and is thus removed Forward-Port-Of: odoo/enterprise#39357
Add balance sheet and profit and loss reports for the Tunisian accounting localization. A french translation is also added. Links to documents used can be found in the task details. task-3093908 Forward-Port-Of: odoo/enterprise#39384
Original PR description
Add balance sheet and profit and loss reports for the Tunisian accounting localization. A french translation is also added. Links to documents used can be found in the task details. task-3093908 Forward-Port-Of: odoo/enterprise#39384
Some demo data bill of material have workorder operation. Trying to use them without the workorder setting activated will give an error on some fields not instantiated. This commit activate/deactivate the operations depending on the workorder setting. opw - 3229621 Forward-Port-Of: odoo/enterprise#40047
Original PR description
Some demo data bill of material have workorder operation. Trying to use them without the workorder setting activated will give an error on some fields not instantiated. This commit activate/deactivate the operations depending on the workorder setting. opw - 3229621 Forward-Port-Of: odoo/enterprise#40047
**Before PR:** If we write a heading in the article and close the tab then the title is not set. **After PR:** The title is set even if we close the tab. Task-3239601 Forward-Port-Of: odoo/enterprise#39728
Original PR description
**Before PR:** If we write a heading in the article and close the tab then the title is not set. **After PR:** The title is set even if we close the tab. Task-3239601 Forward-Port-Of: odoo/enterprise#39728