Monday, October 21, 2024
45 changes · 18.0
Enhancements to existing features
This change updates the spreadsheet global filters area, which controls how users filter spreadsheet data. The available details are limited, but the change appears focused on improving or correcting the filter user interface so spreadsheet users have a smoother experience.
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
This update strengthens internal test tools for marketing automation so teams can verify email recipients, activity creation, and tracking behavior more accurately. It helps reduce false test failures and prepares the module for broader test coverage, with no direct change expected for end users.
Original PR description
Improve tooling defined in marketing automation, notably * add more verbose errors; * add parameters for trace check, notably to be less strict in case of duplicate-like traces; * improve tool methods generating activities; * assert some keys to be sure we effectively check what is intended; * add some docstrings while passing by; Task-2667099: [mail] Improve default template values Prepares Task-4224145: [marketing_automation] Improve test coverage
Resolved issues and error corrections
This fix adjusts the left spacing of the chatter area when it appears inside a chat window. It makes the layout look cleaner and more consistent, improving readability without changing functionality.
Original PR description
Before / After <img width="366" alt="Screenshot 2024-10-21 at 20 45 32" src="https://github.com/user-attachments/assets/ece48e77-cb42-4442-8ff1-fc79743ac718"> <img width="369" alt="Screenshot 2024-10-21 at 20 43 38" src="https://github.com/user-attachments/assets/542034a3-1e01-4222-ad18-edd77090f41d">
Miscellaneous changes
When purchasing event tickets in foreign currencies such as JPY or CAD, Odoo was incorrectly applying small discounts to products even when no discount was intended. This behavior affected the Event Sales module, where the wrong price was shown on the product page. For Odoo 17.4+, this issue displayed as a strikethrough on the correct price next to a mistakenly discounted price. For versions prior to 17.4, only the incorrect discounted price was displayed without a strikethrough. This bug onl
Original PR description
When purchasing event tickets in foreign currencies such as JPY or CAD, Odoo was incorrectly applying small discounts to products even when no discount was intended. This behavior affected the Event…
When purchasing event tickets in foreign currencies such as JPY or CAD, Odoo was incorrectly applying small discounts to products even when no discount was intended. This behavior affected the Event Sales module, where the wrong price was shown on the product page. For Odoo 17.4+, this issue displayed as a strikethrough on the correct price next to a mistakenly discounted price. For versions prior to 17.4, only the incorrect discounted price was displayed without a strikethrough. This bug only occurred when the Event Registration product price was set to a value different from the price defined in the Event record. While this bug is present in 16.0 onwards, the logic causing the issue has been refactored and will require a separate fix. Steps to reproduce the issue: 1. Create Pricelists for additional currencies (CAD, JPY) with empty rules and enable the “Selectable” checkbox for Ecommerce. 2. Set currency rates to 133.6200 for JPY and 1.338800 for CAD to replicate the conditions when the bug was found. 3. Create an Event. 4. Create an Event Registration Ticket, ensuring the linked Event Registration product price is $1.00 and the price in the event view is set to $30.00. 5. Visit the Event page on the website and attempt to purchase a ticket. Switch between currencies (JPY, CAD) to observe the issue. 6. Using JPY at the conversion rate of 133.6200, the expected converted price for a $30.00 ticket should be ¥4009, but Odoo calculates the price as discounted to ¥3997. 7. With CAD at 1.338800, the correct converted price should be $40.16 CAD, but the price is instead calculated as $40.12 CAD. 8. On 17.4+, the original and correct prices will display as a strikethrough discount. Cause of the issue: The method _get_contextual_discount in product_product.py was comparing a rounded lst_price to an unrounded contextual price, leading to a tiny discrepancy being mistaken as a discount. The bug occurred because the rounding of the lst_price did not match the rounding of the contextual price. While this method is defined in the product module, it only is used by the event_booth and event_booth_sale modules. Solution: The fix ensures that both operands are not rounded before comparison. Now, the _get_contextual_discount method does not round both the lst_price and the contextual price, preventing the calculation of an erroneous discount. opw-4213704 Forward-Port-Of: odoo/odoo#182695
Quarter filter values in spreadsheets now stay as Q1 to Q4 regardless of the user's language. This prevents reports and accounting formulas from breaking when users work in languages such as French.
Original PR description
Currently, when using a language that translates the abbreviation of quarters (Q) to anything else, the formula `=filter.value(...)` would return the translated version, which then could not be used on other formulas like `=odoo.balance`, this can be observed by opening the Finance/accounting dashboard while in french and selecting a filter in quarter. After this fix, the formula filter.value will always return Q1 to Q4 for quarter names. Task: [4274741](https://www.odoo.com/odoo/project/2328/tasks/4274741) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo no longer requires an extra developer-only package when running in production. This simplifies installation and avoids pulling in software that is only needed for development work.
Original PR description
The typing_extensions is for dev only and should not be required to run Odoo. Also see #184452
This update cleans up how mail sub-channels are prepared and stored, reducing the chance of inconsistent channel behavior. It also strengthens automated checks so future issues in sub-channel search are easier to catch and diagnose.
Original PR description
- `_to_store` should not be called manually - `Store` constructor already adds the record - code should not assume order of channels in store insert - tour is made more robust and easier to debug by adding extra asserts
This fix updates point-of-sale loyalty test flows so reward pop-ups can be closed after checking that the reward button is highlighted. It helps keep automated checks reliable and reduces the risk of loyalty reward issues going unnoticed.
Original PR description
In this commit, we add the possibility to close the modal after checked that the button reward is higlighted in modal. Also, we fix all tours were the modal has to be closed before continue the tour. 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 misaligned translation controls in quotation template descriptions and other multi-language fields. This makes translated content easier to edit and gives users a cleaner, more consistent form layout.
Original PR description
**Version**: 18.0 **Steps to Reproduce**: 1. Navigate to the Subscription module. 2. Open the quotation template form view. 3. Click on the description field in the lines. **Issue 1**: The position of the translation field in the description lines appears misaligned. **Solution 1**: Align the flex items along the baseline of the text to ensure proper alignment of the translation field. --- **Steps to Reproduce**: 1. Install the Sign, Project, and Web Editor modules. 2. Enable multi-language support. **Issue 2**: The translation button in multi-language support is misaligned due to improper absolute positioning within a `div` tag. **Cause**: The button is positioned using `absolute`, which disrupts alignment. **Solution 2**: Remove the `absolute` positioning to fix the alignment issue and ensure proper placement of the translation button.
This fix ensures Brazilian tax settings correctly mark taxes as included in prices where required. It helps keep invoices and accounting calculations aligned with local tax expectations after an underlying configuration change.
Original PR description
Price inclusion wasn't set on taxes in Brazil because the inverse on price_include was removed [1]. This adapts the csv to use price_include_override instead. [1] https://github.com/odoo/odoo/pull/178571 opw-4239515
The mobile message composer no longer shows extra empty space below the typing area on most phones. This keeps the messaging interface cleaner while preserving the intended spacing for iOS devices.
Original PR description
Purpose of this commit: Previously, there was unnecessary space below the compose area in the mobile view. This space was generally present on all phones but was intended only for iOS devices. This commit adjusts the layout accordingly task-4207316
This fix prevents an error when users add a serial number to maintenance equipment before a name is set. It keeps equipment creation and product information editing working smoothly when only the Maintenance app is installed.
Original PR description
**Steps to reproduce the bug:**
- Create a new database and install only the Maintenance app.
- Go to Equipment and create a new one.
- Navigate to the product information.
- Set a "Serial Number"
Problem:
A traceback is triggered when we try to compute the field display_name
using `self.name + self.serial_no`, but `self.name`` is not yet set
and is therefore False:
```
record.display_name = record.name + '/' + record.serial_no
~~~~~~~~~~~~^~~~~
TypeError: unsupported operand type(s) for +: 'bool' and 'str'
```
opw-[4261222](https://www.odoo.com/web#id=4261222&view_type=form&model=project.task)The pricelist report now works correctly when users click the plus button to adjust quantities. This fixes an error that could block users from changing quantities in the report after a platform change removed an older page dependency.
Original PR description
Versions -------- - 18.0 - master Steps ----- 1. Go to product view; 2. using the actions button, go to Pricelist Report; 3. click on the "+" button of the Quantities selector. Issue ----- ReferenceError: Can't find variable: $ Cause ----- jQuery's `$` selector has been disabled there at some point between 17.4 & 18.0. This wasn't caught by the pricelist report's unit tests, as jQuery is made available in that context. Solution -------- Replace the jQuery selector with `ev.target.previousSibling`, which points to the same `input` element. opw-4230836
The update removes unnecessary warning styling from invoice lines where products are not required, reducing confusion for users. Sales documents still show relevant warnings, but down payment lines are now excluded when the warning is not needed.
Original PR description
Purpose of this commit to remove warning class on product section and note widget when it's not a necessary. This commit move warning class code from account to sale as product field is not require on invoice lines and user can confirm invoice without product so there is no need to add warning class on invoice also add condition in sale to not display warning class on down payment lines.
This fix makes the test mock server return only the data that the real server would provide when no specific fields are requested. This helps prevent tests from passing for the wrong reasons and reduces the risk of client data being overwritten during messaging, live chat, ratings, and web test scenarios.
Original PR description
\* = im_livechat, rating, web Similar as python code, where _read_format returns only id when no field names are provided. Returning more fields than expected might create issues (race condition of server data overriding client data: eg. rtc session join should not return extra fields), or simply make the test pass due to the extra data when in reality those data are not present. Back-port from https://github.com/odoo/odoo/pull/183102
Custom newsletter popups saved for later use now show their preview when selected from the website editor's custom snippets. This helps users identify and reuse popup designs reliably instead of seeing an empty or missing preview.
Original PR description
Steps to Reproduce : 1. Go to Website --> Drop a newsletter popup snippet 2. Saved the snippet for later use 3. Drag and drop the Custom Category snippet -> In that you will find no preview of the Newsletter pop-up. Prior to this fix, to prevent pop-up snippets (like the newsletter) from becoming invisible, we saved the element before invoking cleanForSave. However, this approach specifically targeted the standard pop-up (not newsletter popup) snippet only. With this commit, we adapt the condition to target the newsletter and other pop-up snippets, ensuring proper visibility across all popup types during snippet previews. task-4251878
The Chilean electronic invoicing module now checks shared certificate settings correctly even before a company record is saved. This prevents incorrect validation behavior and helps keep company certificate setup reliable.
Original PR description
Resolve an issue where the compute method `_compute_is_there_shared_cert` was triggered before the record was saved, causing the domain to be incorrectly constructed with `company.id`. Replacing `company.id` with `company._origin.id` to ensure the correct domain is applied by accessing the original record instance.
This fix prevents users from creating an incomplete private key directly from settings, which could cause certificate request generation to fail. Businesses using Argentine electronic invoicing get a smoother setup process with fewer blocking errors.
Original PR description
Currently, an error occurs when generating a certificate request, and the private key is available but it has no content. Step to produce: - Install the ```l10n_ar_edi``` module. - Go to the current…
Currently, an error occurs when generating a certificate request, and the private key is available but it has no content. Step to produce: - Install the ```l10n_ar_edi``` module. - Go to the current company, and add CUIT(vat) and city if it is not available. - Go to Settings, and create a quick 'Private Key' which in the Argentinean Localization section. - And click on ```Generate Request``` ```TypeError: argument should be a bytes-like object or ASCII string, not 'bool'``` An error occurs because a user can directly create a private key without adding content in it which is required in 'certificate.key' model, so an error occurs when the system tries to decode the content of the private key at [1], but it is not available. Link [1]: https://github.com/odoo/enterprise/blob/64d3dfdcc4c5c39ef68d94fbfd972a4930283b66/l10n_ar_edi/models/certificate.py#L28 To resolve this issue, remove the quick 'create' option for a private key from settings form view. Sentry-5999498377
The translation button in Web Studio now appears correctly aligned when multiple languages are enabled. This improves the form editing experience by keeping controls visually consistent and easier to use.
Original PR description
Version: - 18.0 Steps to Reproduce: - Install the sign, project, and web_editor modules. - Enable multi-language support. Issue: - The translation button is misaligned. Cause: - The button is positioned using absolute within a div tag, which causes the alignment issue. Solution: - Remove the absolute positioning to fix the alignment.
Fixed an issue that could interrupt ISO 20022 payment processing when payments involved more than one currency. This prevents an error during payment file generation and helps accounting teams complete exports reliably.
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
On the website, the title of the ProductConfigatorDialog is not translated into any language. This is because only "frontend modules" translations are fetched in the context of the website. The title of the dialog is defined in the "sale" module, which is not a frontend module, so the translation is missing. This commit solves the problem by redefining the string to translate in the website_sale module. Task-4182798 Forward-Port-Of: odoo/odoo#184500
Original PR description
On the website, the title of the ProductConfigatorDialog is not translated into any language. This is because only "frontend modules" translations are fetched in the context of the website. The title of the dialog is defined in the "sale" module, which is not a frontend module, so the translation is missing. This commit solves the problem by redefining the string to translate in the website_sale module. Task-4182798 Forward-Port-Of: odoo/odoo#184500
The project's visibility should be tracked in the chatter of the project, but not in the tasks chatter. This PR will set the tracking of the "project_privacy_visibility" field to False, so that it is no longer displayed in the tasks chatter. task-4210181 Forward-Port-Of: odoo/odoo#184268 Forward-Port-Of: odoo/odoo#181873
Original PR description
The project's visibility should be tracked in the chatter of the project, but not in the tasks chatter. This PR will set the tracking of the "project_privacy_visibility" field to False, so that it is no longer displayed in the tasks chatter. task-4210181 Forward-Port-Of: odoo/odoo#184268 Forward-Port-Of: odoo/odoo#181873
Steps to reproduce: - install project app - create project without any task - change the language Issue: The helper string is not being translated. Reason: This issue occurs because the existing context is lost, particularly the `lang` variable, which impacts the translation functionality. Solution: In this commit, we have updated the method from with_context({'active_id': self.id}) to with_context(active_id=self.id). This fix ensures that the previous context is ret
Original PR description
Steps to reproduce:
- install project app
- create project without any task
- change the language
Issue: The helper string is not being translated.
Reason:
This issue occurs because the existing context is lost, particularly
the `lang` variable, which impacts the translation functionality.
Solution:
In this commit, we have updated the method from
with_context({'active_id': self.id}) to with_context(active_id=self.id).
This fix ensures that the previous context is retained.
task-3940540
Forward-Port-Of: odoo/odoo#184255
Forward-Port-Of: odoo/odoo#170720No description available.
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 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
**Current behavior before PR:** When link-preview is done on public channel invitation links it posts a guest joined the channel message in the public channel. **Desired behavior after PR is merged:** now we are ignoring public channel invitations links for link-preview, so it does not post guest joined the channel backported PR: https://github.com/odoo/odoo/pull/178932 which handle's ignore link-preview. task-4083161 --- I confirm I have signed the CLA and read the PR guid
Original PR description
**Current behavior before PR:** When link-preview is done on public channel invitation links it posts a guest joined the channel message in the public channel. **Desired behavior after PR is merged:** now we are ignoring public channel invitations links for link-preview, so it does not post guest joined the channel backported PR: https://github.com/odoo/odoo/pull/178932 which handle's ignore link-preview. task-4083161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184301 Forward-Port-Of: odoo/odoo#180187
Steps to reproduce : ------------------------- - Install the pos_restaurant module. - Create a restaurant with no floors. - Open Restaurant and click on edit plan button. - Try to do anything from editing options. Issue : -------- As there are no floor exists neither of the options works and some will give tracebacks. Cause : --------- Without any floor we were trying to change properties of the floor. Fix : ---- We will check if any floor exists for that config then only the
Original PR description
Steps to reproduce : ------------------------- - Install the pos_restaurant module. - Create a restaurant with no floors. - Open Restaurant and click on edit plan button. - Try to do anything from editing options. Issue : -------- As there are no floor exists neither of the options works and some will give tracebacks. Cause : --------- Without any floor we were trying to change properties of the floor. Fix : ---- We will check if any floor exists for that config then only the edit plan button will be visible. Forward-Port-Of: odoo/odoo#184231 Forward-Port-Of: odoo/odoo#182702
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
This change adds an Odoo code submodule to the repository configuration. It appears to be a repository setup change rather than a direct change to business functionality, so day-to-day users should not see an immediate product impact.
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
This change updates a GitHub workflow used for repository maintenance rather than changing Odoo features used by customers. It helps keep project automation aligned with the latest branch state, with no expected impact on day-to-day business operations.
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
revert commit 30c561b422d58d7622f7ee173fae2f8158a14657 because it broke existing optimization and users were unable to access the website instead the functionality was moved to `_get_pl_partner_order()` because it's a cached method and the extra search added by the `.sorted()` wouldn't be an issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183805
Original PR description
revert commit 30c561b422d58d7622f7ee173fae2f8158a14657 because it broke existing optimization and users were unable to access the website instead the functionality was moved to `_get_pl_partner_order()` because it's a cached method and the extra search added by the `.sorted()` wouldn't be an issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183805
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
# Issue: When creating a vendor bill for a non EU partner, setting the tax to "22% G RC (Goods)" and generating the XML file, checking the generated XML file gives the error: "Tipo Documento must not be empty." # Steps to reproduce: - create a vendor bill with a non EU partner - add a product with tax "22% G RC (Goods)" - post the bill - click Send Tax Integration - check the generated XML file using an online checker like www.fatturacheck.it - it will show the error "Tipo Documento mu
Original PR description
# Issue: When creating a vendor bill for a non EU partner, setting the tax to "22% G RC (Goods)" and generating the XML file, checking the generated XML file gives the error: "Tipo Documento must not…
# Issue: When creating a vendor bill for a non EU partner, setting the tax to "22% G RC (Goods)" and generating the XML file, checking the generated XML file gives the error: "Tipo Documento must not be empty." # Steps to reproduce: - create a vendor bill with a non EU partner - add a product with tax "22% G RC (Goods)" - post the bill - click Send Tax Integration - check the generated XML file using an online checker like www.fatturacheck.it - it will show the error "Tipo Documento must not be empty." # Solution: - The document type is usually computed. However, in this specific case, it cannot be computed because it does not meet any of the conditions in the computation logic. Additionally, there is no safeguard to prevent the generation of the XML file if the document type is not set. - A check has been added to prevent XML generation when the document type is not set, ensuring the document type is always correctly provided before XML generation. opw-4182531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183834 Forward-Port-Of: odoo/odoo#180364
Issue: ====== - The border-color of the table is different in light mode and dark mode. - convert_inline_test which have the border-color fails because it depends if we are in enterprise or community. Issue [1]. Steps to reproduce the issue: ============================= - Go to any record with chatter - Switch dark mode - Add a table - Log it - Switch light mode - The border-color is different than a table added in light mode. Origin of the issue: ==================== We al
Original PR description
Issue: ====== - The border-color of the table is different in light mode and dark mode. - convert_inline_test which have the border-color fails because it depends if we are in enterprise or…
Issue: ====== - The border-color of the table is different in light mode and dark mode. - convert_inline_test which have the border-color fails because it depends if we are in enterprise or community. Issue [1]. Steps to reproduce the issue: ============================= - Go to any record with chatter - Switch dark mode - Add a table - Log it - Switch light mode - The border-color is different than a table added in light mode. Origin of the issue: ==================== We already have a commit [2] that removes the border-colors from the cssRules since it really depends on the mode. After this [3] we forced to apply the border-color from the computed value which will be wrong. Solution: ========= We remove the border-color from the forced styles. [1]: https://runbot.odoo.com/web#id=103155&view_type=form&model=runbot.build.error&menu_id=405&cids=1 [2]: https://github.com/odoo/odoo/commit/16ab970fa33119a4fc1a9c5dd249ca467ff3b2c8 [3]: https://github.com/odoo/odoo/commit/1e654e8f7e0a403a25b595be410614dfc8a69179 Forward-Port-Of: odoo/odoo#184251
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#184277The **`btw_X0`** tax was updated [Here](https://github.com/odoo/odoo/commit/02ccb58401a45528adb77c768318c9f6dfdf05b6#diff-de6184d4eb5e7e2450afafb9d22046721e4931216a636ec6b945ea27a1488591L391). Despite this update, some customers are still using the original tax, which was mapped during migration [Here](https://github.com/odoo/odoo/blob/17.0/addons/l10n_nl/migrations/3.3/post-migrate_update_taxes.py#L22). As a result of these changes, the customers are unable to view the tax report correctly as i
Original PR description
The **`btw_X0`** tax was updated [Here](https://github.com/odoo/odoo/commit/02ccb58401a45528adb77c768318c9f6dfdf05b6#diff-de6184d4eb5e7e2450afafb9d22046721e4931216a636ec6b945ea27a1488591L391).…
The **`btw_X0`** tax was updated [Here](https://github.com/odoo/odoo/commit/02ccb58401a45528adb77c768318c9f6dfdf05b6#diff-de6184d4eb5e7e2450afafb9d22046721e4931216a636ec6b945ea27a1488591L391). Despite this update, some customers are still using the original tax, which was mapped during migration [Here](https://github.com/odoo/odoo/blob/17.0/addons/l10n_nl/migrations/3.3/post-migrate_update_taxes.py#L22). As a result of these changes, the customers are unable to view the tax report correctly as it appeared in the production environment. To address this issue, I have added the XML ID of the tax to map the old tax. opw-[4091389](https://www.odoo.com/odoo/project/70/tasks/4091389) upg-[1874716](https://upgrade.odoo.com/web#id=1874716&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form) 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#182937
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
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
Before this commit, tests were skipped without using self.skipTest which is not a good practice. Moreover, assertAlmostEqual was not properly used in an older version. ssertAlmostEqual should be used to compare amounts but it can be called with place, delta and message. The named argument should be used correctly. See https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertAlmostEqual The msg parameter should be explicitely named. Runbots: https://runbot.odoo.com/web
Original PR description
Before this commit, tests were skipped without using self.skipTest which is not a good practice. Moreover, assertAlmostEqual was not properly used in an older version. ssertAlmostEqual should be used…
Before this commit, tests were skipped without using self.skipTest which is not a good practice. Moreover, assertAlmostEqual was not properly used in an older version. ssertAlmostEqual should be used to compare amounts but it can be called with place, delta and message. The named argument should be used correctly. See https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertAlmostEqual The msg parameter should be explicitely named. Runbots: https://runbot.odoo.com/web/#id=102838&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102837&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102836&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102835&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102834&view_type=form&model=runbot.build.error&menu_id=405&cids=1 Forward-Port-Of: odoo/enterprise#71974
This commits add the first test for the fiskaly module. This tests mock all the call made to the api so that we can make sure the module is working correctly. opw-4171641 Forward-Port-Of: odoo/enterprise#70369
Original PR description
This commits add the first test for the fiskaly module. This tests mock all the call made to the api so that we can make sure the module is working correctly. opw-4171641 Forward-Port-Of: odoo/enterprise#70369
There is a bug with traceback while going to "Accounting / Configuration / Settings" with "Spanish (Latin America)" language selected on user config (install l10n_ar_edi module and take position on company "(AR) Responsable Inscripto"). This pr fixes it. The bug was introduced on this pr https://github.com/odoo/enterprise/pull/71027 . Bug with traceback: UncaughtPromiseError > OwlError Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property) OwlError: An
Original PR description
There is a bug with traceback while going to "Accounting / Configuration / Settings" with "Spanish (Latin America)" language selected on user config (install l10n_ar_edi module and take position on…
There is a bug with traceback while going to "Accounting / Configuration / Settings" with "Spanish (Latin America)" language selected on user config (install l10n_ar_edi module and take position on company "(AR) Responsable Inscripto"). This pr fixes it. The bug was introduced on this pr https://github.com/odoo/enterprise/pull/71027 .
Bug with traceback:
UncaughtPromiseError > OwlError
Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property)
OwlError: An error occured in the owl lifecycle (see this Error's "cause" property)
Error: An error occured in the owl lifecycle (see this Error's "cause" property)
at handleError (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:916:101)
at App.handleError (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1548:29)
at Fiber._render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:941:19)
at Fiber.render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:939:6)
at ComponentNode.initiateRender (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1007:47)
Caused by: EvalError: Can not parse python expression: (bool(“l10n_ar_afip_ws_crt”))
Error: Invalid expression
EvalError: Can not parse python expression: (bool(“l10n_ar_afip_ws_crt”))
Error: Invalid expression
at evaluateExpr (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:3050:128)
at SettingsFormRenderer.evaluateBooleanExpr (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:3054:8)
at SettingsFormRenderer.slot533 (eval at compile (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1502:374), <anonymous>:9209:26)
at callSlot (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1108:25)
at SearchableSetting.template (eval at compile (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1502:374), <anonymous>:56:13)
at Fiber._render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:940:96)
at Fiber.render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:939:6)
at ComponentNode.initiateRender (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1007:47)
Ticket Adhoc side: 81698
Task latam side: 1279
Forward-Port-Of: odoo/enterprise#72155Steps 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#71842
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#71842
task-4182770 Forward-Port-Of: odoo/enterprise#70570
Original PR description
task-4182770 Forward-Port-Of: odoo/enterprise#70570
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