Wednesday, January 10, 2024
64 changes · 17.0
Enhancements to existing features
This update adds automated checks for several project interface elements, helping ensure task status, subtask counts, and priority controls continue to work as expected. It reduces the risk of future changes accidentally breaking common project management workflows.
Original PR description
Added JS tests for the following widgets: - status_with_color (project.project, project.update) - name_with_subtask_count (project.task) - priority_switch (project.task) Task-3660956 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The CRM test expectations were adjusted because a new security group check adds one extra database query. This keeps automated performance tests aligned with the current security behavior without changing day-to-day CRM functionality.
Original PR description
Enterprise https://github.com/odoo/enterprise/pull/51731 IAP https://github.com/odoo/iap-apps/pull/733
The follow-up report table now displays a clear "Reference" label for the first column instead of the confusing "Invoice Number" header. This change makes the report more user-friendly by accurately reflecting that this column can contain various types of document references, not just invoices.
Original PR description
Before this commit, in the table of the followup report the first column header had no label which was confusing for the user. This commit will add a name to the column ("Reference").
task: 3630022
Forward-Port-Of: odoo/enterprise#53694
Forward-Port-Of: odoo/enterprise#52768This update improves the reliability of email messaging tests by removing hard-coded data that could change when demo data is updated. The test now works consistently regardless of how the demonstration data changes, reducing false test failures and making the system more stable.
Original PR description
The problem was the hard coded `@Mitchell Admin` in the expected result. The case can be different when the demo data changes. Change the test and make it fixed in all cases. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Fixes an issue where Kanban boards grouped by a read-only field did not correctly apply rules that should disable drag and drop. This prevents users from accidentally moving cards when the board configuration says those changes should not be allowed.
Original PR description
As a reminder, the readonly expression in grouped kanban can enable or disable the drag and drop feature. If the view is not reaonly but the field in the arch on which the view is grouped is readonly, the drag would be disabled. Before this commit, there was a regression introduced in the owl refactoring that made the kanban record not able to evaluate the readonly expression in the fields. This commit fixes the issue by making the kanban record evaluate the provided expression. It does not however correctly evaluate the expression if it contains another field as the drag and drop feature can be enabled at a view level, not at a per record level. It would then resolve to not readonly.
Miscellaneous changes
Steps to reproduce: - Create a PO with a tax - Confirm PO and bill it - Deactivate tax Issue: Tax is shown on bill but not on PO Solution: Make sure that we display tax even if inactive. opw-3631087 Forward-Port-Of: odoo/odoo#147825
Original PR description
Steps to reproduce: - Create a PO with a tax - Confirm PO and bill it - Deactivate tax Issue: Tax is shown on bill but not on PO Solution: Make sure that we display tax even if inactive. opw-3631087 Forward-Port-Of: odoo/odoo#147825
Reinstalling the Restaurant Point of Sale module could fail after Point of Sale was uninstalled because an existing cash payment setup was created again. The fix reuses the existing payment method when present, preventing the reinstall error and reducing disruption for businesses using restaurant POS.
Original PR description
A traceback occur when user tries to reinstall the pos_restaurant after following steps: 1. Install `pos_restaurant` module 2. Uninstall the `point_of_sale` module 3. Again install `pos_restaurant`…
A traceback occur when user tries to reinstall the pos_restaurant after following steps:
1. Install `pos_restaurant` module
2. Uninstall the `point_of_sale` module
3. Again install `pos_restaurant` module
Error:
```
UniqueViolation: duplicate key value violates unique constraint "account_journal_code_company_uniq"
DETAIL: Key (company_id, code)=(1, MRCSH) already exists.
File "odoo/tools/convert.py", line 556, in _tag_root
f(rec)
File "odoo/tools/convert.py", line 280, in _tag_function
_eval_xml(self, rec, env)
File "odoo/tools/convert.py", line 205, in _eval_xml
return odoo.api.call_kw(model, method_name, args, kwargs)
File "odoo/api.py", line 466, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "addons/pos_restaurant/models/pos_config.py", line 138, in _setup_main_restaurant_defaults
self._ensure_cash_payment_method('MRCSH', _('Cash Restaurant'))
File "addons/point_of_sale/models/pos_config.py", line 724, in _ensure_cash_payment_method
cash_journal = self.env['account.journal'].create({
File "<decorator-gen-670>", line 2, in create
File "odoo/api.py", line 414, in _model_create_multi
return create(self, [arg])
File "addons/account_check_printing/models/account_journal.py", line 62, in create
journals = super().create(vals_list)
File "<decorator-gen-154>", line 2, in create
File "odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "addons/account/models/account_journal.py", line 691, in create
journals = super(AccountJournal, self.with_context(mail_create_nolog=True)).create(vals_list)
File "<decorator-gen-127>", line 2, in create
File "odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "addons/mail/models/mail_alias_mixin_optional.py", line 92, in create
records = super().create(valid_vals_list)
File "<decorator-gen-129>", line 2, in create
File "odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "addons/mail/models/mail_thread.py", line 259, in create
threads = super(MailThread, self).create(vals_list)
File "<decorator-gen-12>", line 2, in create
File "odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "odoo/models.py", line 4592, in create
records = self._create(data_list)
File "odoo/models.py", line 4780, in _create
cr.execute(SQL(
File "odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
ParseError: while parsing /home/odoo/src/odoo/17.0/addons/pos_restaurant/data/pos_restaurant_data.xml:15, somewhere inside
<function model="pos.config" name="_setup_main_restaurant_defaults">
<value eval="[ref('pos_config_main_restaurant')]"/>
</function>
File "odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "odoo/modules/loading.py", line 480, in load_modules
processed_modules += load_marked_modules(env, graph,
File "odoo/modules/loading.py", line 364, in load_marked_modules
loaded, processed = load_module_graph(
File "odoo/modules/loading.py", line 227, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "odoo/modules/loading.py", line 71, in load_data
tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
File "odoo/tools/convert.py", line 627, in convert_file
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "odoo/tools/convert.py", line 693, in convert_xml_import
obj.parse(doc.getroot())
File "odoo/tools/convert.py", line 613, in parse
self._tag_root(de)
File "odoo/tools/convert.py", line 556, in _tag_root
f(rec)
File "odoo/tools/convert.py", line 569, in _tag_root
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
```
When users try to reinstall the 'pos_restaurant', a traceback will be generated. Because duplicate 'MRCSH'records exist, they raise the ParseError.
Which leads to the traceback from here
https://github.com/odoo/odoo/blob/8b4f4f2e373896fcaa50f6ee55467274f8e440d5/addons/pos_restaurant/models/pos_config.py#L134-L139
After applying this commit, it will resolve the issue by if the pos payment method
exists, returning the values otherwise create it.
sentry-4736057055This update removes problematic line-break formatting from several translatable messages so translation tools can read them correctly. It helps ensure labels and messages in Point of Sale, Sales integration, Project, and Web can be translated reliably for users in different languages.
Original PR description
The parser of the library we use to extract strings to be translated (python-babel) doesn't handle escaped newlines in the same way as the JavaScript parser. The resulting mismatch makes the content that uses them untranslatable.
for example:
```js
const hey = _t("slt \
çv ?"
);
```
is exported as "slt \nçv ?", while the content of the variable is "slt çv?"
This commit removes faulty occurrences from the code base and re-exports the corresponding POT files.
*: point_of_sale, pos_sale, project, web
Enterprise: https://github.com/odoo/enterprise/pull/52617Project todo list views now show the expected bulk actions when users select multiple todo items. This also restores the export option, making it easier to work with selected todo records in bulk.
Original PR description
thanks to the following PR: https://github.com/odoo/odoo/pull/131369/files todo tasks are not considered grouped by M2M when grouped by personnal stage anymore thus the actions are now available when selecting many list records, but still export is missing so we're adding it to the allowed actions Task-3515879 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The project kanban view now counts only open tasks instead of including completed ones. This gives teams a clearer view of remaining work and avoids overstating project workload.
Original PR description
issue: Currently, the project task count in kanban view calculates all closed and opened task. cause: In this commit 03235ae in task count both closed and open task considered. fix: In project kanban view we only show task count for open task.
The web editor link dialog now supports keyboard actions to confirm or cancel creating a link. This makes editing content faster and more accessible for users who rely on keyboard navigation.
Original PR description
The shortcut for the link dialog was not set, so it was not possible to insert or discard the creation of a link with the keyboard. task-3677041 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the spreadsheet cell menu from crashing when users open it on cells that do not contain formulas. It improves stability for users working with accounting spreadsheets and avoids an interruption during normal spreadsheet navigation.
Original PR description
The adaptation made in commit 037e5b8, related to this [commit](https://github.com/odoo/o-spreadsheet/commit/17ba12211) forgot to account for non-fomula cells. 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
Odoo Discuss now avoids updating a video or voice call connection when the underlying peer-to-peer connection is no longer available. This prevents errors during the brief moment when a call switches from direct peer-to-peer mode to server-based mode, improving call stability for users.
Original PR description
Before this commit, it was possible that an attempt to update peer connections made right at the moment the connection was swapped from peer-to-peer to server mode. Which would cause a traceback. This commit fixes this issue by checking if there is a `RTCPeerConnection` before trying to update it.
This fix makes Odoo's web testing tools correctly return requested details for linked records. It helps developers catch issues earlier and improves confidence that web features behave as expected before release.
Original PR description
Before this commit, the mockServer didn't respect the unity specification for many2one fields. When you do a mockWebRead and you want to read other fields than "id" and "display_name" for a many2one field, the mockServeur ignores this part of the specification. The goal of this commit is to ensure that the mockWebRead respects the full specification for many2one fields. 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
This fix adjusts demo public holiday data so generated holidays do not accidentally overlap with fixed holidays on the same working calendar. It prevents installation or demo setup errors on certain dates, improving reliability for trial and demonstration environments.
Original PR description
In demo/data some places public holidays are fixed, and at some places they are "moving" like - datetime.today() + relativedelta(days=+x)). On 06-01-2024 the following error occurred - Two public…
In demo/data some places public holidays are fixed, and at some places they are "moving" like - datetime.today() + relativedelta(days=+x)). On 06-01-2024 the following error occurred - Two public holidays cannot overlap each other for the same working hours This happened because the Indian public holiday - Makar Sakranti - is set on %Y-01-14 [1] And the company is not set on it straight away. It is set in demo [2] That leave overlapped with -Public Time Off [3] which is set as datetime.today() + relativedelta(days=+8)). The public Time off, when server runs 06-01-2024, makes 14-01-2024. As we can't set two public holidays on the same day, we got an error. Note that this issue can be fixed in two ways: - either move Indian public holidays in demo data and assign company on creation, - or fix date_from of generic public holidays. For now, we choose to fix generic public holidays, as it's demo data and less important. [1] https://github.com/odoo/enterprise/blob/fcc15c438a2bdb22f4dc7bcd33bbe78ce4f83246/l10n_in_hr_payroll/data/resource_calendar_leaves_data.xml#L23-L29 [2] https://github.com/odoo/enterprise/blob/fcc15c438a2bdb22f4dc7bcd33bbe78ce4f83246/l10n_in_hr_payroll/demo/l10n_in_hr_payroll_demo.xml#L13-L15 [3] https://github.com/odoo/odoo/blob/762b087aeeaea6e9bbea98795294503f21856ae2/addons/hr_holidays/data/hr_holidays_demo.xml#L451-L457
Fixed an issue where the trash workspace was incorrectly appearing as an option when users created new spreadsheets. The trash workspace is now properly excluded from the workspace selection, ensuring users can only save spreadsheets to active workspaces.
Original PR description
Before this commit: When a user creates a new spreadsheet in all workspace, the trash workspace was included in the selection. After this commit: The trash workspace is no longer available in the selection when creating a new spreadsheet in all workspace. Task-3584275
This update fixes a visual issue in dark mode where the dropdown menu button in the top navigation bar wasn't properly highlighted when focused. The button's background color was blending in with the navigation bar, making it hard to see. We've adjusted the color to make the focused state clearly visible to users.
Original PR description
This PR solves an issue about the dropdown toggle from the topbar navigation not being highlighted on `:focus` state. This comes from a color issue, the `background-color` of the toggle being the same as the navbar one in dark mode. To solve this issue, we redefine the variable in dark mode, and set it to `$o-gray-300`. task-3607749 Forward-Port-Of: odoo/enterprise#51285
This fix corrects a test in the data merge module that was failing due to inconsistent error messages. The test now properly validates error messages when merging partners with hashed invoice entries by ensuring the correct test conditions are in place before running the validation.
Original PR description
Steps to reproduce: - have an instance with no invoice posted - run the test `test_merge_partner_in_hashed_entries` Issue: The error message generated will not match the one specified in the test. Cause: The message discrepancy is dependent on whether all invoices or only a portion of them are hashed. https://github.com/odoo/odoo/blob/2023b96c725617cb8b403cd89769e5dbc07e1ddc/addons/account/models/company.py#L626 Solution: Post an invoice before restricting the journal runbot-54407 Forward-Port-Of: odoo/enterprise#53899
This update fixes translation issues in the Web Studio app creation feature. Two text strings that users see when creating a new app were not being properly translated into different languages. The fix ensures these user-facing messages are now correctly translatable, improving the experience for non-English users.
Original PR description
2 strings related to creating a new app within studio weren't being correctly translated, so we make them translatable now. Note that the solution before v16 is different (uses getter) because for some reason `<t t-set="variable">Some string</t>` isn't correctly parsed as a string by the props, so an error is thrown while in debug mode. Forward-Port-Of: odoo/enterprise#53930 Forward-Port-Of: odoo/enterprise#53585
This update corrects the configuration paths in jsconfig.json, which helps code editors provide accurate autocompletion suggestions to developers. The paths were not properly configured when the web module is used in enterprise environments, and this fix ensures developers have a better coding experience with proper IDE support.
Original PR description
The jsconfig.json file is used by editors to provide autocompletion but the paths were not updated when it's used in the enterprise path. 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#148618 Forward-Port-Of: odoo/odoo#148605
This fix removes the "Kitchen Note" button that was incorrectly appearing in Shop point-of-sale sessions. The button is only relevant for restaurant operations, not retail shops. The change disables the internal notes feature by default for shop configurations, ensuring a cleaner and more appropriate user interface for non-restaurant businesses.
Original PR description
To reproduce (16.2 and >): 1. Install pos_restaurant 2. Open the Shop pos session -> "Kitchen Note" button display => Unintended as this button does only make sense in restaurant Before this commit: The button actually shows due to `iface_orderline_notes` value being set to `True` by default. After this commit: The setting value is unset (for shops) to prevent the button to render opw-3651750 Forward-Port-Of: odoo/odoo#148473 Forward-Port-Of: odoo/odoo#147774
In v16 the configuration of a pos.config got moved from Point of Sale to Settings, with new settings fields related to pos_config fields. The create method got overriden in point_of_sale to write values on the current pos_config after the creation of the new settings. The side-effect of doing so is that each creation of a res.config.setting, i.e. after changing any given setting (pos-related or not), triggers a write on ~50 fields of the current pos.config. Among those fields there are `modi
Original PR description
In v16 the configuration of a pos.config got moved from Point of Sale to Settings, with new settings fields related to pos_config fields. The create method got overriden in point_of_sale to write…
In v16 the configuration of a pos.config got moved from Point of Sale to Settings, with new settings fields related to pos_config fields. The create method got overriden in point_of_sale to write values on the current pos_config
after the creation of the new settings.
The side-effect of doing so is that each creation of a res.config.setting, i.e. after changing any given setting (pos-related or not), triggers a write on ~50 fields of the current pos.config. Among those fields there are `modifying_relations` fields that trigger recomputes on pos.order. Because pos.order can grow quite big in some databases (> 200.000 pos.orders), it makes it almost impossible to change any setting in these database. They reach a TimeoutError on SaaS/SH.
To fix this, this commit filter `pos_fields_vals` to only write new values on pos.config. If no value got changed since the last settings creation, no write is triggered, and no recompute happens.
Because we are in the context of res.config.settings create, and all the pos.config settings fields are related fields, everything should be in cache and no (or very few) query should be executed when doing this filtering.
This is done for res_config_settings in general in https://github.com/odoo/odoo/blob/3b24a13ee217b2d3846ad0953ccf8885d7b1f15a/odoo/addons/base/models/res_config.py
```python
old_value = field0.convert_to_record(
field0.convert_to_cache(vals[fname0], self), self)
for fname in fnames:
old_value = next(iter(old_value), old_value)[fname]
# determine the new value
new_value = field.convert_to_record(
field.convert_to_cache(vals[field.name], self), self)
# drop if the value is the same
if old_value == new_value:
vals.pop(field.name)
```
opw-3547106
opw-3508239
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#139634In this PR we have fixed the line break issue when we submit a feedback for task and ticket . steps: ---- - Install helpdesk - Go to helpdesk > team - Activated customer rating - Set the rating template in the ticket stage - Create a ticket with the customer and move to the next stage - Open the mail and submit a rating and message - Open ticket and check customer message task-3268763 Forward-Port-Of: odoo/odoo#119184
Original PR description
In this PR we have fixed the line break issue when we submit a feedback for task and ticket . steps: ---- - Install helpdesk - Go to helpdesk > team - Activated customer rating - Set the rating template in the ticket stage - Create a ticket with the customer and move to the next stage - Open the mail and submit a rating and message - Open ticket and check customer message task-3268763 Forward-Port-Of: odoo/odoo#119184
**Description of the issue/feature this PR addresses:** Add a missed condition to only show the label if the value is set **Current behavior before PR:** Ugly meaningless label on report **Desired behavior after PR is merged:** No label if not set as expected... Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147897
Original PR description
**Description of the issue/feature this PR addresses:** Add a missed condition to only show the label if the value is set **Current behavior before PR:** Ugly meaningless label on report **Desired behavior after PR is merged:** No label if not set as expected... Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147897
As Czech legislation is changing its VAT structure on 1.1.2024, a new 12% tax is added. Also some account were wrongly named, misclassified or missing. The 15% tax is kept in lower version for backward compatibility. task-3609608 Forward-Port-Of: odoo/odoo#148405 Forward-Port-Of: odoo/odoo#145366
Original PR description
As Czech legislation is changing its VAT structure on 1.1.2024, a new 12% tax is added. Also some account were wrongly named, misclassified or missing. The 15% tax is kept in lower version for backward compatibility. task-3609608 Forward-Port-Of: odoo/odoo#148405 Forward-Port-Of: odoo/odoo#145366
Steps to reproduce: - Install `CRM` module (for test purposes) - Create a lead and set the name, email, phone, company name and contact name - Save the lead - Click on `Send message` button in the chatter - Uncheck/Check the recipient checkbox - Save the partner - Discard the changes on the lead and open the partner created Issue: - In the wizard, the `phone` value is not set with default value and the name is set with the company name instead of the contact name
Original PR description
Steps to reproduce: - Install `CRM` module (for test purposes) - Create a lead and set the name, email, phone, company name and contact name - Save the lead - Click on `Send message` button in the chatter - Uncheck/Check the recipient checkbox - Save the partner - Discard the changes on the lead and open the partner created Issue: - In the wizard, the `phone` value is not set with default value and the name is set with the company name instead of the contact name - On the partner created, the company and phone are not set Cause: The default values retrieved from "/mail/thread/data" route are not set on the recipient object. opw-3512045 Forward-Port-Of: odoo/odoo#147501
Current behavior: Before this fix, when you sent the order to the kitchen, the preparation changes were not saved directly. So if you refreshed the page right after sending the order to the kitchen, the preparation changes were lost. Steps to reproduce: - Open a POS restaurant session - Add a product to the order - Click on Order - Refresh the page (F5) - Go back to the table were you made the order - The product still appears as not sent to the kitchen opw-3614345 --- I confirm I
Original PR description
Current behavior: Before this fix, when you sent the order to the kitchen, the preparation changes were not saved directly. So if you refreshed the page right after sending the order to the kitchen, the preparation changes were lost. Steps to reproduce: - Open a POS restaurant session - Add a product to the order - Click on Order - Refresh the page (F5) - Go back to the table were you made the order - The product still appears as not sent to the kitchen opw-3614345 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146836
When `test_display_name_for_empty_payment_details` was tested around midnight, the test would fail because it compares the current date with the token's create date, which would be the day before. Forward-Port-Of: odoo/odoo#148698 Forward-Port-Of: odoo/odoo#148624
Original PR description
When `test_display_name_for_empty_payment_details` was tested around midnight, the test would fail because it compares the current date with the token's create date, which would be the day before. Forward-Port-Of: odoo/odoo#148698 Forward-Port-Of: odoo/odoo#148624
A class s_turnstile added to the script tag was missing. Without it, the function cleanTurnstile called by the destroyed cannot clean the script tag. So would result in the script being present several times in the DOM after some manipulation. Forward-Port-Of: odoo/odoo#148720
Original PR description
A class s_turnstile added to the script tag was missing. Without it, the function cleanTurnstile called by the destroyed cannot clean the script tag. So would result in the script being present several times in the DOM after some manipulation. Forward-Port-Of: odoo/odoo#148720
Steps: 1. install project ,website,saleorder 2. open project ,share a saleorder project to admin from the share button 3.then go to website,click on projects 4.open the shared project 5. In that the size of the chatter is small Issue: - The size of the chatter is abnormally small Cause : - The problem occurs because the width of the chatter is less Solution: - By increasing the chatter size the problem can be solved task-3549279 Description of the issue/feature this PR ad
Original PR description
Steps: 1. install project ,website,saleorder 2. open project ,share a saleorder project to admin from the share button 3.then go to website,click on projects 4.open the shared project 5. In that the size of the chatter is small Issue: - The size of the chatter is abnormally small Cause : - The problem occurs because the width of the chatter is less Solution: - By increasing the chatter size the problem can be solved task-3549279 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#138657
Todo: unit test Forward-Port-Of: odoo/odoo#148630
Original PR description
Todo: unit test Forward-Port-Of: odoo/odoo#148630
# Issue: The query for the Tax Report Account>Tax is slow. # Analyze: The query for the Tax Report is huge, and exceeds the join_collapse_limit threshold (https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-JOIN-COLLAPSE-LIMIT) of postgresql (8 by default and on our servers). It is then needed to help the query planner to optimize this query. Running the query with increased join_collapse_limit and checking the explain analyze, helps in this process. # Fix: The q
Original PR description
# Issue: The query for the Tax Report Account>Tax is slow. # Analyze: The query for the Tax Report is huge, and exceeds the join_collapse_limit threshold…
# Issue: The query for the Tax Report Account>Tax is slow. # Analyze: The query for the Tax Report is huge, and exceeds the join_collapse_limit threshold (https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-JOIN-COLLAPSE-LIMIT) of postgresql (8 by default and on our servers). It is then needed to help the query planner to optimize this query. Running the query with increased join_collapse_limit and checking the explain analyze, helps in this process. # Fix: The query planer with increased join_collapse_limit made the res_currency joins at the very end of a truncated query. Moving the res_currency join help as the inner join is made on AM^2 on current position. Moving it after the base_line reduce it back to AM^1. # Benchmark: | # Input data | Before PR | After PR | |:-------------:|:----------:|:---------:| | 271000 AM | 900 s | 13.24 s| | 25000 AM | 180 s | 1.5 s | | 51 AM (demo data) |52ms | 80ms | # Related task: opw-3581671 Co-authored-by: Julien Launois (jula) <jula@odoo.com> Forward-Port-Of: odoo/odoo#148340 Forward-Port-Of: odoo/odoo#145904
targeted versions: 15,16,master When a customer with a sale portal link confirms the order, the registrations in the order won't have the data for the partner of the order which would be the expected default. In 6cfdf64a86ef5c10422910734d7356a86c0c1dd6 (#69810) the intention is to avoid that registrations made on the website by anonymous users are registered with the public user. There's a side effect to this in the portal workflow though. We can reproduce it like this: - We need a p
Original PR description
targeted versions: 15,16,master When a customer with a sale portal link confirms the order, the registrations in the order won't have the data for the partner of the order which would be the expected…
targeted versions: 15,16,master When a customer with a sale portal link confirms the order, the registrations in the order won't have the data for the partner of the order which would be the expected default. In 6cfdf64a86ef5c10422910734d7356a86c0c1dd6 (#69810) the intention is to avoid that registrations made on the website by anonymous users are registered with the public user. There's a side effect to this in the portal workflow though. We can reproduce it like this: - We need a payment aqcquire wich confirms our sale order (we can use payment demo) - In backend, create a sale order with the desired partner and a registration to an event. - Send the quotation to the partner. - With the link portal (and without being logged in) sign and pay the order with the demo payment aquirer. Result: - The order gets confirmed. - The registrations are created with no partner (booked by). So this fix avoids the original issue (having a public user as the registration partner) but saving the case where we are confident about the booked by value. cc @Tecnativa TT44782 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#132959
This commit addresses an issue in the `link_tools` test tour where a failure occurs when applying a button style to a link and saving the content directly. The solution involves adding a step before saving to verify the applied style, providing a workaround until a more in-depth investigation can be conducted. runbot-18747 Forward-Port-Of: odoo/odoo#148559 Forward-Port-Of: odoo/odoo#144121
Original PR description
This commit addresses an issue in the `link_tools` test tour where a failure occurs when applying a button style to a link and saving the content directly. The solution involves adding a step before saving to verify the applied style, providing a workaround until a more in-depth investigation can be conducted. runbot-18747 Forward-Port-Of: odoo/odoo#148559 Forward-Port-Of: odoo/odoo#144121
Steps to reproduce: - Using a company whose currency is USD, make sure to have a rate change with EUR a week before Today. - Create an analytic plan with Default Applicability set to Mandatory. - Create an analytic account for the plan. - Create a Storable Product with a Product Category that has FIFO Costing Method and Automated Inventory Valuation. - Create a Request for Quotation in EUR using the new product and the new analytic account. - Confirm it, click on Receive Products, then Val
Original PR description
Steps to reproduce: - Using a company whose currency is USD, make sure to have a rate change with EUR a week before Today. - Create an analytic plan with Default Applicability set to Mandatory. -…
Steps to reproduce: - Using a company whose currency is USD, make sure to have a rate change with EUR a week before Today. - Create an analytic plan with Default Applicability set to Mandatory. - Create an analytic account for the plan. - Create a Storable Product with a Product Category that has FIFO Costing Method and Automated Inventory Valuation. - Create a Request for Quotation in EUR using the new product and the new analytic account. - Confirm it, click on Receive Products, then Validate. - Go back to the RFQ and click on Create Bill. - Change the date to two weeks ago (in order to trigger an exchange difference). - Confirm it. Current Behavior: A `ValidationError` is raised in `_validate_distribution()`: "One or more lines require a 100% analytic distribution." Cause: This happens because the exchange difference journal items are created without `analytic_distribution` even though they should, since it was set as mandatory. Solution: Make sure the `analytic_distribution` is properly set when creating stock valuation lines. task-3582164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147216 Forward-Port-Of: odoo/odoo#142369
In odoo@98ca5140baf96, a test using a product of type 'product' was added. Since this type is introduced in stock, stock needs be installed. Since the delivery module was split in saas-16.2 to remove the dependency to stock, this test needs to be moved in website_sale_stock. Build error 48757 Forward-Port-Of: odoo/odoo#148645 Forward-Port-Of: odoo/odoo#148547
Original PR description
In odoo@98ca5140baf96, a test using a product of type 'product' was added. Since this type is introduced in stock, stock needs be installed. Since the delivery module was split in saas-16.2 to remove the dependency to stock, this test needs to be moved in website_sale_stock. Build error 48757 Forward-Port-Of: odoo/odoo#148645 Forward-Port-Of: odoo/odoo#148547
Current behavior before PR: The editor's code was unnecessarily adding an access token to attachments created from external URLs. This addition of a query string with an access token to an external URL made no sense and could lead to issues. Desired behavior after PR is merged: This commit prevents such behavior by adding a condition to check if the attachment is created from an external URL. If so, it will not generate and add an access token, ensuring the integrity of the external URL
Original PR description
Current behavior before PR: The editor's code was unnecessarily adding an access token to attachments created from external URLs. This addition of a query string with an access token to an external URL made no sense and could lead to issues. Desired behavior after PR is merged: This commit prevents such behavior by adding a condition to check if the attachment is created from an external URL. If so, it will not generate and add an access token, ensuring the integrity of the external URL. task-3470982 Forward-Port-Of: odoo/odoo#146834 Forward-Port-Of: odoo/odoo#132506
Before this commit, when trying to remove a format of a `data-oe-zws-empty-inline` of an empty block, the attribute was added to that block and would never be removed. How to reproduce the original bug: - put the selection inside an emtpy p - ctrl+b (in windows/linux) or cmd+b (in mac) => The zws attribute data-oe-zws-empty-inline is added on the P rather than creating a span. - The next letter that will be typed will not be bold but should be bold - That attribute should
Original PR description
Before this commit, when trying to remove a format of a `data-oe-zws-empty-inline` of an empty block, the attribute was added to that block and would never be removed. How to reproduce the original bug: - put the selection inside an emtpy p - ctrl+b (in windows/linux) or cmd+b (in mac) => The zws attribute data-oe-zws-empty-inline is added on the P rather than creating a span. - The next letter that will be typed will not be bold but should be bold - That attribute should not exists in a block, that could lead to unexpected bug task-3628480 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148089 Forward-Port-Of: odoo/odoo#146186
No description available.
Before this commit, when a project user shares a recurrent task to an internal user, the internal user cannot open the form view of that task because he does not have access to `project.task.recurrence` model. The reason is because the compute methods to set the recurrence fields assumed the user has access to that model. This commit adds `groups="project.project_group_user"` to recurrent fields to be sure the user has access to `project.task.recurrence` model before computing the field
Original PR description
Before this commit, when a project user shares a recurrent task to an internal user, the internal user cannot open the form view of that task because he does not have access to `project.task.recurrence` model. The reason is because the compute methods to set the recurrence fields assumed the user has access to that model. This commit adds `groups="project.project_group_user"` to recurrent fields to be sure the user has access to `project.task.recurrence` model before computing the field. task-3430762 Forward-Port-Of: odoo/odoo#148374 Forward-Port-Of: odoo/odoo#129500
Description of the issue/feature this PR addresses: Current behavior before PR: Handle history divergence if in module installation mode. Can cause `AccessShareLock` when it will write to the bus. Desired behavior after PR is merged: Do not handle history divergence if in module installation mode. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147432
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Handle history divergence if in module installation mode. Can cause `AccessShareLock` when it will write to the bus. Desired behavior after PR is merged: Do not handle history divergence if in module installation mode. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147432
The range widget doesn't work with Serbian language, because language locale subtag contains `@`. Steps to reproduce: 1. Activate Serbian Latin language (sr@latin) on your website 2. Go to /shop 3. Switch to Serbian lang The price ranger slider (which can be disabled) will throw this TB: "RangeError: Incorrect locale information provided". The fix is to do as other places in the code: replace this specific lang code with the expected one. Ideally, a util method should be used at
Original PR description
The range widget doesn't work with Serbian language, because language locale subtag contains `@`. Steps to reproduce: 1. Activate Serbian Latin language (sr@latin) on your website 2. Go to /shop 3. Switch to Serbian lang The price ranger slider (which can be disabled) will throw this TB: "RangeError: Incorrect locale information provided". The fix is to do as other places in the code: replace this specific lang code with the expected one. Ideally, a util method should be used at all those places. Forward-Port-Of: odoo/odoo#148279
### Steps to reproduce: - Install **Purchase** and **Inventory** apps - Go to **General Settings** > **Purchase** > **Invoicing** > **Bill Control** - Choose **Ordered quantities** and **Save** - Go to **Purchase** app > **Products** > **Products** - Create a **New** product - Set the product type to **Storable product** - Go to **Purchase** tab > **Control Policy** - Notice how the control policy is **On received quantities** although we set it up to be O**n Ordered quantities** ###
Original PR description
### Steps to reproduce: - Install **Purchase** and **Inventory** apps - Go to **General Settings** > **Purchase** > **Invoicing** > **Bill Control** - Choose **Ordered quantities** and **Save** - Go…
### Steps to reproduce: - Install **Purchase** and **Inventory** apps - Go to **General Settings** > **Purchase** > **Invoicing** > **Bill Control** - Choose **Ordered quantities** and **Save** - Go to **Purchase** app > **Products** > **Products** - Create a **New** product - Set the product type to **Storable product** - Go to **Purchase** tab > **Control Policy** - Notice how the control policy is **On received quantities** although we set it up to be O**n Ordered quantities** ### Discussion: - I added a compute method to manage the default **purchase method** value based on the res.config.setting **Bill Control**. - I kept the behavior of setting the `purchase_method` to **receive** when the product type is **service** based on [task-2897867](https://www.odoo.com/web#id=2897867&cids=1&menu_id=4720&action=4043&model=project.task&view_type=form) which is associated with the commit **479a38466751e7bc31b26e5635b9735b37dde81f** and [PR](https://github.com/odoo/odoo/pull/96548) opw-3552786 Forward-Port-Of: odoo/odoo#147780 Forward-Port-Of: odoo/odoo#145440
Versions: --------- - 16.4 - 17.0 - master Steps: ------ 1. Have a project with tasks with deadlines; 2. go to My Tasks; 3. open calendar view; 4. select a task. Issue: ------ The task's project field is empty. Cause: ------ Commit fb88a7448c75fdcbe1d9c3664402a1dea2733326 added the `display_in_project` field for tasks. The `project` widget uses this to decide whether to display the project. As this field hadn't been added to the calendar view yet, it defaulted to `false`, s
Original PR description
Versions: --------- - 16.4 - 17.0 - master Steps: ------ 1. Have a project with tasks with deadlines; 2. go to My Tasks; 3. open calendar view; 4. select a task. Issue: ------ The task's project field is empty. Cause: ------ Commit fb88a7448c75fdcbe1d9c3664402a1dea2733326 added the `display_in_project` field for tasks. The `project` widget uses this to decide whether to display the project. As this field hadn't been added to the calendar view yet, it defaulted to `false`, so projects don't get displayed. Solution: --------- Add `display_in_project` to `view_task_calendar`. opw-3672339 Forward-Port-Of: odoo/odoo#148430
Improve the performances when searching journal entries filtering by account. Steps to reproduce: * Accounting > Accounting > Journal Items * Use a name search by account, inputting the code. Do not select the exact account, but keep the name search. On large databases, this can take more than a minute, while using the id of the account directly would take only tens of milliseconds. This is because when using a domain like [('account_id', 'like', string)] it will be translated in SQL a
Original PR description
Improve the performances when searching journal entries filtering by account. Steps to reproduce: * Accounting > Accounting > Journal Items * Use a name search by account, inputting the code. Do not…
Improve the performances when searching journal entries filtering by account.
Steps to reproduce:
* Accounting > Accounting > Journal Items
* Use a name search by account, inputting the code. Do not select the exact account, but keep the name search.
On large databases, this can take more than a minute, while using the id of the account directly would take only tens of milliseconds. This is because when using a domain like
[('account_id', 'like', string)]
it will be translated in SQL as a subquery unable to use a performant index. Therefore the query planner will use other means and filter on the account afterwards.
The reason it is not able to find a good index despite there being one is because char fields are using `unaccent` by default, but the index is a btree.
Since searching for the account with the code
* only makes sense by prefix
* only uses numbers We can and should actually use the btree index without the unaccent feature.
Forward-Port-Of: odoo/odoo#148561
Forward-Port-Of: odoo/odoo#148463opw-3614919 Forward-Port-Of: odoo/odoo#146490
Original PR description
opw-3614919 Forward-Port-Of: odoo/odoo#146490
task-3611153 Forward-Port-Of: odoo/odoo#146158
Original PR description
task-3611153 Forward-Port-Of: odoo/odoo#146158
Steps to reproduce: - Install `survey` module - Go to survey and open any survey - Click on 'Test' button Issue: Navbar is visible in survey mode (and therefore able to edit the survey with web editor). Cause: At some point, the XML has been refactored and the concerned `nav` element as been replaced by a `div` element, but the related CSS that hide the navbar has not been updated. opw-3369894 Forward-Port-Of: odoo/odoo#148434
Original PR description
Steps to reproduce: - Install `survey` module - Go to survey and open any survey - Click on 'Test' button Issue: Navbar is visible in survey mode (and therefore able to edit the survey with web editor). Cause: At some point, the XML has been refactored and the concerned `nav` element as been replaced by a `div` element, but the related CSS that hide the navbar has not been updated. opw-3369894 Forward-Port-Of: odoo/odoo#148434
Currently there are the following bugs when XML-exporting invoices that are not in company currency and use discounts: * The discount is computed and exported in document currency. But it should be exported in company currency. * The unit price value (excl. discount) is computed wrongly since it uses the wrong discount value. This commit corrects the discount and unit price computation / export. PR that introduced the issue: #143328 Forward-Port-Of: odoo/odoo#147781
Original PR description
Currently there are the following bugs when XML-exporting invoices that are not in company currency and use discounts: * The discount is computed and exported in document currency. But it should be exported in company currency. * The unit price value (excl. discount) is computed wrongly since it uses the wrong discount value. This commit corrects the discount and unit price computation / export. PR that introduced the issue: #143328 Forward-Port-Of: odoo/odoo#147781
Before this commit, when an image was cropped in a record on which multiple users were collaborating, multiple attachments would be created for the same image (one per user). Multiple attachments for the same image would also be created if the user uploaded the same image multiple times. This commit makes sure that an existing attachment for the same field values is reused, instead of creating a new one. task-3524601 Forward-Port-Of: odoo/odoo#144878 Forward-Port-Of: odoo/odoo#137403
Original PR description
Before this commit, when an image was cropped in a record on which multiple users were collaborating, multiple attachments would be created for the same image (one per user). Multiple attachments for the same image would also be created if the user uploaded the same image multiple times. This commit makes sure that an existing attachment for the same field values is reused, instead of creating a new one. task-3524601 Forward-Port-Of: odoo/odoo#144878 Forward-Port-Of: odoo/odoo#137403
The current positioning of the table UIs does not consider if the language is RTL. This PR adds that consideration. task-3664939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147904
Original PR description
The current positioning of the table UIs does not consider if the language is RTL. This PR adds that consideration. task-3664939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147904
ISSUE ===== clicks_ratio uses a formula that is not relevant as it accounts for emails that could not lead to a click. It divides the number of clicks by the total of expected emails instead of substracting the cancelled ones as for other KPIs. HOW TO REPRODUCE ================ 1. Create a mailing M 2. Create a mailing list of 5 contacts with same email address 3. Create a link tracker associated to M 4. Send -> 4 emails will be canceled as same email is used 5. Click the link.
Original PR description
ISSUE ===== clicks_ratio uses a formula that is not relevant as it accounts for emails that could not lead to a click. It divides the number of clicks by the total of expected emails instead of substracting the cancelled ones as for other KPIs. HOW TO REPRODUCE ================ 1. Create a mailing M 2. Create a mailing list of 5 contacts with same email address 3. Create a link tracker associated to M 4. Send -> 4 emails will be canceled as same email is used 5. Click the link. 6. Ratio of 'clicked' on the mailing view will be 20% instead of 100% FIX === Only use mailing traces where trace status is not 'cancel' in the query in _compute clicks_ratio. The formula becomes: CR = # clicks / ( # total - # cancel ) A test is modified in test_mass_mailing to assert this behavior. Task-3607171 Forward-Port-Of: odoo/odoo#144382
Currently in calendar views in mobile it is possible to create events selecting the time of the event by dragging. However, in calendar we also have the action swiper responsible for moving between weeks when swiping close to the borders. The issue is that when trying to create events by dragging close to the border will cause the action swiper to trigger a swipe, therefore switching to the next week. This commit fixes this by adding a swipeInvalid prop to the action swiper that will be checked
Original PR description
Currently in calendar views in mobile it is possible to create events selecting the time of the event by dragging. However, in calendar we also have the action swiper responsible for moving between weeks when swiping close to the borders. The issue is that when trying to create events by dragging close to the border will cause the action swiper to trigger a swipe, therefore switching to the next week. This commit fixes this by adding a swipeInvalid prop to the action swiper that will be checked during the touch move event handler. If the swipeInvalid is executed at any move and returns true, the swipe is cancelled. task-3635841 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#146346
When converting a card for e-mail client compatibility, we apply the attributes of the card's block children to their respective cells and unwrap them. However, that's an issue if the child is an image or a link since their respective `src` and `href` attributes are meaningless on the cells. task-3631900 opw-3580317 opw-3630693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147134
Original PR description
When converting a card for e-mail client compatibility, we apply the attributes of the card's block children to their respective cells and unwrap them. However, that's an issue if the child is an image or a link since their respective `src` and `href` attributes are meaningless on the cells. task-3631900 opw-3580317 opw-3630693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147134
Steps to reproduce ================== - Set the zoom option on an image field (You can do it with studio starting from 16.3) - Go to a record and hover over the image => Nothing happens Cause of the issue ================== The tooltip is only displayed in readonly, but with https://github.com/odoo/odoo/pull/100570 , the readonly mode has been removed. So it only applies for views with the readonly attribute. Solution ======== Always display the tooltip opw-3646005 Fo
Original PR description
Steps to reproduce ================== - Set the zoom option on an image field (You can do it with studio starting from 16.3) - Go to a record and hover over the image => Nothing happens Cause of the issue ================== The tooltip is only displayed in readonly, but with https://github.com/odoo/odoo/pull/100570 , the readonly mode has been removed. So it only applies for views with the readonly attribute. Solution ======== Always display the tooltip opw-3646005 Forward-Port-Of: odoo/odoo#148359 Forward-Port-Of: odoo/odoo#148112
When a model_terms translated field is overridden to a model translated field. Its terms in the po files should be ignored otherwise calling field.translate which is boolean will cause error. opw-3644158 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#147481
Original PR description
When a model_terms translated field is overridden to a model translated field. Its terms in the po files should be ignored otherwise calling field.translate which is boolean will cause error. opw-3644158 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#147481
Steps to reproduce: - Go to "Settings / Users & Companies / Groups" - Create a group (e.g. Group X) - Go to "Settings / Technical / Actions / Server Actions" - Create a server action: * Model: [any] (e.g. Contact) * Action To Do: Execute Python Code * Python Code: [any] * Security: Group X - Create contextual action - Connect with a non-admin user (i.e. Marc Demo) - Open Contacts app => An Access Error is raised: "You are not allowed to create 'Model Data' (ir.model.data)
Original PR description
Steps to reproduce: - Go to "Settings / Users & Companies / Groups" - Create a group (e.g. Group X) - Go to "Settings / Technical / Actions / Server Actions" - Create a server action: * Model: [any]…
Steps to reproduce: - Go to "Settings / Users & Companies / Groups" - Create a group (e.g. Group X) - Go to "Settings / Technical / Actions / Server Actions" - Create a server action: * Model: [any] (e.g. Contact) * Action To Do: Execute Python Code * Python Code: [any] * Security: Group X - Create contextual action - Connect with a non-admin user (i.e. Marc Demo) - Open Contacts app => An Access Error is raised: "You are not allowed to create 'Model Data' (ir.model.data) records. This operation is allowed for the following groups: - Administration/Access Rights Contact your administrator to request access if necessary." Cause: When the group is created, its external identifier is not created directly. When opening Contacts app, the list of authorized actions is evaluated. During the process, "_ensure_xml_id" is called on the groups configured on the actions to create the missing external identifiers. However, the current user (i.e. Marc Demo) has not the rights to create an external identifier. opw-3328506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145777
Versions: --------- - saas-16.3e+ Steps: ------ 1. Create an Sales Order with two lines that will create a task; 2. confirm and go to the new project's settings; 3. in Invoicing tab, link an employee to an SO item; 4. link yourself to the other item; 5. go to timesheets; 6. add a new line; 7. select the project and the task created for the other employee. Issue: ------ The SO item changes to the one linked to the other employee instead of the one linked to you in the project's
Original PR description
Versions: --------- - saas-16.3e+ Steps: ------ 1. Create an Sales Order with two lines that will create a task; 2. confirm and go to the new project's settings; 3. in Invoicing tab, link an employee…
Versions: --------- - saas-16.3e+ Steps: ------ 1. Create an Sales Order with two lines that will create a task; 2. confirm and go to the new project's settings; 3. in Invoicing tab, link an employee to an SO item; 4. link yourself to the other item; 5. go to timesheets; 6. add a new line; 7. select the project and the task created for the other employee. Issue: ------ The SO item changes to the one linked to the other employee instead of the one linked to you in the project's settings. Cause: ------ The new `account.analytic.line` record doesn't have an `employee_id`, which `_compute_so_line` needs to accurately determine the sale line. In saas-16.2, the new record retrieved the `employee_id` from the view, which defaulted to the current user's, but these dissapeared at some point between saas-16.2 and saas-16.3. Solution: --------- Modify the `_timesheet_determine_sale_line` method can be modified to compare `map_entry.employee_id` on `self.employee_id` or `self.env.user.employee_id` instead of only `self.employee_id`. This approach was also used in #133478 to fix a similar bug. opw-3641939 Forward-Port-Of: odoo/odoo#148196
Current behaviour before commit: In website, space before the word is lost when deleting the word. Desired behaviour after commit: Now space is preserved when deleting the word. task-3233352 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#126408
Original PR description
Current behaviour before commit: In website, space before the word is lost when deleting the word. Desired behaviour after commit: Now space is preserved when deleting the word. task-3233352 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#126408
This commit addresses a synchronization issue with Microsoft Calendar, which arose after the implementation of commit d9c4043. The mentioned commit added tracking to the pre-commit process, inadvertently causing problems during calendar synchronization. The issue surfaced when the `_message_track_post_template` function was called in the pre-commit phase. If the appointment function was installed, the `_track_template` was overridden in this module, leading to an attempt to access the removed
Original PR description
This commit addresses a synchronization issue with Microsoft Calendar, which arose after the implementation of commit d9c4043. The mentioned commit added tracking to the pre-commit process, inadvertently causing problems during calendar synchronization. The issue surfaced when the `_message_track_post_template` function was called in the pre-commit phase. If the appointment function was installed, the `_track_template` was overridden in this module, leading to an attempt to access the removed event, which raised an error and prevented calendar synchronization. With this modification, the `_track_template` will not be called for the created event that was cancelled in the same transaction. opw-3635261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146871
[FIX] stock: assign partner on return outgoing stock moves Issue: When printing delivery slip report the warehouse address is shown instead of the delivery address. Steps to Reproduce: 1. Install Purchase App. 2. Install Inventory App. 3. Create Purchase Order. 4. Receive Purchase Order. 5. Return the transfer. 6. print delivery slip Solution: Issue was that upon creating the return stock moves that will be outgoing we copy the attributes from the original incoming stock move w
Original PR description
[FIX] stock: assign partner on return outgoing stock moves Issue: When printing delivery slip report the warehouse address is shown instead of the delivery address. Steps to Reproduce: 1. Install Purchase App. 2. Install Inventory App. 3. Create Purchase Order. 4. Receive Purchase Order. 5. Return the transfer. 6. print delivery slip Solution: Issue was that upon creating the return stock moves that will be outgoing we copy the attributes from the original incoming stock move which does not have a partner assigned, So the solution was to assign the partner on the outgoing stock moves right away from the stock picking. opw-3623451 Forward-Port-Of: odoo/odoo#148367 Forward-Port-Of: odoo/odoo#146273
[IMP] l10n_in_edi*: add buy credits button -Added buy credits button in the view which gives ease to user to directly buy l10n_in_edi IAP credits Related PR(16.0)- https://github.com/odoo/enterprise/pull/40806 Forward-Port-Of: odoo/odoo#148309 Forward-Port-Of: odoo/odoo#120785
Original PR description
[IMP] l10n_in_edi*: add buy credits button -Added buy credits button in the view which gives ease to user to directly buy l10n_in_edi IAP credits Related PR(16.0)- https://github.com/odoo/enterprise/pull/40806 Forward-Port-Of: odoo/odoo#148309 Forward-Port-Of: odoo/odoo#120785
This commit ensures that elements returned by the getTabableElements method of the ui utils does not return invisibe elements. This fixes an issue with the trapFocus method of the ui service which could set an invisible element as lastTabableEl therefore making it impossible to loop back to the firstTabableEl when the actual last tabable element is focused and the client presses tab. Also fix a side effect of these changes in list renderer where focusCell would be called before the cell width c
Original PR description
This commit ensures that elements returned by the getTabableElements method of the ui utils does not return invisibe elements. This fixes an issue with the trapFocus method of the ui service which…
This commit ensures that elements returned by the getTabableElements method of the ui utils does not return invisibe elements. This fixes an issue with the trapFocus method of the ui service which could set an invisible element as lastTabableEl therefore making it impossible to loop back to the firstTabableEl when the actual last tabable element is focused and the client presses tab. Also fix a side effect of these changes in list renderer where focusCell would be called before the cell width computations which would work by chance before since getTabableElements took into account elements with 0 width but is now no longer the case. This is fixed by moving down the onPatched method which calls focusCell underneath the useEffect method which performs column style computations. Steps to reproduce: - Go to any dialog with mail installed - Press tab multiple times - At some point, the address bar should be focused instead of the dialog buttons Explanation: the chatter is present in the DOM but not displayed so the last tabable element that is detected by getTabableElements is a child node of the chatter which cannot be reached. OPW-3584847 Forward-Port-Of: odoo/odoo#148300 Forward-Port-Of: odoo/odoo#147978
Prior to this commit, the test test_customer_notes was failing when run without demo data. It was due to the use of base.res_partner_2 which is a demo partner. The fix consists in creating a new partner for the test. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148070
Original PR description
Prior to this commit, the test test_customer_notes was failing when run without demo data. It was due to the use of base.res_partner_2 which is a demo partner. The fix consists in creating a new partner for the test. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148070