Thursday, August 29, 2024
40 changes · saas-17.4
Enhancements to existing features
Industry module knowledge articles are now shown in the language of the user installing the module. This improves localization so users receive setup guidance they can understand immediately.
Original PR description
In industry modules, the knowledge article should be translated in the language of the user installing it. But the `body` of the article is not translatable. This commit forces the rendering of the article in the user language. task-4063061
Resolved issues and error corrections
This change corrects an automated website setup test so it looks in the right place for a language selection popup. It helps keep website creation checks stable and reduces false test failures without changing the user-facing website experience.
Original PR description
[FIX] website: avoid to check for duplicated modal Since [1], the `extra_trigger` key has been removed from the tests. Due to it, the `automatic_editor_on_new_website` test fails as the `.modal div[name="lang_ids"]...` selector is used in a `trigger` element and not in `extra_trigger` anymore. Indeed, at the contrary of `extra_trigger`, the `trigger` element directly searches in the main modal, leading the `.modal` in the selector to be duplicated. To solve the problem, `in_modal: false` is added to indicate to the system that the search does not have to be done in the main modal. [1]: https://github.com/odoo/odoo/commit/68a92cb0dd2ea06102df7cb44ae9121a61575ae1 runbot-69009
Features or functions removed from Odoo
An outdated internal test for scheduled jobs was removed because it no longer matched the current system behavior and was rarely run. This keeps the test suite cleaner without changing how users interact with Odoo.
Original PR description
The third parameter to the cron callback was removed in 7af878d1212e9b249eb9b2278769265ec7cbfa13. This test was likely missed because it's `-standard` and `database_breaking` so not sure it's ever run.
Miscellaneous changes
The 1.25% WH tax was incorrectly configured, it's an ISR withholding tax, not IVA. task-4101407 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177113
Original PR description
The 1.25% WH tax was incorrectly configured, it's an ISR withholding tax, not IVA. task-4101407 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177113
Saving a map block on an event registration page no longer triggers an error that blocks further editing. This keeps website editors from getting stuck when adding location information to event sign-up pages.
Original PR description
In the register page of the events, when you add a map block, and save it, you'll get an UncaughtPromiseError. To Reproduce on Runbot: 1. Go to the events page. 2. Click on one of the events. 3. Go to /register page 4. Go to Editor and add a map block 5. Save it Upon saving, you'll encounter the error, and further cannot make any edits. The issue is due to calling _manageIframeSrc on the element where there is no iframeEl defined yet. So, we'll add the iframeEl first and call _manageIframeSrc. opw-4104300
This fixes an issue in guided website tours where the cursor appeared outside the snippet area during drag-and-drop steps. The change helps automated tours and demonstrations behave correctly when users interact with website editor snippets.
Original PR description
Fix the tour cursor being displayed out of the website snippets when the step is to drag and drop a snippets from the website editor. Adding the '.o_we_draggable' class to the tour compiler so that the drag event is correctly handled in the editor. Related commit: odoo/odoo@5a990d8d8ba2ec2999f84d2f1dae7aeec0f2d9b5 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The chat message editor is now easier to use when editing an existing message in a small chat window. Spacing was reduced and action buttons were moved so users have more room to type and review their changes.
Original PR description
In chat window, editing message composer is too narrow. This commit fixes the issue as follow: 1. Reduce spacing in message and composer while editing a message 2. Move actions to bottom Before / After <img width="363" alt="004-before" src="https://github.com/user-attachments/assets/ef80af40-710c-4de2-a5ed-185a68580ffc">  https://github.com/odoo/enterprise/pull/68573
This update fixes an internal employee leave test so it matches a recent naming change in the allocation workflow. It helps keep automated checks reliable and reduces false failures in quality validation, with no direct change for end users.
Original PR description
Since pr https://github.com/odoo/odoo/pull/158829 holiday type has been moved to a wizard and it's name changed to allocation_mode. This pr corrects the test where we were using old naming. runbot issue-73015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could stop users from opening the Calendar when their profile had no timezone selected. The calendar now handles a missing timezone safely, improving reliability for users with incomplete profile settings.
Original PR description
When customer tries to open ```calendar``` without timezone, a traceback will appear. Steps to reproduce the error: - Go to My profile > In timezone, Select empty timezone - Install ```hr_calendar```…
When customer tries to open ```calendar``` without timezone,
a traceback will appear.
Steps to reproduce the error:
- Go to My profile > In timezone, Select empty timezone
- Install ```hr_calendar```
- Open ```Calendar```
Traceback:
```
AttributeError: 'bool' object has no attribute 'upper'
File "odoo/http.py", line 2373, in __call__
response = request._serve_db()
File "odoo/http.py", line 1903, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1966, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1933, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2177, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 459, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/hr_calendar/models/res_partner.py", line 99, in get_working_hours_for_all_attendees
return self._interval_to_business_hours(reduce(Intervals.__and__, schedule_by_partner.values()))
File "addons/hr_calendar/models/res_partner.py", line 105, in _interval_to_business_hours
"startTime": interval[0].astimezone(timezone(self.env.user.tz)).strftime("%H:%M"),
File "odoo/tools/_monkeypatches_pytz.py", line 129, in timezone
return original_pytz_timezone(name)
File "__init__.py", line 183, in timezone
if zone.upper() == 'UTC':
```
https://github.com/odoo/odoo/blob/3345a0b61630ee1ac11045b09717167744265a24/addons/hr_calendar/models/res_partner.py#L105
When user has an empty timezone and tries to open the ```calendar``` app,
It will give the traceback at the above line.
sentry-5707574801
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe message editing area in WhatsApp conversations is now wider, making it easier to review and update longer messages. This fixes a usability issue that could make editing feel cramped and less efficient.
Original PR description
https://github.com/odoo/odoo/pull/177084
Users editing a room booking will no longer see an incorrect warning that the booking was changed or deleted by someone else. The warning is now reserved for real conflicts caused by another user, reducing confusion and interruption during normal booking edits.
Original PR description
Purpose: ------- Currently when editing a booking from the frontend form view, a warning notification is shown, indicating that the booking being edited has been updated or deleted. This notification should only be shown when the booking being edited has been updated or deleted by another user (because in that case the user will be forced to leave the edition view without doing anything). Task-4104748
This fix ensures certain intercompany stock and purchase settings remain read-only where intended. It prevents configuration changes from being incorrectly passed through to company records, reducing the risk of inconsistent warehouse, delivery, or receipt behavior between companies.
Original PR description
Because of https://github.com/odoo/odoo/blob/e1fb54cb3d5db9c906946fa11ff49c1ca86d3722/odoo/fields.py#L620-L621, writing on a field which is `related` and `readonly=False` will effectively forward the new value on the parent field if this one is also `readonly=False`. This was not the case for fields + `intercompany_warehouse_id` + `intercompany_sync_delivery_receipt` + `intercompany_receipt_type_id` defined in res_company and related in res_config_setting As they are computed fields which implies that are `readonly=True` by default.
Steps to reproduce the bug: - Create two products tracked by Serial Number (SN): “P1” and “P2”. - Update their quantities. - Create a delivery with one unit of each. - Mark it as "To Do". - Go to the detailed operation. - Attempt to edit the "pick from" (`quant_id`) or the serial number of P1. - Save. Problem: The product “P2” is incorrectly updated to “P1”. opw-3995450 Forward-Port-Of: odoo/odoo#177711
Original PR description
Steps to reproduce the bug: - Create two products tracked by Serial Number (SN): “P1” and “P2”. - Update their quantities. - Create a delivery with one unit of each. - Mark it as "To Do". - Go to the detailed operation. - Attempt to edit the "pick from" (`quant_id`) or the serial number of P1. - Save. Problem: The product “P2” is incorrectly updated to “P1”. opw-3995450 Forward-Port-Of: odoo/odoo#177711
This PR fixes issues linked to the fact that the sliding of carousels is an asynchronous operation. Indeed, the options and the history of the carousels were not taking this into account. - [FIX] website: always set the first carousel slide as the active one - [FIX] website: make the `Carousel` options atomic - [FIX] website: prevent recording sliding of some carousels in history - [FIX] website: add a tour to test the `Carousel` options task-3744613 related to opw-3675019 Forward-Po
Original PR description
This PR fixes issues linked to the fact that the sliding of carousels is an asynchronous operation. Indeed, the options and the history of the carousels were not taking this into account. - [FIX] website: always set the first carousel slide as the active one - [FIX] website: make the `Carousel` options atomic - [FIX] website: prevent recording sliding of some carousels in history - [FIX] website: add a tour to test the `Carousel` options task-3744613 related to opw-3675019 Forward-Port-Of: odoo/odoo#177967 Forward-Port-Of: odoo/odoo#153892
…number Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about t
Original PR description
…number Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial move. Instead of using a context or adding new fields, we add a hook in which we can specify certain conditions to bypass the document check/formatting for localisations. opw-3993305 Forward-Port-Of: odoo/odoo#177974 Forward-Port-Of: odoo/odoo#174950
Description of the issue/feature this PR addresses: Add DUA exempt tax and its mapping Current behavior before PR: Only one way to manage DUA Desired behavior after PR is merged: Added an alternative to manage DUA with an innocuous tax and its mapping --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167545 Forward-Port-Of: odoo/odoo#165912
Original PR description
Description of the issue/feature this PR addresses: Add DUA exempt tax and its mapping Current behavior before PR: Only one way to manage DUA Desired behavior after PR is merged: Added an alternative to manage DUA with an innocuous tax and its mapping --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167545 Forward-Port-Of: odoo/odoo#165912
Steps to reproduce: - Install `l10n_{ar,pe}_pos` and `l10n_ec_edi_pos` - Enable "Use QR Code on ticket" - Make an order and validate it inside the POS - Open in an incognito window the link given by the QR Code Issues: Internal error, the cause is the multiple else that are added to the `get_info_div` block. This problem is blocking #175591 and #175593 related enterprise PR: https://github.com/odoo/enterprise/pull/68432 Forward-Port-Of: odoo/odoo#176746
Original PR description
Steps to reproduce:
- Install `l10n_{ar,pe}_pos` and `l10n_ec_edi_pos`
- Enable "Use QR Code on ticket"
- Make an order and validate it inside the POS
- Open in an incognito window the link given by the QR Code
Issues:
Internal error, the cause is the multiple else that are added to the `get_info_div` block.
This problem is blocking #175591 and #175593
related enterprise PR: https://github.com/odoo/enterprise/pull/68432
Forward-Port-Of: odoo/odoo#176746**Description of the issue/feature this PR addresses:** There is a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment with "Checks" Payment Method. **Steps to reproduce:** 1) With a database in v16 onwards, install the account_check_printing module. 2) Go to "Accounting / Configuration / Accounting / Journals" and create a new journal bank with more than one outgoing payment with "Checks" Payment Method. 3
Original PR description
**Description of the issue/feature this PR addresses:** There is a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment…
**Description of the issue/feature this PR addresses:** There is a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment with "Checks" Payment Method. **Steps to reproduce:** 1) With a database in v16 onwards, install the account_check_printing module. 2) Go to "Accounting / Configuration / Accounting / Journals" and create a new journal bank with more than one outgoing payment with "Checks" Payment Method. 3) Go to "Accounting / Vendor / Payments" and create a new payment with journal created on step 1 and "Checks" payment method and confirm. 4) Go to "Accounting" and on "Accounting dashboard" click on "Check to print" on Journal created on step 1 and then a bug with traceback is raised. **Current behavior before PR:** There is a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment with "Checks" Payment Method. **Desired behavior after PR is merged:** There is not a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment with "Checks" Payment Method. **Video/Screenshot link:** https://drive.google.com/file/d/1r6A3uMkFv2nIDZ1HYJLgj6e18pNH1P67/view Ticket Adhoc side: 75606 Task latam: 1217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168383
Currently an error occurs when a user adds a character in the `Model Year` of fleet vehicles. Stack Trace: ``` ValueError: invalid literal for int() with base 10: '2016/2017' File "odoo/http.py", line 2373, in __call__ response = request._serve_db() File "odoo/http.py", line 1903, in _serve_db return self._transactioning( File "odoo/http.py", line 1966, in _transactioning return service_model.retrying(func, env=self.env) File "odoo/service/model.py", line 134, in
Original PR description
Currently an error occurs when a user adds a character in the `Model Year` of fleet vehicles. Stack Trace: ``` ValueError: invalid literal for int() with base 10: '2016/2017' File "odoo/http.py",…
Currently an error occurs when a user adds a character in the `Model Year` of fleet vehicles.
Stack Trace:
```
ValueError: invalid literal for int() with base 10: '2016/2017'
File "odoo/http.py", line 2373, in __call__
response = request._serve_db()
File "odoo/http.py", line 1903, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1966, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1933, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2177, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 459, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 73, in web_save
self = self.create(vals)
File "<decorator-gen-41>", line 2, in create
File "odoo/api.py", line 421, in _model_create_multi
return create(self, [arg])
File "addons/mail/models/mail_thread.py", line 268, in create
threads = super(MailThread, self).create(vals_list)
File "<decorator-gen-0>", line 2, in create
File "odoo/api.py", line 422, in _model_create_multi
return create(self, arg)
File "odoo/models.py", line 4768, in create
records = self._create(data_list)
File "odoo/models.py", line 4935, in _create
colval = field.convert_to_column(stored[fname], self, stored)
File "odoo/fields.py", line 1491, in convert_to_column
return int(value or 0)
```
With the recently code change with https://github.com/odoo/odoo/commit/d69cb61b6c69a4110bc1af30323d5c8b8398129b, a 'char' widget was added in the field 'model_year' so it allows entering a character instead of an of an integer.
This commit removes the 'char' widget from the mode l'model_year' so the user will allow entering only numbers.
sentry-5667064353
Forward-Port-Of: odoo/odoo#175490In some cases, like when another tests activates a language, the log output can include an extra line. See an example here: https://runbot.odoo.com/runbot/build/66699073 After this commit, we only check for the logs we care about. See also: https://github.com/odoo/odoo/pull/175344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177209
Original PR description
In some cases, like when another tests activates a language, the log output can include an extra line. See an example here: https://runbot.odoo.com/runbot/build/66699073 After this commit, we only check for the logs we care about. See also: https://github.com/odoo/odoo/pull/175344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177209
**Current behavior before PR:** - When a table was created within an empty list item `(li)`, it was inserted directly inside the `ul` and as a sibling of the list item `(li)`. Furthermore, an additional `li` element was generated after the table. **Desired behavior after PR is merged:** - Now, when a table created inside empty `li` elements, it will be correctly inserted within the list item itself instead of the `ul`. Additionally, no extra `li` element will be generated after the tabl
Original PR description
**Current behavior before PR:** - When a table was created within an empty list item `(li)`, it was inserted directly inside the `ul` and as a sibling of the list item `(li)`. Furthermore, an additional `li` element was generated after the table. **Desired behavior after PR is merged:** - Now, when a table created inside empty `li` elements, it will be correctly inserted within the list item itself instead of the `ul`. Additionally, no extra `li` element will be generated after the table. task-3550599 Forward-Port-Of: odoo/odoo#164304
Current behavior: When a cashier enter a payment value with more precision than the rounding precision (eg. rounding=0.10 and payment value=1.25), he just cannot proceed to the payment. Steps to reproduce: - Install "Point of Sale" app - Go to the settings and enable the cash rounding - Go the shop settings and enable the cash rounding and create a down rounding method with a precision of 0.10 - Start a shop session, select a product and go to the payment screen - Select a payment metho
Original PR description
Current behavior: When a cashier enter a payment value with more precision than the rounding precision (eg. rounding=0.10 and payment value=1.25), he just cannot proceed to the payment. Steps to…
Current behavior: When a cashier enter a payment value with more precision than the rounding precision (eg. rounding=0.10 and payment value=1.25), he just cannot proceed to the payment. Steps to reproduce: - Install "Point of Sale" app - Go to the settings and enable the cash rounding - Go the shop settings and enable the cash rounding and create a down rounding method with a precision of 0.10 - Start a shop session, select a product and go to the payment screen - Select a payment method and write a number on the numpad so that the value goes up to the cent (eg. 1.25) - Select another payment method to pay the rest Solution: With this commit, an error popup will be displayed explaining why the cashier cannot proceed the payment and what he could change to authorize the payment. This popup should appear when selecting another payment method and when validating the payment. opw-3992018 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177072 Forward-Port-Of: odoo/odoo#174145
The tax_discount field was removed in 512574861691. We take the opportunity to also mention our new EDI module. task-4145576 Forward-Port-Of: odoo/odoo#178291
Original PR description
The tax_discount field was removed in 512574861691. We take the opportunity to also mention our new EDI module. task-4145576 Forward-Port-Of: odoo/odoo#178291
added more options to print via cups: - duplex mode (recto/verso), - landscape mode. Task: 3598690 Forward-Port-Of: odoo/odoo#177882
Original PR description
added more options to print via cups: - duplex mode (recto/verso), - landscape mode. Task: 3598690 Forward-Port-Of: odoo/odoo#177882
Purpose ======= Fix the traceback appearing when flagging a question or answer without being a moderator. Specification ============= The .forum_answer class has been removed from the element when doing the website_forum redesign (ref: https://github.com/odoo/odoo/commit/4b1cf2e06643171e5ae10ea44648c4db66d09319 ) The element is thus not found and a traceback occurs when trying to perform the animation. Now using the 'o_wforum_answer' element and making sure it exists before callin
Original PR description
Purpose ======= Fix the traceback appearing when flagging a question or answer without being a moderator. Specification ============= The .forum_answer class has been removed from the element when doing the website_forum redesign (ref: https://github.com/odoo/odoo/commit/4b1cf2e06643171e5ae10ea44648c4db66d09319 ) The element is thus not found and a traceback occurs when trying to perform the animation. Now using the 'o_wforum_answer' element and making sure it exists before calling the animation. Task-4058832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173614
Before this commit we had (rare) situation where events would have matching dates, and then Postgres wouldn't guarantee their order, causing issue with pagination. [Reproduce] - have events with the same dates - query the events with and without limit opw-4061191 Forward-Port-Of: odoo/odoo#177553
Original PR description
Before this commit we had (rare) situation where events would have matching dates, and then Postgres wouldn't guarantee their order, causing issue with pagination. [Reproduce] - have events with the same dates - query the events with and without limit opw-4061191 Forward-Port-Of: odoo/odoo#177553
[FIX] hr_holidays: take time into account during deserialization Steps to reproduce: - Install Time Off - Set your time-zone to UTC+1 - Modify your working schedules for Monday Morning to start at 00:30 - Create a leave for Monday and Tuesday in the Time Off app Issues: The calendar show 3 days for the leave. This is due to the field `all_day`, since it's set we will deserialize the record with the function `deserializeDate`. https://github.com/odoo/odoo/blob/44a1b163481b0b781028
Original PR description
[FIX] hr_holidays: take time into account during deserialization Steps to reproduce: - Install Time Off - Set your time-zone to UTC+1 - Modify your working schedules for Monday Morning to start at…
[FIX] hr_holidays: take time into account during deserialization Steps to reproduce: - Install Time Off - Set your time-zone to UTC+1 - Modify your working schedules for Monday Morning to start at 00:30 - Create a leave for Monday and Tuesday in the Time Off app Issues: The calendar show 3 days for the leave. This is due to the field `all_day`, since it's set we will deserialize the record with the function `deserializeDate`. https://github.com/odoo/odoo/blob/44a1b163481b0b781028ce337d72fbb0c8730475/addons/web/static/src/views/calendar/calendar_model.js#L503-L509 This function doesn't take into account the time in the record, which means that it will just deserialize the date which is Sunday in our case because of the timezone conversion to UTC. Because of this the frontend thinks that the leave takes place from Sunday to Tuesday. We can remove `all_day` thanks to this [fix](https://github.com/odoo/odoo/commit/3ccc6bfa86618b0ca13c13960c15b60f8f75f3ce) which enable `allDaySlot` options by default which allow us to preserve the original behavior of the calendar view in hr_holidays while correctly deserializing the datetime. opw-4043180 Forward-Port-Of: odoo/odoo#173147
To reproduce: - Install `account` in a fresh DB - Change the CoA to one which doesn't use anglo-saxon accounting - Notice how anglo-saxon accounting is still activated on the company Analysis: - Since `anglo_saxon_accounting` has a default value of False, we don't bother to specify its value in the templates which don't use it. - So, when switching CoA from one which uses anglo-saxon accounting to one which doesn't, False doesn't get written. Solution: - We explicitly reset it when c
Original PR description
To reproduce: - Install `account` in a fresh DB - Change the CoA to one which doesn't use anglo-saxon accounting - Notice how anglo-saxon accounting is still activated on the company Analysis: -…
To reproduce: - Install `account` in a fresh DB - Change the CoA to one which doesn't use anglo-saxon accounting - Notice how anglo-saxon accounting is still activated on the company Analysis: - Since `anglo_saxon_accounting` has a default value of False, we don't bother to specify its value in the templates which don't use it. - So, when switching CoA from one which uses anglo-saxon accounting to one which doesn't, False doesn't get written. Solution: - We explicitly reset it when changing CoA. - We could have put a default value of False in the template values, but that doesn't combine nicely with the existing code, so this solution is preferred. This has been causing issues for new SaaS databases, since the `saas_worker` first generates a database template for the Accounting app, and only afterwards generates database templates for each localization by changing the CoA. As far as I can see, no other fields need the same treatment. taskid: none Forward-Port-Of: odoo/odoo#178113
SYSCOHADA should stay SYSCOHADA when translated task-4118393 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#177886
Original PR description
SYSCOHADA should stay SYSCOHADA when translated task-4118393 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#177886
When the l10n_es_pos module is installed, the post_init_hook attempts to create an account journal for each Spanish company using a chart template. However, the method does not verify whether the journal already exists for the company, leading to potential duplication errors. Steps to Reproduce: - Create a journal for a Spanish company with the code 'SINV'. - Install the Point of Sale module and the l10n_es_pos module. - An error is raised because the journal 'SINV' already exists. Solu
Original PR description
When the l10n_es_pos module is installed, the post_init_hook attempts to create an account journal for each Spanish company using a chart template. However, the method does not verify whether the journal already exists for the company, leading to potential duplication errors. Steps to Reproduce: - Create a journal for a Spanish company with the code 'SINV'. - Install the Point of Sale module and the l10n_es_pos module. - An error is raised because the journal 'SINV' already exists. Solution: This fix adds a check to ensure the journal does not already exist before attempting to create it. opw-4108466 Forward-Port-Of: odoo/odoo#176953
Purchase IRPF 19% Spanish tax has 2 target models: 111 and 123. New law requires a more specific breakdown. Now, the tax for 111 is relabeled as "Retenciones IRPF 19% (Compra consejero de persona física)" to be more accurate, and the new one for model 123 is named "Retenciones IRPF 19% (Compra consejero de sociedad)". Since Odoo doesn't implement model 123 yet, that new tax includes no repartition lines. See https://github.com/OCA/l10n-spain/issues/3520 for more context. ---
Original PR description
Purchase IRPF 19% Spanish tax has 2 target models: 111 and 123. New law requires a more specific breakdown. Now, the tax for 111 is relabeled as "Retenciones IRPF 19% (Compra consejero de persona física)" to be more accurate, and the new one for model 123 is named "Retenciones IRPF 19% (Compra consejero de sociedad)". Since Odoo doesn't implement model 123 yet, that new tax includes no repartition lines. See https://github.com/OCA/l10n-spain/issues/3520 for more context. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @moduon MT-5767 Ticket link: https://www.odoo.com/web#model=project.task&id=3864840 opw-3864840 Forward-Port-Of: odoo/odoo#173724 Forward-Port-Of: odoo/odoo#161633
Problem: When a discount is based on quantity and we update the quantity to a value that does not have a discount, the stale discount value remains. Steps to reproduce: - Create a product with two vendor lines for the same vendor but different discounts based on quantity: - Vendor1: Quantity 10 - Discount 5% - Vendor1: Quantity 20 - Discount 10% - Create a new quotation with the product and set the quantity to 10. - Update the quantity to 20. - Update the quantity to 1. The 10% discoun
Original PR description
Problem: When a discount is based on quantity and we update the quantity to a value that does not have a discount, the stale discount value remains. Steps to reproduce: - Create a product with two vendor lines for the same vendor but different discounts based on quantity: - Vendor1: Quantity 10 - Discount 5% - Vendor1: Quantity 20 - Discount 10% - Create a new quotation with the product and set the quantity to 10. - Update the quantity to 20. - Update the quantity to 1. The 10% discount still appears, even though it should have been removed. opw-4123984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177404
Versions -------- - 17.0+ Steps ----- 1. Have industry_fsm_sale from enterprise installed; 2. create a SO using a different `partner_id` for the shipping address; 3. add a product that uses timesheets without creating a task; 3. confirm the sale order; 4. in Field Service, create a new task; 5. set Customer to `partner_id` used for shipping address; 6. select the relevant Sales Order Item; 7. add a product in catalog. Issue ----- After adding a product to the field service tas
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have industry_fsm_sale from enterprise installed; 2. create a SO using a different `partner_id` for the shipping address; 3. add a product that uses…
Versions -------- - 17.0+ Steps ----- 1. Have industry_fsm_sale from enterprise installed; 2. create a SO using a different `partner_id` for the shipping address; 3. add a product that uses timesheets without creating a task; 3. confirm the sale order; 4. in Field Service, create a new task; 5. set Customer to `partner_id` used for shipping address; 6. select the relevant Sales Order Item; 7. add a product in catalog. Issue ----- After adding a product to the field service task, a new SO is created instead of adding it to the existing SO (as would be the case if the task was created by the SOL). Cause ----- When computing a task's `sale_order_id`, it checks whether the task's `partner_id` matches that of the sale order. FSM tasks generally use the `partner_shipping_id` instead, so if this one is different, `sale_order_id` is set to `False`. Solution -------- Aside from sale order's `partner_id`, also check its `partner_invoice_id` and `partner_shipping_id` when deciding whether the task should get linked to the SO. Also changes one of the dependent fields of the compute method from `project_id` to `project_id.sale_order_id`, assuming that when a task's `sale_order_id` is derived from its project's, changing the project's SO should trigger a recompute for the task's as well. opw-3901885 Forward-Port-Of: odoo/odoo#177961 Forward-Port-Of: odoo/odoo#175658
Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial
Original PR description
Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial move. Instead of using a context or adding new fields, we add a hook in which we can specify certain conditions to bypass the document check/formatting for localisations. We had to add `partner_id` to avoid the flow in wich the user set a foreign customer and a custom document type to change back the customer to an ecuadorian one; hence the second part of the test opw-3993305 Forward-Port-Of: odoo/enterprise#68949 Forward-Port-Of: odoo/enterprise#67589
Steps to reproduce: - Install `l10n_{ar,pe}_pos` and `l10n_ec_edi_pos` - Enable "Use QR Code on ticket" - Make an order and validate it inside the POS - Open in an incognito window the link given by the QR Code Issues: Internal error, the cause is the multiple else that are added to the `get_info_div` block. This problem is blocking #175591 and #175593 related community PR: https://github.com/odoo/odoo/pull/176746 Forward-Port-Of: odoo/enterprise#68432
Original PR description
Steps to reproduce:
- Install `l10n_{ar,pe}_pos` and `l10n_ec_edi_pos`
- Enable "Use QR Code on ticket"
- Make an order and validate it inside the POS
- Open in an incognito window the link given by the QR Code
Issues:
Internal error, the cause is the multiple else that are added to the `get_info_div` block.
This problem is blocking #175591 and #175593
related community PR: https://github.com/odoo/odoo/pull/176746
Forward-Port-Of: odoo/enterprise#68432Changes ----- Since 17.2, the subscription view in the portal only shows what will be invoiced next. SO lines of non recurring products are hidden if already invoiced. This commit makes the following changes: 1. When viewing a subscription in the portal from the Orders button, the breadcrumb links to the Subscriptions page instead of the Sales Orders page. 2. To allow the user to see non recurring products of a subscription, accessing previous orders from the "History" link of a subscripti
Original PR description
Changes ----- Since 17.2, the subscription view in the portal only shows what will be invoiced next. SO lines of non recurring products are hidden if already invoiced. This commit makes the following changes: 1. When viewing a subscription in the portal from the Orders button, the breadcrumb links to the Subscriptions page instead of the Sales Orders page. 2. To allow the user to see non recurring products of a subscription, accessing previous orders from the "History" link of a subscription will link to the sales orders (which show the non recurring lines). opw-4028536 Forward-Port-Of: odoo/enterprise#67595
[IMP] l10n_in_asset: add unit tests to indian asset depreciation This is about adding test to the new indian asset depreciation feature https://github.com/odoo/enterprise/pull/67225/commits/23591bb39500018afb3c4dab1c33c665c5f3a064 task-id#3909619 original-pr: https://github.com/odoo/enterprise/pull/67225 Forward-Port-Of: odoo/enterprise#68460
Original PR description
[IMP] l10n_in_asset: add unit tests to indian asset depreciation This is about adding test to the new indian asset depreciation feature https://github.com/odoo/enterprise/pull/67225/commits/23591bb39500018afb3c4dab1c33c665c5f3a064 task-id#3909619 original-pr: https://github.com/odoo/enterprise/pull/67225 Forward-Port-Of: odoo/enterprise#68460
Before this Fix =============== The repost and like operations on the feed view lead to failure. Reason ====== Due to the modifications in [code](https://github.com/odoo/odoo/blob/844ef1895c8fd4f39c5bebe7e3cffa5a6e68fe0d/addons/web/controllers/home.py#L37) any RPC calls with URLs starting with 'social_twitter/' are now being redirected to the mentioned controller, causing errors and operational failures. After this Fix ============== Rpcs call will be redirected to the respected cont
Original PR description
Before this Fix =============== The repost and like operations on the feed view lead to failure. Reason ====== Due to the modifications in [code](https://github.com/odoo/odoo/blob/844ef1895c8fd4f39c5bebe7e3cffa5a6e68fe0d/addons/web/controllers/home.py#L37) any RPC calls with URLs starting with 'social_twitter/' are now being redirected to the mentioned controller, causing errors and operational failures. After this Fix ============== Rpcs call will be redirected to the respected controller and operations will not fail. Task-4072724 Forward-Port-Of: odoo/enterprise#68298
While the format for the guid is the right in the xml, for the CSV, we should add double quotes, as asked by the format. The 2 zip should really be separated, with one for the csv and the other for the attachments Renamed the 2 buttons to indicate more clearly what they are about. The csv only expects a single attachment per move. We should then only export the message_main_attachment_id task-4131986 Forward-Port-Of: odoo/enterprise#68941 Forward-Port-Of: odoo/enterprise#68794
Original PR description
While the format for the guid is the right in the xml, for the CSV, we should add double quotes, as asked by the format. The 2 zip should really be separated, with one for the csv and the other for the attachments Renamed the 2 buttons to indicate more clearly what they are about. The csv only expects a single attachment per move. We should then only export the message_main_attachment_id task-4131986 Forward-Port-Of: odoo/enterprise#68941 Forward-Port-Of: odoo/enterprise#68794
Manual Fowardport latam task 1097 Forward-Port-Of: https://github.com/odoo/enterprise/pull/48754 Forward-Port-Of: https://github.com/odoo/enterprise/pull/47967 Forward-Port-Of: odoo/enterprise#58901 Forward-Port-Of: odoo/enterprise#52999
Original PR description
Manual Fowardport latam task 1097 Forward-Port-Of: https://github.com/odoo/enterprise/pull/48754 Forward-Port-Of: https://github.com/odoo/enterprise/pull/47967 Forward-Port-Of: odoo/enterprise#58901 Forward-Port-Of: odoo/enterprise#52999