Friday, September 22, 2023
61 changes · master
Enhancements to existing features
Browser links that include selected company IDs are now easier to read. The separator between company IDs has changed so links no longer show encoded comma text, improving clarity when copying or sharing URLs.
Original PR description
Before this commit, cids in the url (in the hash part) were separated by a comma, which was encoded by encodeURIComponent as it is not considered as a safe character, resulting into "%2C" appearing in the url in between company ids. This was kind of ugly and made the url a bit hard to read. This commit uses "-" as separator for cids, which is a safe characters [1] to use in the url and which is thus left untouched by encodeURIComponent. AL request. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent#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
New spreadsheet pivots, lists, and Odoo charts now automatically reuse existing filter field matches when they are based on the same model. This reduces repetitive setup for users and helps keep spreadsheet filters consistent across related reports.
Original PR description
- When a new pivot is added, and if the user has already defined field matching in a previous pivot, the new pivot will inherit the field matching from the previous pivot as default values. - If multiple pivots are added from different models, will check the model of the new pivot against previous pivots. If the model matches, the field matching from the matching previous pivot will be used. If no matching model is found, the field matching will be left empty. - Same will also done in case of list and odoo chart. taskId: [3373163](https://www.odoo.com/web#id=3373163&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Email templates shown inside messages are now kept visually separate from the surrounding page. This prevents template formatting from being unintentionally changed, making email previews and message content more consistent for users.
Original PR description
Email templates are now rendered in shadow dom inside the messages. This fixes the issue where CSS styles of email templates were getting affected when they get rendered inside the message. Task-2978463 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Employee contract screens now use the term “Benefit” instead of “Advantage” for clearer, more familiar wording. This improves consistency in HR contract terminology and makes the interface easier for users to understand.
Original PR description
In this commit, I have made changes from 'Advantage' to 'Benefit' because I made modifications in the 'hr_contract_module'. This group is being utilized in 'hr_contract', so I updated the file accordingly. task-3374616
Purchase teams can now store vendor discounts directly on vendor pricelists and have them automatically carried into purchase orders. This helps ensure purchase prices reflect agreed discounts consistently, including correct tax-excluded calculations and future pricelist updates from confirmed orders.
Original PR description
In this commit ============== - Added the discount fields to the vendor pricelist and PO line models, making them optional and hidden. - Implemented automatic filling of the discount field on the PO line when the unit price is sourced from the vendor pricelist. - Implemented a mechanism to automatically populate the discount field on the PO line when the unit price is fetched from the vendor pricelist. - Modified the pricing logic to ensure the discount is applied to the tax-excluded price. - PO confirmation process to check if a pricelist already exists for the vendor. If not, a new pricelist line is created, including the discount if it is present. task - 3380306
Online shoppers can now choose product extra options that were previously only available through Sales. This helps businesses offer richer product customization directly on their eCommerce storefront, improving the buying experience and reducing manual follow-up.
Original PR description
[A previous commit](https://github.com/odoo/odoo/commit/5ca1da8ab33d4dd6a9ed0b6737e5d19f1a3ac9d2) introduces a new attribute `display_type`, `multi`, which allows users to define extra-options to products. But this option was only available in Sales. This commit allows eCommerce users to use this new attribute in the online shop. task-3497046
Google Calendar integration can now synchronize a single selected event instead of requiring the whole calendar to be synced. This helps features such as appointments retrieve Google Meet links faster and with less unnecessary calendar data processing, while adding checks to confirm a user's calendar is ready for Google syncing.
Original PR description
Purpose ======= Add the possibility to only synchronize one specific event of a user calendar instead of syncing the whole calendar. See sub commits for more details. Task-3285601
The spreadsheet app has been updated to a newer version, adding useful statistics formulas and a tool to trim extra whitespace from data. It also improves copying, exporting, drag-and-drop behavior, and error display, making spreadsheets more reliable and easier to use.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0b7527d5 [REL] 16.5.0-alpha.8 https://github.com/odoo/o-spreadsheet/commit/f8de9ab6 [IMP] Formulas: Add new statistics…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0b7527d5 [REL] 16.5.0-alpha.8 https://github.com/odoo/o-spreadsheet/commit/f8de9ab6 [IMP] Formulas: Add new statistics formulas https://github.com/odoo/o-spreadsheet/commit/1a685a08 [IMP] data: add the trim whitespace feature Task: 3356367 https://github.com/odoo/o-spreadsheet/commit/1f5bb485 [REM] spreadsheet_edition: remove dead edit text https://github.com/odoo/o-spreadsheet/commit/7956f571 [REF] drag&drop: stop using CUT/PASTE commands Task: 3502194 https://github.com/odoo/o-spreadsheet/commit/e26eee16 [FIX] GridOverlay: Hovering over a figure should not open popovers Task: 3475001 https://github.com/odoo/o-spreadsheet/commit/33b04fb0 [FIX] deepEquals: fix simple type comparison Task: 3479451 https://github.com/odoo/o-spreadsheet/commit/f7e58774 [FIX] clipboard: copy/paste of CF in another sheet Task: 3479451 https://github.com/odoo/o-spreadsheet/commit/be185413 [IMP] demo: disable HTML quirks mode Task: 3506565 https://github.com/odoo/o-spreadsheet/commit/a529d61b [IMP] export: do not export defaulf style values Task: / https://github.com/odoo/o-spreadsheet/commit/4fe9e1a6 [IMP] build: add banner https://github.com/odoo/o-spreadsheet/commit/dd52c9b0 [FIX] build: restore commit hash https://github.com/odoo/o-spreadsheet/commit/c2640de1 [FIX] ErrorToolTip: fix error tooltip long text Task: 3328557
Payment forms now show available payment methods directly, instead of asking customers to choose a payment provider first. This makes checkout simpler, gives administrators better control over payment ordering and availability, and helps Odoo record the selected payment method for follow-up actions like refunds or saved payment details.
Original PR description
**[CLN] payment(_*): correct code styling inconsistencies** This commit mainly removes the extra indent level left over after commit odoo/odoo@8ec2e8cf807b3d3a8f84b8583887cb4b6a2828c1. It also cleans…
**[CLN] payment(_*): correct code styling inconsistencies** This commit mainly removes the extra indent level left over after commit odoo/odoo@8ec2e8cf807b3d3a8f84b8583887cb4b6a2828c1. It also cleans up purely cosmetic code styling inconsistencies. --- **[FIX] payment(_*): make a proper usage of async and promises** Several functions were: - called with `await` while there are synchronous; - declared as synchronous while they should have been asynchronous; - declared as synchronous but their overrides were async; - explicitly encapsulating their return values in a `Promise` when it was unnecessary. This commit also cleans up a few mistakes in comments and docstrings. --- **[REM] payment: remove unused payment method icons and SCSS rules** --- **[IMP] payment, \*: replace providers with payment methods in payment forms** Before this commit, the payment providers (e.g., Stripe, Adyen...) available for payment were displayed on the payment forms. The customer had to select one to process their payment. After that, the customer had to select their preferred payment method (e.g., Credit Card, Bancontact...) from a list of payment methods supported by the selected provider over which the website administrator had close to no control. This was making the payment forms confusing because the payment methods were displayed sometimes more than once, if at all, in a non-controlled order, and behind the selection of a payment provider that customers should not have to deal with. As the payment method was selected in an iframe or directly on the provider's website, the information on the selection payment method was not available in Odoo. This posed many problems, among which were the impossibility of assessing whether a specific feature (e.g., tokenization, refunds, manual capture...) was available, not being able to easily identify payment tokens through the payment method logo, listing available payment methods on the website, sorting and fine-grained configuration of the available payment method, subpar payment method-specific display on the payment form (e.g., PayPal that requires displaying a "Pay with PayPal" button), etc. In this commit, the payment providers are thus replaced by the payment methods on the payment forms. All contextually available (depending on the country, currency, requested feature...) payment methods are displayed one after the other on a single-level list and in the order configured by the website administrator. Each payment method is "powered by" (i.e., linked) to a single payment provider: the first one, by model order, to support it. This allows, for example, offering the PayPal payment method through Mollie, which charges low processing fees, while also offering Klarna through Stripe, which supports more payment methods but charges higher processing fees. While doing so, the two different payment forms, "Checkout" and "Manage", are also merged together in a new, configurable case-by-case, payment form that is entirely redesigned to offer a better user experience. After payment, the information on the selected payment method is saved on the transaction and eventual payment record and updated with the information received from the provider. --- task-2882677 See also: - https://github.com/odoo/enterprise/pull/40666 - https://github.com/odoo/upgrade/pull/5103 - https://github.com/odoo/documentation/pull/5717
This change lets Odoo administrators define which screen layout should open first on mobile for a given action, instead of relying on indirect view ordering rules. It makes mobile navigation more predictable and allows desktop and mobile defaults to differ without workarounds.
Original PR description
Up until this commit, which view was displayed by default on mobile was somewhat of a lottery. Initially, only kanban views were considered as 'more adapted to mobile devices' and used as a main…
Up until this commit, which view was displayed by default on mobile was somewhat of a lottery. Initially, only kanban views were considered as 'more adapted to mobile devices' and used as a main fallback to display records who had a kanban view in the window action definition. The the concept of 'mobile-friendly view' was extended to map and grid so that these views could take precedence over the kanban view in specific circumstances (indsutry_fsm and timesheet_grid, both of which are enterprise edition apps) - basically they were marked as mobile-friendly not because they *are*, but because it was the only way to override the kanban override. But this comes with its lot of problems and limitations, namely that the mobile friendly view will be found based on the order of view modes for a window action, so if you have a window action with the view modes `kanban,map,tree,form`, you will never be able to have e.g. the kanban view shown on desktop by default and the map view on mobile. This commit introduces the notion of a 'default mobile view' on window actions so that one may decide on an *arbitrary* view mode to use on mobile for an action - without impacting the ordering of views on other models, etc. Task-3460374 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
Users can now duplicate multiple records directly from a list view using the action menu. This saves time for teams that need to create similar records in bulk and makes the list view workflow more complete.
Original PR description
Include the 'duplicate' action in the action menu in list view. The copy_batch method will call the copy method with a loop to keep any existing override. TASK-ID: 3456679 Description of the issue/feature this PR addresses: Allow to mass duplicate in the list view Current behavior before PR: No duplicate in list views Desired behavior after PR is merged: Duplicate recards from the list views --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now lets users enter their Adyen account URL prefix instead of manually building several API URLs. This reduces setup effort and helps prevent configuration mistakes when connecting Adyen payments.
Original PR description
Before this commit, users were required to compute the API URLs, which is specific to each Adyen account, themselves. After this commit, users will be able to copy their account prefix from Adyen to automatically generate the API URLs. task-3338126 See also: - https://github.com/odoo/upgrade/pull/4876
Users can now choose which website domain is used when sharing Documents workspaces or files. This helps businesses present shared links under the right brand or storefront while keeping the shared content accessible as before.
Original PR description
In some cases, it might be useful to be able to choose which domain you want to use to share a workspace or file(s) in Documents. For instance, you might have two eshops with high-ends products with…
In some cases, it might be useful to be able to choose which domain you want to use to share a workspace or file(s) in Documents. For instance, you might have two eshops with high-ends products with big margins on one hand and low-end products with low-margin on the other. For obvious reasons, you don't want people to see that as they could complain about it. For those reasons, when sharing documents or a folder, the user can now choose the domain of the shared URL by selecting on which website the link is shared. By default, the website of the company folder is selected. If there is no company on that folder or the company has no website, the current company website is selected (which might be "False"). The user can override the default choice. The base URL is determined by the website associated with the sharing. If the website is set and has a "domain", it is used as base URL. If not, the web.base.url of the config parameters is used. The shared URL is automatically updated when the website is changed. When deleting a website, all sharings associated with it are deleted as well. Note that no matter the website chosen, the shared documents/folder can be accessed with any domain configured on the server instance. Task-3325062
Odoo now uses a clearer and more predictable way to choose the right view on mobile devices. This improves the mobile experience for field service, timesheets, grid, and map workflows by showing mobile-appropriate screens where needed.
Original PR description
A new, deterministic mechanism to decide which view should be displayed in a mobile environment for window actions has been created. This allows us to remove the 'mobile-friendly' flag for grid and map views which were added to override the kanban views in some cases. The modules that use these views (timesheet_grid and industry_fsm) have been modified so that the proper mobile view is set on the window action where needed. Task-3460374
Subscription and SEPA Direct Debit payment screens now focus on payment methods rather than payment providers, making checkout and payment management clearer for customers. The update also cleans up related payment form behavior and tests, reducing the risk of payment flow inconsistencies.
Original PR description
**[CLN] payment(_\*): correct code styling inconsistencies** This commit mainly removes the extra indent level left over after commit https://github.com/odoo/enterprise/commit/96148dbf. --- **[FIX] payment(_\*): make a proper usage of promises** Several functions were explicitly encapsulating their return values in a `Promise` when it was unnecessary. --- **[IMP] payment_sdd, sale_subscription: replace providers with payment methods in payment forms** See the community PR for more details. --- task-2882677 See also: - https://github.com/odoo/odoo/pull/120446 - https://github.com/odoo/upgrade/pull/5103 - https://github.com/odoo/documentation/pull/5717
Belgian companies can now import CODA bank statements that use foreign IBAN bank accounts. This removes a previous import error and makes CODA processing more flexible for businesses with non-Belgian accounts.
Original PR description
Implements support for CODA files with foreign IBANs for Belgian companies. Previously, the CODA module could only handle Belgian IBANs, resulting in an "Error R1002: Foreign bank accounts with IBAN structure are not supported" when attempting to process CODA files with a non-Belgian IBAN This limitation hampered Belgian companies that have accounts with foreign IBANs. Task-3493359
Appointment organizers can now choose which videoconference link is sent when clients book an appointment: Odoo Discuss, Google Meet, or no link. This gives teams more control over the client booking experience and helps avoid duplicate calendar entries when Google Meet is used.
Original PR description
Purpose ======== Give full control to users on which link will be used for the events Odoo will generate when appointments are booked. Specifications ============ Add a selection field called "Videoconference Link" in the appointment form view under the appointment location. This field will allow the user to specify which videocall link to give to their clients when an appointment from this appointment type is booked. The default videocall link is the Odoo Discuss one. The user could also choose a Google Meet one or to not give any link at all. Task-3285601
This update replaces the term "advantage" with "benefit" across employee salary package screens, menus, payroll configuration, and related records. The clearer wording makes compensation options easier for HR teams and employees to understand without changing the underlying process.
Original PR description
In this commit, We have replaced the term advantage with benefit. We made changes to the following - Payroll configuration - Menu - Model name task-3374616
Web links now show company identifiers with dashes instead of commas, making URLs easier to read and share. This is a small consistency improvement that supports related web changes without altering business workflows.
Original PR description
This commit is the counter part of odoo/odoo#136104 where we replace the comma separator of cids in the url by a "-".
New spreadsheet pivots, lists, and charts now reuse existing field matching settings when they come from the same model. This saves users from repeatedly configuring the same filter connections and reduces setup errors when building reports.
Original PR description
- When a new pivot is added, and if the user has already defined field matching in a previous pivot, the new pivot will inherit the field matching from the previous pivot as default values. - If multiple pivots are added from different models, will check the model of the new pivot against previous pivots. If the model matches, the field matching from the matching previous pivot will be used. If no matching model is found, the field matching will be left empty. - Same will also done in case of list and odoo chart. taskId: [3373163](https://www.odoo.com/web#id=3373163&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Resolved issues and error corrections
The activity view now paginates records correctly when many items have multiple activities, so users see the expected number of records on each page. This prevents missing or confusing activity results when navigating large activity lists.
Original PR description
This solves the following problem: - Add 150 records with 2 activities each (ex. A call and a to do) - Go to the activity view (ex.: event through the systray) and clear filter - Only 50 of the 150 records are displayed (instead of 100) - Going to the next page, only 2 are displayed (instead of ~50) (will depends on the data already present) Technical notes: Not all activities were displayed because the search limit was applied on the activity search instead of searching all activity related to the records. The method fetchActivityData was doing half of the job because it was not assigning the activity data fetch on the server to the instance variable activityData, which was causing strange behavior when clicking on next page. To simplify and correct the code, that logic has been moved to that method instead of relying on the caller to do that assignation. Task-3508744
Code cleanup and technical improvements
The Discuss messaging system now uses clearer model relationships to manage messages, threads, attachments, live chat, and related records. This is an internal improvement that reduces complexity, helps prevent data cleanup bugs when records are deleted, and should make future messaging and live chat changes faster and safer to build.
Original PR description
Before these commits, discuss relations were difficult to maintain: relations are named by local ids and ids of record, and we must juggle all the time between these local ids and the records. Also…
Before these commits, discuss relations were difficult to maintain: relations are named by local ids and ids of record, and we must juggle all the time between these local ids and the records. Also when the record is deleted, we must add lots of code to properly delete all relations on this record. Some dedicated services that manage relations on models had complicated data-structures, such as `messageIdsByChannelId` in `message_pin` service for something equivalent to `channel.pinnedMessages`.
This commit improves the readability and maintainability of relations in discuss models:
Can define a "one" relation on a discuss model:
```js
class Message extends Record {
author = Record.one("Persona");
}
```
Relational fields can be used to uniquely identify records:
```js
class ChatWindow extends Record {
static id = "thread";
thread = Record.one("Thread");
}
```
There's also support for many relations:
```js
class Thread extends Record {
messages = Record.many("Messages");
}
// ...
thread.messages = messages;
thread.messages.push(message);
thread.messages[0];
thread.messages.filter((msg) => !msg.isEmpty);
```
And support for patching models to add relations:
```js
patch(Thread.prototype, {
setup() {
this.pinnedMessages = Record.many("Messages");
},
});
```
Typing of models and their patches is managed in a `@types/models.d.ts` file:
```ts
declare module "models" {
export interface Thread {
pinnedMessages: Message[],
}
}
```
When a record is deleted, it is automatically removed to all its inverse relations:
```js
thread.messages = [message];
message.delete();
thread.messages; // []
```
Introducing relational fields is a key step to reduce complexity of discuss code in the models, making code less prone to bugs, and simplify development of new features that require using a lot of relations on models.
https://github.com/odoo/enterprise/pull/47745Miscellaneous changes
This traceback arises when the user clicks the `Create Employee` button from `Recruitment` To reproduce this issue: 1) Install `hr_recruitment` and `Website` 2) Open `Recruitment` and click the `Job Page` button of any published `Job Position`. 3) Click on `Apply Now` and apply for that job. 4) Now open that job application from `Recruitment/Application/By job positions` 5) Change the stage from `New` to `Contract Signed`. 6) A button `Create Employee` will appear, click on that
Original PR description
This traceback arises when the user clicks the `Create Employee` button from `Recruitment` To reproduce this issue: 1) Install `hr_recruitment` and `Website` 2) Open `Recruitment` and click the `Job…
This traceback arises when the user clicks the `Create Employee` button from `Recruitment`
To reproduce this issue:
1) Install `hr_recruitment` and `Website`
2) Open `Recruitment` and click the `Job Page` button of any published
`Job Position`.
3) Click on `Apply Now` and apply for that job.
4) Now open that job application from `Recruitment/Application/By job positions`
5) Change the stage from `New` to `Contract Signed`.
6) A button `Create Employee` will appear, click on that.
Error:-
```
ProgrammingError: can't adapt type 'res.country'
File "odoo/http.py", line 2134, in __call__
response = request._serve_db()
File "odoo/http.py", line 1710, 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 1737, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1938, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 233, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 717, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 34, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 26, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "addons/hr_recruitment/models/hr_applicant.py", line 581, in create_employee_from_applicant
employee = self.env['hr.employee'].create(self._get_employee_create_vals())
File "<decorator-gen-457>", line 2, in create
File "odoo/api.py", line 409, in _model_create_multi
return create(self, [arg])
File "addons/project_timesheet_holidays/models/hr_employee.py", line 12, in create
employees = super().create(vals_list)
File "<decorator-gen-361>", line 2, in create
File "odoo/api.py", line 410, in _model_create_multi
return create(self, arg)
File "addons/hr_recruitment/models/hr_employee.py", line 27, in create
employees = super().create(vals_list)
File "<decorator-gen-468>", line 2, in create
File "odoo/api.py", line 410, in _model_create_multi
return create(self, arg)
File "addons/hr_skills/models/hr_employee.py", line 21, in create
res = super(Employee, self).create(vals_list)
File "<decorator-gen-189>", line 2, in create
File "odoo/api.py", line 410, in _model_create_multi
return create(self, arg)
File "addons/hr/models/hr_employee.py", line 369, in create
employees = super().create(vals_list)
File "<decorator-gen-355>", line 2, in create
File "odoo/api.py", line 410, in _model_create_multi
return create(self, arg)
File "addons/hr_holidays/models/hr_employee.py", line 198, in create
return super().create(vals_list)
File "<decorator-gen-124>", line 2, in create
File "odoo/api.py", line 410, in _model_create_multi
return create(self, arg)
File "addons/mail/models/mail_thread.py", line 253, in create
threads = super(MailThread, self).create(vals_list)
File "<decorator-gen-169>", line 2, in create
File "odoo/api.py", line 410, in _model_create_multi
return create(self, arg)
File "addons/resource/models/resource_mixin.py", line 49, in create
return super(ResourceMixin, self.with_context(check_idempotence=True)).create(vals_list)
File "<decorator-gen-10>", line 2, in create
File "odoo/api.py", line 410, in _model_create_multi
return create(self, arg)
File "odoo/models.py", line 4261, in create
records = self._create(data_list)
File "odoo/models.py", line 4464, in _create
cr.execute(
File "odoo/sql_db.py", line 320, in execute
res = self._obj.execute(query, params)
File "psycopg2/extensions.py", line 113, in getquoted
pobjs = [adapt(o) for o in self._seq]
File "psycopg2/extensions.py", line 113, in <listcomp>
pobjs = [adapt(o) for o in self._seq]
```
On the `create_employee_from_applicant` method, the employee record is created by using
`_get_employee_create_vals` method.
In that `_get_employee_create_vals` method, `private_country_id` is created from
`address_sudo.country_id` which is an object.
See:-
https://github.com/odoo/odoo/blob/a5911b7d560a4e259570cf9d46fff5fb286e3d62/addons/hr_recruitment/models/hr_applicant.py#L587-L605
Here in the above use-case instead of passing `ID`, an `Object` is passed.
Which leads to the above traceback.
Sentry-4450017781
Forward-Port-Of: odoo/odoo#135596This fix ensures several field widgets refresh correctly when records are updated, preventing stale or incorrect information from being shown. It improves reliability in accounting, inventory, manufacturing, email marketing, and general web interface screens affected by recent model changes.
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
The web editor now avoids a crash that could happen when users switch between records containing editable HTML content. This makes navigation between items such as tasks or Knowledge articles more reliable and prevents interruptions while editing or reviewing content.
Original PR description
How to reproduce: - open a record with an html_field (i.e. todo or a Knowledge article) - switch back and forth with the pager or the knowledge sidebar between 2 records Current behavior: - traceback…
How to reproduce: - open a record with an html_field (i.e. todo or a Knowledge article) - switch back and forth with the pager or the knowledge sidebar between 2 records Current behavior: - traceback `this._elementHookMap.get(element)` is undefined Expected behavior: - no traceback Technical explanation: When changing the editable content (i.e. `resetContent` when changing record), there is no guarantee that `_intersectionObserverCallback` (intersectionObserver) won't be called before `_updateHooks` (mouseMove/resize after a mutation occured). This is an issue because `this._elementHookMap` may not yet have a hook element related to the editable element which stops intersecting the document. If such a case occurs, the next `_updateHooks` should be called when the mutationObserver flags `_resetHooksNextMouseMove` to `true` and then after the next `mouseMove` (or after the next resize). Ignore the hook style update if there is currently no hook for an element which stops intersecting. Remove a redundant check in `_getMovableElements` task-3506666
This update restores compatibility for existing links that use the previous company identifier format in the web address. It helps ensure links already sent in emails or saved by users continue to open correctly after the newer URL format was introduced.
Original PR description
Commit [1] changed the separator of cids in the url to make it better looking, by using a character that doesn't need to be encoded (namely, "-" instead of ","). However, by doing so, urls still using the former separator couldn't be correctly parsed anymore. This commit adds a small backward compatibility layer, s.t. links in emails for instance keep working as before. [1] abae4d4a5ce2a420581a0ce1b52349457019c66d Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents survey matrix row and column answers from showing incorrect labels or causing errors in survey response views. It also removes an unnecessary way to create answers outside a question, reducing confusion for users managing surveys.
Original PR description
We here fix the `SurveyQuestionAnswer._compute_display_name` method introduced in 55fa52be. `survey.question.answers` used as matrix rows and columns require different treatment as they are not used in triggers but are both shown on the `survey.user.input.line` views, where the display shouldn't change (nor cause a crash). It also doesn't make much sense to create answers outside the context of a question, so we remove the button that already wasn't shown on the tree view. As users may not fully upgrade their views though, we added a fallback question title in `compute_display_name`too. Task-3495142
Point of Sale orders shared between registers now include products even when the receiving register had not loaded them yet. This prevents incomplete orders and helps staff process cross-register sales accurately.
Original PR description
Prior to this commit if an order was sent to another pos with the cross order, if the product was missing in the target pos, the product will be missing in the order. This commit loads the products that are missing for the cross orders. Task-3504316
This update adjusts internal tests so they verify the final back button behavior instead of counting how many times supporting code is called. This reduces false test failures during development without changing customer-facing features.
Original PR description
These tests assert overrideBackButton() is called only once. This makes the assumption that it tests only a single component that overrides the back button. Discuss tests mount many components at…
These tests assert overrideBackButton() is called only once. This makes the assumption that it tests only a single component that overrides the back button. Discuss tests mount many components at once, so that it test a functionally meaningful flows rather than tiny and irrelevant unit tests. Due to backbutton being override in many components, like chat windows and messaging menu, tests were prone to call the override back buttons many times. This is especially true in chat window tests, as opening a chat window usually requires to make use of the messaging menu, hence more than 1 override back button call. This commit fixes the tests by checking only the resulting state of enabled override back button. Note that these tests still sucks, because that doesn't mean the override is made by the component we really care... And even the design of the test sucks: it should actually simulate back button and assert expected UI changes from that. Since these tests were posing an immediate problem for a dev in progress, it was best to keep the tests while quick fixing the problem at hand. https://github.com/odoo/odoo/pull/134884
This update modernizes automated tests across Odoo's messaging-related areas by replacing older test matching patterns. It helps keep the test suite reliable and easier to maintain without changing how users interact with the product.
Original PR description
* = web, sms
This update reorganizes and renames internal messaging data structures to make Discuss-related code easier to maintain and extend. It prepares the messaging, live chat, calendar, and HR areas for future improvements without changing expected user-facing behavior.
Original PR description
https://github.com/odoo/enterprise/pull/45090
The mail and live chat discuss components were reorganized to manage internal records more consistently. This prepares the messaging system for safer cleanup of deleted records, improving maintainability without introducing a direct user-facing workflow change.
Original PR description
1. Introduce `static id` to all models, to uniquely identify a record in a model. This allows normalizing discuss store for all models, which helps as preparation for managing record deletion. Can…
1. Introduce `static id` to all models, to uniquely identify
a record in a model. This allows normalizing discuss store
for all models, which helps as preparation for managing
record deletion. Can also be combined
```js
class Message {
static id = "id";
id;
}
class Thread {
static id = AND("model", "id");
}
```
2. Introduce `Model.get()` to easily get a record of model
from data that can identify the record. This prevent leaking
the way the record are stored in `records`, as now all records
are indexed by localId, and localId is technical detail.
```js
Message.get(messageId);
Thread.get({ model: "discuss.channel", id: 1 });
```
3. Introduce `record.delete()` to easily delete a record from
from the `static records` object.
```js
// before
delete this.store.Model.records[record.localId];
// after
record.delete();
```
4. Introduce `Record.one()` relational field on model.
This allow storing only the local id internally, and there are
automatic `get`/`set` to get the related record. This prepares
support of record deletion that would automatically delete
all relational fields, in a follow-up PR.
Relational fields can be used to uniquely identify records.
```js
class Message {
author = one();
}
class ChatWindow {
static id = "thread";
thread = one();
}
```This internal refactoring simplifies how Discuss-related data structures are defined and stored in Odoo. It reduces duplicate code across mail, live chat, and calendar integrations, making future messaging improvements easier and less error-prone without changing day-to-day user workflows.
Original PR description
https://github.com/odoo/enterprise/pull/46170 Discuss models are hard to use in discuss code: they need to define a model define a `insert()` function in a service, and define a store entry. For…
https://github.com/odoo/enterprise/pull/46170
Discuss models are hard to use in discuss code: they need to define a model define a `insert()` function in a service, and define a store entry. For example, with threads:
```js
// thread_model.js
class Thread {}
// store_service.js
threads: {},
// thread_service.js
class ThreadService {
insert(data) {}
}
```
This commit eases defining a Model by just adding code in the model file:
```js
class Thread extends Record {}
discussModelRegistry.add(Thread.name, Thread)
```
This will automatically add a store entry named with the ModelName, e.g. `this.store.Thread`. This is the shape of this store entry:
```
store: {
[ModelName]: {
records: {}
insert(data) {}
findById(data) {}
}
}
```
Records in a model must be uniquely identified. Fields that uniquely define a record in a model is defined in the class of model:
```js
class Thread extends Record {
static id = ["model", "id"];
}
```This update removes older test utilities used for file handling and moves tests to the newer shared approach. It helps keep the codebase easier to maintain and reduces duplicated testing infrastructure, with no expected direct impact on users.
Original PR description
\* = mrp https://github.com/odoo/enterprise/pull/47716
This update cleans up internal automated tests for Belgian payroll accounting and documents by replacing older testing utilities. It helps keep quality checks reliable and easier to maintain without changing day-to-day product behavior.
Original PR description
https://github.com/odoo/odoo/pull/136141
## Steps to reproduce: 1. Have 2 companies, and select the one w/ the highest ID 2. Create a new product tracked by lot + expiration date 3. Receive product 4. Set the received lot's expiration and alert dates in the past 5. Inventory > Operations > Run scheduler ## Before this commit: An activity is created on the lot for OdooBot, despite the product's responsible set to the current user. It happens because the default value for `responsible_id` is the current user, but the value is o
Original PR description
## Steps to reproduce: 1. Have 2 companies, and select the one w/ the highest ID 2. Create a new product tracked by lot + expiration date 3. Receive product 4. Set the received lot's expiration and alert dates in the past 5. Inventory > Operations > Run scheduler ## Before this commit: An activity is created on the lot for OdooBot, despite the product's responsible set to the current user. It happens because the default value for `responsible_id` is the current user, but the value is only set for the current company. When the scheduler runs, it doesn't set the company; therefore, it takes the product's responsible user for the company with the lowest ID, which is not set. ## After this commit: The activity is created for the product's responsible user using the lot's company. opw-3489340 Forward-Port-Of: odoo/odoo#135361
This commit excludes off-balance accounts from appearing in tax repartition lines. Previously, off-balance accounts were included in the selection, which was causing confusion and unnecessary clutter in the interface. The need for this change was raised due to the observation that off-balance accounts are never actually used in tax repartition scenarios. Including them only complicates the account selection process without adding any functional value. --- I confirm I have signed the
Original PR description
This commit excludes off-balance accounts from appearing in tax repartition lines. Previously, off-balance accounts were included in the selection, which was causing confusion and unnecessary clutter in the interface. The need for this change was raised due to the observation that off-balance accounts are never actually used in tax repartition scenarios. Including them only complicates the account selection process without adding any functional value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#135827 Forward-Port-Of: odoo/odoo#135763
there is a loophole that allows the same third-party check to be used for multiple outbound payments. This issue causes data inconsistencies and disrupts the expected behavior of the financial workflow, thereby undermining the integrity of the accounting processes. In order to address it a constraint was introduced on the l10n_latam_check_id field. This constraint is triggered whenever a payment transaction involves the use of 'out_third_party_checks' as the payment method. The system now con
Original PR description
there is a loophole that allows the same third-party check to be used for multiple outbound payments. This issue causes data inconsistencies and disrupts the expected behavior of the financial workflow, thereby undermining the integrity of the accounting processes. In order to address it a constraint was introduced on the l10n_latam_check_id field. This constraint is triggered whenever a payment transaction involves the use of 'out_third_party_checks' as the payment method. The system now conducts a search to identify any pre-existing payments that might be using the same third-party check. If a duplicate use of a check is detected, a ValidationError is promptly raised, effectively blocking the transaction. Task-3503556 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#135815
PR #134787 was introduced to fix an error with product template attribute values. However, when moving `ptavId.concat` into the if statement, it missed the fact that the function returns a copy rather than editing in place. This means that the line achieved nothing. opw-3513820 Forward-Port-Of: odoo/odoo#136082
Original PR description
PR #134787 was introduced to fix an error with product template attribute values. However, when moving `ptavId.concat` into the if statement, it missed the fact that the function returns a copy rather than editing in place. This means that the line achieved nothing. opw-3513820 Forward-Port-Of: odoo/odoo#136082
Steps to reproduce: ------------------- - add an allocation for an employee; - add a leave with this allocation; - validate the leave; - refuse the leave; - in action menu, click on "Time off Analysis by Employee and Time Off Type". Issue: ------ The report does not take into account refused allocations and leaves. Solution: --------- Add a condition to take a number of days equal to zero if the allocation or leave is in a refused state. Handled the case where no record is fou
Original PR description
Steps to reproduce: ------------------- - add an allocation for an employee; - add a leave with this allocation; - validate the leave; - refuse the leave; - in action menu, click on "Time off Analysis by Employee and Time Off Type". Issue: ------ The report does not take into account refused allocations and leaves. Solution: --------- Add a condition to take a number of days equal to zero if the allocation or leave is in a refused state. Handled the case where no record is found for leave (with `COALESCE` because `value - NULL = NULL`). opw-3503617 Forward-Port-Of: odoo/odoo#135882 Forward-Port-Of: odoo/odoo#135748
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#126222
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 Forward-Port-Of: odoo/odoo#126222
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#103864
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 Forward-Port-Of: odoo/odoo#103864
adress both use cases in : https://github.com/odoo/odoo/commit/ed2849a55c1463689cbc201a782b0200207bfd37 and https://github.com/odoo/odoo/commit/4248aac2d224363a6ac4a59881bdb7c321623e4b button should be red if there's no qty in stock but still be green if the qty was reserved for the move Forward-Port-Of: odoo/odoo#135937 Forward-Port-Of: odoo/odoo#135049
Original PR description
adress both use cases in : https://github.com/odoo/odoo/commit/ed2849a55c1463689cbc201a782b0200207bfd37 and https://github.com/odoo/odoo/commit/4248aac2d224363a6ac4a59881bdb7c321623e4b button should be red if there's no qty in stock but still be green if the qty was reserved for the move Forward-Port-Of: odoo/odoo#135937 Forward-Port-Of: odoo/odoo#135049
Steps to reproduce ================== - Use a mobile viewport - Create a quotation - Add an order line - Set a packaging -> The Packaging Quantity field is missing The same happens on purchase orders --- opw-3504829 Forward-Port-Of: odoo/odoo#136122 Forward-Port-Of: odoo/odoo#135928
Original PR description
Steps to reproduce ================== - Use a mobile viewport - Create a quotation - Add an order line - Set a packaging -> The Packaging Quantity field is missing The same happens on purchase orders --- opw-3504829 Forward-Port-Of: odoo/odoo#136122 Forward-Port-Of: odoo/odoo#135928
Two fixes: 1. use same digits configuration as currency_rate The rate used by the journal items is defined by the aml field currency_rate We use the same digits (no digits) of that field for consistency https://github.com/odoo/odoo/blob/a719faf517b363ffc57018bdcf27c1c10e687315/addons/account/models/account_move_line.py#L115 2. Use the same method and date used to compute the rate on aml field currency_rate VIDEO: https://drive.google.com/file/d/1GGza0waSsUYzPoPhhPONFi6Rf9LUna92/view
Original PR description
Two fixes: 1. use same digits configuration as currency_rate The rate used by the journal items is defined by the aml field currency_rate We use the same digits (no digits) of that field for consistency https://github.com/odoo/odoo/blob/a719faf517b363ffc57018bdcf27c1c10e687315/addons/account/models/account_move_line.py#L115 2. Use the same method and date used to compute the rate on aml field currency_rate VIDEO: https://drive.google.com/file/d/1GGza0waSsUYzPoPhhPONFi6Rf9LUna92/view --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#134709
Current behavior: If you had 2 products with different expense account and using real-time inventory valuation, there was an error when validating the picking. This was happening because move_vals we were trying to assign multiple moves to one pos_order here https://github.com/odoo/odoo/blob/95cec6ea3daebce6491cc2a8a69d9688322989ba/addons/point_of_sale/models/stock_picking.py#L155 The account move is actually reserved for the invoicing of the order. So we just need to remove that line. S
Original PR description
Current behavior: If you had 2 products with different expense account and using real-time inventory valuation, there was an error when validating the picking. This was happening because move_vals we…
Current behavior: If you had 2 products with different expense account and using real-time inventory valuation, there was an error when validating the picking. This was happening because move_vals we were trying to assign multiple moves to one pos_order here https://github.com/odoo/odoo/blob/95cec6ea3daebce6491cc2a8a69d9688322989ba/addons/point_of_sale/models/stock_picking.py#L155 The account move is actually reserved for the invoicing of the order. So we just need to remove that line. Steps to reproduce: - Create a product with expense account A - Create a product with expense account B - Make sure both products are set to real-time inventory valuation - Activate ship later in the PoS - Open the PoS and add both products to the order - Validate the order with ship later and no invoice - Close the PoS and try to validate the picking of the order. opw-3428033 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#135909 Forward-Port-Of: odoo/odoo#133301
Downpayment might have been determined by a fixed amount set by the user. This amount is tax included. This can lead to rounding issues. E.g. a user wants a 100€ DP on a product with 21% tax. 100 / 1.21 = 82.64, 82.64 * 1,21 = 99.99 This is already corrected by adding/removing the missing cents on the DP invoice but it would still be wrong when creating the final invoice (as it is based on the actual base amount + tax of the SO DP's) opw-3466409 Forward-Port-Of: odoo/odoo#135262
Original PR description
Downpayment might have been determined by a fixed amount set by the user. This amount is tax included. This can lead to rounding issues. E.g. a user wants a 100€ DP on a product with 21% tax. 100 / 1.21 = 82.64, 82.64 * 1,21 = 99.99 This is already corrected by adding/removing the missing cents on the DP invoice but it would still be wrong when creating the final invoice (as it is based on the actual base amount + tax of the SO DP's) opw-3466409 Forward-Port-Of: odoo/odoo#135262
Current behaviour: --- Traceback when trying to create a new external identifier Steps to reproduce: --- 1. Activate the developer mode 2. Go to settings 3. Technical > External Identifiers 4. Click on "New" 5. Traceback Cause of the issue: --- Introduced by https://github.com/odoo/odoo/commit/3c62ca1eb96d571b2b686b5caee370324c589ab4 When computing display_name, the model can be false, and not be in self.env Co-authored-by: Rémy Voet <ryv@odoo.com> opw-3489581 --- I co
Original PR description
Current behaviour: --- Traceback when trying to create a new external identifier Steps to reproduce: --- 1. Activate the developer mode 2. Go to settings 3. Technical > External Identifiers 4. Click on "New" 5. Traceback Cause of the issue: --- Introduced by https://github.com/odoo/odoo/commit/3c62ca1eb96d571b2b686b5caee370324c589ab4 When computing display_name, the model can be false, and not be in self.env Co-authored-by: Rémy Voet <ryv@odoo.com> opw-3489581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#136142
When you are using a different currency in a PoS config, invoicing an order that was created in a previous session, causes an unbalanced entry error. Because the amount_currency and balance of the payment moves are incorrect. Steps to reproduce: - Create POS config with currency other than company currency - Create order in a session - Close the session - Open a new session - Load paid orders - Try to invoice the created order opw-3479292 --- I confirm I have signed the CLA and
Original PR description
When you are using a different currency in a PoS config, invoicing an order that was created in a previous session, causes an unbalanced entry error. Because the amount_currency and balance of the payment moves are incorrect. Steps to reproduce: - Create POS config with currency other than company currency - Create order in a session - Close the session - Open a new session - Load paid orders - Try to invoice the created order opw-3479292 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#135280
To reproduce the issue: 1. In Settings, enable "Multi Routes" 2. Edit the warehouse: - Manufacture: 2 steps 3. Create three storable products P1, P2, P3 4. Create and confirm a MO for 1 x P1 with 1 x P2 - It should create the PBM picking 5. Add a component line for P3 6. (Because the MO is locked, the user can not edit the 'to consume' quantity, so) Unlock the MO 7. Set the 'to consume' qty to 1 8. Save the MO Error: P3 is not added to PBM picking. Worst: suppose the user
Original PR description
To reproduce the issue: 1. In Settings, enable "Multi Routes" 2. Edit the warehouse: - Manufacture: 2 steps 3. Create three storable products P1, P2, P3 4. Create and confirm a MO for 1 x P1 with 1 x…
To reproduce the issue: 1. In Settings, enable "Multi Routes" 2. Edit the warehouse: - Manufacture: 2 steps 3. Create three storable products P1, P2, P3 4. Create and confirm a MO for 1 x P1 with 1 x P2 - It should create the PBM picking 5. Add a component line for P3 6. (Because the MO is locked, the user can not edit the 'to consume' quantity, so) Unlock the MO 7. Set the 'to consume' qty to 1 8. Save the MO Error: P3 is not added to PBM picking. Worst: suppose the user does the internal transfer and then checks the availability of P3, the line will still be unreserved Step 6, when unlocking the MO, it also triggers a save. As a result, the SM for P3 is created with its demand defined to 0. When adding such SM, we do several things through this method call: https://github.com/odoo/odoo/blob/be0b61cbaf3d3b7082aca8f96dcf8a6ee7885fea/addons/mrp/models/mrp_production.py#L776 - We will adapt its procure method (here, because of 2-steps manufacturing, it will be MTO) - We will confirm the new SM -> we will run a procurement for a zero quantity -> it will not generate any new SM Then, when updating the SM quantity (step 7), nothing will run a new procurement. Moreover, this also explains why trying to reserve the SM does not work: it's an MTO one, but it does not have any `move_orig_ids`, so it is not possible to assign it. Solutions: - It should be possible to edit the 'to consume' qty of a new SM, even on a locked and confirmed MO - A procurement should be executed when updating the demand of an SM from 0 to >0. From 16.1, a procurement will always be executed each time the quantity changed (see [1]). Here, we want to limit the impact/risk of the fix [1] https://github.com/odoo/odoo/commit/1f4fb64a197729b709bba8524b6bc59892a2f099 OPW-3253204 Forward-Port-Of: odoo/odoo#135886 Forward-Port-Of: odoo/odoo#135478
If a list view row switches to more than one line (e.g. because of some field which overflows), the record selection checkbox need to respect the same alignment as other 'blocky' widget like statuses, priorities, etc. and be middle-aligned. Task-3515864 Forward-Port-Of: odoo/odoo#136115
Original PR description
If a list view row switches to more than one line (e.g. because of some field which overflows), the record selection checkbox need to respect the same alignment as other 'blocky' widget like statuses, priorities, etc. and be middle-aligned. Task-3515864 Forward-Port-Of: odoo/odoo#136115
…ations Cleanup some code bits in common classes, add some docstrings. Improve notifications related helpers, notably to ease checking content of mail.mail or outgoing emails when posting messages. Update 'test_message_post' with those new helpers, to ease inclusion of additional specific values test with alias domains in mind in next commits. Prepares Task-36879 (Mail: Support MultiCompany Aliases) Forward-Port-Of: odoo/odoo#136281 Forward-Port-Of: odoo/odoo#136102
Original PR description
…ations Cleanup some code bits in common classes, add some docstrings. Improve notifications related helpers, notably to ease checking content of mail.mail or outgoing emails when posting messages. Update 'test_message_post' with those new helpers, to ease inclusion of additional specific values test with alias domains in mind in next commits. Prepares Task-36879 (Mail: Support MultiCompany Aliases) Forward-Port-Of: odoo/odoo#136281 Forward-Port-Of: odoo/odoo#136102
Internally, the method `_compute_stage_id` of the `knowledge.article` model generates a hashmap mapping an article id to a stage. The hashmap will then be used to efficiently assign a stage to an article. When fetching a stages from that hashmap, the method uses as key a recordset of article instead of an article id. As a result, the hashmap does not return any entry and the article items are not be assigned to a default stage. This commit will address that issue by ensuring that the provided
Original PR description
Internally, the method `_compute_stage_id` of the `knowledge.article` model generates a hashmap mapping an article id to a stage. The hashmap will then be used to efficiently assign a stage to an article. When fetching a stages from that hashmap, the method uses as key a recordset of article instead of an article id. As a result, the hashmap does not return any entry and the article items are not be assigned to a default stage. This commit will address that issue by ensuring that the provided key will be an article id. Steps to reproduce the issue: 1. Create an article with article items 2. Create a few stages and link them to the parent article 3. Read the `stage_id` value from an article item => The article items are not assigned to any stage TO BE: By default, the article items should be assigned to the stage attached to its parent having the lowest sequence number. task-3514830 Forward-Port-Of: odoo/enterprise#46392
The search functionality in the `ExistingFields` component allows the enduser to search for fields present on the model but not yet in the view. However, the res.users view uses `sel_group_id_{list}` pseudo fields indicating membership of certain security groups. These pseudo fields also have a textual description that can be searched but no field name as regular fields do. Before this commit, this caused a traceback when using the search functionality in dev mode in the presence of such fiel
Original PR description
The search functionality in the `ExistingFields` component allows the enduser to search for fields present on the model but not yet in the view. However, the res.users view uses `sel_group_id_{list}` pseudo fields indicating membership of certain security groups. These pseudo fields also have a textual description that can be searched but no field name as regular fields do.
Before this commit, this caused a traceback when using the search functionality in dev mode in the presence of such fields: `toLowerCase` was called on the field undefined field name. The problem is easily mitigated by checking for a name.
opw-3482276
Forward-Port-Of: odoo/enterprise#47691Right now it takes too much time to delete the discuss channel so after this it's fast to delete the discuss channel. task: 3515911 Forward-Port-Of: odoo/enterprise#47519
Original PR description
Right now it takes too much time to delete the discuss channel so after this it's fast to delete the discuss channel. task: 3515911 Forward-Port-Of: odoo/enterprise#47519
When a user tries to access 'Unrealized Currency Gains/Losses' accounting report with single currency activated the error will occur. Steps to reproduce: 1. Turn on developer mode. 2. Install `account`, `account_reports`. 3. Keep only one currency active. 4. Go to Accounting > Configuration > Management > Accounting Reports > 'Unrealized Currency Gains/Losses' 5. Create Menu Item of 'Unrealized Currency Gains/Losses' 6. Now open report 'Unrealized Currency Gains/Losses' from Accounting
Original PR description
When a user tries to access 'Unrealized Currency Gains/Losses' accounting report with single currency activated the error will occur. Steps to reproduce: 1. Turn on developer mode. 2. Install…
When a user tries to access 'Unrealized Currency Gains/Losses' accounting report with single currency activated the error will occur.
Steps to reproduce:
1. Turn on developer mode.
2. Install `account`, `account_reports`.
3. Keep only one currency active.
4. Go to Accounting > Configuration > Management > Accounting Reports > 'Unrealized Currency Gains/Losses'
5. Create Menu Item of 'Unrealized Currency Gains/Losses'
6. Now open report 'Unrealized Currency Gains/Losses' from Accounting > Reporting, the error will occur
See this traceback:
```
File "odoo/http.py", line 2123, in __call__
response = request._serve_db()
File "odoo/http.py", line 1699, 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 1726, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1927, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 190, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 716, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 30, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 26, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 3718, in get_report_information
lines = self._get_lines(options, all_column_groups_expression_totals)
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 1855, in _get_lines
lines = self._fully_unfold_lines_if_needed(lines, options)
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 1884, in _fully_unfold_lines_if_needed
to_insert = self._expand_unfoldable_line(line_dict['expand_function'], line_dict['id'], groupby, options, progress, 0,
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 3911, in _expand_unfoldable_line
expansion_result = expand_function(line_dict_id, groupby, options, progress, offset, unfold_all_batch_data=unfold_all_batch_data)
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 4022, in _report_expand_unfoldable_line_with_groupby
rslt_lines = line._expand_groupby(line_dict_id, groupby, options, offset=offset, limit=limit_to_load, load_one_more=bool(limit_to_load), unfold_all_batch_data=unfold_all_batch_data)
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 4970, in _expand_groupby
all_column_groups_expression_totals = self.report_id._compute_expression_totals_for_each_column_group(
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 2138, in _compute_expression_totals_for_each_column_group
current_group_expression_totals = self._compute_expression_totals_for_single_column_group(
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 2266, in _compute_expression_totals_for_single_column_group
formula_results = self._compute_formula_batch(column_group_options, engine, date_scope, formulas_dict, current_groupby, next_groupby, offset=offset, limit=limit)
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 2546, in _compute_formula_batch
return getattr(self, engine_function_name)(
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 2985, in _compute_formula_batch_with_engine_custom
rslt[(formula, expressions)] = custom_engine_function(
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_multicurrency_revaluation_report.py", line 165, in _report_custom_engine_multi_currency_revaluation_to_adjust
return self._multi_currency_revaluation_get_custom_lines(options, 'to_adjust', current_groupby, next_groupby, offset=offset, limit=limit)
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_multicurrency_revaluation_report.py", line 340, in _multi_currency_revaluation_get_custom_lines
self._cr.execute(full_query, params)
File "odoo/sql_db.py", line 319, in execute
res = self._obj.execute(query, params)
SyntaxError: syntax error at or near ")"
LINE 2: ...ITH custom_currency_table(currency_id, rate) AS ((VALUES )),
```
The issue is occurring when currency_rates is missing in options -
https://github.com/odoo/enterprise/blob/cb520b0bf404d5829b2daab2519958213215bbf4/account_reports/models/account_multicurrency_revaluation_report.py#L174
To solve this issue a UserError has been raised when we not get
more than one currency active.
sentry-4372099370
Forward-Port-Of: odoo/enterprise#47662
Forward-Port-Of: odoo/enterprise#456062 bugfixes. 1. The Retained Earnings section of the Balance Sheet should have a date_scope of `to_beginning_of_fiscalyear`, rather than `to_beginning_of_period`. Without this, AMLs between the beginning of the Fiscal Year and the report date will be counted both in Retained Earnings and Current Year Earnings, leading to an unbalanced Balance Sheet. 2. The Common Summary of Accounts section needs to be added to the total of Equity. This is part of the wider task of rebalancing the Balan
Original PR description
2 bugfixes. 1. The Retained Earnings section of the Balance Sheet should have a date_scope of `to_beginning_of_fiscalyear`, rather than `to_beginning_of_period`. Without this, AMLs between the beginning of the Fiscal Year and the report date will be counted both in Retained Earnings and Current Year Earnings, leading to an unbalanced Balance Sheet. 2. The Common Summary of Accounts section needs to be added to the total of Equity. This is part of the wider task of rebalancing the Balance Sheets. taskid:3060790 Forward-Port-Of: odoo/enterprise#47608
Task-3489665 Forward-Port-Of: odoo/enterprise#46715
Original PR description
Task-3489665 Forward-Port-Of: odoo/enterprise#46715
The issue: If there are no posted invoices while trying to generate an FAIA report on the Luxembourg localization there is a syntax error thrown The fix: make an empty list if no products found opw-3470105 Forward-Port-Of: odoo/enterprise#47087
Original PR description
The issue: If there are no posted invoices while trying to generate an FAIA report on the Luxembourg localization there is a syntax error thrown The fix: make an empty list if no products found opw-3470105 Forward-Port-Of: odoo/enterprise#47087
Problem --------- In the Bank Reco Widget, we visualize selected lines when relevant to the interface. For example, the selected transaction is in blue on the right. In the Matching tab, if a line is selected, it's in blue as well. But when you use the "Manual Operations tab", there is no such information. Despite the fact you can click on the different lines above and visualize each of them in the "Manual Operations" tab (and they have different values / fields), the line above is not h
Original PR description
Problem --------- In the Bank Reco Widget, we visualize selected lines when relevant to the interface. For example, the selected transaction is in blue on the right. In the Matching tab, if a line is selected, it's in blue as well. But when you use the "Manual Operations tab", there is no such information. Despite the fact you can click on the different lines above and visualize each of them in the "Manual Operations" tab (and they have different values / fields), the line above is not highlighted. Objective --------- When the tab "Manual Operations" is opened, highlight the selected line above to improve overall clarity. Solution --------- 1. In the SCSS file, modify the background color of selected line from the tag `o_bank_rec_selected_line`. 2. Add a condition so that the tag is not given to the selected line when the notebook page is not the Manual operation tab one. task-3482064 Forward-Port-Of: odoo/enterprise#46639
Allows the warnings to be displayed even if there is 'no data to display' Forward-Port-Of: odoo/enterprise#47647
Original PR description
Allows the warnings to be displayed even if there is 'no data to display' Forward-Port-Of: odoo/enterprise#47647