Daily updates from Odoo
Thursday, November 28, 2024
122 changes
15 changes
Resolved issues and error corrections
A test in the Sales Project area was corrected so it checks the intended result instead of passing accidentally. This improves confidence that future changes to project milestone forms are validated properly before release.
Original PR description
Currently, the assert function returns undefined, which is why this test case is passing. However, assert always returns undefined, regardless of whether the value satisfies the condition or not. task-4354290
Miscellaneous changes
Currently, an error occurs when the user attempts to preview an invoice, and invoice date is not available. Step to produce: - Install the ```account``` module. - Create a new invoice, add a customer name and invoice line, and add a 'Payment Terms' which have an 'Early Discount' available. - 'Cancel' this invoice. - Click on the 'Preview' button (ensure that the invoice has no date). ```TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'``` An error occurs whe
Original PR description
Currently, an error occurs when the user attempts to preview an invoice, and invoice date is not available. Step to produce: - Install the ```account``` module. - Create a new invoice, add a customer name and invoice line, and add a 'Payment Terms' which have an 'Early Discount' available. - 'Cancel' this invoice. - Click on the 'Preview' button (ensure that the invoice has no date). ```TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'``` An error occurs when the system attempts to calculate the discount days with the invoice date, but the invoice date is not available there. To resolve this issue, we hide the preview button on canceled invoices. Sentry-6006569495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188134 Forward-Port-Of: odoo/odoo#184817
Description of the issue/feature this PR addresses: This PR adds the signed corporate Contributor License Agreement (CLA) for Xcellent Exchange, allowing contributions from our organization to the Odoo repository in compliance with Odoo's contribution policies. Current behavior before PR: Contributions from Xcellent Exchange are not formally recognized due to the absence of a signed CLA in the Odoo repository. Desired behavior after PR is merged: The signed corporate CLA for Xcellent Ex
Original PR description
Description of the issue/feature this PR addresses: This PR adds the signed corporate Contributor License Agreement (CLA) for Xcellent Exchange, allowing contributions from our organization to the Odoo repository in compliance with Odoo's contribution policies. Current behavior before PR: Contributions from Xcellent Exchange are not formally recognized due to the absence of a signed CLA in the Odoo repository. Desired behavior after PR is merged: The signed corporate CLA for Xcellent Exchange is added to the Odoo repository. Contributions from Xcellent Exchange can be properly acknowledged and merged. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188672
Install mass-mailing and crm. Change the email address of Brandon to a@example.com;b@example.com. In the list view of crm, add the select all leads and change their customer to Brandon (the customer column is not displayed by default, just make it visible). Create a new mass-mailing with the recipient list as "Lead/Opportunity". Start the campaign. Brandon receives as many emails as there are leads but he shall only receive one. The system has a known limitation when it comes to filtering dup
Original PR description
Install mass-mailing and crm. Change the email address of Brandon to a@example.com;b@example.com. In the list view of crm, add the select all leads and change their customer to Brandon (the customer…
Install mass-mailing and crm. Change the email address of Brandon to a@example.com;b@example.com. In the list view of crm, add the select all leads and change their customer to Brandon (the customer column is not displayed by default, just make it visible). Create a new mass-mailing with the recipient list as "Lead/Opportunity". Start the campaign. Brandon receives as many emails as there are leads but he shall only receive one. The system has a known limitation when it comes to filtering duplicates: it skips all records that have multiple recipients. In this case Brandon has two: [a@example.com](mailto:a@example.com) and [b@example.com](mailto:b@example.com). The de-duplication mechanism was skipped for every lead he was the customer of and each time a new email was sent, spamming him. In this work we make it possible to also process records with multiple recipients. It is a best-effort and will still let some duplicates through. Nonetheless it solves the current problem with minimal changes. Note: any([]) and any(['']) are both False while all([]) is True, hence we now check for empty list / empty email first otherwise an empty list would be considered to be opt-out instead of empty. Task-3927361 Forward-Port-Of: odoo/odoo#186799 Forward-Port-Of: odoo/odoo#186149
Raise an error when the user tries to load syscebnl template the same way we block syscohada, as those templates should not be used directly. chart added in https://github.com/odoo/odoo/pull/166211 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187274
Original PR description
Raise an error when the user tries to load syscebnl template the same way we block syscohada, as those templates should not be used directly. chart added in https://github.com/odoo/odoo/pull/166211 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187274
Introduced in #57155 (commit da29586). Steps to reproduce: - Install Odoo on a Windows machine - The install path defaults to Program Files as expected - Uninstall Odoo - Try to install Odoo again - The install path defaults to the empty string, forcing the user to manually set one Expected behaviour: - The install path defaults to the previous install path task-4104451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-O
Original PR description
Introduced in #57155 (commit da29586). Steps to reproduce: - Install Odoo on a Windows machine - The install path defaults to Program Files as expected - Uninstall Odoo - Try to install Odoo again - The install path defaults to the empty string, forcing the user to manually set one Expected behaviour: - The install path defaults to the previous install path task-4104451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188637
If we replace the original definition then the check between the existing definition and the original one will always fail, thus we are always removing and re-adding the same constraint. https://github.com/odoo/odoo/blob/5ba361ddffa757cf60968f37180c7fd1304b3fd4/odoo/models.py#L3209 Replacing `%` by `%%` works for `LIKE` operator because they are equivalent. Since they are sent as-is to the DB the constraint could actually be plainly wrong. ```sql test_17=> SELECT coalesce(d.description, p
Original PR description
If we replace the original definition then the check between the existing definition and the original one will always fail, thus we are always removing and re-adding the same constraint.…
If we replace the original definition then the check between the existing definition and the original one will always fail, thus we are always removing and re-adding the same constraint. https://github.com/odoo/odoo/blob/5ba361ddffa757cf60968f37180c7fd1304b3fd4/odoo/models.py#L3209
Replacing `%` by `%%` works for `LIKE` operator because they are equivalent. Since they are sent as-is to the DB the constraint could actually be plainly wrong.
```sql
test_17=> SELECT coalesce(d.description, pg_get_constraintdef(c.oid))
FROM pg_constraint c
JOIN pg_class t
ON t.oid = c.conrelid
LEFT JOIN pg_description d
ON c.oid = d.objoid
WHERE t.relname = 'ir_model_fields'
AND conname = 'ir_model_fields_name_manual_field'
+------------------------------------------------+
| coalesce |
|------------------------------------------------|
| CHECK (state != 'manual' OR name LIKE 'x\_%%') |
+------------------------------------------------+
```
Example where the definition sent to the DB is wrong:
```py
class A(models.Model):
_inherit = "res.users"
_sql_constraints = [("test_constraint", "CHECK (login !~ '%')", "Cannot have % in login")]
```
```sql
test_17=> \d res_users
...
Check constraints:
"res_users_test_constraint" CHECK (login::text !~ '%%'::text)
...
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#188593In the domain selector (and expression editor), using autocompletion to build conditions for X2many fields will use their domains. Note that it cannot be done for a field many2one since values can be created outside of the field domain in that case. Forward-Port-Of: odoo/odoo#187740
Original PR description
In the domain selector (and expression editor), using autocompletion to build conditions for X2many fields will use their domains. Note that it cannot be done for a field many2one since values can be created outside of the field domain in that case. Forward-Port-Of: odoo/odoo#187740
This commit fixes the blank page when we print documents with PDF.js. It seems that pdf.js lib won't fix it because it's platform specific. We first try to fix this issue by hiding the "Download" and "Print" buttons as you can see in [1] but in this case, it's the only way to be able to dowload or print the document. So we patched the lib with the fix given inside the thread issue [2]. Steps to reproduce: - Open Odoo on the Android mobile App - Go to "Shop Floor" - Click on 'WH/
Original PR description
This commit fixes the blank page when we print documents with PDF.js. It seems that pdf.js lib won't fix it because it's platform specific. We first try to fix this issue by hiding the "Download" and "Print" buttons as you can see in [1] but in this case, it's the only way to be able to dowload or print the document. So we patched the lib with the fix given inside the thread issue [2]. Steps to reproduce: - Open Odoo on the Android mobile App - Go to "Shop Floor" - Click on 'WH/MO/00003' > 'Assembly 1' > 'Worksheet' - Click the print button on pdf.js toolbar => blank screen opw-4190135 [1]: https://github.com/odoo/odoo/commit/8a755d58330218b550efc0fea2f98800151c09a5 [2]: https://github.com/mozilla/pdf.js/issues/10630#issuecomment-855754913 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188650
Currently, an error occurs when splitting a backorder of MO's. Step to produce: - Install the 'mrp' module. - Enable work orders in the settings. - Create a BOM for a product P with an operation: - OP1: Assembly line 1, duration 10 minutes. - Create and confirm an MO for 5 units of P. - Add a Work Center and Operation in the work order line. - Set a producing quantity of 2. - Validate the MO and create a backorder. - Open a backorder of MO, Select a backorder that is in a confirmed
Original PR description
Currently, an error occurs when splitting a backorder of MO's. Step to produce: - Install the 'mrp' module. - Enable work orders in the settings. - Create a BOM for a product P with an operation: -…
Currently, an error occurs when splitting a backorder of MO's.
Step to produce:
- Install the 'mrp' module.
- Enable work orders in the settings.
- Create a BOM for a product P with an operation: - OP1: Assembly line 1, duration 10 minutes.
- Create and confirm an MO for 5 units of P.
- Add a Work Center and Operation in the work order line.
- Set a producing quantity of 2.
- Validate the MO and create a backorder.
- Open a backorder of MO, Select a backorder that is in a confirmed state.
- Click on the 'Action' button to split a backorder into two productions.
See Traceback:
```
TypeError: argument of type 'NoneType' is not iterable
File "odoo/http.py", line 2363, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 40, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/mrp/wizard/mrp_batch_produce.py", line 59, in action_done
return self._production_text_to_object(mark_done=True)
File "addons/mrp/wizard/mrp_batch_produce.py", line 90, in _production_text_to_object
productions = self.production_id._split_productions({self.production_id: productions_amount})
File "home/odoo/src/enterprise/18.0/mrp_workorder/models/mrp_production.py", line 87, in _split_productions
productions = super()._split_productions(amounts=amounts, cancel_remaining_qty=cancel_remaining_qty, set_consumed_qty=set_consumed_qty)
File "addons/mrp/models/mrp_production.py", line 1996, in _split_productions
if workorder.production_id.id not in self.env.context.get('mo_ids_to_backorder', []):
```
An error occurs because the system retrieves a None value for 'mo_ids_to_backorder' from the context at [1], which is not iterable. This causes issues as an iterable value is expected.
Link [1]: https://github.com/odoo/odoo/blob/99e2b13416256a0a23a1a619b92873bcfe15b8a9/addons/mrp/models/mrp_production.py#L1846
To resolve this issue, provide an empty list
for 'mo_ids_to_backorder' if the retrieved value is None instead of an iterable.
Sentry-6080156727
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#188434Forward-Port-Of: odoo/odoo#188632
Original PR description
Forward-Port-Of: odoo/odoo#188632
Backport of PR odoo/odoo#182407 for 17.0. The major difference is the removal of the batching of `orderpoint._qty_in_progress` and the removal of the check on the inter-company location as this was only introduced in 17.4. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183964
Original PR description
Backport of PR odoo/odoo#182407 for 17.0. The major difference is the removal of the batching of `orderpoint._qty_in_progress` and the removal of the check on the inter-company location as this was only introduced in 17.4. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183964
Revert the following fix: https://github.com/odoo/odoo/commit/5e3b471f4a67553d6f7525595b15dc3d7b4efb3f Which is no longer necessary since we have streams: https://github.com/odoo/odoo/commit/da8def8e410de68256ba4ab09ebf7a8b699355ac In particular, media must be returned with code 206 and a range, which is now the case. Forward-Port-Of: odoo/odoo#188887 Forward-Port-Of: odoo/odoo#188872
Original PR description
Revert the following fix: https://github.com/odoo/odoo/commit/5e3b471f4a67553d6f7525595b15dc3d7b4efb3f Which is no longer necessary since we have streams: https://github.com/odoo/odoo/commit/da8def8e410de68256ba4ab09ebf7a8b699355ac In particular, media must be returned with code 206 and a range, which is now the case. Forward-Port-Of: odoo/odoo#188887 Forward-Port-Of: odoo/odoo#188872
### Steps to reproduce: - Create two alias domains - Create a Helpdesk team with alias name 'test' for example and with one of the alias domains created in the first step - Create another helpdesk team with the same alias name but with the other alias domain created in the first step - Notice the 'Invalid operation' pop-up that will be shown ### Current behavior before PR: This is happening because when creating the helpdesk team we should get the alias creation values but when getti
Original PR description
### Steps to reproduce: - Create two alias domains - Create a Helpdesk team with alias name 'test' for example and with one of the alias domains created in the first step - Create another helpdesk team with the same alias name but with the other alias domain created in the first step - Notice the 'Invalid operation' pop-up that will be shown ### Current behavior before PR: This is happening because when creating the helpdesk team we should get the alias creation values but when getting those values we are passing a default value for the alias_domain_id in the context https://github.com/odoo/odoo/blob/17.0/addons/mail/models/mail_alias_mixin_optional.py#L70:L72 which change the alias_domain_id value that will be used for the helpdesk team creation. ### Desired behavior after PR is merged: We are checking if the alias_domain_id is present in the vals_list or not and if it does exist we don't change it. opw-4286060 Forward-Port-Of: odoo/odoo#186474
When the write is called with multiple companies (like the test TestAccountComposerPerformance), the values are updated with the values of the very first company. This will write a new peppol_endpoint on all companies. However, in this test, the very first company is a BE one but another is FR. Then, this write makes an inconsistency between the original FR EAS and the new BE endpoint. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of:
Original PR description
When the write is called with multiple companies (like the test TestAccountComposerPerformance), the values are updated with the values of the very first company. This will write a new peppol_endpoint on all companies. However, in this test, the very first company is a BE one but another is FR. Then, this write makes an inconsistency between the original FR EAS and the new BE endpoint. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188985
2 changes
Enhancements to existing features
The timesheet and planning shift form views now avoid showing the same approval-related actions in both the header and the actions menu. This reduces duplicate options and makes the form screens clearer for users without changing the underlying workflow.
Original PR description
Before this commit, the `Validate` and `Reset to Draft` buttons are displayed in the header of the timesheet form view but also in the `CogMenu` (actions dropdown), which is a bit redundant since the buttons in the header of the form view are sufficient. This commit removes the `Validate` and `Reset to Draft` buttons inside the Cog menu when we are in the form view. task-4279748
Updates several Odoo apps to follow the latest guidelines for scheduled background tasks. This should make recurring maintenance jobs more consistent and reliable without changing day-to-day user workflows.
83 changes
Enhancements to existing features
Odoo now initializes messaging and live chat data through a read-only startup route, reflecting that messaging setup no longer needs to change user settings. This reduces unnecessary write access during web client loading while preserving chat, onboarding, and notification behavior.
Original PR description
* = im_livechat, mail_bot, test_discuss_full Backport of https://github.com/odoo/odoo/pull/179352 OdooBot onboarding needs to be moved to webclient load. Write access is not useful since settings were moved out of the init messaging. See https://github.com/odoo/odoo/pull/150625
The email template previously labeled for portal signup is now named for inviting new internal users, reducing confusion for administrators. The mail template editor also adds a reminder that dynamic email values can be inserted with the `/field` command.
Original PR description
The mail template "Settings: New Portal Signup" has been renamed to "Settings: New User Invite" to reduce confusion. The previous name implied the creation of a new portal user account, which was misleading since the template is intended for creating new internal user accounts. Its new name should now better reflect its purpose. Additionally, this commit adds a small placeholder beneath the mail template editor. This placeholder serves as a helpful reminder for users to insert dynamic values into emails using the `/field` command. task-4273520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change separates unrounded and rounded tax values when preparing Mexican electronic invoicing and point-of-sale documents. It reduces ambiguity in tax calculations, helping make invoice and receipt totals more reliable and easier to maintain.
Original PR description
Before `_add_tax_details_in_base_line` populated tax details like `tax_amount_currency` directly, and `_round_base_lines_tax_details` subsequently moved these values to new keys prefixed with `raw_` while rounding the originals. The problem with that is the meaning of certain dictionary keys like `tax_amount_currency` changed depending on the method that processed them Now, `_add_tax_details_in_base_line` only adds raw values (e.g., `raw_tax_amount_currency`), and `_round_base_lines_tax_details` separately adds the rounded values This simplifies state management and makes sure that raw and rounded values are clearly separated. related pr: https://github.com/odoo/odoo/pull/187780 task: 4277573
This update adjusts automated tests to match a recent change in how messaging is initialized. It helps keep accounting and studio test coverage reliable without changing day-to-day user workflows.
Original PR description
Backport of https://github.com/odoo/enterprise/pull/69565
Resolved issues and error corrections
This fix prevents upgrade failures caused by duplicate tracking records when industry modules include files excluded from code line counts. It ensures only new entries are created and makes those entries easier to distinguish across modules.
Original PR description
When upgrading an industry, the records originating from a file listed in `cloc_exclude` entry of the manifest generate an entry in `ir_model_data` with the module `__cloc_exclude__`. When upgrading the module, it tries to create a second time the same entries, raising the unicity constrain. This commit fixes the issue by creating only new `ir_model_data` entries. It also changes the name to better distinguish different modules, who can share same id. opw-4339886 opw-4274755
Odoo no longer creates extra calendar settings records for portal and public users when they do not need them. This reduces unnecessary data creation while keeping calendar privacy behavior consistent by falling back to public privacy when no settings record exists.
Original PR description
Before this commit, res.users.settings entries were being created for portal and public users in the inverse method of the 'calendar_default_privacy' computed field. From now on, we will not create these entries for these type of users anymore since we don't make use of the fields inside it when the user is not internal. After this commit, we no longer create res.users.settings entries for portal and public users since this creation is skipped using the '_is_internal()' check during the inverse method execution. Additionally, we added the 'public' value fallback for the calendar_default_privacy' field when the 'res_users_settings_id' field is not created. task-4260834
Users without inventory permissions no longer see the serial number shortcut on maintenance equipment records. This prevents confusing access errors and keeps the equipment screen usable for those users.
Original PR description
To reproduce the issue: (Need stock. Enable demo data) 1. In Settings, edit user "Marc Demo": - Inventory: Nothing 2. Log in as Marc Demo 3. Maintenance > Equipment, click on an equipment Error: an…
To reproduce the issue: (Need stock. Enable demo data) 1. In Settings, edit user "Marc Demo": - Inventory: Nothing 2. Log in as Marc Demo 3. Maintenance > Equipment, click on an equipment Error: an Access Error is displayed because a forbidden read operation on `stock.lot` Because of a condition on a smart button of the form view https://github.com/odoo/odoo/blob/f1e217c5cb4934de4cb52d46136d89500d84d904/addons/maintenance/views/maintenance_views.xml#L373-L378 We execute the compute method of `match_serial`, which leads to https://github.com/odoo/odoo/blob/61e586556028aff2f989f5bb90a94afffbd1ac96/addons/maintenance/models/maintenance.py#L166-L170 But the user does not have any access to `stock.lot` (cf step 1). The current diff is not the most elegant one, but: - Adding a `sudo` in the compute method would let the smart button displayed, which would result in a bad UX (when clicking on the button, the user would have another access error) - Adding a `groups` attribute on the button would require a bridge module and would not affect any existing database The above ideas will be applied on master Indirectly related to sentry-5964505411 (cf discussion on PR of https://github.com/odoo-dev/odoo/commit/f1e217c5cb4934de4cb52d46136d89500d84d904)
The payment registration wizard now fills the memo with only the invoice or journal entry reference, instead of combining multiple references in some cases. This prevents confusing payment descriptions and helps keep payment records clearer for reconciliation and communication.
Original PR description
With those commits: https://github.com/odoo/odoo/commit/a6cbb7c2d3538d57dc8498f0dacf4566ea1492e7 https://github.com/odoo/odoo/commit/67e2270d56a81d385db3ca27d29fa3945501fca8 The communication field in the payment register wizard has been changed, when there was only one line we took the line.name. But the line name was in some condition the payment ref and move ref separated with a "-". The communication should only be the move reference or the name of the move. task: 4366478 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The embedded live chat unread message banner now uses the correct text size after a recent chat window redesign made it appear too small. This improves readability for website visitors and keeps chat styling more consistent across Odoo and embedded chat windows.
Original PR description
Since the redesign of chat windows, the "smaller" class is used for the unread message banner. In the embed live chat, rem were converted to em to avoid being impacted by the host font size. However, maintaining consistent styles between odoo and the embed live chat is more complicated because of this. This PR removes this convertion and fixes the text size. before/after 
Batch transfer shipping weight estimates now include the weight of the package itself, not just the products inside. This makes shipping weight calculations more accurate for warehouse teams and can help avoid underestimating delivery weights.
Original PR description
The `estimated_sipping_weight` value of stock picking batch did not take the package itself into account. Only the weight of the product inside. opw: 4311447 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
Fixes how project side panel statistic buttons store and use their context information. This reduces the risk of button actions breaking due to hard-to-read or incorrectly formatted data, improving reliability for project users.
Original PR description
The stringified context is hardly readable and error-prone. After this commit, we keep it like it is given, as a regular JSON object. version-18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update stabilizes an automated website navigation menu test by ensuring pending background actions finish before the browser closes. It helps reduce false test failures and improves confidence in website quality checks, without changing the user-facing website experience.
Original PR description
In this commit, we fix the Uncaught (in promise)Event error in this tour by adding few additionnal steps to ensure every Promise is resumed before to close browser. runbot_error_id~70404 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
Pressing Enter in certain protected report sections no longer causes an error. This makes editing Studio reports more reliable and prevents users from being interrupted by a traceback.
Original PR description
Steps to Reproduce: 1. Navigate to Project. 2. Open Studio and go to Reports -> Timesheets Report. 3. Place the cursor before the text "Expression" and press Enter. 4. Next, place the cursor before the text "Name" and press Enter. 5. A traceback occurs. Description of the issue/feature this PR addresses: When pressing Enter with the cursor inside an unsplittable block, instead of creating a new tag, the `insertLineBreakElement`is called which adds a `<br>` and returns `undefined`. Consequently, in `handleSplitBlockHeading`, `newElement` is `undefined`, leading to a traceback when attempting to access its `tagName`. Desired behavior after PR is merged: The traceback no longer occurs when pressing Enter in an unsplittable block. task-4334925
Double-clicking an image in the HTML editor now opens the image preview instead of the editing toolbar. This makes viewing images faster and aligns the interaction with user expectations.
Original PR description
**Current behavior before PR:** - Double clicking on an image opens the image toolbar. **Desired behavior after PR is merged:** - Now, double clicking on an image opens the image preview instead of toolbar. task:4350231
The loan computation flow now handles cases where the Start Date is removed instead of showing an error. This helps accounting users continue setting up loans smoothly and avoids interruptions during loan entry.
Original PR description
This error occurs when we remove the Start Date while computing a new loan. Steps to reproduce: - Install ``accountant`` module - Create a new loan in ``Loans``(eg: Test) > Click ``Compute`` button - Add any loan amount and remove ``Start Date`` Traceback: ``TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'`` [1]- https://github.com/odoo/enterprise/blob/42b7b322d6c720de45661e3370397adaf74fe1f4/account_loans/wizard/account_loan_compute_wizard.py#L79 sentry-6093500366
This fix ensures the Indian balance sheet report runs the standard report setup logic as intended. It helps prevent missing or incorrect report options after the introduction of a custom handler.
Original PR description
Since https://github.com/odoo/enterprise/commit/e598fcb48b5e4f0126406a4008f175a88528ba85 the balance sheet report has a custom handler. Make indian balance sheet handler execute super method in it's _custom_options_initializer() do execute parent logic.
This fix ensures the Belgian reports setup only creates an accounting journal when one does not already exist. It helps avoid duplicate records during setup or upgrades, reducing cleanup work and improving data consistency.
Original PR description
create account journal only if it doesn't exist related: https://github.com/odoo/upgrade/pull/6714
The work order list now uses compact icon buttons for common actions like start, pause, and done, reducing wasted space and improving readability. Blocking controls are also clearer, with the unblock action moved into a menu and blocked items more visibly highlighted.
Original PR description
This is only a cosmetic change from a text button to an icon button. The main changes of the PR are done in https://github.com/odoo/odoo/pull/184308/. ----------------------- Community pr description: - changed the "start", "pause" and "done" button text to icons to be able to set the button column size at a fixed value - moved the unblock button in the dropdown - made the previous block button toggle between block and unblock - change the dropdown bullet to red when blocked This commit also modifies the width of the json_popover as it was using the base column width which was too big for the icon. It also modifies the width of the mo_list_dropdown column to limit the empty space. This implies changes in the web module: in `column_width_hook.js`, the width of a widget is equal to it's `listViewWidth`, like the fields. However, unlike the fields, the widget class is missing a validation for that props. task-id: 4279789
The Belgian payroll holiday attest now uses the year when an employee's notice period starts, rather than the year it ends. This avoids incorrect attest information when notice periods cross into a new year and also prevents an error when a contract has no end date.
Original PR description
The year considered in the holiday attest should be the same as the start of the notice period, not the end which could be in the following year. Task: 4274127
This update prevents subscription-related errors when a sales subscription line is not linked to an invoice. It helps keep subscription processing stable in edge cases where invoice references are missing.
This update fixes minor display issues in the Documents app when using dark mode. Colors and borders now adapt correctly to the selected theme, improving readability and visual consistency for users.
Original PR description
This PR fixes some minor color scheme issue within Documents. Prior to this PR, some elements where using raw values instead of BS one, which led to some dark mode issues (e.g hardcoding the…
This PR fixes some minor color scheme issue within Documents. Prior to this PR, some elements where using raw values instead of BS one, which led to some dark mode issues (e.g hardcoding the border-color hex will not adapt it if we are in dark mode). Same thing goes for some color mix that were using `$o-white` thus pure black in dark mode, while it should have used `$o-view-background-color` which is already dark mode proof. Since we were tweaking some values here and there, this commit adapts some part of the code by rationalizing the value, either by using BS variables, CSS one to ease the maintainability of the code as well as avoiding `!important` statements. | 18.0 | This PR | |--------|--------| | <img width="310" alt="image" src="https://github.com/user-attachments/assets/16bcf240-84aa-4788-8527-7103a80deb40"> | <img width="308" alt="image" src="https://github.com/user-attachments/assets/476b6fd3-ab4d-4b1e-bf51-1ef50151f333"> | |  |  | task-4357165
A document folder used in an automated deletion test is now given the right internal access so the test administrator can see and edit it. This prevents a test failure caused by recent permission changes and helps keep document deletion behavior reliably validated.
Original PR description
Following odoo/enterprise#73372 where we create a new group, so that the admin users don't see all the documents by default, the admin user used in this tour is not able to see anymore the "Folder1" created in the test as it is owned by odooBot with no additional rights. To solve the problem, we set access_internal="edit" on the "Folder1". Task-4361749
Features or functions removed from Odoo
This change removes leftover unused code from the HTML editor that should have been deleted in an earlier cleanup. It has no expected impact on users, but helps keep the editor codebase simpler and easier to maintain.
Original PR description
`split_unsplittable_handlers` was not removed in [1] by mistake. [1]: https://github.com/odoo/odoo/commit/75f6f0a20cb7a860a703e73e80a4247e716ab620
Miscellaneous changes
Currently, the assert function returns undefined, which is why this test case is passing. However, assert always returns undefined, regardless of whether the value satisfies the condition or not. task-4354290 Forward-Port-Of: odoo/odoo#188923
Original PR description
Currently, the assert function returns undefined, which is why this test case is passing. However, assert always returns undefined, regardless of whether the value satisfies the condition or not. task-4354290 Forward-Port-Of: odoo/odoo#188923
### Steps to reproduce: - Create two alias domains - Create a Helpdesk team with alias name 'test' for example and with one of the alias domains created in the first step - Create another helpdesk team with the same alias name but with the other alias domain created in the first step - Notice the 'Invalid operation' pop-up that will be shown ### Current behavior before PR: This is happening because when creating the helpdesk team we should get the alias creation values but when getti
Original PR description
### Steps to reproduce: - Create two alias domains - Create a Helpdesk team with alias name 'test' for example and with one of the alias domains created in the first step - Create another helpdesk team with the same alias name but with the other alias domain created in the first step - Notice the 'Invalid operation' pop-up that will be shown ### Current behavior before PR: This is happening because when creating the helpdesk team we should get the alias creation values but when getting those values we are passing a default value for the alias_domain_id in the context https://github.com/odoo/odoo/blob/17.0/addons/mail/models/mail_alias_mixin_optional.py#L70:L72 which change the alias_domain_id value that will be used for the helpdesk team creation. ### Desired behavior after PR is merged: We are checking if the alias_domain_id is present in the vals_list or not and if it does exist we don't change it. opw-4286060 Forward-Port-Of: odoo/odoo#186474
### Steps to reproduce: - Install 'l10n_sa' and switch to a Saudi company - Do not have the Arabic language installed - try to generate a Customer Invoice - An error pops up ### Cause: The way the language is retrieved changed in saas-17.2 from `lang='ar_001'` to `lang=o.env['res.lang']._get_code('ar_001')` The forward port of this [commit](https://github.com/odoo/odoo/commit/f1fa69f6a924a68bad4b10e6854f8caae89b43c3) from 16.0 does not adapt to the way the language is retrieved. ### S
Original PR description
### Steps to reproduce:
- Install 'l10n_sa' and switch to a Saudi company
- Do not have the Arabic language installed
- try to generate a Customer Invoice
- An error pops up
### Cause:
The way the language is retrieved changed in saas-17.2 from `lang='ar_001'` to `lang=o.env['res.lang']._get_code('ar_001')` The forward port of this [commit](https://github.com/odoo/odoo/commit/f1fa69f6a924a68bad4b10e6854f8caae89b43c3) from 16.0 does not adapt to the way the language is retrieved.
### Solution:
Use the new way to retrieve the language.
opw-4303367
Forward-Port-Of: odoo/odoo#188662Before this commit: When a public user accessed a forum page, a "Odoo session expired" notification would appear unnecessarily. After this commit: The loadLanguages RPC call is now executed only for authenticated (non-public) users. The "Translate" button in the toolbar is hidden for public users. task-4348290 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188255
Original PR description
Before this commit: When a public user accessed a forum page, a "Odoo session expired" notification would appear unnecessarily. After this commit: The loadLanguages RPC call is now executed only for authenticated (non-public) users. The "Translate" button in the toolbar is hidden for public users. task-4348290 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188255
Since this commit [1], where the "media dialog insert media" was added, the runbot sometimes fails because the tour contacts the "media-api.odoo.com" API, which is not allowed in a tour. This commit fixes the issue by inserting an icon instead of an image, as the icon does not require any API call. [1]: https://github.com/odoo/odoo/commit/2231148db55cfc6fa3f3f5b2b5c5250b74f2feac runbot-107920 Forward-Port-Of: odoo/odoo#188681 Forward-Port-Of: odoo/odoo#188480
Original PR description
Since this commit [1], where the "media dialog insert media" was added, the runbot sometimes fails because the tour contacts the "media-api.odoo.com" API, which is not allowed in a tour. This commit fixes the issue by inserting an icon instead of an image, as the icon does not require any API call. [1]: https://github.com/odoo/odoo/commit/2231148db55cfc6fa3f3f5b2b5c5250b74f2feac runbot-107920 Forward-Port-Of: odoo/odoo#188681 Forward-Port-Of: odoo/odoo#188480
This commit fixes the blank page when we print documents with PDF.js. It seems that pdf.js lib won't fix it because it's platform specific. We first try to fix this issue by hiding the "Download" and "Print" buttons as you can see in [1] but in this case, it's the only way to be able to dowload or print the document. So we patched the lib with the fix given inside the thread issue [2]. Steps to reproduce: - Open Odoo on the Android mobile App - Go to "Shop Floor" - Click on 'WH/
Original PR description
This commit fixes the blank page when we print documents with PDF.js. It seems that pdf.js lib won't fix it because it's platform specific. We first try to fix this issue by hiding the "Download" and "Print" buttons as you can see in [1] but in this case, it's the only way to be able to dowload or print the document. So we patched the lib with the fix given inside the thread issue [2]. Steps to reproduce: - Open Odoo on the Android mobile App - Go to "Shop Floor" - Click on 'WH/MO/00003' > 'Assembly 1' > 'Worksheet' - Click the print button on pdf.js toolbar => blank screen opw-4190135 [1]: https://github.com/odoo/odoo/commit/8a755d58330218b550efc0fea2f98800151c09a5 [2]: https://github.com/mozilla/pdf.js/issues/10630#issuecomment-855754913 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188804 Forward-Port-Of: odoo/odoo#188650
When the session of the kiosk is closed in the backoffice, the kiosk is supposed to show the "We are closed" banner and to no longer accept orders. Currently, this is not the case. In this commit we fix the issue Task: 4219525 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183285 Forward-Port-Of: odoo/odoo#182081
Original PR description
When the session of the kiosk is closed in the backoffice, the kiosk is supposed to show the "We are closed" banner and to no longer accept orders. Currently, this is not the case. In this commit we fix the issue Task: 4219525 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183285 Forward-Port-Of: odoo/odoo#182081
Install mass-mailing and crm. Change the email address of Brandon to a@example.com;b@example.com. In the list view of crm, add the select all leads and change their customer to Brandon (the customer column is not displayed by default, just make it visible). Create a new mass-mailing with the recipient list as "Lead/Opportunity". Start the campaign. Brandon receives as many emails as there are leads but he shall only receive one. The system has a known limitation when it comes to filtering dup
Original PR description
Install mass-mailing and crm. Change the email address of Brandon to a@example.com;b@example.com. In the list view of crm, add the select all leads and change their customer to Brandon (the customer…
Install mass-mailing and crm. Change the email address of Brandon to a@example.com;b@example.com. In the list view of crm, add the select all leads and change their customer to Brandon (the customer column is not displayed by default, just make it visible). Create a new mass-mailing with the recipient list as "Lead/Opportunity". Start the campaign. Brandon receives as many emails as there are leads but he shall only receive one. The system has a known limitation when it comes to filtering duplicates: it skips all records that have multiple recipients. In this case Brandon has two: [a@example.com](mailto:a@example.com) and [b@example.com](mailto:b@example.com). The de-duplication mechanism was skipped for every lead he was the customer of and each time a new email was sent, spamming him. In this work we make it possible to also process records with multiple recipients. It is a best-effort and will still let some duplicates through. Nonetheless it solves the current problem with minimal changes. Note: any([]) and any(['']) are both False while all([]) is True, hence we now check for empty list / empty email first otherwise an empty list would be considered to be opt-out instead of empty. Task-3927361 Forward-Port-Of: odoo/odoo#186799 Forward-Port-Of: odoo/odoo#186149
Forward-Port-Of: odoo/odoo#188632
Original PR description
Forward-Port-Of: odoo/odoo#188632
Currently, an error occurs when splitting a backorder of MO's. Step to produce: - Install the 'mrp' module. - Enable work orders in the settings. - Create a BOM for a product P with an operation: - OP1: Assembly line 1, duration 10 minutes. - Create and confirm an MO for 5 units of P. - Add a Work Center and Operation in the work order line. - Set a producing quantity of 2. - Validate the MO and create a backorder. - Open a backorder of MO, Select a backorder that is in a confirmed
Original PR description
Currently, an error occurs when splitting a backorder of MO's. Step to produce: - Install the 'mrp' module. - Enable work orders in the settings. - Create a BOM for a product P with an operation: -…
Currently, an error occurs when splitting a backorder of MO's.
Step to produce:
- Install the 'mrp' module.
- Enable work orders in the settings.
- Create a BOM for a product P with an operation: - OP1: Assembly line 1, duration 10 minutes.
- Create and confirm an MO for 5 units of P.
- Add a Work Center and Operation in the work order line.
- Set a producing quantity of 2.
- Validate the MO and create a backorder.
- Open a backorder of MO, Select a backorder that is in a confirmed state.
- Click on the 'Action' button to split a backorder into two productions.
See Traceback:
```
TypeError: argument of type 'NoneType' is not iterable
File "odoo/http.py", line 2363, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 40, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/mrp/wizard/mrp_batch_produce.py", line 59, in action_done
return self._production_text_to_object(mark_done=True)
File "addons/mrp/wizard/mrp_batch_produce.py", line 90, in _production_text_to_object
productions = self.production_id._split_productions({self.production_id: productions_amount})
File "home/odoo/src/enterprise/18.0/mrp_workorder/models/mrp_production.py", line 87, in _split_productions
productions = super()._split_productions(amounts=amounts, cancel_remaining_qty=cancel_remaining_qty, set_consumed_qty=set_consumed_qty)
File "addons/mrp/models/mrp_production.py", line 1996, in _split_productions
if workorder.production_id.id not in self.env.context.get('mo_ids_to_backorder', []):
```
An error occurs because the system retrieves a None value for 'mo_ids_to_backorder' from the context at [1], which is not iterable. This causes issues as an iterable value is expected.
Link [1]: https://github.com/odoo/odoo/blob/99e2b13416256a0a23a1a619b92873bcfe15b8a9/addons/mrp/models/mrp_production.py#L1846
To resolve this issue, provide an empty list
for 'mo_ids_to_backorder' if the retrieved value is None instead of an iterable.
Sentry-6080156727
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#188434Steps to reproduce the issue: 1. Navigate to the Events page. 2. Activate the Web Editor. 3. Attempt to edit the Event's short description. Issue: The short description of the event was previously not editable directly from the Events page. the reason behind that is they have used `t-out` instead of `t-field` in template. `t-out` lacks the necessary attributes to enable field updates. Solution: This PR adds the necessary attributes to the short description element, making it editable
Original PR description
Steps to reproduce the issue: 1. Navigate to the Events page. 2. Activate the Web Editor. 3. Attempt to edit the Event's short description. Issue: The short description of the event was previously not editable directly from the Events page. the reason behind that is they have used `t-out` instead of `t-field` in template. `t-out` lacks the necessary attributes to enable field updates. Solution: This PR adds the necessary attributes to the short description element, making it editable from the Events page. Updated the tour functionality to test the latest changes of Event's short description. task-4014153 Forward-Port-Of: odoo/odoo#188526 Forward-Port-Of: odoo/odoo#184263
The chart template loading process involves loading demo data for branches [^1], but at the moment this is not tested and broken. This commit fixes the flow and adds a test. [^1]: https://github.com/odoo/odoo/blob/b79bcb0574354a17a2aa64e2fe8d05da95535257/addons/account/models/chart_template.py#L232 Enterprise PR: https://github.com/odoo/enterprise/pull/74409 task-none Forward-Port-Of: odoo/odoo#188496 Forward-Port-Of: odoo/odoo#188247
Original PR description
The chart template loading process involves loading demo data for branches [^1], but at the moment this is not tested and broken. This commit fixes the flow and adds a test. [^1]: https://github.com/odoo/odoo/blob/b79bcb0574354a17a2aa64e2fe8d05da95535257/addons/account/models/chart_template.py#L232 Enterprise PR: https://github.com/odoo/enterprise/pull/74409 task-none Forward-Port-Of: odoo/odoo#188496 Forward-Port-Of: odoo/odoo#188247
Before this commit, all fields of product tags were loaded into PoS, which was unnecessary. For example, product templates field and product variants field, which contain all products with that tag, were loaded. This caused performance issues when there were a high number of products using tags. This commit fixes the issue by only loading the name field, which is needed in PoS. opw-4343131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Po
Original PR description
Before this commit, all fields of product tags were loaded into PoS, which was unnecessary. For example, product templates field and product variants field, which contain all products with that tag, were loaded. This caused performance issues when there were a high number of products using tags. This commit fixes the issue by only loading the name field, which is needed in PoS. opw-4343131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188849 Forward-Port-Of: odoo/odoo#188405
Steps to Reproduce: - Set up a website for a Peru company. - Go to the shop section. - Purchase any product. - Click submit on address form. Issue: - A traceback appears upon clicking submit. Cause: - The error is due to an attempt to access an element in the form that is not present. Fix: - Updated the view and controller to display the identification type field when use_delivery_as_billing is enabled. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4314252) opw-43
Original PR description
Steps to Reproduce: - Set up a website for a Peru company. - Go to the shop section. - Purchase any product. - Click submit on address form. Issue: - A traceback appears upon clicking submit. Cause: - The error is due to an attempt to access an element in the form that is not present. Fix: - Updated the view and controller to display the identification type field when use_delivery_as_billing is enabled. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4314252) opw-4314252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185644
This commit fixes two issues with the editable grouped list view. In a group, click on a row to switch it into edition and edit an input field (e.g. a char). Do not blur the input. From this state, - clicking on the group header to close the group, or - clicking on "Add a line" to add a new record would both lead to the change being lost. This commit ensures the keep the change in those flows by correctly calling `leaveEditMode` before closing the group or adding the new record. opw~41
Original PR description
This commit fixes two issues with the editable grouped list view. In a group, click on a row to switch it into edition and edit an input field (e.g. a char). Do not blur the input. From this state, - clicking on the group header to close the group, or - clicking on "Add a line" to add a new record would both lead to the change being lost. This commit ensures the keep the change in those flows by correctly calling `leaveEditMode` before closing the group or adding the new record. opw~4174315 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#188717 Forward-Port-Of: odoo/odoo#188611
Introduced in #57155 (commit da29586). Steps to reproduce: - Install Odoo on a Windows machine - The install path defaults to Program Files as expected - Uninstall Odoo - Try to install Odoo again - The install path defaults to the empty string, forcing the user to manually set one Expected behaviour: - The install path defaults to the previous install path task-4104451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-O
Original PR description
Introduced in #57155 (commit da29586). Steps to reproduce: - Install Odoo on a Windows machine - The install path defaults to Program Files as expected - Uninstall Odoo - Try to install Odoo again - The install path defaults to the empty string, forcing the user to manually set one Expected behaviour: - The install path defaults to the previous install path task-4104451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188637
Issue ===== When a GS1 barcode is scanned, if it starts with a FNC1, it can't be parsed. How to reproduce ================ - In Inventory Settings, select "Default GS1 Nomenclature" as the used nomenclature; - Create a product with a valid EAN13 as barcode (eg. 1234567891231); - Open the Barcode app, then the Inventory Adjustments; - Scan a GS1 barcode for the created product who start with the FNC1 (eg. "\x1D0101234567891231") -> The product's barcode is not decoded. Solution
Original PR description
Issue ===== When a GS1 barcode is scanned, if it starts with a FNC1, it can't be parsed. How to reproduce ================ - In Inventory Settings, select "Default GS1 Nomenclature" as the used nomenclature; - Create a product with a valid EAN13 as barcode (eg. 1234567891231); - Open the Barcode app, then the Inventory Adjustments; - Scan a GS1 barcode for the created product who start with the FNC1 (eg. "\x1D0101234567891231") -> The product's barcode is not decoded. Solution ======== To fix this issue, before to be parsed, the given barcode will be cleaned and if it starts with a FNC1, it will be removed from the string. opw-4118637 Forward-Port-Of: odoo/odoo#188162 Forward-Port-Of: odoo/odoo#187875
Raise an error when the user tries to load syscebnl template the same way we block syscohada, as those templates should not be used directly. chart added in https://github.com/odoo/odoo/pull/166211 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187274
Original PR description
Raise an error when the user tries to load syscebnl template the same way we block syscohada, as those templates should not be used directly. chart added in https://github.com/odoo/odoo/pull/166211 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187274
Description of the issue/feature this PR addresses: This PR adds the signed corporate Contributor License Agreement (CLA) for Xcellent Exchange, allowing contributions from our organization to the Odoo repository in compliance with Odoo's contribution policies. Current behavior before PR: Contributions from Xcellent Exchange are not formally recognized due to the absence of a signed CLA in the Odoo repository. Desired behavior after PR is merged: The signed corporate CLA for Xcellent Ex
Original PR description
Description of the issue/feature this PR addresses: This PR adds the signed corporate Contributor License Agreement (CLA) for Xcellent Exchange, allowing contributions from our organization to the Odoo repository in compliance with Odoo's contribution policies. Current behavior before PR: Contributions from Xcellent Exchange are not formally recognized due to the absence of a signed CLA in the Odoo repository. Desired behavior after PR is merged: The signed corporate CLA for Xcellent Exchange is added to the Odoo repository. Contributions from Xcellent Exchange can be properly acknowledged and merged. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188672
Steps to reproduce : --------------------------- - Install the point_of_sale and sales module. - Set downpayment on the shop and open session. - Press quotation/orders action button. - Open any quotation try apply percentage downpayment. - Try to press backspace twice. Issue : --------- The number buffer would be "" at starting but when we again press backspace it will become null as mentioned from number buffer services which was directly passed to parseFloat function. Cause : --
Original PR description
Steps to reproduce : --------------------------- - Install the point_of_sale and sales module. - Set downpayment on the shop and open session. - Press quotation/orders action button. - Open any quotation try apply percentage downpayment. - Try to press backspace twice. Issue : --------- The number buffer would be "" at starting but when we again press backspace it will become null as mentioned from number buffer services which was directly passed to parseFloat function. Cause : ---------- The parse float function applies startsWith function which won't be there if value is null. Fix : ------ Instead of passing buffer directly now just send buffer to parse if it exist else send "" instead of null. Forward-Port-Of: odoo/odoo#182555
Before this commit: - In the product configurator popup, it was possible to deselect a product attribute and add a product without a variant to the cart, which violated the standard behavior of radio buttons. Following this commit : - Product attributes in the product configurator popup can no longer be deselected aligning with the expected functionality of radio buttons. task- 4285309 Forward-Port-Of: odoo/odoo#185655
Original PR description
Before this commit: - In the product configurator popup, it was possible to deselect a product attribute and add a product without a variant to the cart, which violated the standard behavior of radio buttons. Following this commit : - Product attributes in the product configurator popup can no longer be deselected aligning with the expected functionality of radio buttons. task- 4285309 Forward-Port-Of: odoo/odoo#185655
Before this commit: ========== - The currency symbol was not visible on the product card on the self-order product page. After this commit: ========== - The currency symbol is now visible on the product card on the self-order product page. task-4342039 Forward-Port-Of: odoo/odoo#187585
Original PR description
Before this commit: ========== - The currency symbol was not visible on the product card on the self-order product page. After this commit: ========== - The currency symbol is now visible on the product card on the self-order product page. task-4342039 Forward-Port-Of: odoo/odoo#187585
This commit fixes a bug introduced in the PR ( https://github.com/odoo/odoo/pull/186434 ). This PR aims to batch operations on svls by grouping based on products. However, it didn't take into account the possibility where svls could belong to different companies. This would lead to a singleton error upon referencing the field "anglo_saxon_accounting". To fix the problem, grouping svls must be done based on a composite key based on product and value of "anglo_saxon_accounting". --- I con
Original PR description
This commit fixes a bug introduced in the PR ( https://github.com/odoo/odoo/pull/186434 ). This PR aims to batch operations on svls by grouping based on products. However, it didn't take into account the possibility where svls could belong to different companies. This would lead to a singleton error upon referencing the field "anglo_saxon_accounting". To fix the problem, grouping svls must be done based on a composite key based on product and value of "anglo_saxon_accounting". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188680
Before this commit, in the ticket screen, when you filtered paid orders, you could press the delete button, which was useless and confusing. opw-4339996 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188286
Original PR description
Before this commit, in the ticket screen, when you filtered paid orders, you could press the delete button, which was useless and confusing. opw-4339996 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188286
When adding a custom filter, we can produce a domain of the form ["id", "in", [ 1415T215, 1545481, ... ]] with a very long list of ids. In this commit we make the domain description contain only the 20 first ids of the list. If we don't do that we obtain a (unscrollable) search bar facet that is not fully visible when confirming the domain. Forward-Port-Of: odoo/odoo#188649 Forward-Port-Of: odoo/odoo#188438
Original PR description
When adding a custom filter, we can produce a domain of the form
["id", "in", [
1415T215,
1545481,
...
]]
with a very long list of ids. In this commit we make the domain description contain only the 20 first ids of the list. If we don't do that we obtain a (unscrollable) search bar facet that is not fully visible when confirming the domain.
Forward-Port-Of: odoo/odoo#188649
Forward-Port-Of: odoo/odoo#188438**Problem**: This commit: https://github.com/odoo/odoo/commit/655e1ea63cf469937c53762e93f93da40b6b9099 breaks the behavior of the `list_renderer` when an autocomplete is present in the same view. Specifically, it prevents discarding a row when clicking outside the input. **Solution**: Revert the commit, as the issue it aimed to fix (opw-3180055) is now resolved by the addition of the "Search more" functionality, rendering the commit unnecessary. **Steps to reproduce**: 1. Open the *Pu
Original PR description
**Problem**: This commit: https://github.com/odoo/odoo/commit/655e1ea63cf469937c53762e93f93da40b6b9099 breaks the behavior of the `list_renderer` when an autocomplete is present in the same view. Specifically, it prevents discarding a row when clicking outside the input. **Solution**: Revert the commit, as the issue it aimed to fix (opw-3180055) is now resolved by the addition of the "Search more" functionality, rendering the commit unnecessary. **Steps to reproduce**: 1. Open the *Purchase* tab on a product form. 2. Add a vendor line (with or without selecting a vendor). 3. Focus on the vendor line, then click to add *Vendor Taxes*. 4. After selecting a tax, observe that the focus incorrectly shifts back to the vendor line instead of remaining on the *Vendor Taxes* input. opw-4263276 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188767 Forward-Port-Of: odoo/odoo#187872
Steps to reproduce: - create two workcenters, one having a shift with a lunch pause (WC A) (i.e. the default 40hours week will do the job), the other having no lunch pause (WC B). - create a MO with a work order of a sufficient duration to be splitted in two part (before and after lunch) (6h for instance) and add it on the WC A. - plan the MO - go to the planning by workcenter view - move the WO from WC A to WC B (in the same day) - move it back to WC A (in the same day) - move the WO a
Original PR description
Steps to reproduce: - create two workcenters, one having a shift with a lunch pause (WC A) (i.e. the default 40hours week will do the job), the other having no lunch pause (WC B). - create a MO with…
Steps to reproduce: - create two workcenters, one having a shift with a lunch pause (WC A) (i.e. the default 40hours week will do the job), the other having no lunch pause (WC B). - create a MO with a work order of a sufficient duration to be splitted in two part (before and after lunch) (6h for instance) and add it on the WC A. - plan the MO - go to the planning by workcenter view - move the WO from WC A to WC B (in the same day) - move it back to WC A (in the same day) - move the WO a day later (on the same WC) Problem: The duration displayed changes from 6h (correct one) to 7h on the first step, which is incorrect. Moving the MO back to it's original WC will change the time to 5h which is also incorrect, but moving it a day later fixes the issue (6h) The problem is that computing the date_finished in the write method is incorrect when `workcenter_id` is in vals, as calling `_calculate_date_finished` will return the value computed with the non-modified yet workcenter opw-4321104 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188130 Forward-Port-Of: odoo/odoo#187864
Before this commit, the internal reference was not displayed. With this commit, the internal reference will be shown in the product info popup and for products with variants in the product configurator. opw-4334505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187879
Original PR description
Before this commit, the internal reference was not displayed. With this commit, the internal reference will be shown in the product info popup and for products with variants in the product configurator. opw-4334505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187879
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#188190
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#188190
Steps to reproduce: - go to Employees>Configuration>Skill Types - create new skill or edit an existing one - change name or progress percentage of levels or add a new level - toggle default level - The fields revert to their original state, and only the toggle switch cause: it does not save other fields and just saves the default button when clicked solution: add this.props.record.model.root.save(); so it saves the record and not just the toggle button only. task-4223036 Forwa
Original PR description
Steps to reproduce: - go to Employees>Configuration>Skill Types - create new skill or edit an existing one - change name or progress percentage of levels or add a new level - toggle default level - The fields revert to their original state, and only the toggle switch cause: it does not save other fields and just saves the default button when clicked solution: add this.props.record.model.root.save(); so it saves the record and not just the toggle button only. task-4223036 Forward-Port-Of: odoo/odoo#188299 Forward-Port-Of: odoo/odoo#183369
In the employees module, the civil status field in the private information section has terms that are always in English. These terms were not exported to be translated. This commit makes them translatable and exports them to the translators. Opw-4292046 Opw-4278798 Enterprise: https://github.com/odoo/enterprise/pull/73406 Forward-Port-Of: odoo/odoo#188595 Forward-Port-Of: odoo/odoo#186473
Original PR description
In the employees module, the civil status field in the private information section has terms that are always in English. These terms were not exported to be translated. This commit makes them translatable and exports them to the translators. Opw-4292046 Opw-4278798 Enterprise: https://github.com/odoo/enterprise/pull/73406 Forward-Port-Of: odoo/odoo#188595 Forward-Port-Of: odoo/odoo#186473
Before this commit, the PoS interface would continue to show loading indefinitely without displaying any message if an error occurred during data retrieval from the server. This commit resolves the issue by introducing an alert mechanism to inform the user of any errors encountered during the loading process. opw-4176629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183398
Original PR description
Before this commit, the PoS interface would continue to show loading indefinitely without displaying any message if an error occurred during data retrieval from the server. This commit resolves the issue by introducing an alert mechanism to inform the user of any errors encountered during the loading process. opw-4176629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183398
Before this commit, loading a product with a barcode into the PoS did not respect the user language. This was due to overriding the context when reading the product from the server. opw-4346227 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188607
Original PR description
Before this commit, loading a product with a barcode into the PoS did not respect the user language. This was due to overriding the context when reading the product from the server. opw-4346227 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188607
Issue: ====== `enter` command doesnt work properly for `pre` element inside list element. Steps to reproduce the issue: ============================= - Add a list - Add a code block with `/code` - Add sone text - Put the cursor at the end of the text - click `enter` - It adds a `br` element and puts the selection at the start. Origin of the issue: ==================== The `oEnter` function of the `pre` element is triggered which adds a `p` element just after the `pre` element in
Original PR description
Issue: ====== `enter` command doesnt work properly for `pre` element inside list element. Steps to reproduce the issue: ============================= - Add a list - Add a code block with `/code` - Add sone text - Put the cursor at the end of the text - click `enter` - It adds a `br` element and puts the selection at the start. Origin of the issue: ==================== The `oEnter` function of the `pre` element is triggered which adds a `p` element just after the `pre` element inside the same `li` element. Now in sanitiwe we unwrap the p elements inside `li` which leaves us with only a `br` after the `pre`. Since we put the selection at the start of the newly added then removed `p` element, the final selection will not behave correctly. Solution: ========= We single out the case when the parent element of the `pre` is a `li` and treat it as a break inside a `li`. task-4187676 Forward-Port-Of: odoo/odoo#188056 Forward-Port-Of: odoo/odoo#180268
This PR resolves an issue with the `scroll to the first unread message` test, which occasionally failed due to race conditions. Several issues were identified with this test: - We do not wait for the initial scroll to complete, which can lead to race conditions. - Under high CPU load, the message highlight can be shorter than the scroll. We should wait for the scroll to complete before allowing adjustments to be made. runbot-103421 Description of the issue/feature this PR addresses:
Original PR description
This PR resolves an issue with the `scroll to the first unread message` test, which occasionally failed due to race conditions. Several issues were identified with this test: - We do not wait for the initial scroll to complete, which can lead to race conditions. - Under high CPU load, the message highlight can be shorter than the scroll. We should wait for the scroll to complete before allowing adjustments to be made. runbot-103421 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#188399
We fix a problem occuring in pivot and graph views. Have a property like properties.441515 used somewhere as groupby. If that property has not been added via the search bar menu, the corresponding (fake) field definition is not known (fillSearchViewItemsProperty has not been called). Thus in that case, a crash occurs because one tries to read info in the undefined field definition for instance. This can happen in several ways: - save a favorite with a property used somewhere (context.group
Original PR description
We fix a problem occuring in pivot and graph views. Have a property like properties.441515 used somewhere as groupby. If that property has not been added via the search bar menu, the corresponding (fake) field definition is not known (fillSearchViewItemsProperty has not been called). Thus in that case, a crash occurs because one tries to read info in the undefined field definition for instance. This can happen in several ways: - save a favorite with a property used somewhere (context.group_by or context.pivot_row_groupby for example), reload, apply the favorite -> crash. - add the pivot or graph view to dashboard or to spreadsheet, (re)Load the dashboard or the spreadsheet -> crash. We fix the problem by adding on the fly a fake field definition when the groupbys used by the views are known (i.e. when the view models are about to fetch the data). Task ID: 4141824 Forward-Port-Of: odoo/odoo#188594 Forward-Port-Of: odoo/odoo#187287
For an expense report paid by an employee, the bank account should be set on the employee form and be used to create the Journal Entry and in Register Payment Wizard. enterprise: https://github.com/odoo/enterprise/pull/71080 task-4206895 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188542 Forward-Port-Of: odoo/odoo#181870
Original PR description
For an expense report paid by an employee, the bank account should be set on the employee form and be used to create the Journal Entry and in Register Payment Wizard. enterprise: https://github.com/odoo/enterprise/pull/71080 task-4206895 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188542 Forward-Port-Of: odoo/odoo#181870
Before this commit, if an invalid record existed in db, and it was open from a list, a notification was raised even if the user didn't modify the record. Also, if an invalid record is open, and the user click to create a new record, a notification is raised. Now, the notifications only raise if the user modifies the record. opw-3987849 Forward-Port-Of: odoo/odoo#188550 Forward-Port-Of: odoo/odoo#187106
Original PR description
Before this commit, if an invalid record existed in db, and it was open from a list, a notification was raised even if the user didn't modify the record. Also, if an invalid record is open, and the user click to create a new record, a notification is raised. Now, the notifications only raise if the user modifies the record. opw-3987849 Forward-Port-Of: odoo/odoo#188550 Forward-Port-Of: odoo/odoo#187106
Currently, customers are unable to invoice orders through a pos session if they use the Bulgarian localization. Steps to reproduce: ------------------- * Install **point_of_sale** and **l10n_bg** * Change the current company to the Bulgarian one * Set up a shop and open it * Make an order, select any customer * Select payment * Select the invoice option * Select payment method and validate > Observation: Traceback appears psycopg2.errors.CheckViolation: new row for relation "accou
Original PR description
Currently, customers are unable to invoice orders through a pos session if they use the Bulgarian localization. Steps to reproduce: ------------------- * Install **point_of_sale** and **l10n_bg** *…
Currently, customers are unable to invoice orders through a pos session if they use the Bulgarian localization. Steps to reproduce: ------------------- * Install **point_of_sale** and **l10n_bg** * Change the current company to the Bulgarian one * Set up a shop and open it * Make an order, select any customer * Select payment * Select the invoice option * Select payment method and validate > Observation: Traceback appears psycopg2.errors.CheckViolation: new row for relation "account_move_line" violates check constraint "account_move_line_check_accountable_required_fields" Why the fix: ------------ The constraints is violated because the value for account_id does not exist. https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/point_of_sale/models/pos_payment.py#L115-L117 We observe that `self.company_id.account_default_pos_receivable_account_id.id` is not set. This field belogns to the `account` module but can only be modified if the module `account_accountant` because of the group `group_account_readonly`. https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/point_of_sale/views/res_config_settings_views.xml#L163-L167 Other localizations do not have the issue as they set the default account through the data in `account`module. https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/l10n_au/data/account_chart_template_data.xml#L14 https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/l10n_au/data/account.account.template.csv#L8 opw-4279804 Forward-Port-Of: odoo/odoo#188018 Forward-Port-Of: odoo/odoo#186551
Current: Users go to Elearning > Certificates to create a test and do not fill in a description for the test. After the employee finishes the test, they are given a certificate and it is displayed in the employee profile but it is displayed as "False" as shown in the image. This PR fixes that error and fills it back as '' so that it does not display 'False' if the test does not have a description. ![Screenshot from 2024-11-07 10-42-28](https://github.com/user-attachments/assets/a26851e4-4
Original PR description
Current: Users go to Elearning > Certificates to create a test and do not fill in a description for the test. After the employee finishes the test, they are given a certificate and it is displayed in the employee profile but it is displayed as "False" as shown in the image. This PR fixes that error and fills it back as '' so that it does not display 'False' if the test does not have a description.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188517 Forward-Port-Of: odoo/odoo#186531
Following #156437, the destination location of a rule is now determined by the associated picking type destination. To keep compatibility with the old pull system (where each rule determined which destination it had, regardless of its picking type), a new field was added to force the destination defined on the rule to apply instead. This was done for `pull` and `pull_push` rules, as it was mainly the pull rules that were affected, but the `manufacture` case was overlooked, as it would break e
Original PR description
Following #156437, the destination location of a rule is now determined by the associated picking type destination. To keep compatibility with the old pull system (where each rule determined which destination it had, regardless of its picking type), a new field was added to force the destination defined on the rule to apply instead. This was done for `pull` and `pull_push` rules, as it was mainly the pull rules that were affected, but the `manufacture` case was overlooked, as it would break existing manufacture rules having a different destination on the rule than the one in the related picking type. To allow that back again, we enable that parameter to be set on `manufacture` rules as well. opw-4300074 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187898
Steps to reproduce ================== - Install crm - Add a single property - Drag and drop it to the second group => TypeError: Cannot read properties of undefined (reading 'elements') Cause of the issue ================== A properties field is composed of a list of property stored in a JSON object. A property can either be a separator, or any other type, char, bool, ... The properties field has a columns props. If we either have no separator, or we have only one and i
Original PR description
Steps to reproduce ================== - Install crm - Add a single property - Drag and drop it to the second group => TypeError: Cannot read properties of undefined (reading 'elements') Cause of the…
Steps to reproduce ================== - Install crm - Add a single property - Drag and drop it to the second group => TypeError: Cannot read properties of undefined (reading 'elements') Cause of the issue ================== A properties field is composed of a list of property stored in a JSON object. A property can either be a separator, or any other type, char, bool, ... The properties field has a columns props. If we either have no separator, or we have only one and it is at the first position, we enter the split mode. This means that properties are displayed across the available columns. If we move a property in a group, it means we wan't that property to stay in that group. When we're in split mode, we need to add the least amount of new separators so that we get the expected layout. In some cases, it wasn't possible to get the actual group where we dropped a property. This can happen for example when the target was inside an empty group with a default invisible separator (it has no name). In some cases also, the behavior wasn't simply what was expected. opw-3961445 Forward-Port-Of: odoo/odoo#188266 Forward-Port-Of: odoo/odoo#169056
Fix validation to ensure the CFDI origin field is assigned properly. Prevents cases like `04|`, ensuring the UUID is correctly validated. Before: `{'tipo_relacion': '04', 'cfdi_relationado_list': ['']}` After: `{'tipo_relacion': '04', 'cfdi_relationado_list': []}` Forward-Port-Of: odoo/enterprise#74226
Original PR description
Fix validation to ensure the CFDI origin field is assigned properly. Prevents cases like `04|`, ensuring the UUID is correctly validated.
Before:
`{'tipo_relacion': '04', 'cfdi_relationado_list': ['']}`
After:
`{'tipo_relacion': '04', 'cfdi_relationado_list': []}`
Forward-Port-Of: odoo/enterprise#74226### Steps to reproduce the issue: 1. In a Colombian Company, create an Invoice with a Product with UNSPSC 2. Confirm then Send & Print (check DIAN option in wizard) 3. Access Error: > You are not allowed to access 'Colombian operation modes of DIAN used for different documents' (l10n_co_dian.operation_mode) records. > > This operation is allowed for the following groups: > - Administration/Settings ### Explanation: Access Rights for `l10n_co_dian.operation_mode` are
Original PR description
### Steps to reproduce the issue: 1. In a Colombian Company, create an Invoice with a Product with UNSPSC 2. Confirm then Send & Print (check DIAN option in wizard) 3. Access Error: > You are not…
### Steps to reproduce the issue: 1. In a Colombian Company, create an Invoice with a Product with UNSPSC 2. Confirm then Send & Print (check DIAN option in wizard) 3. Access Error: > You are not allowed to access 'Colombian operation modes of DIAN used for different documents' (l10n_co_dian.operation_mode) records. > > This operation is allowed for the following groups: > - Administration/Settings ### Explanation: Access Rights for `l10n_co_dian.operation_mode` are reserved to `base.group_system`. During tests, discovered an Access Rights issue with `l10n_co_dian.certificate` as well when trying to "Reload DIAN configuration" of `account.journal`. ### Fix reasoning: Log note from MASI on the ticket: add Read Access for Invoicing / Billing on `l10n_co_dian.operation_mode` Since `l10n_co_dian.certificate` should not be openly accessible, we will use sudo to retrieve them while sending the request. Testing access rights for invoicing, sudo addition and journal flow at the same time. opw-4242695 Forward-Port-Of: odoo/enterprise#72623
The module description of `account_sepa_direct_debit` in the manifest states that posting an invoice will automatically generate a payment. Actually that feature was dropped in Odoo 13 with commit e3d390c4455c620793c481874b4503fa91bb6125 but the `__manifest__.py` was not updated at that time. This makes the situation uncomfortable where a feature not present in the code is still advertised in the module description. This commit updates the description of the module in the manifest. Forward-P
Original PR description
The module description of `account_sepa_direct_debit` in the manifest states that posting an invoice will automatically generate a payment. Actually that feature was dropped in Odoo 13 with commit e3d390c4455c620793c481874b4503fa91bb6125 but the `__manifest__.py` was not updated at that time. This makes the situation uncomfortable where a feature not present in the code is still advertised in the module description. This commit updates the description of the module in the manifest. Forward-Port-Of: odoo/enterprise#74532 Forward-Port-Of: odoo/enterprise#73380
Currently the view has the default priority and become the main search view for product despite being specific to industry_fsm_sale. It creates issues in inventory at date view where the filters doesn't exist due to this. Forward-Port-Of: odoo/enterprise#74600
Original PR description
Currently the view has the default priority and become the main search view for product despite being specific to industry_fsm_sale. It creates issues in inventory at date view where the filters doesn't exist due to this. Forward-Port-Of: odoo/enterprise#74600
Branches can access their parent companies' accounts, and generally will just use their parent companies' CoA. Therefore, it makes no sense to create an account `123456 Account Payslip Houserental` in a branch if it already exists in the parent company. Community PR: https://github.com/odoo/odoo/pull/188247 task-none Forward-Port-Of: odoo/enterprise#74409
Original PR description
Branches can access their parent companies' accounts, and generally will just use their parent companies' CoA. Therefore, it makes no sense to create an account `123456 Account Payslip Houserental` in a branch if it already exists in the parent company. Community PR: https://github.com/odoo/odoo/pull/188247 task-none Forward-Port-Of: odoo/enterprise#74409
- Add .pot base translation file. - Replace potentially unsafe `const_eval()` with a `json.loads()`. - Use the built-in methods for setting filename for received files. Forward-Port-Of: odoo/enterprise#74424 Forward-Port-Of: odoo/enterprise#74347
Original PR description
- Add .pot base translation file. - Replace potentially unsafe `const_eval()` with a `json.loads()`. - Use the built-in methods for setting filename for received files. Forward-Port-Of: odoo/enterprise#74424 Forward-Port-Of: odoo/enterprise#74347
this commit prevent the auto installation of the french payroll because it's not up to date and currently maintained task-4283506 Forward-Port-Of: odoo/enterprise#72980
Original PR description
this commit prevent the auto installation of the french payroll because it's not up to date and currently maintained task-4283506 Forward-Port-Of: odoo/enterprise#72980
Purpose ======= Fix the calendar slots selection display when sharing appointment availabilities. Specification ============= The working hours have recently been added to the user's calendar. To highlight those, the non-business hours cells are grayed out (from 9am to 5pm). Following this change, it is now difficult to differentiate the non-business hours cells from the "Share Availabilities" gray overlay set on all the past cells. Fixing that by darkening a bit the color of the past
Original PR description
Purpose ======= Fix the calendar slots selection display when sharing appointment availabilities. Specification ============= The working hours have recently been added to the user's calendar. To highlight those, the non-business hours cells are grayed out (from 9am to 5pm). Following this change, it is now difficult to differentiate the non-business hours cells from the "Share Availabilities" gray overlay set on all the past cells. Fixing that by darkening a bit the color of the past cells when sharing availabilities. Additionally, for today, a div with a computed height was added to gray out cells before the current time. This div is now pushing the non-business hours divs which makes them overflow the day display. Fixing that by changing today's past hours div to position absolute. related commit: odoo/odoo@09ddd9f46c0d7528cb0138af283f6ec4f388a445 Task-4337795 Forward-Port-Of: odoo/enterprise#74349
When the customer clicks on the validate button in delivery with Sendcloud carrier, a traceback will appear. Steps to reproduce the error: - Enable Sendcloud Connecter - Go to Inventory > Configuration > Delivery Methods > Create new Method > Provider: SendCloud > Max Weight: 2 kg - Create a new product A > Type: Goods > Weight: 10 kg - Create a new Delivery > add Product A > Carrier: SendCloud > Validate Traceback: ``` File "home/odoo/src/enterprise/18.0/delivery_sendcloud/mode
Original PR description
When the customer clicks on the validate button in delivery with Sendcloud carrier,
a traceback will appear.
Steps to reproduce the error:
- Enable Sendcloud Connecter
- Go to Inventory > Configuration > Delivery Methods > Create new Method >
Provider: SendCloud > Max Weight: 2 kg
- Create a new product A > Type: Goods > Weight: 10 kg
- Create a new Delivery > add Product A > Carrier: SendCloud > Validate
Traceback:
```
File "home/odoo/src/enterprise/18.0/delivery_sendcloud/models/sendcloud_service.py", line 389, in _prepare_parcel
product_moves = format_list(self.env, overweight_products.mapped('name'))
AttributeError: 'SendCloud' object has no attribute 'env'
```
https://github.com/odoo/enterprise/blob/5dd7022e079bbb45492356a66a60c98a249cec8a/delivery_sendcloud/models/sendcloud_service.py#L389
Here, ``self`` is used instead of ``picking``,
So, It will lead to the above traceback.
sentry-6086972478
Forward-Port-Of: odoo/enterprise#74474Oversight of odoo/enterprise#73209. Service invoices don't use the reason field at all (hidden in view) and thus will always fail the constraint. To fix it, disable the constraint for service invoices. opw-4354637 Forward-Port-Of: odoo/enterprise#74619 Forward-Port-Of: odoo/enterprise#74552
Original PR description
Oversight of odoo/enterprise#73209. Service invoices don't use the reason field at all (hidden in view) and thus will always fail the constraint. To fix it, disable the constraint for service invoices. opw-4354637 Forward-Port-Of: odoo/enterprise#74619 Forward-Port-Of: odoo/enterprise#74552
Problem: In a multi-company environment where a user has an employee record per company, the approval request will retrieve the incorrect employee record upon confirmation, which leads to an access error. Purpose: Upon confirming the approval request, the employee record from the same company as the request should be fetched, rather than retrieving the latest employee record made for the user. Steps to reproduce on Runbot: 1. Install Approvals and Employees 2. Create a default company
Original PR description
Problem: In a multi-company environment where a user has an employee record per company, the approval request will retrieve the incorrect employee record upon confirmation, which leads to an access…
Problem: In a multi-company environment where a user has an employee record per company, the approval request will retrieve the incorrect employee record upon confirmation, which leads to an access error. Purpose: Upon confirming the approval request, the employee record from the same company as the request should be fetched, rather than retrieving the latest employee record made for the user. Steps to reproduce on Runbot: 1. Install Approvals and Employees 2. Create a default company 3. Create a non-default company 4. Create a Test Employee user on the default company, enable multi-company rights, and create an employee record for the default company. Switch to the non-default company and create an employee record for the user. 5. Repeat Step 4 when creating a Test Manager user 6. On the employee record for Test Employee, set Test Manager as the manager on both companies. 7. Create an approval type on the default company and set "Manager is required approver" 8. Login as Test Employee and create an approval request for the approval type created in Step 7 on the default company 9. Submit the request and an AccessError occurs Note: Bug was not reproducible on previous versions because the record rule for Employee multi company rule for Employees module are different. opw-4212341 Forward-Port-Of: odoo/enterprise#71955
Steps to reproduce ================== - Have a gantt arch with a default_scale that is not part of scales ```xml <gantt scales="week,month" default_scale"day">...</gantt> ``` => Cannot destructure property 'defaultRange' of 'metaData.scales[scaleId]' Solution ======== If we set a default scale that is not part of the scales, add it to the list of allowed scales. opw-4175183 Forward-Port-Of: odoo/enterprise#74525
Original PR description
Steps to reproduce ================== - Have a gantt arch with a default_scale that is not part of scales ```xml <gantt scales="week,month" default_scale"day">...</gantt> ``` => Cannot destructure property 'defaultRange' of 'metaData.scales[scaleId]' Solution ======== If we set a default scale that is not part of the scales, add it to the list of allowed scales. opw-4175183 Forward-Port-Of: odoo/enterprise#74525
Steps to reproduce ================== - Go to planning - Open studio - Change the default scale to Month (expanded) - Close studio - Switch to Schedule > By Role => Cannot destructure property 'defaultRange' of 'metaData.scales[scaleId]' Cause of the issue ================== The planning view has the scales attribute as `scales="day,week,month,year"`. month_3 is not part of the allowed scales. opw-4175183 Forward-Port-Of: odoo/enterprise#74407
Original PR description
Steps to reproduce ================== - Go to planning - Open studio - Change the default scale to Month (expanded) - Close studio - Switch to Schedule > By Role => Cannot destructure property 'defaultRange' of 'metaData.scales[scaleId]' Cause of the issue ================== The planning view has the scales attribute as `scales="day,week,month,year"`. month_3 is not part of the allowed scales. opw-4175183 Forward-Port-Of: odoo/enterprise#74407
The civil status field in the swizz localization has terms that are not exported to be translated. Also, There was a typo in one of the terms. This commit fixes the typo and exports the terms to be translated later on. Opw-4292046 Opw-4278798 Community: https://github.com/odoo/odoo/pull/186473 Forward-Port-Of: odoo/enterprise#74581 Forward-Port-Of: odoo/enterprise#73406
Original PR description
The civil status field in the swizz localization has terms that are not exported to be translated. Also, There was a typo in one of the terms. This commit fixes the typo and exports the terms to be translated later on. Opw-4292046 Opw-4278798 Community: https://github.com/odoo/odoo/pull/186473 Forward-Port-Of: odoo/enterprise#74581 Forward-Port-Of: odoo/enterprise#73406
Apply [this fix] to templates introduced with [this commit]. The purpose is to prevent images that are the only child of their parent from taking too much space. Furthermore, fix the src path for some of these templates. [this fix]: https://github.com/odoo/odoo/commit/d5297a75f50022b406b226ebf4c300f4bd033c3d [this commit]: https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833 task-4178640 Forward-Port-Of: odoo/enterprise#74192
Original PR description
Apply [this fix] to templates introduced with [this commit]. The purpose is to prevent images that are the only child of their parent from taking too much space. Furthermore, fix the src path for some of these templates. [this fix]: https://github.com/odoo/odoo/commit/d5297a75f50022b406b226ebf4c300f4bd033c3d [this commit]: https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833 task-4178640 Forward-Port-Of: odoo/enterprise#74192
### Steps to reproduce: - Install "l10n_mx" and switch to a Mexican company - Create a vendor bill with this partner using the tax "Exento" - Go to Reports -> Tax report -> DIOT.txt ### Cause: For partners that only have lines with the tax "Exento", no information are retrieved for the report. The columns "Type of third", "type of operation", "VAT", etc. are empty in the Tax report before trying to download the DIOT report. When trying to generate the txt file, the code tries to access th
Original PR description
### Steps to reproduce: - Install "l10n_mx" and switch to a Mexican company - Create a vendor bill with this partner using the tax "Exento" - Go to Reports -> Tax report -> DIOT.txt ### Cause: For…
### Steps to reproduce: - Install "l10n_mx" and switch to a Mexican company - Create a vendor bill with this partner using the tax "Exento" - Go to Reports -> Tax report -> DIOT.txt ### Cause: For partners that only have lines with the tax "Exento", no information are retrieved for the report. The columns "Type of third", "type of operation", "VAT", etc. are empty in the Tax report before trying to download the DIOT report. When trying to generate the txt file, the code tries to access the value "third_party_code" in a dictionary but the key is not there so an error is raised. This occurs because the tax "Exento" is "on_invoice" so there are no cash basis entry created. But in the custom query to retrieve the information of the partners it is specified the journal_id must be part of the cash basis journals. So no lines with "on_invoice" taxes were selected. ### Solution: Remove the journal restriction. opw-4312155 Forward-Port-Of: odoo/enterprise#74423 Forward-Port-Of: odoo/enterprise#74105
Steps ----- - Subscriptions > Configuration > Alerts. - Create an alert triggered when the stage goes from 'Initial' (placeholder) to 'In Progress', set 'Create next activity', chose Email as activity. - Create a subscription, confirm it. ** Multiple activities created in the chatter (1 would be expected) ** Cause ----- The `pre_domain_filter` of the `base.automation` is not set, leading to an activity being created every time a write happens on the sale order while it is in the `s
Original PR description
Steps ----- - Subscriptions > Configuration > Alerts. - Create an alert triggered when the stage goes from 'Initial' (placeholder) to 'In Progress', set 'Create next activity', chose Email as activity. - Create a subscription, confirm it. ** Multiple activities created in the chatter (1 would be expected) ** Cause ----- The `pre_domain_filter` of the `base.automation` is not set, leading to an activity being created every time a write happens on the sale order while it is in the `stage_to_id` stage. Change ----- Add a pre-domain/domain filter to only trigger actions when the stage changes. opw-4273625 Forward-Port-Of: odoo/enterprise#74292 Forward-Port-Of: odoo/enterprise#73601
The links created with the many2OneGridRow widget won't work correctly. This commit, will change the link to the new format. This commit is a followup of https://github.com/odoo/odoo/commit/98f748603ed7677265280d33b0b4750010f71fe0 Forward-Port-Of: odoo/enterprise#74461
Original PR description
The links created with the many2OneGridRow widget won't work correctly. This commit, will change the link to the new format. This commit is a followup of https://github.com/odoo/odoo/commit/98f748603ed7677265280d33b0b4750010f71fe0 Forward-Port-Of: odoo/enterprise#74461