Tuesday, August 20, 2024
31 changes · saas-17.4
Resolved issues and error corrections
Reloading views with embedded actions, such as project task kanban views, no longer replays the opening animation unnecessarily. This removes a distracting flicker while preserving the expected animation behavior for notifications.
Original PR description
In a view with embedded actions (e.g. kanban view of tasks in a project), toggle it on s.t. it is visible, and then click on the kanban view switcher (basically to reload the kanban view). Before…
In a view with embedded actions (e.g. kanban view of tasks in a project), toggle it on s.t. it is visible, and then click on the kanban view switcher (basically to reload the kanban view). Before this commit, the embedded actions animation was played at each reload, causing a weird flickering. The reason is that when the view is reloaded, the ControlPanel is destroyed and a new one is created, with the embedded actions to be displayed by default (as they had been toggled beforehand). Before this commit, in such a situation, the Transition component (and the useTransition hook) played the animation. This behavior is only useful (and relevant) for a single usecase: Notifications. The NotificationContain uses a t-foreach to iterate over the notifications it has to display, and wrap them inside a Transition component. That means that when a notification pops, it must animate directly (it is always visible). For the remaining usecases in Odoo, we don't want to animate initially, if the element is visible by default. This commit introduces an option "immediate" (in the HOC and the hook), which is false by default. When set to true, if the element is initially visible, the animation is played. task~4035839 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale contact list no longer crashes when it encounters a contact without a name, such as certain address-only records. This helps keep checkout and customer selection reliable when customer data is incomplete.
Original PR description
Before this commit, encountering a contact with a false name (particularly contacts of type address with no name) would lead to a TypeError, `a.name.localeCompare` is not a function. opw-4124243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix removes an extra company name entry that could appear in the accounting quick encoding systray when only one active company remained. Users now see a cleaner, non-redundant menu because the standard company switcher already shows the company information.
Original PR description
Steps to reproduce: - Archive all but 1 company - Settings > Quick encoding to 'Customer invoices' An extra systray item displays the company name, this is redundant with the SwitchCompanyMenu which is always displayed as of this commit dc844df86958d2e31c4e758f600b9c37a8818ca1. opw-4100655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Safari on iOS from mishandling a print-related style rule when preparing sales order emails. It helps users send orders by email reliably from Safari on mobile devices.
Original PR description
To reproduce: ============= on IOS device on Safari Sales -> Orders -> open any order -> send it by email Problem: ======== Safari may have limitations or require specific conditions to properly interpret @page. Solution: ========= Skip the `@page` rule while converting the inline style opw-4101387 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes a background website cleanup task that could incorrectly report negative progress when new visitor records appeared during processing. This prevents avoidable errors and keeps routine visitor data cleanup running reliably.
Original PR description
Since commit 9d78a326, we attempt to send the progress, but because we count before the loop, by the time we make the request again a few milliseconds later, new records have already been added. As a result, the remaining count becomes negative, since done < remaining. ``` ValueError: <class 'ValueError'>: "`done` and `remaining` must be positive integers." while evaluating 'model._cron_unlink_old_visitors() ``` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Salary benefits signing requests now only include the HR responsible person when their signature is actually required. This prevents unnecessary signing tasks and keeps the approval process clearer for employees and HR teams.
Original PR description
In the case where the HR responsible is not required to sign, he should not be added to the request items.
The date dropdown now shows the correct fiscal year period when opening reports that use fiscal year filtering. This avoids confusion for users reviewing accounting reports and helps ensure they are looking at the intended reporting period.
Original PR description
Before this commit when opening a report that take fiscal year as the period_type, the display in the date dropdown was wrong. task: 4096212
Fixed an issue where Social Marketing could crash when opening Instagram post records containing faulty image data. The change helps users continue viewing and managing posts even when some imported or stored media information is incomplete or invalid.
Original PR description
Whenever there is faulty data, it returns only one value, but it requires two. I have made a fix for that. Traceback group: 1415 ```py ('social.menu_social_post', 609, 'Social Marketing > Posts',…
Whenever there is faulty data, it returns only one value, but it requires two. I have made a fix for that.
Traceback group: 1415
```py
('social.menu_social_post', 609, 'Social Marketing > Posts', 860):
Traceback (most recent call last):
File /tmp/tmpccnj1owi/migrations/base/tests/test_mock_crawl.py, line 256, in crawl_menu
self.mock_action(action_vals)
File /tmp/tmpccnj1owi/migrations/base/tests/test_mock_crawl.py, line 429, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File /tmp/tmpccnj1owi/migrations/base/tests/test_mock_crawl.py, line 458, in mock_view_form
[data] = record.read(fields_list)
File /home/odoo/src/odoo/saas-17.4/odoo/models.py, line 3670, in read
return self._read_format(fnames=fields, load=load)
File /home/odoo/src/odoo/saas-17.4/odoo/models.py, line 3902, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File /home/odoo/src/odoo/saas-17.4/odoo/models.py, line 6727, in __getitem__
return self._fields[key].__get__(self)
File /home/odoo/src/odoo/saas-17.4/odoo/fields.py, line 1263, in __get__
self.compute_value(recs)
File /home/odoo/src/odoo/saas-17.4/odoo/fields.py, line 1445, in compute_value
records._compute_field_value(self)
File /home/odoo/src/odoo/saas-17.4/addons/mail/models/mail_thread.py, line 428, in _compute_field_value
return super()._compute_field_value(field)
File /home/odoo/src/odoo/saas-17.4/odoo/models.py, line 5037, in _compute_field_value
fields.determine(field.compute, self)
File /home/odoo/src/odoo/saas-17.4/odoo/fields.py, line 101, in determine
return needle(*args)
File /home/odoo/src/enterprise/saas-17.4/social_instagram/models/social_post_template.py, line 36, in _compute_instagram_preview
faulty_images, error_code = post._get_instagram_image_error()
ValueError: too many values to unpack (expected 2)
```Miscellaneous changes
[FIX] website_blog: prevent "List" layout from overflowing on mobile Steps to reproduce: - Go to the "/blog" page. - In edit mode, set the "Layout" option to "List" and save. - Toggle the mobile preview or reduce the screen size at around 580px or below. => There is a horizontal scrollbar. The scrollbar appears because the row containing the blog posts has a bigger width than its container, which makes it overflow from it. It happens because of the `o_container_small` class set on
Original PR description
[FIX] website_blog: prevent "List" layout from overflowing on mobile Steps to reproduce: - Go to the "/blog" page. - In edit mode, set the "Layout" option to "List" and save. - Toggle the mobile…
[FIX] website_blog: prevent "List" layout from overflowing on mobile Steps to reproduce: - Go to the "/blog" page. - In edit mode, set the "Layout" option to "List" and save. - Toggle the mobile preview or reduce the screen size at around 580px or below. => There is a horizontal scrollbar. The scrollbar appears because the row containing the blog posts has a bigger width than its container, which makes it overflow from it. It happens because of the `o_container_small` class set on the container, which has a rule forcing its horizontal padding to 0, where it was supposed to compensate the row margins. This commit therefore fixes this issue by forcing the row horizontal margins to 0 for screen sizes under the `MD` screen breakpoint, which is approximately where the blogs layout becomes mobile. This fix also has the advantage of improving the "List" mobile layout by making it look similar to the "Grid" layout one, that is, with a bit of space around the posts, instead of being glued to the viewport. opw-4052853 --- [FIX] web_editor: prevent grid item inner row child from overflowing Steps to reproduce: - In edit mode, drop the "Team" snippet. - Toggle it to grid mode. - Set the "Content Width" option to "Full". => A horizontal scrollbar appears. This happens because the `.row` elements generally have a `--gutter-x` CSS variable set to 30px that is used to compute their horizontal margins, such that it compensates the padding of the parent (generally a `.container` element) which is set to the same value. So the parent is supposed to always have a padding of 15px, which is compensated by the row margins, set to -15px. When a row is a direct child of a grid item, the row can overflow its parent if the grid item has a padding below 15px. Indeed, the row expects its parent to have a 15px padding, so its margins are too big if the value is below. A horizontal scrollbar can therefore appear, if the snippet container takes the whole screen width. This commit fixes this issue by making the margins of row elements that are direct children of a grid item compensate the padding of this grid item, while it is below 15px. When it is set to 15px or above, they are back compensating the usual 15px. opw-4052853 opw-3981579 Forward-Port-Of: odoo/odoo#176975 Forward-Port-Of: odoo/odoo#176421
Extra checkout step was unable to be enabled because of a change (commit 533325a2) that was made to sync it with the active state of the extra info view. However, the view that was being checked was actually a view that did not exist. Correctly changed the view name to be extra_info instead of extra_info_option so the setting could be enabled. opw-4113506 Forward-Port-Of: odoo/odoo#176871
Original PR description
Extra checkout step was unable to be enabled because of a change (commit 533325a2) that was made to sync it with the active state of the extra info view. However, the view that was being checked was actually a view that did not exist. Correctly changed the view name to be extra_info instead of extra_info_option so the setting could be enabled. opw-4113506 Forward-Port-Of: odoo/odoo#176871
**Current behaviour before PR:** In table, empty single cell is not selectable through mouse. This happens because isVisible function fails to check if cell is empty or not. **Desired behaviour after PR:** Now it is possible to select empty cell through mouse. Now we are using isEmptyBlock to check if cell is empty or not. task-4067376 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174663
Original PR description
**Current behaviour before PR:** In table, empty single cell is not selectable through mouse. This happens because isVisible function fails to check if cell is empty or not. **Desired behaviour after PR:** Now it is possible to select empty cell through mouse. Now we are using isEmptyBlock to check if cell is empty or not. task-4067376 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174663
Before this commit, accessing start and stop values directly from new event values could lead to a KeyError if these keys were missing. This commit adds a safeguard to prevent such errors by checking for the existence of these keys before attempting to access them, ensuring a more robust handling of event data. Here is traceback: ``` File "/home/odoo/src/odoo/addons/google_calendar/controllers/main.py", line 46, in google_calendar_sync_data need_refresh = request.env.user.sudo()._syn
Original PR description
Before this commit, accessing start and stop values directly from new event values could lead to a KeyError if these keys were missing. This commit adds a safeguard to prevent such errors by checking…
Before this commit, accessing start and stop values directly from new event values could lead to a KeyError if these keys were missing. This commit adds a safeguard to prevent such errors by checking for the existence of these keys before attempting to access them, ensuring a more robust handling of event data.
Here is traceback:
```
File "/home/odoo/src/odoo/addons/google_calendar/controllers/main.py", line 46, in google_calendar_sync_data
need_refresh = request.env.user.sudo()._sync_google_calendar(GoogleCal)
File "/home/odoo/src/odoo/addons/google_calendar/models/res_users.py", line 73, in _sync_google_calendar
synced_recurrences = self.env['calendar.recurrence'].with_context(write_dates=recurrences_write_dates)._sync_google2odoo(recurrences)
File "/home/odoo/src/odoo/addons/google_calendar/models/google_sync.py", line 197, in _sync_google2odoo
odoo_record.with_context(context)._write_from_google(gevent, vals)
File "/home/odoo/src/odoo/addons/google_calendar/models/calendar_recurrence_rule.py", line 122, in _write_from_google
if old_event_values and any(new_event_values[key] != old_event_values[key] for key in base_event_time_fields):
File "/home/odoo/src/odoo/addons/google_calendar/models/calendar_recurrence_rule.py", line 122, in <genexpr>
if old_event_values and any(new_event_values[key] != old_event_values[key] for key in base_event_time_fields):
KeyError: 'start'
```
opw-4100958
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#176634**Issue:** When several invoices are selected and sent via "Send & print" action, it happens that some invoices are sent several times. It seems to be caused by a serialization failure on an invoice in "_compute_debit_credit" when a concurrent write operation is executed on an invoice being sent. This serialization failure cause a retry on the batch being sent, resulting on the invoice to be re-sent. **Cause:** "Send & print" action triggers "_compute_debit_credit" method that writes
Original PR description
**Issue:** When several invoices are selected and sent via "Send & print" action, it happens that some invoices are sent several times. It seems to be caused by a serialization failure on an invoice…
**Issue:** When several invoices are selected and sent via "Send & print" action, it happens that some invoices are sent several times. It seems to be caused by a serialization failure on an invoice in "_compute_debit_credit" when a concurrent write operation is executed on an invoice being sent. This serialization failure cause a retry on the batch being sent, resulting on the invoice to be re-sent. **Cause:** "Send & print" action triggers "_compute_debit_credit" method that writes on debit and credit fields. The values are generally the same, so no write is really performed. However, for some values (e.g. 14.79), there is a floating point issue (i.e. 14.790000000000001) and the "get_records_different_from" method considers the record as different and triggeres an actual write. **Solution:** In "get_records_different_from" method, for monetary fields, apply the same rounding to the current value than the one applied when the value is converted to cache. opw-3773287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176218
We did not catch checkout errors, which lead to server not restarting. Errors are now caught. Forward-Port-Of: odoo/odoo#177087
Original PR description
We did not catch checkout errors, which lead to server not restarting. Errors are now caught. Forward-Port-Of: odoo/odoo#177087
[FIX] website_sale_slides: scale down big num price Before this commit price had h2 class always. With this commit if price is longer than 10 digits we'll use smaller heading. [Reproduce] - Install website_sale_slides - Have a course: - "Enroll Policy": "On Payment" - It's related product's price has more than 10 digits - You not enrolled in it yet - Open course page -> UX BUG: price overflows opw-4075034 Forward-Port-Of: odoo/odoo#176754 Forward-Port-Of: odoo/odoo#175987
Original PR description
[FIX] website_sale_slides: scale down big num price Before this commit price had h2 class always. With this commit if price is longer than 10 digits we'll use smaller heading. [Reproduce] - Install website_sale_slides - Have a course: - "Enroll Policy": "On Payment" - It's related product's price has more than 10 digits - You not enrolled in it yet - Open course page -> UX BUG: price overflows opw-4075034 Forward-Port-Of: odoo/odoo#176754 Forward-Port-Of: odoo/odoo#175987
**Description of the issue/feature this PR addresses:** steps to reproduce error:- 1.create db with 'point_of_sale' module 2.duplicate the record of pos_payement_method with journal type cash 3. install 'pos_restaurant' module this traceback will raise the **OR** start pos session validation error will come ``` Traceback (most recent call last): File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 1764, in _serve_db return service_model.retryin
Original PR description
**Description of the issue/feature this PR addresses:** steps to reproduce error:- 1.create db with 'point_of_sale' module 2.duplicate the record of pos_payement_method with journal type cash 3.…
**Description of the issue/feature this PR addresses:**
steps to reproduce error:-
1.create db with 'point_of_sale' module
2.duplicate the record of pos_payement_method with journal type cash
3. install 'pos_restaurant' module this traceback will raise the **OR** start pos session validation error will come
```
Traceback (most recent call last):
File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 1764, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/odoo/odoo/17.0/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 1791, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 1995, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 741, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/odoo/odoo/17.0/addons/web/controllers/dataset.py", line 28, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/home/odoo/odoo/odoo/17.0/addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/odoo/odoo/17.0/odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/home/odoo/odoo/odoo/17.0/odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "<decorator-gen-77>", line 2, in button_immediate_install
File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_module.py", line 75, in check_and_log
return method(self, *args, **kwargs)
File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_module.py", line 466, in button_immediate_install
return self._button_immediate_function(self.env.registry[self._name].button_install)
File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_module.py", line 590, in _button_immediate_function
registry = modules.registry.Registry.new(self._cr.dbname, update_module=True)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/odoo/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/odoo/odoo/17.0/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 480, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 364, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 227, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 71, in load_data
tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 627, in convert_file
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 693, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 613, in parse
self._tag_root(de)
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 556, in _tag_root
f(rec)
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 567, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/odoo/17.0/addons/pos_restaurant/data/pos_restaurant_data.xml:4
You cannot use the same journal on multiples cash payment methods.
View error context:
'-no context-'
```
- Here is the reason why above mentioned traceback is raised:
-> [here](https://github.com/odoo/odoo/blob/b64a507697381fd7bb205f4a2b2217322d31811a/addons/pos_restaurant/data/pos_restaurant_data.xml#L4) new record of pos.config is creating which trigger the check of pos.config model due to that traceback is raised due to this [validation](https://github.com/odoo/odoo/blob/c72b25969715ab8331acd45d7fea8bfc2d9ab541/addons/point_of_sale/models/pos_config.py#L354)
- **Current behavior before PR:**
if we create ``new`` record of pos.payment.method journal_id field domain not let create another record of journal with type cash if its already present
but if we ``duplicate`` record we can do which is not corrrect as per this [validation](https://github.com/odoo/odoo/blob/c72b25969715ab8331acd45d7fea8bfc2d9ab541/addons/point_of_sale/models/pos_config.py#L354)
- **Desired behavior after PR is merged:**
for resolving this not let duplicate journal_id with type cash. After, this patch user will not able select journal_id with type cash due to [domain](https://github.com/odoo/odoo/blob/b64a507697381fd7bb205f4a2b2217322d31811a/addons/point_of_sale/models/pos_payment_method.py#L29) on journal_id and records never will create. From ui .
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#176300
Forward-Port-Of: odoo/odoo#175530**Current behavior:** In a scenario where dropshipping and subcontracting are being used to fulfill an order, if the dropship is split via backorder then the valuation layers which get created for each subsequent backorder will have a cumulative value instead of reflecting the value for the sequence portion for which they were generated. **Expected behavior:** The SVL records should have a value which accurately reflects the moves involved in the portion of the valuation sequence that they
Original PR description
**Current behavior:** In a scenario where dropshipping and subcontracting are being used to fulfill an order, if the dropship is split via backorder then the valuation layers which get created for…
**Current behavior:** In a scenario where dropshipping and subcontracting are being used to fulfill an order, if the dropship is split via backorder then the valuation layers which get created for each subsequent backorder will have a cumulative value instead of reflecting the value for the sequence portion for which they were generated. **Expected behavior:** The SVL records should have a value which accurately reflects the moves involved in the portion of the valuation sequence that they are being created with respect to. **Steps to reproduce:** 1. Create a component_product such that: - is storable - category has automated valuation and avg cost method - has the `dropship subcontractor on order` route - has some vendor 2. Create a final_product such that: - is storable - category has automated valuation and avg cost method - invoice policy is on quantity delivered - has a subcontract bom that consumes some quantity of component_product - has a subcontractor vendor 3. Create a sale order for >1 of the final_product, set the route on order line to dropship, confirm the SO and the PO which is generated 4. In the dropship transfer, set the quantity to half the demand and validate -> generate the backorder 5. On the SO, create an invoice for the completed quantity and confirm it 6. Complete the rest of the order in the backordered dropship transfer and create and confirm another invoice on the SO 7. Go to the SVL tree view and observe that the latest SVL is ~2x (before the compensatory SVL difference is applied) **Cause of the issue:** When the SVL is created, its value is calculated by taking the difference of subcontract SVL(s) values and dropship SVL(s) values. The subcontract SVLs come from the `move_orig_ids` of the current SVL's move. When the sequence is broken up by backorders, these moves are still used in the calculation for the value of future SVLs. This results in the inaccuracy. **Fix:** Only use SVLs from the move in the current move's `move_orig_ids` which has the maximum `backorder_sequence`. opw-4078510 Forward-Port-Of: odoo/odoo#176958 Forward-Port-Of: odoo/odoo#176163
Description of the issue/feature this PR addresses: This PR simply adds a hook to allow changing the parameters used by _select_seller during order line price computation. Current behavior before PR: Unable to inherit properly to change the selection of the seller, and have the correct price Desired behavior after PR is merged: Can change the parameter of _select_seller before price computation --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-p
Original PR description
Description of the issue/feature this PR addresses: This PR simply adds a hook to allow changing the parameters used by _select_seller during order line price computation. Current behavior before PR: Unable to inherit properly to change the selection of the seller, and have the correct price Desired behavior after PR is merged: Can change the parameter of _select_seller before price computation --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176943 Forward-Port-Of: odoo/odoo#170021
@amoyaux Following the conversation there : https://github.com/odoo/odoo/pull/75806#discussion_r1184797977 Thanks --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#120538
Original PR description
@amoyaux Following the conversation there : https://github.com/odoo/odoo/pull/75806#discussion_r1184797977 Thanks --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#120538
Description of the issue/feature this PR addresses: Passing a context as a dict rather than a key-value pair will drop the current context and only keep the explicitly passed dict. In some modules methods like `name_get` have been overridden to have a conditional behavior based on context. This, however, will never work if `_compute_translated_display_name` drops all the context before it gets to said method. This fix simply makes all the upstream context pass through. Current behavi
Original PR description
Description of the issue/feature this PR addresses: Passing a context as a dict rather than a key-value pair will drop the current context and only keep the explicitly passed dict. In some modules methods like `name_get` have been overridden to have a conditional behavior based on context. This, however, will never work if `_compute_translated_display_name` drops all the context before it gets to said method. This fix simply makes all the upstream context pass through. Current behavior before PR: Calls to methods that have `_compute_translated_display_name` somewhere in the call stack will not see the context that they have been originally given. Desired behavior after PR is merged: All methods will see the context that they have been given at the call --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170682 Forward-Port-Of: odoo/odoo#170050
Steps to reproduce ================== - Edit a kanban view so that the default_group_by is a date field - Go to that view - Open studio => Granularity not set on a date(time) field Cause of the issue ================== `web_read_group` is called with a limit of 1 First a call to `read_group` is made Then in order to return the total number of groups when the limit is reached, a call to _read_group is made. Inside `read_group`, there is a compatibility layer that notably
Original PR description
Steps to reproduce ================== - Edit a kanban view so that the default_group_by is a date field - Go to that view - Open studio => Granularity not set on a date(time) field Cause of the issue ================== `web_read_group` is called with a limit of 1 First a call to `read_group` is made Then in order to return the total number of groups when the limit is reached, a call to _read_group is made. Inside `read_group`, there is a compatibility layer that notably add a default month granularity to date(time) fields. This isn't the case inside `_read_group`, which causes a crash Solution ======== Extract the compatibility layer related to the groupby from `read_group` and use that for both methods opw-4051657 Forward-Port-Of: odoo/odoo#176672 Forward-Port-Of: odoo/odoo#174396
`Other income` and `Other income previous years` are obviously income accounts and not expense accounts. Forward-Port-Of: odoo/odoo#176629 Forward-Port-Of: odoo/odoo#175023
Original PR description
`Other income` and `Other income previous years` are obviously income accounts and not expense accounts. Forward-Port-Of: odoo/odoo#176629 Forward-Port-Of: odoo/odoo#175023
When adding a new field to a website form, the label width is copied from the first label inside the form. This fails if all fields have been deleted. One form where all fields can be deleted is the extra info step in eCommerce. This commit fixes this by using the default "200px" width (which is the default value inside the form templates) when there are no more field labels inside the form. Steps to reproduce: - Install eCommerce. - In Settings/Website, enable the extra info step. - G
Original PR description
When adding a new field to a website form, the label width is copied from the first label inside the form. This fails if all fields have been deleted. One form where all fields can be deleted is the extra info step in eCommerce. This commit fixes this by using the default "200px" width (which is the default value inside the form templates) when there are no more field labels inside the form. Steps to reproduce: - Install eCommerce. - In Settings/Website, enable the extra info step. - Go in shop, add a product to the cart and proceed until you reach the extra info step. - Edit the extra info page. - Remove all form fields. - Add a field to the form. => An error dialog was displayed. opw-4102127 Forward-Port-Of: odoo/odoo#176559
Steps to reproduce: - Switch the user language to arabic - Go to CRM - Insert the CRM lead pivot in spreadsheet => the values are in #ERROR The reason is that `toFormat` returns the date with arabic numbers, which can't be parsed by the spreadsheet engine. Similartly, we have to tell `.fromFormat` to parse the string using latn numbering system. Task: 4102957 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo
Original PR description
Steps to reproduce: - Switch the user language to arabic - Go to CRM - Insert the CRM lead pivot in spreadsheet => the values are in #ERROR The reason is that `toFormat` returns the date with arabic numbers, which can't be parsed by the spreadsheet engine. Similartly, we have to tell `.fromFormat` to parse the string using latn numbering system. Task: 4102957 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176039
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#176620 Forward-Port-Of: odoo/odoo#176012
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#176620 Forward-Port-Of: odoo/odoo#176012
steps: - be connected as someone with no accrual - give accrual allocation to an employee - go to his time offs using the smart button on his employee profile -> no settings to set the date, has_accrual_allocation is false because our user's employee doesn't have accrual allocation expected -> see the date picker on the leave dashboard if the employee has accrual allocations, not the connected user Forward-Port-Of: odoo/odoo#176386 Forward-Port-Of: odoo/odoo#175686
Original PR description
steps: - be connected as someone with no accrual - give accrual allocation to an employee - go to his time offs using the smart button on his employee profile -> no settings to set the date, has_accrual_allocation is false because our user's employee doesn't have accrual allocation expected -> see the date picker on the leave dashboard if the employee has accrual allocations, not the connected user Forward-Port-Of: odoo/odoo#176386 Forward-Port-Of: odoo/odoo#175686
[Test](https://runbot.odoo.com/runbot/build/66575239) was failing as website module is not dependency for test_assetsbundle, but we were trying to call website model. As a solution, test was moved from test_assetsbundle to website. The test was always failing, but we didn't catch it before as we were not testing said module. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176007 Forward-Port-Of: odoo/odoo#175894
Original PR description
[Test](https://runbot.odoo.com/runbot/build/66575239) was failing as website module is not dependency for test_assetsbundle, but we were trying to call website model. As a solution, test was moved from test_assetsbundle to website. The test was always failing, but we didn't catch it before as we were not testing said module. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176007 Forward-Port-Of: odoo/odoo#175894
before this commit: When the user removes the end date and then selects a new date, that date is update the start date. after this commit: When the user removes the end date and then selects a new date, that date should update the end date. Task-3899581 Forward-Port-Of: odoo/odoo#171215
Original PR description
before this commit: When the user removes the end date and then selects a new date, that date is update the start date. after this commit: When the user removes the end date and then selects a new date, that date should update the end date. Task-3899581 Forward-Port-Of: odoo/odoo#171215
Steps to reproduce: - Download french accouning localization module - Switch company to 'FR Company' - Invoicing > Customers > Invoice > New - Fill in a product - Confirm > Gear > Print > Invoice It's the typical column formatting error where columns are squeezed to the left and overlapping (See ticket for picture). opw-4089199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176209
Original PR description
Steps to reproduce: - Download french accouning localization module - Switch company to 'FR Company' - Invoicing > Customers > Invoice > New - Fill in a product - Confirm > Gear > Print > Invoice It's the typical column formatting error where columns are squeezed to the left and overlapping (See ticket for picture). opw-4089199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176209
Issue: In the portal page for managing your mailing lists, to subscribe or unsubscribe, you can see also the ones that are supposely marked for not appearing in this view, when this happen the appear as "Mailing list .#number" which is not ideal, since it will still let us subscribe to it when we shouldn be able to. Stesp to reproduce: 1. Install mass_mailing. 2. Create atleast 2 lists, one with "Show in Preferences" ticked and the other not. 3. Now go to "/mailing/my" to manage the list
Original PR description
Issue: In the portal page for managing your mailing lists, to subscribe or unsubscribe, you can see also the ones that are supposely marked for not appearing in this view, when this happen the appear as "Mailing list .#number" which is not ideal, since it will still let us subscribe to it when we shouldn be able to. Stesp to reproduce: 1. Install mass_mailing. 2. Create atleast 2 lists, one with "Show in Preferences" ticked and the other not. 3. Now go to "/mailing/my" to manage the lists and see how they appear. Solution: It seems logical to filter out for the lists we are not subscribed the non public lists out (the ones that are not marked as "Show In Preferences"), with this we will only see the ones we should have access to see and subscribe/unsubscribe. opw-3877385 Forward-Port-Of: odoo/odoo#162835
- 17.0 <hr> - Currently, the tour is written according to the demo data. The selector .o_form_sheet div[name] input will match if the work template is 'Device Installation and Maintenance' . This template is available in the demo. If the demo loads, the default 'Device Installation and Maintenance' will be set via the post hook. When the demo does not load, we will have the default template instead. That's why we used the .o_form_sheet p.oe-command-temporary-hint class in the OR condit
Original PR description
- 17.0 <hr> - Currently, the tour is written according to the demo data. The selector .o_form_sheet div[name] input will match if the work template is 'Device Installation and Maintenance' . This template is available in the demo. If the demo loads, the default 'Device Installation and Maintenance' will be set via the post hook. When the demo does not load, we will have the default template instead. That's why we used the .o_form_sheet p.oe-command-temporary-hint class in the OR condition. - Remove import `loaded_demo_data` from industry_fsm tests because it was not in use from this [commit](https://github.com/odoo/enterprise/commit/90ca61c62ecb0e5ddcf4d1e1ec9e0a2bf27c27f1). task-4086026 Forward-Port-Of: odoo/enterprise#68487 Forward-Port-Of: odoo/enterprise#67846