Wednesday, November 22, 2023
48 changes · 17.0
New functionality added to Odoo
Users can now access an Unreserve action directly from batch pickings. This makes it easier to release reserved stock in grouped warehouse operations without leaving the batch context.
Original PR description
Added a contextual action 'Unreserve' on batch pickings. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change adds a new configuration file for an Odoo 17 deployment package. It appears to support packaging or environment setup rather than changing day-to-day business functionality.
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
Enhancements to existing features
This update improves how the Mail app creates sample data used for testing and demonstrations. It makes user and notification data generation faster and better balanced, reducing wait times while keeping the generated data useful.
Resolved issues and error corrections
The Time Off setup now keeps leave types without a company from incorrectly receiving a default project or task. This prevents the task field from appearing unexpectedly on leave type forms, keeping configuration screens clearer and consistent.
Original PR description
Description of the bug:
task field is displayed in leave type form when company field is False
Steps to reproduce:
- install time off app
- open a leave type form
Source:
When installling time off app,
_compute_{timesheet_project_id, timesheet_task_id, timesheet_generate} work perfectly, when company = False => project/task = False and timesheet_generate = True
Then, the post_init is executed. it will set the project and task according to env.company when company is False. so now project and task can have values even that the leave company is False. Then in the xml, we hide project if company is null and task if project is null, that's why project is not displayed but not task
Solution:
- In post_init method, we only get leaves types without a company set and stop using env.company to be coherent with the compute methods.
X-original-commit: e647374Miscellaneous changes
When Odoo is installed with the latest version of the PostgreSQL client (postgres-client or postgres-client-16) and running in Docker (possibly other environments as well but not reproduced so far), executing `pg_dump` via `exec_pg_command` fails with Database backup error: Postgres subprocess ('/usr/bin/pg_dump', '--no-owner', '--file=/tmp/tmpmnqiktog/dump.sql', '15TEST') error 1 This seems to be because `os.devnull` is being opened in *read* mode which is incorrect (as it's written t
Original PR description
When Odoo is installed with the latest version of the PostgreSQL client (postgres-client or postgres-client-16) and running in Docker (possibly other environments as well but not reproduced so far),…
When Odoo is installed with the latest version of the PostgreSQL client (postgres-client or postgres-client-16) and running in Docker (possibly other environments as well but not reproduced so far), executing `pg_dump` via `exec_pg_command` fails with
Database backup error: Postgres subprocess ('/usr/bin/pg_dump', '--no-owner', '--file=/tmp/tmpmnqiktog/dump.sql', '15TEST') error 1
This seems to be because `os.devnull` is being opened in *read* mode which is incorrect (as it's written to). It's not entirely clear if older `pg_dump` simply ignored the non-writable stdout or if docker adds some restrictions which cause the failure.
Either way this can be solved by either opening `os.devnull` in write mode or switching to the `DEVNULL` constant. While the function is deprecated in 16.0 (7f14631fe804ffdcc82d8b2fc1d2e70e485bf806) and removed in master (ae3056f3f4fca82c6aee69bf201532e14829c45e) the latter is not a huge change and it a touch cleaner.
fixes #139687
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#142987This update removes outdated warning functionality from tax closing forms that was no longer working properly since version 16.4. Warning messages about tax control failures are now displayed only on the tax report itself, which is the standard workflow users follow anyway. This simplifies the system and ensures users see warnings in the right place.
Original PR description
The field tax_report_control_error defined on account.move was previously used to display a warning message on the tax closing's form view when some of the controls defined on the report failed. This…
The field tax_report_control_error defined on account.move was previously used to display a warning message on the tax closing's form view when some of the controls defined on the report failed. This was only used in l10n_be_reports at this point. From 16.4 on, this feature did not work anymore, because of the introduction of sections, and the fact the options dict is generated separately from the lines, and hence cannot be modified while these are being generated. https://github.com/odoo/enterprise/commit/9b3bb03f27a142d367310e6def856efd194b3006 already removed such a warning on the Belgian XML export wizard, and introduced a warning banner directly on the report to replace it. With this commit, we make the choice to remove the wanring on the closing move as well ; any regular tax closing flow should anyway go through the report, and then view the warning displayed there. Another PR will follow in master to finish removing the unneeded fields. Forward-Port-Of: odoo/enterprise#50910
The WhatsApp template variables are now displayed in a logical, organized sequence instead of appearing randomly. Variables are now sorted by type (Location, Header, Buttons, Body) making the interface cleaner and easier to use when setting up WhatsApp message templates.
Original PR description
Before This Commit: Currently, the variables are not populating in the proper sequence. It makes the variable tab look untidy. After This Commit: Sequence the variables with variable type in the sequence Location Defaults > Header > Buttons > Body Variables Solution: used the _order attribute to sort the variables in the order of variable type and placeholder 1. location - address 2. location - latitude, longitude 3. location - name 4. header 5. button 6. body Task - 3516187 Forward-Port-Of: odoo/enterprise#48526
Archiving an employee with a departure description now completes successfully instead of showing an Odoo error. The departure note is still recorded in the employee chatter, preserving the audit trail without relying on unsupported tracking for HTML content.
Original PR description
Step to reproduce the bug: -Go to the employee app -Go to an employee form view -Click on the archive button -Put a description -Click on the archive button -> Odoo error Bug explaination: The tracking is not implemented for the html field, so when we archive an employee the tracking cannot work. Expected behavior: The employee is archived and the tracking is done without errors. Bug resolution: The tracking has been removed from the html field. The tracking is now replaced by a message in the chatter in the write method. Behavior after this commit: The employee is archived and the tracking is done without errors with a mesage in the chatter if a value is entered for the departure_description field has a value. task-3576659 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The IoT system now checks whether a database is connected to the IoT box before starting its communication client. This prevents needless background processing and avoids errors when no database is linked.
Original PR description
Add a condition that check if the DB is connected to the iot box before the start of the websocket client, before, if no DB was connected the Thread was lauched for nothing and an exeption was thrown --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now delete multiple employee work locations without triggering an error. The fix corrects how related employee location records are checked, preventing a crash during routine HR configuration cleanup.
Original PR description
This traceback arises when the user tries to delete `Work Locations`. To reproduce this issue: 1) Install `hr_homeworking` 2) Open `Employees/Configuration/Work Locations` 3) Try to delete multiple…
This traceback arises when the user tries to delete `Work Locations`.
To reproduce this issue:
1) Install `hr_homeworking`
2) Open `Employees/Configuration/Work Locations`
3) Try to delete multiple records
Error:-
```
ValueError: too many values to unpack (expected 3)
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 466, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "odoo/models.py", line 4160, in unlink
func(self)
File "addons/hr_homeworking/models/hr_work_location.py", line 17, in _unlink_except_used_by_employee
exceptions_using_location = self.env['hr.employee.location'].search(('work_location_id', 'in', self.ids))
File "odoo/models.py", line 1604, in search
return self.search_fetch(domain, [], offset=offset, limit=limit, order=order)
File "odoo/models.py", line 1627, in search_fetch
query = self._search(domain, offset=offset, limit=limit, order=order or self._order)
File "odoo/models.py", line 5366, in _search
query = self._where_calc(domain)
File "odoo/models.py", line 5081, in _where_calc
return expression.expression(domain, self).query
File "odoo/osv/expression.py", line 788, in __init__
self.expression = domain_combine_anies(domain, model)
File "odoo/osv/expression.py", line 597, in domain_combine_anies
domain_any = _anyfy_leaves(domain, model)
File "odoo/osv/expression.py", line 371, in _anyfy_leaves
left, operator, right = item = tuple(item)
```
An invalid domain format is used when searching for the record in `hr.employee.location`.
See:
https://github.com/odoo/odoo/blob/def16f3725f8005874a18eb28b171523af1a0ecf/addons/hr_homeworking/models/hr_work_location.py#L17
sentry-4644429734Point of Sale receipt printing now hides the on-screen receipt while generating the print preview, preventing duplicate receipt content from appearing. This makes receipt previews and printed receipts look correct for users printing through the browser without a connected printer.
Original PR description
To reproduce ============ on POS (without having a connected print), make an order and print the receipt, the preview will show the receipt not well rendered Problem ======= we add the element that contains the receipt to the page, so we have two copies of the receipt (the page using CSS `@media print` and the added element) Solution ======== hide the original element on the page while printing, and bring it back after opw-3596341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now open the messaging menu even when the messaging system has not fully initialized yet. This prevents a frustrating access issue and makes the mail interface more dependable during loading or startup delays.
Users connecting to Codabox will now see a clear message if Odoo's IAP service is unavailable, instead of being sent to an incorrect web page. This helps businesses understand the issue quickly and avoid confusion during setup or connection attempts.
Original PR description
Currently, if IAP is down, we'll get no confirmation url when connecting to Codabox. Therefore, a null fallback was being used which would lead to an incorrect Odoo web page. Now, instead, we'll let the user know with a proper message that something is wrong with IAP. task-id: none
A test in the spreadsheet documents module was failing in certain timezones due to improper date handling. The fix adjusts the test date to noon (12PM) to ensure consistent results across different timezone regions. This is a temporary solution until the underlying date library is updated to use a more robust time handling system.
Original PR description
The test `list with a contextual domain` was failing on some timezone because the date isn't well patched. We cannot correctly patch the date at the moment, because PyDate doesn't use luxon but new Date(). Fix the issue by setting the date to 12PM, so the test will work in most timezones. We should properly fix the issue once PyDate make the switch to luxon.
In commit b47be9f254b2f7327ea3e0e92c6b1b97bff016d0 we changed the background of the popover selector making the title unreadable in white mode. This commit applies the text-dark color to make sure the title is readable. It also removes the primary background on hover behind the btns to use a color change instead. We will later on improve this component with the btn-link + contextual class to manage the hover effect in another task. When a field is selected the active class is added on th
Original PR description
In commit b47be9f254b2f7327ea3e0e92c6b1b97bff016d0 we changed the background of the popover selector making the title unreadable in white mode. This commit applies the text-dark color to make sure the title is readable. It also removes the primary background on hover behind the btns to use a color change instead. We will later on improve this component with the btn-link + contextual class to manage the hover effect in another task. When a field is selected the active class is added on the parent `<li>` rather than the `<button>` This commit applies it on the button to display an active state on the selected element. task-3577065 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#140654
After this fix, UBL now uses the same helper as Factur-X for the import of the product. Also clean some dead code in UBL. task-3559040 Forward-Port-Of: odoo/odoo#142766 Forward-Port-Of: odoo/odoo#139153
Original PR description
After this fix, UBL now uses the same helper as Factur-X for the import of the product. Also clean some dead code in UBL. task-3559040 Forward-Port-Of: odoo/odoo#142766 Forward-Port-Of: odoo/odoo#139153
Add taxes in l10n_es: - Retenciones IRPF 19% Consejeros y administradores - Retenciones IRPF 35% Consejeros y administradores **Current behavior before PR:** Update taxes list with 2 new taxes. This is the open issue : https://github.com/OCA/l10n-spain/issues/3174 MT-2835 Please reviews @moduon @rafaelbn @Shide :) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#134922 Forward-Port-Of: odoo/odoo#130
Original PR description
Add taxes in l10n_es: - Retenciones IRPF 19% Consejeros y administradores - Retenciones IRPF 35% Consejeros y administradores **Current behavior before PR:** Update taxes list with 2 new taxes. This is the open issue : https://github.com/OCA/l10n-spain/issues/3174 MT-2835 Please reviews @moduon @rafaelbn @Shide :) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#134922 Forward-Port-Of: odoo/odoo#130728
Before this commit, adding images to POS categories caused the search bar to disappear. This commit addresses the problem by fixing the layout issue that led to the disappearance of the search bar. Now, even when POS categories have images, the search bar remains visible and correctly positioned to the right. opw-3598922 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142856
Original PR description
Before this commit, adding images to POS categories caused the search bar to disappear. This commit addresses the problem by fixing the layout issue that led to the disappearance of the search bar. Now, even when POS categories have images, the search bar remains visible and correctly positioned to the right. opw-3598922 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142856
* Create a tax of type `group` and with a `tax_scope` set * Add a child tax without `tax_scope` set This will raise an error because the `tax_scope` is not exactly the same since it doesn't have a value. We should be able to share sub taxes without a scope, exactly like for `type_tax_use`. This is also what the message suggests. Forward-Port-Of: odoo/odoo#142951
Original PR description
* Create a tax of type `group` and with a `tax_scope` set * Add a child tax without `tax_scope` set This will raise an error because the `tax_scope` is not exactly the same since it doesn't have a value. We should be able to share sub taxes without a scope, exactly like for `type_tax_use`. This is also what the message suggests. Forward-Port-Of: odoo/odoo#142951
Previously, 'amount_currency' was calculated using data from the purchase line. However, numerous variables could interfere with the accurate computation of 'purchase_price_unit' (e.g., taxes, taxes without account, standard costing method, kit product, and potentially more). This commit revises the approach by utilizing the pre-calculated value and converting it to the desired currency. This maintains coherence between the balance and 'amount_currency' without necessitating the recreation of
Original PR description
Previously, 'amount_currency' was calculated using data from the purchase line. However, numerous variables could interfere with the accurate computation of 'purchase_price_unit' (e.g., taxes, taxes…
Previously, 'amount_currency' was calculated using data from the purchase line. However, numerous variables could interfere with the accurate computation of 'purchase_price_unit' (e.g., taxes, taxes without account, standard costing method, kit product, and potentially more). This commit revises the approach by utilizing the pre-calculated value and converting it to the desired currency. This maintains coherence between the balance and 'amount_currency' without necessitating the recreation of a function like '_get_price_unit()' in 'purchase_stock.' ## Reproduce Errors ## ### Tax Included in price without Account: - Create a currency, CTest, with a conversion factor of 10 (10 CTest = 1 USD). - Define a new tax: ° No accounts in repartition lines ° Rate: 15% ° Included in the price - Create a Purchase Order: ° 1 unit | 100 CTest | Tax applied - Receive the product. -> SVL value is 10 USD, because tax without account increments the stock value. Refer to 'test_valuation_multicurrency_with_tax'. -> Check SVL journal entry: credit / debit is 10, but amount currency is 86.96 CTest instead of 100 CTest. ### Reproduce With Kit ## - Create a currency, CTest, with a conversion factor of 10 (10 CTest = 1 USD). - Create a Kit (storable, fifo), with 5 unit of CPM (storable fifo) in it's BoM - Create a Purchase Order: Kit: 1 unit | 100 CTest - Receive product -> Check SVL journal entry: credit / debit is 10, but amount currency is 500 CTest instead of 100 CTest. Video example: https://watch.screencastify.com/v/kCpY0GHbSCoa933efUyd End result: Purchase value = ¥ 100.00, Account move value = ¥ 600.00 --- OPW-3453703 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142336 Forward-Port-Of: odoo/odoo#141689
**Current behavior before PR:** Format and style are lost when copying content that has some style or format applied on it. **Desired behavior after PR is merged:** Now, able to copy content with its format and style. Task-3263360 Forward-Port-Of: odoo/odoo#119967
Original PR description
**Current behavior before PR:** Format and style are lost when copying content that has some style or format applied on it. **Desired behavior after PR is merged:** Now, able to copy content with its format and style. Task-3263360 Forward-Port-Of: odoo/odoo#119967
Without it, like in no-demo testing conditions, tests with rights depending on Karma fail. Task-3575692 Forward-Port-Of: odoo/odoo#142179 Forward-Port-Of: odoo/odoo#140309
Original PR description
Without it, like in no-demo testing conditions, tests with rights depending on Karma fail. Task-3575692 Forward-Port-Of: odoo/odoo#142179 Forward-Port-Of: odoo/odoo#140309
If you have a survey of several pages, but don't valid all, you don't have any survey_input_line for some question, so the [0] will crash. Since the method wait only one input_line maximum, instead to force to take the first one without take care if no reply, we just use the browser record that will work in both case. If it is empty it will enter in the 4th case, 'skipped' what is expected and was dead code before. -- Bug on the prod -- Forward-Port-Of: odoo/odoo#142219
Original PR description
If you have a survey of several pages, but don't valid all, you don't have any survey_input_line for some question, so the [0] will crash. Since the method wait only one input_line maximum, instead to force to take the first one without take care if no reply, we just use the browser record that will work in both case. If it is empty it will enter in the 4th case, 'skipped' what is expected and was dead code before. -- Bug on the prod -- Forward-Port-Of: odoo/odoo#142219
Before the commit, there was a small issue where a foldable badge would be slightly smaller in height than A4 paper. This commit fixes this by giving foldable badges more height. Task-3389338 Forward-Port-Of: odoo/odoo#130721
Original PR description
Before the commit, there was a small issue where a foldable badge would be slightly smaller in height than A4 paper. This commit fixes this by giving foldable badges more height. Task-3389338 Forward-Port-Of: odoo/odoo#130721
Suppose a user who imports a new picking thanks to this: ```csv location_id,location_dest_id,picking_type_id WH/Stock,Partners/Customers,YourCompany: Delivery Orders ``` Then, on the inferface, for one of the fields, he sets the value as "Database ID" (for instance "Destination Location/Database ID"). When trying to import the file, an error is raised, which could make sense since the provided value is not a DB identifier, but the error is actually incorrect: > Odoo Server Error. Curre
Original PR description
Suppose a user who imports a new picking thanks to this: ```csv location_id,location_dest_id,picking_type_id WH/Stock,Partners/Customers,YourCompany: Delivery Orders ``` Then, on the inferface, for…
Suppose a user who imports a new picking thanks to this:
```csv
location_id,location_dest_id,picking_type_id
WH/Stock,Partners/Customers,YourCompany: Delivery Orders
```
Then, on the inferface, for one of the fields, he sets the value as
"Database ID" (for instance "Destination Location/Database ID").
When trying to import the file, an error is raised, which could make
sense since the provided value is not a DB identifier, but the error
is actually incorrect:
> Odoo Server Error. Current transaction is aborted, commands ignored
> until end of transaction block
When looking for the destination location in the database, it will
raise a legit error since the domain does not make sense:
`[('id', '=', tentative_id)]`
Hence this:
> ERROR: invalid input syntax for type integer: "Partners/Customers"
The good point is that everything in the code already handles this:
we catch the error and add some detailed explanations in the import
error report, but... The SQL transaction is now broken. So, as soon
as another SQL request is executed, it will trigger an
`InFailedSqlTransaction` error, we will not catch it and this error
will be returned to the frontend (we lose the import report).
sentry-3969379125
Forward-Port-Of: odoo/odoo#142825Before this commit, when Odoo faced an internal error and lost the current synchronization token with Microsoft, after fetching events from Graph API an `410 Gone` was being thrown carrying the `SyncStateNotFound` code. Since we didn't handle this error code, we were experiencing a traceback after the request: ``` 2023-11-15 09:16:15,046 4 ERROR report-one-16-0-staging-1-10315840 odoo.addons.microsoft_account.models.microsoft_service: Bad microsoft request : b'{"error":{"code":"SyncStateNotF
Original PR description
Before this commit, when Odoo faced an internal error and lost the current synchronization token with Microsoft, after fetching events from Graph API an `410 Gone` was being thrown carrying the…
Before this commit, when Odoo faced an internal error and lost the current synchronization token with Microsoft, after fetching events from Graph API an `410 Gone` was being thrown carrying the `SyncStateNotFound` code. Since we didn't handle this error code, we were experiencing a traceback after the request:
```
2023-11-15 09:16:15,046 4 ERROR report-one-16-0-staging-1-10315840 odoo.addons.microsoft_account.models.microsoft_service: Bad microsoft request : b'{"error":{"code":"SyncStateNotFound","message":"The sync state generation is not found; generation=25;[highest=28][28][26][27]."}}' !
Traceback (most recent call last):
File "/home/odoo/src/odoo/addons/microsoft_account/models/microsoft_service.py", line 154, in _do_request
res.raise_for_status()
File "/usr/lib/python3/dist-packages/requests/models.py", line 943, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 410 Client Error: Gone for url: https://graph.microsoft.com/v1.0/me/calendarView/delta?%24deltatoken=MOCK_TOKEN_HERE
2023-11-15 09:16:15,051 4 ERROR report-one-16-0-staging-1-10315840 odoo.http: Exception during request handling.
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/http.py", line 2003, in __call__
response = request._serve_db()
File "/home/odoo/src/odoo/odoo/http.py", line 1589, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/src/odoo/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/src/odoo/odoo/http.py", line 1616, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/odoo/http.py", line 1820, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/addons/website/models/ir_http.py", line 237, in _dispatch
response = super()._dispatch(endpoint)
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/odoo/http.py", line 697, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/addons/microsoft_calendar/controllers/main.py", line 55, in sync_data
need_refresh = request.env.user.sudo().with_context(sync_context)._sync_microsoft_calendar()
File "/home/odoo/src/odoo/addons/microsoft_calendar/models/res_users.py", line 99, in _sync_microsoft_calendar
events, next_sync_token = calendar_service.get_events(self.microsoft_calendar_sync_token, token=token)
File "/home/odoo/src/odoo/addons/microsoft_calendar/utils/microsoft_calendar.py", line 20, in wrapped
return func(self, *args, **kwargs)
File "/home/odoo/src/odoo/addons/microsoft_calendar/utils/microsoft_calendar.py", line 152, in get_events
events, next_sync_token = self._get_events_delta(sync_token=sync_token, token=token, timeout=timeout)
File "/home/odoo/src/odoo/addons/microsoft_calendar/utils/microsoft_calendar.py", line 20, in wrapped
return func(self, *args, **kwargs)
File "/home/odoo/src/odoo/addons/microsoft_calendar/utils/microsoft_calendar.py", line 111, in _get_events_delta
raise e
File "/home/odoo/src/odoo/addons/microsoft_calendar/utils/microsoft_calendar.py", line 105, in _get_events_delta
events, next_sync_token = self._get_events_from_paginated_url(
File "/home/odoo/src/odoo/addons/microsoft_calendar/utils/microsoft_calendar.py", line 20, in wrapped
return func(self, *args, **kwargs)
File "/home/odoo/src/odoo/addons/microsoft_calendar/utils/microsoft_calendar.py", line 76, in _get_events_from_paginated_url
_, data, _ = self.microsoft_service._do_request(
File "/home/odoo/src/odoo/addons/microsoft_account/models/microsoft_service.py", line 173, in _do_request
raise error
File "/home/odoo/src/odoo/addons/microsoft_account/models/microsoft_service.py", line 154, in _do_request
res.raise_for_status()
File "/usr/lib/python3/dist-packages/requests/models.py", line 943, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 410 Client Error: Gone for url: https://graph.microsoft.com/v1.0/me/calendarView/delta?%24deltatoken=MOCK_TOKEN_HERE
```
After this commit, everytime we receive the `SyncStateNotFound` code from Microsoft, we will trigger the full synchronization with Graph API. This way, the outdated token will be replaced with a brand new token.
Task-id: 3597211
Forward-Port-Of: odoo/odoo#142153Before this commit, when changing the event organizer to a new one, if the new organizer was not synced with Odoo a ValidationError was being thrown requesting that the new organizer must be added as attendee when it shouldn't (since the new organizer is not synced with Outlook). Additionaly, there was an extra call being made to the method `_is_microsoft_calendar_valid()` in the user synchronization checking which should be removed. After this commit, this restriction is removed: the new org
Original PR description
Before this commit, when changing the event organizer to a new one, if the new organizer was not synced with Odoo a ValidationError was being thrown requesting that the new organizer must be added as attendee when it shouldn't (since the new organizer is not synced with Outlook). Additionaly, there was an extra call being made to the method `_is_microsoft_calendar_valid()` in the user synchronization checking which should be removed. After this commit, this restriction is removed: the new organizer won't need to be added as attendee during this change of event organizers and the extra call to `_is_microsoft_calendar_valid()` is removed. Issue from: 3450045 Forward-Port-Of: odoo/odoo#142364
[FIX] Appointment based on user don't use manual confirmation What are the steps to reproduce your issue? - Create/Open an appointment type - Availability on: Resources - Options / Manual Confirmation: Yes - Update the appointment type - Availability on: Users - Set some Users - Publish - Open the page of the appointment - Schedule appointment and confirm What is the current behavior that you observe? - Traceback, division by zero - Confirmation line in mail te
Original PR description
[FIX] Appointment based on user don't use manual confirmation
What are the steps to reproduce your issue?
- Create/Open an appointment type
- Availability on: Resources
- Options / Manual Confirmation: Yes
- Update the appointment type
- Availability on: Users
- Set some Users
- Publish
- Open the page of the appointment
- Schedule appointment and confirm
What is the current behavior that you observe?
- Traceback, division by zero
- Confirmation line in mail template
What would be your expected behavior in this case?
- Appointment planned and confirmed on UI
- No confirmation line ine the mail
Caused by task-2453291
opw-3603634
Forward-Port-Of: odoo/odoo#142897**Description of the issue/feature this PR addresses:** - Have a delivery order sent to a shipper and done - Return this delivery order completely (without a shipper, might not be important) - Return of the return to resend to the customer (with a shipper and therefore a tracking number) This will lead to a endless loop as the move_origin_ids say so (might be a bug or not) Anyway, we make sure that the logic makes sure that we do not process twice the same stock move. **Current beh
Original PR description
**Description of the issue/feature this PR addresses:** - Have a delivery order sent to a shipper and done - Return this delivery order completely (without a shipper, might not be important) - Return of the return to resend to the customer (with a shipper and therefore a tracking number) This will lead to a endless loop as the move_origin_ids say so (might be a bug or not) Anyway, we make sure that the logic makes sure that we do not process twice the same stock move. **Current behavior before PR:** Endless loop -> 💣 💥 **Desired behavior after PR is merged:** Happy users -> 😄 Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142942 Forward-Port-Of: odoo/odoo#139278
Steps to reproduce: - Install modules: 'account_accountant', 'l10n_eg', 'l10n_eg_edi_eta'. - Switch company to "EG Company". - Configure "Large Cabinet Accounting" with ETA item code "10001138" and set Customer Taxes to "VAT 14%". - In "Journal Customer Invoices", disable "Factur-X (FR)" under Advanced Settings -> Electronic invoicing. Also, set Branch to "Deco Addict", ETA Activity Code to "Accounting, auditing, bookkeeping and tax advice activities", and ETA Branch ID to 0. - Update "Deco
Original PR description
Steps to reproduce: - Install modules: 'account_accountant', 'l10n_eg', 'l10n_eg_edi_eta'. - Switch company to "EG Company". - Configure "Large Cabinet Accounting" with ETA item code "10001138" and…
Steps to reproduce: - Install modules: 'account_accountant', 'l10n_eg', 'l10n_eg_edi_eta'. - Switch company to "EG Company". - Configure "Large Cabinet Accounting" with ETA item code "10001138" and set Customer Taxes to "VAT 14%". - In "Journal Customer Invoices", disable "Factur-X (FR)" under Advanced Settings -> Electronic invoicing. Also, set Branch to "Deco Addict", ETA Activity Code to "Accounting, auditing, bookkeeping and tax advice activities", and ETA Branch ID to 0. - Update "Deco Addict" with Tax ID "204899053" and set building number to 2. - Update "Azure Interior" with Tax ID "204899052" and set building number to 2. - In Accounting -> Configuration -> Thumb Drive, create a new record using "EG Company" with 123 as both the ETA USB Pin and Access Token. - Manually set the certificate in the Thumb Drive record. - Create a new Customer Invoice with Customer set to "Azure Interior", Invoice Date as today, add a line item "Large Cabinet", set the Price to 0, remove "0% taxes" and add "VAT 14%", and set Journal to "Customer invoices in EUR". - Confirm the invoice and attempt to "Sign Invoice". Issue: A traceback occurs with a divide by zero error in the invoice calculation when different currencies are involved. Solution: Refined _l10n_eg_edi_exchange_currency_rate function to calculate the currency exchange rate. Now, it ensures the division by amount_currency only occurs when it's not zero, preventing divide by zero errors during currency conversion in invoices. opw-3580529 Forward-Port-Of: odoo/odoo#141842
Before this commit, when creating a move with a product having no label. The label will be automatically fill with "Bacon Burger" in the report. By adding a condition on the span, the span will be empty if the label is empty and can still be modified in studio if needed. task: 3604617 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142882
Original PR description
Before this commit, when creating a move with a product having no label. The label will be automatically fill with "Bacon Burger" in the report. By adding a condition on the span, the span will be empty if the label is empty and can still be modified in studio if needed. task: 3604617 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142882
Before this commit, the modified test sometimes failed on runbot because it couldn't click on "Create and edit..." in the many2one dropdown. Here's what happened: 1) call editInput to write something in the many2one input 2) call selectDropdownItem to select "Create and edit..." This was done without mocking setTimeout. The problem is that editInput triggers the opening of the dropdown, but as setTimeout wasn't mocked, that opening was delayed. Then, selectDropdownItem first clicked on t
Original PR description
Before this commit, the modified test sometimes failed on runbot because it couldn't click on "Create and edit..." in the many2one dropdown. Here's what happened: 1) call editInput to write something…
Before this commit, the modified test sometimes failed on runbot because it couldn't click on "Create and edit..." in the many2one dropdown. Here's what happened: 1) call editInput to write something in the many2one input 2) call selectDropdownItem to select "Create and edit..." This was done without mocking setTimeout. The problem is that editInput triggers the opening of the dropdown, but as setTimeout wasn't mocked, that opening was delayed. Then, selectDropdownItem first clicked on the input to open the dropdown, and then clicked on the requested item. It might happen that the click on the input actually closed the dropdown instead of opening it, if it had been already opened via editInput. In that case, the test failed because it couldn't click later on on "Create and edit". This commit also improves the test utils to better log what really happens: in this case, the dropdown isn't open at all, so we detect that specific issue and log it with a proper message (which is different than "the dropdown is open, but I can find the item you're looking found). Runbot issue 28207 Task 3603040 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#142865
Issue: ====== When using l10n_ar company , the public user (without sign in) will have an access error on the address page when clicking on process checkout from the website. Steps to reproduce the issue: ============================= - Install ecommerce + l10n_ar - Go to website without signing in and add any product to cart and process checkout Origin of the issue: ==================== Public user doesn't have the right to read `l10n_ar.afip.responsibility.type` and `l10n_latam.i
Original PR description
Issue: ====== When using l10n_ar company , the public user (without sign in) will have an access error on the address page when clicking on process checkout from the website. Steps to reproduce the issue: ============================= - Install ecommerce + l10n_ar - Go to website without signing in and add any product to cart and process checkout Origin of the issue: ==================== Public user doesn't have the right to read `l10n_ar.afip.responsibility.type` and `l10n_latam.identification.type` opw-3591440 Forward-Port-Of: odoo/odoo#142879
Issue: ====== When we have 1 delivery method enabled that have pickup locations, it will be selected by default and the pickup locations will never be displayed. Steps to reproduce the issue: ============================= - Set up pickup locations carried for sendcloud (like mondial relay) - Go through the website with just that shipping method available and add a product to cart valid with the configuration of sendcloud. - Go to checkoutout you will get the shipping method selected but
Original PR description
Issue: ====== When we have 1 delivery method enabled that have pickup locations, it will be selected by default and the pickup locations will never be displayed. Steps to reproduce the issue: ============================= - Set up pickup locations carried for sendcloud (like mondial relay) - Go through the website with just that shipping method available and add a product to cart valid with the configuration of sendcloud. - Go to checkoutout you will get the shipping method selected but no pick up options Origin of the issue: ==================== If the delivery method is already selected it will skip showing pickup locations. Solutions: ========== Now there is another check to make sure that it will be skipped only when the pick up locations are displayed. opw-3569497 Forward-Port-Of: odoo/odoo#142845 Forward-Port-Of: odoo/odoo#142484
Steps to reproduce: ------------------- - add an alternative product B for a product A; - go to product A page on ecommerce; Issue: ------ The alternative product B is not displayed below the product A. Solution: --------- Use the `o_dynamic_empty` instead of `d-none` to manage display of the snippet. opw-3568699 Forward-Port-Of: odoo/odoo#141627
Original PR description
Steps to reproduce: ------------------- - add an alternative product B for a product A; - go to product A page on ecommerce; Issue: ------ The alternative product B is not displayed below the product A. Solution: --------- Use the `o_dynamic_empty` instead of `d-none` to manage display of the snippet. opw-3568699 Forward-Port-Of: odoo/odoo#141627
Update the Japanese tax group template names to better fit the needs. Task id #3315696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142886 Forward-Port-Of: odoo/odoo#142461
Original PR description
Update the Japanese tax group template names to better fit the needs. Task id #3315696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142886 Forward-Port-Of: odoo/odoo#142461
Steps to reproduce: - New DB - Switch to russian - Install stock app Bug: throw back is raised when setting up the data caused by a duplicate operation type (Sequence Packing/Picking) Fix: apply the correct translation note: manual PR created since there's no russian translation on transifex after 16.0 opw-3589539 Forward-Port-Of: odoo/odoo#142715
Original PR description
Steps to reproduce: - New DB - Switch to russian - Install stock app Bug: throw back is raised when setting up the data caused by a duplicate operation type (Sequence Packing/Picking) Fix: apply the correct translation note: manual PR created since there's no russian translation on transifex after 16.0 opw-3589539 Forward-Port-Of: odoo/odoo#142715
Before this commit, the account mapping from fiscal position was not taken into account for payable/receivable accounts. Steps: - Create a fiscal position - In accounts mapping, set the default receivable account X as source account and an other one Y as destination account. - Create an invoice and set the fiscal position newly created. - Add an invoice line and select a product. - Go to journal items tab -> The receivable line as X account instead of Y account. opw-3600605 Forward-Port-Of:
Original PR description
Before this commit, the account mapping from fiscal position was not taken into account for payable/receivable accounts. Steps: - Create a fiscal position - In accounts mapping, set the default receivable account X as source account and an other one Y as destination account. - Create an invoice and set the fiscal position newly created. - Add an invoice line and select a product. - Go to journal items tab -> The receivable line as X account instead of Y account. opw-3600605 Forward-Port-Of: odoo/odoo#142801 Forward-Port-Of: odoo/odoo#142733
### Steps to reproduce: 1. Create a new product with a cost of 10 (std, manual) 2. Create an inventory adjustment to set the quantity to -3 3. Change the product's category to real-time Now the valuation for this product is -30€, but the accounting part has 30€, creating a difference of 60€. ### Before this commit: Changing the valuation to real-time while having a negative quantity/value gives a positive value in accounting. ### After this commit: Changing the valuation to real-ti
Original PR description
### Steps to reproduce: 1. Create a new product with a cost of 10 (std, manual) 2. Create an inventory adjustment to set the quantity to -3 3. Change the product's category to real-time Now the valuation for this product is -30€, but the accounting part has 30€, creating a difference of 60€. ### Before this commit: Changing the valuation to real-time while having a negative quantity/value gives a positive value in accounting. ### After this commit: Changing the valuation to real-time while having a negative quantity/value gives a negative value in accounting. opw-3390692 Forward-Port-Of: odoo/odoo#130674
The editor has specific behaviors when it comes to icons. For instance, marking them as `contenteditable="false"` so no text can end up into their container element. Those behaviors were only enabled for fa icons, this commit enables them for the new Odoo icons introduced at [1]. [1]: https://github.com/odoo/odoo/commit/546477dafab327d9990a5176bed4a9c2565eef74 Forward-Port-Of: odoo/odoo#142530
Original PR description
The editor has specific behaviors when it comes to icons. For instance, marking them as `contenteditable="false"` so no text can end up into their container element. Those behaviors were only enabled for fa icons, this commit enables them for the new Odoo icons introduced at [1]. [1]: https://github.com/odoo/odoo/commit/546477dafab327d9990a5176bed4a9c2565eef74 Forward-Port-Of: odoo/odoo#142530
# Issue: The hr_referral application can not be installed with demo data. # Analyze: The db is being auto locked. And transaction is not rollback due to the xml failure. # Fix: Add corresponding line into hr_demo.xml instead of hr_referral_demo.xml # Note: It does not fix the root cause, but until the root cause is well defined and fix, it is the best workaround. # Related ticket: opw-3547638 # Affected version: 16.0 and above Forward-Port-Of: odoo/odoo#142589 Forward-Port-
Original PR description
# Issue: The hr_referral application can not be installed with demo data. # Analyze: The db is being auto locked. And transaction is not rollback due to the xml failure. # Fix: Add corresponding line into hr_demo.xml instead of hr_referral_demo.xml # Note: It does not fix the root cause, but until the root cause is well defined and fix, it is the best workaround. # Related ticket: opw-3547638 # Affected version: 16.0 and above Forward-Port-Of: odoo/odoo#142589 Forward-Port-Of: odoo/odoo#142302
To Reproduce ============ - enable a currency and make it for example = 0.01$ - create pricelist for that currency - make sale order with that pricelist (let's say 1000 = 10$) - on dashboards the Revenue will be 1 000$ Problem ======== on spreadsheet we use the field `amount_untaxed` from `sale.order`, which contains the amount in the currency of the sale order and not the company. Solution ======== as `sale.oder` module doesn't have any field containing the converted amount, we w
Original PR description
To Reproduce ============ - enable a currency and make it for example = 0.01$ - create pricelist for that currency - make sale order with that pricelist (let's say 1000 = 10$) - on dashboards the Revenue will be 1 000$ Problem ======== on spreadsheet we use the field `amount_untaxed` from `sale.order`, which contains the amount in the currency of the sale order and not the company. Solution ======== as `sale.oder` module doesn't have any field containing the converted amount, we will use the field `price_subtotal` from `sale.report` opw-3527802 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142762 Forward-Port-Of: odoo/odoo#142489
…Invoicing only Steps to reproduce: 1. Create a database in demo mode with only Invoicing installed 2. Create a new company 3. Set any accounting localization package in Settings 4. Traceback because User doesn't have access rights on account.bank.statement task-id: 3584244 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/
Original PR description
…Invoicing only Steps to reproduce: 1. Create a database in demo mode with only Invoicing installed 2. Create a new company 3. Set any accounting localization package in Settings 4. Traceback because User doesn't have access rights on account.bank.statement task-id: 3584244 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#141196
## Description Since 54857ec409d2cd2a565ad73b069a8641046aedac , the results of the expensive recursive CTE on `res.partner` were never used. So the query doesn't do anything at all, besides slowing down the whole process for minutes on databases with a large volume of `res.partner` entries. ## Fix Removing the dead code ## Reference task-3601394 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142578
Original PR description
## Description Since 54857ec409d2cd2a565ad73b069a8641046aedac , the results of the expensive recursive CTE on `res.partner` were never used. So the query doesn't do anything at all, besides slowing down the whole process for minutes on databases with a large volume of `res.partner` entries. ## Fix Removing the dead code ## Reference task-3601394 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142578
Before this commit, some tests of the SwitchCompanyMenu sometimes failed: - "companies can be logged in even if some toggled within delay" - "can toggle multiple companies at once" They failed because the debounce delay between the first click to toggle a company and the moment the company service is notified to actually select the companies was sometimes too short for the 2 or 3 clicks on the menu to toggle companies to occur, as those clicks are separated by nextTick(), i.e. a mix o
Original PR description
Before this commit, some tests of the SwitchCompanyMenu sometimes failed: - "companies can be logged in even if some toggled within delay" - "can toggle multiple companies at once" They failed…
Before this commit, some tests of the SwitchCompanyMenu sometimes failed: - "companies can be logged in even if some toggled within delay" - "can toggle multiple companies at once" They failed because the debounce delay between the first click to toggle a company and the moment the company service is notified to actually select the companies was sometimes too short for the 2 or 3 clicks on the menu to toggle companies to occur, as those clicks are separated by nextTick(), i.e. a mix of calls to setTimeout and requestAnimationFrame. In tests, we patch the debounce delay to 0 by default, and before this commit we set a delay of 50 in the two faulty tests. This commit fixes the issue by keeping the real delay in those tests (1s), as they aim at testing the fact that the user has the time to do multiple clicks before committing the company changes and reloading. Fixes runbot error 29962 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#142607 Forward-Port-Of: odoo/odoo#142544
Since the refactoring to owl, the stats in the left zone were not shown anymore and the hover was missing. This was because the method that fixes the xpath to match line by line the qweb, was done on a getter and not on the data itself. Now we replace in the prop value, from this way, in every place we use the getter, we have fixed the data with the xpath. /t/div -> /t[1]/div[1] Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior aft
Original PR description
Since the refactoring to owl, the stats in the left zone were not shown anymore and the hover was missing. This was because the method that fixes the xpath to match line by line the qweb, was done on a getter and not on the data itself. Now we replace in the prop value, from this way, in every place we use the getter, we have fixed the data with the xpath. /t/div -> /t[1]/div[1] 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#142515 Forward-Port-Of: odoo/odoo#142463
po_uom_id and uom_id should be from similar uom_group. It was not the case by default using `'default_detailed_type': 'service'`. This fix the issue 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#139298
Original PR description
po_uom_id and uom_id should be from similar uom_group. It was not the case by default using `'default_detailed_type': 'service'`. This fix the issue 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#139298
Welcome the missing reports for PLE: - PLE 5.1: General Journal - PLE 5.3: Chart of Accounts - PLE 6.1: General Ledger Forward-Port-Of: odoo/enterprise#50188
Original PR description
Welcome the missing reports for PLE: - PLE 5.1: General Journal - PLE 5.3: Chart of Accounts - PLE 6.1: General Ledger Forward-Port-Of: odoo/enterprise#50188