Daily updates from Odoo
Navigate
Branch
Monday, October 21, 2024
50 changes
13 changes
Security fixes and vulnerability patches
This fix ensures that permissions for checking user groups are based on the person making the request, not the user being checked. It prevents portal or external users from accessing group information they should not see while allowing internal users to perform valid checks.
Original PR description
The code comment says non-internal users should not have access to has_group if it's not for themselves. But the code checked the group of the targetted user, not the current user. Added test failed without fix failed because an AssertError was not raised, and an AssertError was raised when it should not have. note: found when reviewing 18.0 forward-port of d0828eecf60f7c8622d6875b opw-4096073
Enhancements to existing features
Users now see one consolidated warning when invoice lines or products have missing or invalid HSN codes, instead of repeated alerts. This makes E-waybill creation smoother and easier to correct, including for service products and inventory flows.
Original PR description
Before this PR: - If the HSN code was missing or invalid in multiple lines, an alert message was displayed multiple times with the product label. Additionally, the HSN warning wasn't displayed for service-type products in invoices. - In the inventory module, HSN validation occurred twice when creating an E-waybill. After this PR: - The alert message is displayed only once. A single button allows the user to list view of invoice lines with invalid or empty HSN codes and an HSN warning will be displayed for all types of products in invoices. - HSN validation will occur only once during the final generation of the E-waybill in inventory, with the error message showing only once for all invalid or empty HSN products. A single button redirects to the list view of all those products. **task**-3660731
The email-based two-factor authentication enforcement module is now installed automatically for this version. This prepares systems for stronger login protection, while the actual enforcement setting remains inactive for now.
Original PR description
The module is installed but the config parameter is not activated (yet) Master plan: - saas-17.2 : auth_totp_mail_enforced install by default (#169621) - master: auth_totp_mail_enforced merged into auth_totp_mail + activated by default for everybody (#169608)
Resolved issues and error corrections
This update fixes an error that could occur when opening an employee form view in the HR app. It restores reliable access to HR employee records after a recent change introduced the issue.
Original PR description
Fix an error introcuded by commit 2773ab7ff5855a8345eabaf52a3bb5f8b1b80235
This fix corrects how the HR app checks a user's group permissions when opening employee forms. It helps ensure the right employee form view or action is shown based on user access rights, avoiding errors caused by checking permissions on the wrong record type.
Original PR description
With this commit; the function previously called user_has_group is replaced by the method has_group and need to be called with res.users model not hr.employee model. task-4262917 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
Miscellaneous changes
For the longest time, the base `ModelConverter` (and `ModelsConverter`) have added a group around their regex. That was (apparently) never useful but Werkzeug didn't care. Except, it turns out, Werkzeug 2.2 specifically, which is the one we require for Python 3.11, because it's the one bundled in Debian Bookworm. In this version and this version only werkzeug gets tripped up by our extra group, and doubles up the parameters. This makes it very hard to see as: - we need a version which u
Original PR description
For the longest time, the base `ModelConverter` (and `ModelsConverter`) have added a group around their regex. That was (apparently) never useful but Werkzeug didn't care. Except, it turns out,…
For the longest time, the base `ModelConverter` (and `ModelsConverter`) have added a group around their regex. That was (apparently) never useful but Werkzeug didn't care.
Except, it turns out, Werkzeug 2.2 specifically, which is the one we require for Python 3.11, because it's the one bundled in Debian Bookworm.
In this version and this version only werkzeug gets tripped up by our extra group, and doubles up the parameters. This makes it very hard to see as:
- we need a version which uses at least two converters, at least one of which is `model` or `models` in non-last position
- we need to realise that the latter converter gets a copy of the former
The first one is relatively common (70 cases in community, of which 48 use multiple `model` or `models`), however the part where it has to be test and noticed is a lot less likely as we don't routinely test this configuration. Unless somebody happens to use 3.11 locally and follow the `requirements.txt` when installing odoo...
Fixes runbot error 73290
Repro case:
- install tox
- create a file `tox.ini` containing:
```ini
[tox]
requires = tox >= 4
env_list = werkzeug{016,10,21,22,23,3}
[testenv]
deps =
pytest
werkzeug016: werkzeug~=0.16.0
werkzeug10: werkzeug~=1.0.0
werkzeug21: werkzeug~=2.1.0
werkzeug22: werkzeug~=2.2.0
werkzeug23: werkzeug~=2.3.0
werkzeug3: werkzeug~=3.0
commands = pytest app.py
```
- create a file `app.py` containing:
```python
import json
import pytest
from werkzeug.wrappers import Response
from werkzeug.test import Client
from werkzeug.routing import Map, Rule, BaseConverter
class ModelConverter(BaseConverter):
regex = r'([0-9]+)'
def to_python(self, value: str) -> int:
return int(value)
class ModelsConverter(BaseConverter):
regex = r'([0-9,]+)'
def to_python(self, value: str) -> list[int]:
return [int(v) for v in value.split(',')]
url_map = Map(
[
Rule("/id/<id:a>"),
Rule("/id/<id:a>/<id:b>"),
Rule("/ids/<ids:as>"),
Rule("/ids/<ids:as>/<id:b>"),
],
strict_slashes=False,
converters={
'id': ModelConverter,
'ids': ModelsConverter,
}
)
def application(environ, start_response):
urls = url_map.bind_to_environ(environ)
endpoint, args = urls.match()
start_response('200 OK', [('Content-Type', 'text/plain')])
return [json.dumps(args)]
@pytest.mark.parametrize('url,res', [
("/id/1", {'a': 1}),
("/id/1/2", {'a': 1, 'b': 2}),
("/ids/1,2,3", {"as": [1, 2, 3]}),
("/ids/1,2,3/4", {"as": [1, 2, 3], "b": 4}),
])
def test_routing(url, res):
c = Client(application, Response)
r = c.get(url)
assert json.loads(r.get_data()) == res
```
- run `tox`
- observe that Werkzeug 2.2 and that version only blows up on cases 2 and 4
Removing the parenthesis inside the regexes fixes the issue.
Forward-Port-Of: odoo/odoo#184277Issue: ====== Empty inline code block isn't working as expected and produces issues in the following flows: First Flow: - Create a note - Add ` 2 times - Delete forward 2 times - The button send message is modified!! Second Flow: - Log a note in the chatter of the note - Open composer - Add ` 2 times - Delete forwart 2 times - Traceback Origin of the issue: ===================== After adding the {backtick} 2 times, it will have the following html `<p>{backtick}[]<code cla
Original PR description
Issue: ====== Empty inline code block isn't working as expected and produces issues in the following flows: First Flow: - Create a note - Add ` 2 times - Delete forward 2 times - The button send…
Issue:
======
Empty inline code block isn't working as expected and produces issues in
the following flows:
First Flow:
- Create a note
- Add ` 2 times
- Delete forward 2 times
- The button send message is modified!!
Second Flow:
- Log a note in the chatter of the note
- Open composer
- Add ` 2 times
- Delete forwart 2 times
- Traceback
Origin of the issue:
=====================
After adding the {backtick} 2 times, it will have the following html
`<p>{backtick}[]<code class="o_inline_code">{backtick}</code></p>` which
is not the expected behavior. now after delete forward we will have the
following html
`<p>{backtick}[]<code class="o_inline_code" data-oe-zws-empty-inline></code></p>`
now we delete forward again it will delete the inline block which
validate the following condition [1] which forces a deleteForward in the
parent element at offset one which is basically here
`<p>{backtick}[]<p>` which now will reach this part of code [2] and the
`findNode` will return a node outside the editable because we didn't
specify the `root` element as a stopping condition.
Solution:
=========
- First we fix the spec of the inline code block which should do nothing
in case there is no content inside it.
- We add the root as stopping condition while generating the path.
[1]: https://github.com/odoo/odoo/blob/16.0/addons/web_editor/static/src/js/editor/odoo-editor/src/commands/deleteForward.js#L125-L143
[2]: https://github.com/odoo/odoo/blob/d0828eecf60f7c8622d6875b8651eb663bc7d695/addons/web_editor/static/src/js/editor/odoo-editor/src/commands/deleteForward.js#L214-L241
opw-4254182
Forward-Port-Of: odoo/odoo#183567Issue: ====== clipboard data has ufeff characters in it. Steps to reproduce the issue: ============================= - Create a new note/todo - Add a link - Copy it - Visualise the data copied - It contains ufeff characters of the link Solution: ========= We remove the characters fron the text and html we put in the clipboard data. opw-4029722 Forward-Port-Of: odoo/odoo#182596
Original PR description
Issue: ====== clipboard data has ufeff characters in it. Steps to reproduce the issue: ============================= - Create a new note/todo - Add a link - Copy it - Visualise the data copied - It contains ufeff characters of the link Solution: ========= We remove the characters fron the text and html we put in the clipboard data. opw-4029722 Forward-Port-Of: odoo/odoo#182596
Versions -------- - 17.0+ Steps ----- 1. Enter debug mode; 2. create an Automation Rule; 3. select Task as model; 4. set trigger to Stage is set to New; 5. set domain to a specific customer; 6. add send email as action; 7. create a task. Issue ----- Email is sent after task creation, regardless of the customer. Cause ----- The triggers added to 0a744accc2aa automatically compute the `filter_domain` value, and hide the field in view. With debug mode enabled, the `filter_pre
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Enter debug mode; 2. create an Automation Rule; 3. select Task as model; 4. set trigger to Stage is set to New; 5. set domain to a specific customer; 6. add…
Versions -------- - 17.0+ Steps ----- 1. Enter debug mode; 2. create an Automation Rule; 3. select Task as model; 4. set trigger to Stage is set to New; 5. set domain to a specific customer; 6. add send email as action; 7. create a task. Issue ----- Email is sent after task creation, regardless of the customer. Cause ----- The triggers added to 0a744accc2aa automatically compute the `filter_domain` value, and hide the field in view. With debug mode enabled, the `filter_pre_domain` field is still visible & editable. The newly added triggers are applied on both create & update, while `filter_pre_domain` is only applied on update. This leads to confusion when clients add a domain which appears to be ignored, as the selected trigger is immediately hit on creation. Solution -------- 1. Specify in the help string that `filter_pre_domain` is ignored on creation. 2. When entering debug mode, also show the `filter_domain` field, allowing users to further modify the domain computed by the selected trigger, and helping to distinguish itself from `filter_pre_domain`. opw-3928082 Forward-Port-Of: odoo/odoo#180209
Just add a missing space in the French translation. Forward-Port-Of: odoo/odoo#184041
Original PR description
Just add a missing space in the French translation. Forward-Port-Of: odoo/odoo#184041
Steps to reproduce the bug: - Create a storable product P1 with the following BoM: - Components: - Component 1 - Component 2 - Kit (which has its own BoM) - BoM of the kit: - Component 3 - Component 4 - Create a Mo for one unit of P1 - Confirm the MO - Update the BoM of P1: - Delete Component 2 - Go back to the MO - Refresh the page - Click "Update from BoM" Problem: Only the move for Component 1 is retained. The moves for Compon
Original PR description
Steps to reproduce the bug: - Create a storable product P1 with the following BoM: - Components: - Component 1 - Component 2 - Kit (which has its own BoM) - BoM of the kit: - Component 3 - Component…
Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
- Components:
- Component 1
- Component 2
- Kit (which has its own BoM)
- BoM of the kit:
- Component 3
- Component 4
- Create a Mo for one unit of P1
- Confirm the MO
- Update the BoM of P1:
- Delete Component 2
- Go back to the MO
- Refresh the page
- Click "Update from BoM"
Problem:
Only the move for Component 1 is retained. The moves for Components 2 (which were deleted) and for Components 3 and 4 (which belong to the kit) are removed, while the kit should be decomposed into its own components (3 and 4) and their moves retained.
The current logic did not handle kit products properly when updating the MO. It only compared the components at the top level of the BoM, ignoring the fact that kits contain their own components. As a result, the moves corresponding to the kit's components were not detected and were deleted when updating the MO.
opw-4247193
Forward-Port-Of: odoo/odoo#183638Issue: ====== Extra button in the sent email. Steps to reproduce the issue: ============================= - Create a new mailing - Start from scratch - Drop cover template - Add a link inside it - Test send the email - There is an extra link in the sent email. Origin of the issue: ==================== In the case when the button is inside the cover template we end up with something like this `<!--mso condition ab <!-- another condition cd endif--> ef endif-->` but in reality c
Original PR description
Issue: ====== Extra button in the sent email. Steps to reproduce the issue: ============================= - Create a new mailing - Start from scratch - Drop cover template - Add a link inside it - Test send the email - There is an extra link in the sent email. Origin of the issue: ==================== In the case when the button is inside the cover template we end up with something like this `<!--mso condition ab <!-- another condition cd endif--> ef endif-->` but in reality comments can't be nested so the first comment will close at the ending of the second comment so we will end up with the content `ef` being displayed. Solution: ========= Since the two conditions are opposites, we remove completely the content of the nested comment if it has oppisite condition otherwise we just remove the comment tags since they will be replaced with the upper comment opw-4149948 Forward-Port-Of: odoo/odoo#181504
**Steps to reproduce:** - Install Accounting and l10n_it_edi - Switch to an Italian company (e.g. IT Company) - Create an invoice: * Customer: [an Italian customer] * Product: [any] * Taxes: [a split payment tax] (e.g. 22% SP) - Confirm the invoice - Process to E-invoicing service - Check the XML of the electronic invoice => <ImportoTotaleDocumento> node is including the tax amount - Create a credit note (Full refund) - Confirm the credit note - Process to E-invoicing service
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_it_edi - Switch to an Italian company (e.g. IT Company) - Create an invoice: * Customer: [an Italian customer] * Product: [any] * Taxes: [a split payment tax] (e.g. 22% SP) - Confirm the invoice - Process to E-invoicing service - Check the XML of the electronic invoice => <ImportoTotaleDocumento> node is including the tax amount - Create a credit note (Full refund) - Confirm the credit note - Process to E-invoicing service - Check the XML of the credit note **Issue:** <ImportoTotaleDocumento> node is not including the tax amount. Task [link](https://www.odoo.com/odoo/project/967/tasks/4161435) opw-4161435 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184334 Forward-Port-Of: odoo/odoo#183774
24 changes
Enhancements to existing features
Payment terminal credentials can now be stored once and reused across multiple point-of-sale terminal methods from the same vendor. This reduces duplicate setup work, saves time when adding payment methods, and makes terminal configuration easier to maintain.
Original PR description
Before this commit: ========== - Previously, there was no model for storing mandatory credentials for different terminal methods. - So, it was necessary to enter the same credentials with different terminal IDs for various payment terminal methods provided by the same vendor. - This resulted in the duplication of credentials. After this commit: ========== - So, we are introducing a new 'pos.payment.provider' model for storing the same mandatory credentials in one model. - We allow credentials to be entered once and used across multiple terminal payment methods. This enhancement streamlines the function of payment terminals and saves time when new payment methods are created. Related PR: - Community: odoo/odoo#172471 - Upgrade: odoo/upgrade#6248 task-3506646
Knowledge now uses database indexes better for article permissions and hierarchy lookups, while removing indexes that were not useful. This should reduce server response times, especially when opening large Knowledge article lists or checking access rights.
Original PR description
This PR aims to optimize Knowledge by appropriately setting SQL indexes on the fields that are frequently used to join tables and filter out records. The new indexes should help reducing the server…
This PR aims to optimize Knowledge by appropriately setting SQL indexes on the fields that are frequently used to join tables and filter out records. The new indexes should help reducing the server response times. For the `knowledge.article` model: 1. Remove the `is_article_item` index Setting an index on a boolean field is generally speaking not recommended as the field has only two possible values and does not allow us to discriminate the records efficiently. Indeed, the index will be used only when searching for an uncommon boolean value. In the other cases, the index does not provide much benefit compared to a full table scan. PostgreSQL will then favor another index that will better reduce the search space of the query. 2. Remove the `category` index The index set on the `category` column is almost never used as we never search for articles based on their categories and we never join tables based on that value. The index could be used when the user applies a search filter in the list view but, in that case, PostgreSQL could use another index that better discriminate the records. 3. Add index on `parent_id` The `parent_id` field is heavily used in the user's permission computation. Adding an index for that field will ensure that we can quickly explore the article hierarchy and compute the user's permissions efficiently. For the `knowledge.article.member` model: 1. Add index on `article_id` The `article_id` field is heavily used in the user's permission computation. Adding an index for that field will ensure that we can quickly compute the user membership on the article. task-4046060
The spreadsheet list properties panel now lets users edit list names directly, matching the behavior of other Odoo and spreadsheet inputs. This creates a more consistent editing experience and reduces friction when organizing spreadsheet lists.
Original PR description
Currently, in the list properties panel, the name stil uses the old component. Now the name is always editable, just like any other inputs in odoo and spreadsheet Task: 4243854
Missed call notifications for VoIP are now shown directly on the phone icon in the top bar instead of as separate top-bar text. This makes call alerts easier to find while keeping the interface cleaner, and the call dropdown no longer opens automatically by default.
Original PR description
<h3>PURPOSE</h3> - Move missed call notifications in the top bar text to the top icon <h3>SPECIFICATION</h3> - Move the VOIP missed called counter to the systray item, like as discuss. - Stop opening the dropdown by default. Task-3392951
Resolved issues and error corrections
This fixes a test conflict that happened when the demo social media module was installed alongside Twitter social features. It ensures anti-spam checks can be tested reliably without being disrupted by demo data behavior.
Original PR description
If `social_demo` is installed, it overrides all social method calls to return hardcoded data, and notably does not account for the "anti-spam" system. This means running the anti-spam test with `social_demo` installed can not succeed.
This change updates inter-company sales and purchasing tests so they no longer assume that multi-currency mode is enabled. It helps ensure the tests run reliably in databases with only one active currency, reducing false failures in validation environments.
Original PR description
Both modules have tests with an unstated dependency on the multi-currency mode, as they unconditionally try setting currencies into forms.
They will pass if they run in a multi-currency-enabled database[^1] but if the context is non-multi-currency (e.g. no l10n module is explicitly installed so only `l10n_us` is present and USD is the only currency) then they fail with
can't write on invisible field 'currency_id'
[^1]: generally the case on runbot where `l10n_be` is ~always
installed, which enables EUR, which being a second currency
automatically enables multi-currencyCode cleanup and technical improvements
This update renames an internal WhatsApp message preview field so the web interface matches the server-side naming. It helps keep the codebase consistent and easier to maintain, with no expected change for end users.
Original PR description
https://github.com/odoo/odoo/pull/184311
The eSignature module code has been reorganized into smaller, more focused files. This does not change how the feature works for users, but it makes the code easier to maintain and safer to update in the future.
Original PR description
## Purpose This PR refactors the `sign` module by splitting large model files (`sign_request.py`, `sign_template.py`, `sign_send_request.py` and `test_sign_controller.py`) into class-specific files. This improves the maintainability and readability of the codebase. ## Changes - Split large model files into smaller, class-focused files. - Improved modularity by ensuring each class resides in its own dedicated file. This refactor does not introduce any functional changes but significantly improves the structure and organization of the code.
Several business modules were updated to use Odoo's newer internal reporting method before the older one is retired. This keeps features such as subscriptions, payroll, helpdesk, field service, stock barcode, and accounting-related workflows maintainable without changing day-to-day user behavior.
Original PR description
read_group will be deprecated soon, replace read_group usage from the the business code with _read_group. https://github.com/odoo/odoo/pull/184153
Miscellaneous changes
Spotted by runbot in master by the `self-in-iter` semgrep check. Forward-Port-Of: odoo/enterprise#72335
Original PR description
Spotted by runbot in master by the `self-in-iter` semgrep check. Forward-Port-Of: odoo/enterprise#72335
Before the commit: - The fields such as `padding_time`, `extra_hour`, and `extra_day` did not update since the adoption of `ir.default` in the related onchange methods. After the commit: - Removed the related attribute from the fields, and converted them into computed fields. The compute methods now retrieve the company-specific default values using the _get method from `ir.default`. - Added inverse methods to ensure that changes made to these fields are saved back to `ir.default`, allowin
Original PR description
Before the commit: - The fields such as `padding_time`, `extra_hour`, and `extra_day` did not update since the adoption of `ir.default` in the related onchange methods. After the commit: - Removed the related attribute from the fields, and converted them into computed fields. The compute methods now retrieve the company-specific default values using the _get method from `ir.default`. - Added inverse methods to ensure that changes made to these fields are saved back to `ir.default`, allowing company-specific default values to be updated as expected. - This change allows for the correct fetching and updating of default values, ensuring that fields can be modified and persisted properly. Forward-Port-Of: odoo/enterprise#70838
Before this commit, when the user has more than one project linked to a same stage then a traceback will be raised when the user will group by stage in `/my/tasks` portal view. This commit reviews the visibility condition of the Documents button in that portal list view and makes sure the project variable in the template contains either no project or just one project to avoid having a traceback because `project` variable contains more than one project. And so, in `/my/tasks` view, the Documen
Original PR description
Before this commit, when the user has more than one project linked to a same stage then a traceback will be raised when the user will group by stage in `/my/tasks` portal view. This commit reviews…
Before this commit, when the user has more than one project linked to a same stage then a traceback will be raised when the user will group by stage in `/my/tasks` portal view. This commit reviews the visibility condition of the Documents button in that portal list view and makes sure the project variable in the template contains either no project or just one project to avoid having a traceback because `project` variable contains more than one project. And so, in `/my/tasks` view, the Documents button should not be displayed when the view is grouped by Stage. Steps to reproduce the issue ============================ 1. Install documents_project 2. Create 2 projects 3. Go to Tasks stage menu and set the both projects in the first stage (create new stage if there is no stage displayed in that menu) 4. create a task for each project with that first stage 5. Go to `/my/tasks` portal list view 6. Group by `Stage` Actual Behavior --------------- A traceback is raised because there is more than one project contained inside `project` variable. Expected Behavior ----------------- The documents button should not be displayed in `/my/tasks` since we could have more than one project in that view. task-4239772 Forward-Port-Of: odoo/enterprise#71984
Reproduce: * create an asset * duplicate it, and change the journal * in list view, compute the depreciation * in list view, confirm Traceback because we try to get the lock date related to multiple journals. Forward-Port-Of: odoo/enterprise#71103
Original PR description
Reproduce: * create an asset * duplicate it, and change the journal * in list view, compute the depreciation * in list view, confirm Traceback because we try to get the lock date related to multiple journals. Forward-Port-Of: odoo/enterprise#71103
Currently we search for the 'us' chart template but we should search for the 'generic_coa' instead. This commit corrects it. task-None Forward-Port-Of: odoo/enterprise#71908
Original PR description
Currently we search for the 'us' chart template but we should search for the 'generic_coa' instead. This commit corrects it. task-None Forward-Port-Of: odoo/enterprise#71908
Before this commit, it was possible to fill two date fields in two different date formats in the same document. This happened because the date format was dependent on the location of the user who is signing. After this commit, date fields will be auto-filled by a fixed date format, that format depends on the language of the company's partner. Task: 3930358 Forward-Port-Of: odoo/enterprise#71864 Forward-Port-Of: odoo/enterprise#64591
Original PR description
Before this commit, it was possible to fill two date fields in two different date formats in the same document. This happened because the date format was dependent on the location of the user who is signing. After this commit, date fields will be auto-filled by a fixed date format, that format depends on the language of the company's partner. Task: 3930358 Forward-Port-Of: odoo/enterprise#71864 Forward-Port-Of: odoo/enterprise#64591
Traceback: ``ValueError: Expected singleton: res.currency(1, 125)`` At [1], mistakenly written self instead of rec [1]- https://github.com/odoo/enterprise/blob/e9a2ae47fcdf98635dbdc7a55cb9ed1bfa1f0f5e/account_iso20022/models/account_payment.py#L41-L43 sentry-6000953570 Forward-Port-Of: odoo/enterprise#72264
Original PR description
Traceback: ``ValueError: Expected singleton: res.currency(1, 125)`` At [1], mistakenly written self instead of rec [1]- https://github.com/odoo/enterprise/blob/e9a2ae47fcdf98635dbdc7a55cb9ed1bfa1f0f5e/account_iso20022/models/account_payment.py#L41-L43 sentry-6000953570 Forward-Port-Of: odoo/enterprise#72264
This allows to rely on the framework's inheritance instead of python's inheritance. Indeed, there was an issue where `sale_subscription` overrides were ignored by the framework. This change applies to both the product and combo configurators (and extracts any duplicated logic into shared methods). task-4263961 Community PR: https://github.com/odoo/odoo/pull/181135 Forward-Port-Of: odoo/enterprise#70533
Original PR description
This allows to rely on the framework's inheritance instead of python's inheritance. Indeed, there was an issue where `sale_subscription` overrides were ignored by the framework. This change applies to both the product and combo configurators (and extracts any duplicated logic into shared methods). task-4263961 Community PR: https://github.com/odoo/odoo/pull/181135 Forward-Port-Of: odoo/enterprise#70533
Steps to Reproduce: 1. Navigate to the Documents app. 2. Select "All". 3. Click "New" > "Spreadsheet". 4. Choose a different workspace. 5. Click the "Create" button, resulting in an `AccessError`. The issue was caused by passing the ID as a string in the `orm` call to the `action_open_new_spreadsheet` method. This has been corrected by passing the ID as a number instead. Task: [4215415](https://www.odoo.com/odoo/project/2328/tasks/4215415) Forward-Port-Of: odoo/enterprise#72326 Forwa
Original PR description
Steps to Reproduce: 1. Navigate to the Documents app. 2. Select "All". 3. Click "New" > "Spreadsheet". 4. Choose a different workspace. 5. Click the "Create" button, resulting in an `AccessError`. The issue was caused by passing the ID as a string in the `orm` call to the `action_open_new_spreadsheet` method. This has been corrected by passing the ID as a number instead. Task: [4215415](https://www.odoo.com/odoo/project/2328/tasks/4215415) Forward-Port-Of: odoo/enterprise#72326 Forward-Port-Of: odoo/enterprise#71842
Steps: - Install sale app. - Go to sale module. - Open product form. - Go to accounting page. Issue: - Empty accounting page. Cause: - In account_accountant module added invoice group to display accounting page even though there is no content added in that module to display which should be visible without have account readonly access. Fix: - Remove invoice group for stable to display that page only for readonly group. To-do master: Remove that view. opw-4209850 Forward-Por
Original PR description
Steps: - Install sale app. - Go to sale module. - Open product form. - Go to accounting page. Issue: - Empty accounting page. Cause: - In account_accountant module added invoice group to display accounting page even though there is no content added in that module to display which should be visible without have account readonly access. Fix: - Remove invoice group for stable to display that page only for readonly group. To-do master: Remove that view. opw-4209850 Forward-Port-Of: odoo/enterprise#71616
task-4182770 Forward-Port-Of: odoo/enterprise#70570
Original PR description
task-4182770 Forward-Port-Of: odoo/enterprise#70570
A previous [commit](https://github.com/odoo/enterprise/pull/63926/commits/c749e1358dbd0175d0de5f32eab2c4dd98053905) added a readonly condition on the field auto_sync of the account.online.link view. This was made to prevent the automatic fetching of transaction from interactive providers when the connexion had expired. The issue lies in that condition being based on the field it applies to. This does not work well with manual editing as the readonly condition would update before hitting 'sav
Original PR description
A previous [commit](https://github.com/odoo/enterprise/pull/63926/commits/c749e1358dbd0175d0de5f32eab2c4dd98053905) added a readonly condition on the field auto_sync of the account.online.link view. This was made to prevent the automatic fetching of transaction from interactive providers when the connexion had expired. The issue lies in that condition being based on the field it applies to. This does not work well with manual editing as the readonly condition would update before hitting 'save', preventing to save the changes when unticking the 'auto_sync' checkbox. After discussion with FLG, we decided to keep things simple and remove that condition altogether. Else, one would have had to create a new field and import new data from the institution (is_interactive). No opw but the issue was raised in a odoofin support discord thread. Forward-Port-Of: odoo/enterprise#72047 Forward-Port-Of: odoo/enterprise#71643
Steps to reproduce: - As admin > Settings > Users & Companies > Users - Edit Marc Demo's access rights: Planning: admin; Time off: blank - As Marc Demo > Planning app > Apply 'Employees on time off' filter Access denied due to missing read rights on model hr.leave. This is triggered by _get operations on fields request_unit_half and request_unit_hours and doesn't happen in earlier versions because we did not use to need the number_of_days in _get_leave_warning_parameters. opw-4222955 F
Original PR description
Steps to reproduce: - As admin > Settings > Users & Companies > Users - Edit Marc Demo's access rights: Planning: admin; Time off: blank - As Marc Demo > Planning app > Apply 'Employees on time off' filter Access denied due to missing read rights on model hr.leave. This is triggered by _get operations on fields request_unit_half and request_unit_hours and doesn't happen in earlier versions because we did not use to need the number_of_days in _get_leave_warning_parameters. opw-4222955 Forward-Port-Of: odoo/enterprise#72005
Currently, there's no menu to get a list of all quote calculator spreadsheet templates. This commits adds a menu in the technical settings. It allows to: - delete/clean unused spreadsheet templates - import a template from its json file (BA do that quite often for dashboards, I expect they'll want to do it for spreadsheet quotation templates) Feedback from OXP Note: we don't add the menu in the Sales app menus because we don't want to add noise in there. It must be kept clean.
Original PR description
Currently, there's no menu to get a list of all quote calculator spreadsheet templates. This commits adds a menu in the technical settings. It allows to: - delete/clean unused spreadsheet templates - import a template from its json file (BA do that quite often for dashboards, I expect they'll want to do it for spreadsheet quotation templates) Feedback from OXP Note: we don't add the menu in the Sales app menus because we don't want to add noise in there. It must be kept clean. Task: 4236559 Forward-Port-Of: odoo/enterprise#71363
Currently, an error was generated when the user tries to filter `Customer/Saleperson` in the subscription dashboard. error: `Invalid field sale.subscription.report.message_partner_ids in leaf ('message_partner_ids', 'in', [3])` This is because we have used fields 'message_partner_ids' and 'activity_user_id' to filter out records, but this field is not available in the model. This commit will fix the above issue by using fielels 'partner_id' and 'user_id' to fielter records. sentry-56
Original PR description
Currently, an error was generated when the user tries to filter `Customer/Saleperson` in the subscription dashboard.
error: `Invalid field sale.subscription.report.message_partner_ids in leaf ('message_partner_ids', 'in', [3])`
This is because we have used fields 'message_partner_ids' and 'activity_user_id' to filter out records, but this field is not available in the model.
This commit will fix the above issue by using fielels 'partner_id' and 'user_id' to fielter records.
sentry-5657224204
Forward-Port-Of: odoo/enterprise#72151
Forward-Port-Of: odoo/enterprise#7136013 changes
New functionality added to Odoo
Added new versions of Balance Sheet and Profit & Loss reports for Dutch companies that use account tags instead of account codes. This provides an alternative reporting method that better aligns with how Dutch businesses typically organize their chart of accounts, making financial reporting more flexible and user-friendly.
Original PR description
In the Netherlands localization, the Balance Sheet and Profit&Loss reports are only currently built on account codes. We want to add another version of the accounting reports that uses account tags. Community PR: odoo/odoo#157362 Task link: https://www.odoo.com/web#model=project.task&id=3794536 task-3794536
Enhancements to existing features
Odoo now supports Chinese Yuan (CNY) currency exchange rates from the Banxico provider. Previously, only USD, EUR, JPY, and GBP were available. This expansion allows businesses operating in or with China to access live currency conversion rates through the same Banxico data source.
Original PR description
Currently, Odoo supports several currencies (USD, EUR, JPY, GBP) for Banxico data parsing, but CNY (Chinese Yuan) is missing. This commit adds support for CNY in the list of currencies retrieved from Banxico’s API (through iap proxy). related pr: https://github.com/odoo/iap-apps/pull/912 task-4205613
Resolved issues and error corrections
This update corrects a problem with the Spanish VAT reporting model (Modelo 349) that was preventing accurate report generation. The changes include updated wording, a new calculation engine for rectifications, and fixes for data errors like negative amounts and incorrect discount calculations. This ensures accurate VAT reporting for Spanish businesses.
Original PR description
The model 349 wasn't working as expected, here are the points that have been changed: - Some keys were missing, in particular the keys R, D, and C. - Changed some wording of the report, such as replacing 'refunds' with 'rectifications'. - The biggest change was changing the way the lines are computed in the report. Before this commit, we used only the domain engine, but now we need to use a custom engine to handle the rectifications part. - Fixed some other bugs, like negative amounts which are not supposed to appear as the report only deals with positive values, and also ensured the discounts on the move lines are computed correctly. task-3992046 Forward-Port-Of: odoo/enterprise#65074
This update corrects a variable scope problem in the Peru electronic invoicing stock module that was causing incorrect values to be used in certain operations. The fix ensures that the correct data is referenced when processing stock movements for Peru's electronic document system, improving the accuracy of EDI compliance.
Original PR description
Forward-Port-Of: odoo/enterprise#72307
This update fixes how GST tax rates are calculated in Indian tax reports by properly tracking different tax types (IGST, CGST, SGST) separately before combining them. This ensures that businesses filing GST returns get accurate tax rate calculations, especially when multiple tax types apply to the same transaction.
Original PR description
In this PR: - Added a `rate_by_tax_tag` dictionary to store tax rates by tax type (IGST, CGST, SGST) at the line level. - Adjusted the logic to populate `gst_tax_rate` by summing the values from `rate_by_tax_tag`, ensuring accurate tax rate calculations when multiple tax types are involved. - This change improves handling of scenarios with different tax types and ensures consistent and accurate GST reporting.
This fix prevents automated email scanners from accidentally changing the status of signature requests. Previously, security scanners that check links in emails could trigger HTTP HEAD requests that would mark sign requests as ignored without any user action. Now the system properly handles these scanner requests so they don't affect the actual signature workflow.
Original PR description
Issue: Mail scanners can send HTTP HEAD requests to links contained in emails, which can change the state of a sign request without user action. Steps: - send a sign request - look in mailhog to get the notification mail - copy the link at the bottom of the mail and `curl --head <url>` - the sign request is now ignored opw-4217355
A test in the Planning module was failing when run on weekends or non-working days. This fix ensures the test runs consistently by simulating a working day environment, improving the reliability of automated testing.
Original PR description
Recently, this commit is merged: https://github.com/odoo/enterprise/pull/63002/commits/32776c6eb7ce1dafca2f8f4d0f825c19da641b71 the test case is failing in the weekends or non-working days, so I have used freeze_time to run it as if it were a working day. Forward-Port-Of: odoo/enterprise#72343
Fixed a bug in the manufacturing shop floor where the Quality Checks button would remain visible and cause errors even after quality checks were already completed. The system now properly updates its internal record reference when production data changes, ensuring the interface stays in sync with the actual production status.
Original PR description
## Steps to reproduce: 1. Create a quality control point for the operation type Manufacturing 2. Create a manufacturing order and plan it 3. Go to the Shop floor 4. Register the production & do the quality checks 5. The Quality Checks button is still there; clicking again displays a traceback because the quality checks are already done. ## Before this commit: Upon reloading the production, the new data is not propagated to `this.record`. ## After this commit: Change `this.record` when props are updated so it always contains the correct reference to the record. opw-4176393
This fix corrects a bug in the Brazilian electronic invoice system where messages were being posted to the wrong invoice. The issue was detected by an automated code quality check and has been resolved to ensure messages are properly associated with their correct invoices.
Original PR description
Spotted by runbot in master by the `self-in-iter` semgrep check.
Fixed an issue where authorized users couldn't duplicate document templates due to insufficient access rights. The system now properly handles permissions when creating a copy of a template, allowing users with the appropriate authorization to successfully duplicate templates without encountering errors.
Original PR description
To reproduce: ============= - log as admin and create a template on sign - give a user with **User : Own templates** authorization to the template - log as the user and try to use layout (from 3 dots in kanban view) -> access error Problem: ======== when duplicating the template we copy the original template, as the user does not have enough rights it leads to an access error Solution: ========= perform the copy as `sudo`, as the template won't be visible for the user if he is not authorized to see it. opw-4166973 Forward-Port-Of: odoo/enterprise#70496
This update corrects an incorrect reference in the US payroll accounting module. The system was looking for the wrong chart template name and has been fixed to use the correct generic chart of accounts template. This ensures proper accounting setup for US payroll operations.
Original PR description
Currently we search for the 'us' chart template but we should search for the 'generic_coa' instead. This commit corrects it. task-None
This update fixes an issue where demo project stages were being removed when they were already in use by other projects. By removing default stages before assigning new ones, the system now prevents conflicts between demo data from different modules, ensuring a smoother setup experience.
Original PR description
Remove the default stages before assigning new stages to the demo project. This update prevents the removal of stages that are being used in other projects, thereby avoiding conflicts with demo data from other modules.
This fix corrects a variable scope problem in the Peru EDI stock picking functionality. The issue was causing incorrect values to be used in the stock module's EDI processing, which could affect the accuracy of electronic document generation for inventory movements in Peru.