Daily updates from Odoo
Monday, October 21, 2024
33 changes
11 changes
Enhancements to existing features
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
21 changes
Enhancements to existing features
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
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#713601 change
Resolved issues and error corrections
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