Wednesday, June 14, 2023
43 changes · master
Enhancements to existing features
When creating or editing service products that are prepaid or billed from timesheets, Odoo now automatically selects Hours as the unit of measure when the timesheet sales app is installed. This reduces manual setup work and helps keep billing and timesheet products configured consistently, while still allowing users to change the unit manually when needed.
Original PR description
- product form view: set 'hours' as the UoM if the service is either prepaid or invoice based on timesheets and if sale_timesheet is installed. - Details: Before this commit, the default UoM was the…
- product form view: set 'hours' as the UoM if the service is either
prepaid or invoice based on timesheets and if sale_timesheet is
installed.
- Details: Before this commit, the default UoM was the same for every
invoice policy or product type selected. With this commit the UoM is
automatically changed to 'Hours' when the product is of type service
and the invoice policy is either prepaid (A) or based on
timesheet (B). The value of the UoM can still be changed manually. The
following corner cases are managed:
- The user edits (or creates) a product, changes its type to
service then to storable/consumable without saving it. The UoM
should then be set to its initial value (before change) or its
default value.
- The user edits (or creates) a product, changes its invoice
policy to A or B then again to another one without saving it. The
UoM should then be set to its initial value (before change) or its
default value.
- The user edits a product of type service with invoice policy set
to A (or B) and UoM that has manually been changed to something
else than 'Hours'. He then modifies the invoice policy to B (or A)
and then again to A (or B) without saving the changes. The UoM should
then be set back to its initial value.
Task-3072818Storage location and operation type barcode reports now use a 4x7 label layout instead of the previous 8x3 format. This makes barcode printing consistent with the desired label sheet format and helps businesses use the correct paper layout without manual adjustments.
Original PR description
Currently, Storage locations and Operations type barcode are printing in 8x3 layout. So in this commit, I have changed Report of Storage locations and Operations type barcode print into 4x7. TaskID - 2579195 Enterprise PR: https://github.com/odoo/enterprise/pull/38901
Point of Sale pricing now uses one clear price status instead of two overlapping fields. This makes price changes easier to manage across discounts, loyalty, sales orders, self-ordering, and French POS certification, reducing confusion and maintenance risk.
Original PR description
*: l10n_fr_pos_cert, pos_discount, pos_loyalty, pos_sale, pos_self_order The `Orderline` model contains the fields: `price_manually_set` and `price_automatically_set`. They are meant to signify what type of price the orderline has: `automatic`, `manual` or `original`. It's very confusing to manage the two fields when in fact they only describe three types of setting the orderline price. This PR replaces the 2 fields with a single one: `price_type`, which will take one of the 3 possible values. Task: 3358265 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo can now target default field values to a specific business object instead of applying them broadly to any screen with a similarly named field. This reduces accidental data being pre-filled in the wrong place and improves consistency when users move between apps.
Original PR description
Purpose ======= The `default_` context key set the default value for a specific field, but currently, for all model having that field. For example, if you navigate in Odoo and you have `default_parent_id` in the context to set the parent_id on `res.partner`, then you go to the knowledge and you create an article, because article also have a `parent_id` field, it will be set to the value in the context, even if this context was set for the `res.partner` model. This change allow us to reduce a lot the collision that can happen (if 2 models have fields with the same name, and if a default_ context key was set for one of those model). A double underscore is used to separate the model and the field (because a field / model can itself contain underscore). Task-3358295
When users reschedule a meeting activity, the Calendar app now opens directly on the meeting's due-date week with the relevant meeting already selected. This reduces extra clicks and helps users quickly confirm or adjust the correct appointment.
Original PR description
**PURPOSE:** Calendar app should open with pop-up opened **SPECIFICATIONS:** When activity of type meeting is edited(Reschedule), he gets a calendar app open on due date's week.The calendar app should be opened with the corresponding meeting highlighted (or the pop-up opened same as if the user has click on it) **LINKS:** Task-2528115 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Cumulative line charts can now begin from an already accumulated value when the chart filters out earlier dated data. This gives business users a more accurate view of trends over a selected time period instead of always starting from zero.
Original PR description
This PR allow line graph to start to the accumulated value at the start of the graph instead of defaulting to 0. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Attachment image previews no longer show the file name as a hover title in normal use. This removes unnecessary technical information from the interface while keeping it available for debugging contexts.
Original PR description
This commit remove the title on the attachment image widget when not in debug mode. The title gave the name of the file and wasn't really necessary as it is rather a technical info. task 3343366
Recruiter names and job titles now stay neatly within the contact card, even when they are long. The phone icon is hidden when no phone number is available, giving job applicants a cleaner and less confusing experience.
Original PR description
Before this PR, when the recruiter's name and job position were excessively long, it extended beyond the boundaries of the box. And, if the recruiter did not have a phone number, the phone symbol would still be displayed within the box. In this PR, The name and job position of the recruiter were shortened and the space at the bottom of the recruiter's email was minimized. task-3342768
A new automated test confirms that binary fields can safely be used to control available choices in many-to-many tag fields. This helps protect an existing supported behavior used by business apps and reduces the risk of future regressions.
Original PR description
The commit only adds a test which checks that binary field can be used as the domain of many2many tags field. We already have a case in the "account" addon so the test is there to check that the feature is supported. task id: 3336189
Belgian payroll individual accounts are now easier to review and update with inline editing and clearer on-screen interactions. Users also receive notifications while PDFs are being created, reducing uncertainty and removing less helpful information from the workflow.
Original PR description
This commit will simplify the usage of individual accounts by : - adding inline editing, - adding notifications when pdf's are being created - removing non-user friendly informations task - 3143597
The timesheet timer is now easier to control from the keyboard: users can stop it with Enter and see clearer shortcut guidance for starting the timer or adding time. This reduces interruptions while entering timesheet details and makes hidden shortcuts more discoverable.
Original PR description
Before this commit:
- When filling the timer fields (project, task, description), you need
to switch the mouse to stop timer, it breaks the flow and annoy the user
as doing it by just clicking Enter will make him more confortable.
- 'press Enter or a letter to start the timer' wording is confusing as the
user can understand that he can press any letter.
- no indication displayed to let the user know about the existance of
'Shift + [a] shortcut to add {min duration} minutes to the timer'.
After this commit:
- Stopping the timer can be done via Enter button
- 'press Enter or a letter to start the timer' -> 'press Enter or [a] to launch the timer'.
- Display 'press Shift + [A] to add {min duration} minutes' at the right of start/stop timer
button
- When pressing Shift, the message saying 'click on + to add {min duration} minutes was removed.
task-3186662Barcode command reports for warehouse operations are now split into separate printouts instead of being combined into one report. This makes printed barcode sheets clearer and improves page usage so staff can scan and manage locations and operation types more efficiently.
Original PR description
Currently, all operation From barcode command are in single report. In this commit,I have Split both the Operations from barcode commands and now we are printing reports separately. TaskID - 2579195 Community PR: https://github.com/odoo/odoo/pull/116844
Resolved issues and error corrections
This update fixes a timing issue that could cause automated sale loyalty checks to fail when they ran around midnight. It improves the reliability of nightly validation without changing customer-facing behavior.
Original PR description
Fix nightly fails
Code cleanup and technical improvements
This update moves the channel selection component into the Discuss area of the Mail app without changing how users interact with messaging. The change helps keep related messaging code together, making future maintenance and improvements easier and safer.
Original PR description
Part of task-3265211
Miscellaneous changes
The demo company vat number would fail the check in base_vat and thus always cause the demo company to not be added when installing l10n_sg. So we replace it with a number that passes the check to ease testing and avoid throwing errors in the face of our users if they want to try that localisation. Task id #3366323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#124597
Original PR description
The demo company vat number would fail the check in base_vat and thus always cause the demo company to not be added when installing l10n_sg. So we replace it with a number that passes the check to ease testing and avoid throwing errors in the face of our users if they want to try that localisation. Task id #3366323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#124597
Fixed an issue where article links inserted with the /article command could disappear when editing content inside pop-up windows. This helps users keep their Knowledge articles accurate and avoids losing links during normal editing.
This fix prevents newly created partners from being accidentally linked to an unrelated parent when users create them from a grouped embedded Kanban view in Knowledge. It ensures Knowledge article defaults are only applied to the correct type of record, reducing confusing data errors for users.
Original PR description
Bug === In an embed kanban view, if you group the article by a "res.partner", you will be able to create new partner from there (by creating new column). Because the context key "default_parent_id" is set, and because "res.partner" also have a "parent_id" field, the parent of the newly created partner was set to a random one (that have the same id of the parent article). Task-3358295
Before:  After:  Forward-Port-Of: odoo/odoo#124866
Original PR description
Before:  After:  Forward-Port-Of: odoo/odoo#124866
This task aims to rework the wizard that creates a salary configurator and pre-fills the applicant's name, phone and email task - 3171707 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#124679 Forward-Port-Of: odoo/odoo#118213
Original PR description
This task aims to rework the wizard that creates a salary configurator and pre-fills the applicant's name, phone and email task - 3171707 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#124679 Forward-Port-Of: odoo/odoo#118213
Based on the government documentation, NumeroDDT should be alphanumeric format and max length 20 characters. Currently it's possible to NumeroDDT larger than 20 characters which will fail if sent to the authorities. Now this value will be trimmed to the last 20 characters to respect the specifications. opw-3343345 Forward-Port-Of: odoo/odoo#124012 Forward-Port-Of: odoo/odoo#123904
Original PR description
Based on the government documentation, NumeroDDT should be alphanumeric format and max length 20 characters. Currently it's possible to NumeroDDT larger than 20 characters which will fail if sent to the authorities. Now this value will be trimmed to the last 20 characters to respect the specifications. opw-3343345 Forward-Port-Of: odoo/odoo#124012 Forward-Port-Of: odoo/odoo#123904
Since [1], navigating from the website application to another one raises an error when using Firefox. This commit avoids looking at the URL if the iframe is not available. It seems that in Firefox the `pagehide` event is triggered after the iframe is released. Steps to reproduce: - Use Firefox. - Go to the Website app. - Go to Discuss. => An error popup was displayed. [1]: https://github.com/odoo/odoo/commit/eacfab230b8b6d676f378ad74a402849af83dcbb task-3302981 Forward-Po
Original PR description
Since [1], navigating from the website application to another one raises an error when using Firefox. This commit avoids looking at the URL if the iframe is not available. It seems that in Firefox the `pagehide` event is triggered after the iframe is released. Steps to reproduce: - Use Firefox. - Go to the Website app. - Go to Discuss. => An error popup was displayed. [1]: https://github.com/odoo/odoo/commit/eacfab230b8b6d676f378ad74a402849af83dcbb task-3302981 Forward-Port-Of: odoo/odoo#124294
Steps to reproduce: - Go to a website page > Add a 'Form' block. - Go to the page (in 'edit_translations' mode) > Reload the page > The form won't be pre-filled with default values. [1] The page reloading with `?edit_translations=1` leads to a misleading situation where the form block is handled as on 'edit_translations' mode (see: `data-edit_translations="1"` on the DOM) hence the behaviour in [1]. The goal of this commit is to prevent this inconsistency by simply adapting the bro
Original PR description
Steps to reproduce: - Go to a website page > Add a 'Form' block. - Go to the page (in 'edit_translations' mode) > Reload the page > The form won't be pre-filled with default values. [1] The page reloading with `?edit_translations=1` leads to a misleading situation where the form block is handled as on 'edit_translations' mode (see: `data-edit_translations="1"` on the DOM) hence the behaviour in [1]. The goal of this commit is to prevent this inconsistency by simply adapting the browser URL once "edit_translations" mode is activated. Forward-Port-Of: odoo/odoo#124171
*: website_sale_stock When translations are loaded in a front-end page, the language is initially deduced by the server. The `GET` that obtains them does not have a language parameter set. Because of this, this initial result is reused from the browser cache on subsequent page accesses. This is a problem when the user toggles between languages because the cached content is reused while it is related to a previously selected language. This commit avoids this problem by making the cach
Original PR description
*: website_sale_stock When translations are loaded in a front-end page, the language is initially deduced by the server. The `GET` that obtains them does not have a language parameter set. Because of…
*: website_sale_stock When translations are loaded in a front-end page, the language is initially deduced by the server. The `GET` that obtains them does not have a language parameter set. Because of this, this initial result is reused from the browser cache on subsequent page accesses. This is a problem when the user toggles between languages because the cached content is reused while it is related to a previously selected language. This commit avoids this problem by making the cache specific to the current front-end language. Steps to reproduce: - Make sure "Disable cache" is not enabled in your browser. - Install website_sale_stock. - Add the French language and activate it on the first website. - In the backend, go to a product (e.g. Office Lamp)'s Sales tab. - Disable "Out-of-Stock: Continue selling". - Enter an "Out-of-Stock Message" in both English and French. - Open the product's website page in French. - Copy the URL. - Open a new browser private navigation window. - Go to the copied URL. - Switch to English. - Switch to French. => The price is first displayed correctly in French with a "," decimal separator then is replaced by using the English "." decimal separator and the out-of-stock message is displayed in English. opw-3293403 opw-3343614 Forward-Port-Of: odoo/odoo#124756 Forward-Port-Of: odoo/odoo#121593
This commit clears the cache of we-many2X widgets. Since [the merge of the backend into the frontend], the page is not refreshed when the user goes to modify data in his backend. This means that if the data has been changed between two editions of a page and the many2X widget has already made the RPC call, it will not do it again and will still have the old data. For example with website installed: - Edit a page of your website - Add the add to cart button - Search for "ERP" product - The pr
Original PR description
This commit clears the cache of we-many2X widgets. Since [the merge of the backend into the frontend], the page is not refreshed when the user goes to modify data in his backend. This means that if…
This commit clears the cache of we-many2X widgets. Since [the merge of the backend into the frontend], the page is not refreshed when the user goes to modify data in his backend. This means that if the data has been changed between two editions of a page and the many2X widget has already made the RPC call, it will not do it again and will still have the old data. For example with website installed: - Edit a page of your website - Add the add to cart button - Search for "ERP" product - The product does not exist so save the page - Create and publish a new product called "ERP" - Edit the page again - Search for the product "ERP" => It is not present because the query is in the cache which has not been cleared. If you refresh the page, the product will be found. This commit fixes this problem by clearing the cache after an edit. [the merge of the backend into the frontend]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b task-3078137 Forward-Port-Of: odoo/odoo#124759 Forward-Port-Of: odoo/odoo#122040
The report layout has been improved with this following commit: https://github.com/odoo/odoo/pull/107714 However, some class were missing to fully incorporate the elements of the left and right elements in the body. This caused issue with the Mexican localization (see related commit) Also sets by default the setting display_invoice for the Mexican localization. As this localization uses its own amount to words function, the related commit enables an override of the generic function to use it cor
Original PR description
The report layout has been improved with this following commit: https://github.com/odoo/odoo/pull/107714 However, some class were missing to fully incorporate the elements of the left and right elements in the body. This caused issue with the Mexican localization (see related commit) Also sets by default the setting display_invoice for the Mexican localization. As this localization uses its own amount to words function, the related commit enables an override of the generic function to use it correctly with Mexican localization. task-3367243 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#124801 Forward-Port-Of: odoo/odoo#124696
On the welcome page, in the join channel button, the arrow icon is not centered. Technical reason: Currently, fa-stack class is used with the oi class, that results in the misalignment of the arrow icon, which prevents it from being centered. After this PR icon will be centered. Task-3355356 Forward-Port-Of: odoo/odoo#124822
Original PR description
On the welcome page, in the join channel button, the arrow icon is not centered. Technical reason: Currently, fa-stack class is used with the oi class, that results in the misalignment of the arrow icon, which prevents it from being centered. After this PR icon will be centered. Task-3355356 Forward-Port-Of: odoo/odoo#124822
Steps to reproduce the bug: - Install the Website Slides module. - Got to the /slides page. - Click on a course. - Click on the "Add Content" button. - Choose "Web Page" in the modal. - Once in edit mode, drag and drop a "Table of Content" snippet onto the page. - Save the page. - Scroll the page and observe that the navbar items are updated as you scroll. - Click on the "Fullscreen" button. - Bug: When scrolling the page, the navbar items are no longer updated as you scroll. This
Original PR description
Steps to reproduce the bug: - Install the Website Slides module. - Got to the /slides page. - Click on a course. - Click on the "Add Content" button. - Choose "Web Page" in the modal. - Once in edit mode, drag and drop a "Table of Content" snippet onto the page. - Save the page. - Scroll the page and observe that the navbar items are updated as you scroll. - Click on the "Fullscreen" button. - Bug: When scrolling the page, the navbar items are no longer updated as you scroll. This commit fixes the issue by detecting the scrolling element by traversing up the ancestors from the 'table of content' snippet, instead of using the 'getScrollingElement' function, which always returned the '#wrapwrap' when a Website Slides page is in fullscreen. opw-3302118 Forward-Port-Of: odoo/odoo#124459
This is to clarify that the file_name param is not used if a ZIP is downloaded: in that case, the filenames in the ZIP are used to save the attachment. See discussion in https://github.com/odoo/odoo/pull/115720#pullrequestreview-1392562860 Forward-Port-Of: odoo/odoo#119382
Original PR description
This is to clarify that the file_name param is not used if a ZIP is downloaded: in that case, the filenames in the ZIP are used to save the attachment. See discussion in https://github.com/odoo/odoo/pull/115720#pullrequestreview-1392562860 Forward-Port-Of: odoo/odoo#119382
steps to reproduce the issue: -Navigate to POS, Open Bar (needs to be restaurant POS) -Click on a table and add some items to the order. -Click the Bill button under the order -Wait about 90 seconds -Bill page times out and goes back to the floor screen -Click on Orders at the top and view Ongoing Orders. The one you just made is not here (it should be) The solution is to prevent removing the not finalized order when coming back to the FloorScreen. opw-3276345 --- I confirm I h
Original PR description
steps to reproduce the issue: -Navigate to POS, Open Bar (needs to be restaurant POS) -Click on a table and add some items to the order. -Click the Bill button under the order -Wait about 90 seconds -Bill page times out and goes back to the floor screen -Click on Orders at the top and view Ongoing Orders. The one you just made is not here (it should be) The solution is to prevent removing the not finalized order when coming back to the FloorScreen. opw-3276345 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#124797 Forward-Port-Of: odoo/odoo#120548
## Current behaviour In mobile view, if an user that doesn't have any rights over "Employees", clicking on any of the Many2One `employee_id` (for ex: when adding a timesheet on a task and clicking on the employee field), for either the dropdown, or to the form view with the `external` button, we get a stacktrace. ## Expected behaviour We shouldn't be met with a stacktrace, if we don't have rights, we should be redirected to the corresponding view for the `hr.employee. public` model. ## S
Original PR description
## Current behaviour In mobile view, if an user that doesn't have any rights over "Employees", clicking on any of the Many2One `employee_id` (for ex: when adding a timesheet on a task and clicking on…
## Current behaviour In mobile view, if an user that doesn't have any rights over "Employees", clicking on any of the Many2One `employee_id` (for ex: when adding a timesheet on a task and clicking on the employee field), for either the dropdown, or to the form view with the `external` button, we get a stacktrace. ## Expected behaviour We shouldn't be met with a stacktrace, if we don't have rights, we should be redirected to the corresponding view for the `hr.employee. public` model. ## Steps to reproduce - Install Timesheets - Set Marc Demo's Employee's right to `none/empty`, login as Marc - In mobile view, go to Project > a task > open the timesheet sheet - Click on Add or any of the present timesheets - Click on employee field, either on it (redirect to the mobile kanban view of all employees) or to the right edge of it (redirect to the form view for the currently selected employee). - Instead of being redirected, you are met with a stacktrace. ## Reason for the problem Since the migration to Owl, there is an implicit consistency expected between what is the requested model for said view, and the model we get back from the server for said view. In general (for example when in desktop view), usually we pass by an override of `get_formview_action` which changes the model we are loading front-end side depending on the access to the employee model. If access, we load `hr.employee`, if no access, `hr.employee.public`. But for mobile, we don't pass by an action, we just load a dialog, and the `resModel` used for the dialog is based on the `relation` of the `Many2OneField`, which is `hr.employee`. In that case when `get_views` is being called, we receive a view with the model key being `hr.employee.public`, which is inconsistent with what the front-end requested (which is `hr.employee`) and we have a stacktrace in owl. ## Fix Override the `relation` property to the correct model in the corresponding widget set on the template of the field, based on available group. This relation is used to set the `resModel` when opening the dialog. ## Affected versions - 16.0 - saas-16.1 - saas-16.2 - saas-16.3 - master --- opw-3269817 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#124861 Forward-Port-Of: odoo/odoo#123217
As of this commit, only confirmed leaves will be considered when computing the current leave or absence of an employee. Additionally, a bug in the `is_absent` search implementation was fixed: before this commit, the same results were returned for absent and non-absent searches. opw-2877328 Forward-Port-Of: odoo/odoo#123999 Forward-Port-Of: odoo/odoo#105451
Original PR description
As of this commit, only confirmed leaves will be considered when computing the current leave or absence of an employee. Additionally, a bug in the `is_absent` search implementation was fixed: before this commit, the same results were returned for absent and non-absent searches. opw-2877328 Forward-Port-Of: odoo/odoo#123999 Forward-Port-Of: odoo/odoo#105451
The computation of the cash_balance of the sessions was falsy due to a change retrieving a part of the domain related to the payment lines of the session. The change of the domain led to retrieving all payments done during the entire lifetime of the config instead of only the ones done during the session and leading to miscomputation of the cash balance. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#124788
Original PR description
The computation of the cash_balance of the sessions was falsy due to a change retrieving a part of the domain related to the payment lines of the session. The change of the domain led to retrieving all payments done during the entire lifetime of the config instead of only the ones done during the session and leading to miscomputation of the cash balance. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#124788
Default mail template for coupon on next order was linked to the gift card mail template, but it should be linked to loyalty coupon card. OPW-3281621 Forward-Port-Of: odoo/odoo#124757
Original PR description
Default mail template for coupon on next order was linked to the gift card mail template, but it should be linked to loyalty coupon card. OPW-3281621 Forward-Port-Of: odoo/odoo#124757
'Error while converting to PDF/A' log error is generated when the user uploads the files and that file could' t convert PDF to PDF-A. Trace-back on sentry: ``` eyError: '/Outlines' File "addons/account_edi_ubl_cii/models/account_edi_format.py", line 170, in _prepare_invoice_report pdf_writer.convert_to_pdfa() File "odoo/tools/pdf.py", line 383, in convert_to_pdfa outlines = self._root_object['/Outlines'].getObject() File "PyPDF2/generic.py", line 520, in __getitem__
Original PR description
'Error while converting to PDF/A' log error is generated when the user uploads the files and that file could' t convert PDF to PDF-A.
Trace-back on sentry:
```
eyError: '/Outlines'
File "addons/account_edi_ubl_cii/models/account_edi_format.py", line 170, in _prepare_invoice_report
pdf_writer.convert_to_pdfa()
File "odoo/tools/pdf.py", line 383, in convert_to_pdfa
outlines = self._root_object['/Outlines'].getObject()
File "PyPDF2/generic.py", line 520, in __getitem__
return dict.__getitem__(self, key).getObject()
```
we stop catching exception in sentry.
sentry-4172828056
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#121749This commit fixes the display of the ColumnProgress component, which was no longer displaying an animation when a filter is applied. This was due to changes made in commit (1), introducing an "activeBar" key on the value given to the ColumnProgress component. A test has been modified to assert that the classes corresponding to the animation are added as expected when a filter is selected. 1) 58ca40b03215ef4c6c575267494dc8bccc30a033 Forward-Port-Of: odoo/odoo#124950
Original PR description
This commit fixes the display of the ColumnProgress component, which was no longer displaying an animation when a filter is applied. This was due to changes made in commit (1), introducing an "activeBar" key on the value given to the ColumnProgress component. A test has been modified to assert that the classes corresponding to the animation are added as expected when a filter is selected. 1) 58ca40b03215ef4c6c575267494dc8bccc30a033 Forward-Port-Of: odoo/odoo#124950
## Task Description When autofilling a pivot/list cell from another pivot/list cell, the format of the target wasn't overwritten. This can lead to some strange behaviour where the user set the desired format to a cell then autofill the remaning cell of the column/row to apply the same format once and nothing happen. We now propagate the set format with the pivot/list autofill, but we still don't propagate the style and border definition, as it could break the currently defined pivot/list sty
Original PR description
## Task Description When autofilling a pivot/list cell from another pivot/list cell, the format of the target wasn't overwritten. This can lead to some strange behaviour where the user set the desired format to a cell then autofill the remaning cell of the column/row to apply the same format once and nothing happen. We now propagate the set format with the pivot/list autofill, but we still don't propagate the style and border definition, as it could break the currently defined pivot/list style. ## Related Task - task-3252442 - https://github.com/odoo/enterprise/pull/41777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#124606
## Task Description When autofilling a pivot/list cell from another pivot/list cell, the format of the target wasn't overwritten. This can lead to some strange behaviour where the user set the desired format to a cell then autofill the remaning cell of the column/row to apply the same format once and nothing happen. We now propagate the set format with the pivot/list autofill, but we still don't propagate the style and border definition, as it could break the currently defined pivot/list st
Original PR description
## Task Description When autofilling a pivot/list cell from another pivot/list cell, the format of the target wasn't overwritten. This can lead to some strange behaviour where the user set the desired format to a cell then autofill the remaning cell of the column/row to apply the same format once and nothing happen. We now propagate the set format with the pivot/list autofill, but we still don't propagate the style and border definition, as it could break the currently defined pivot/list style. ## Related Task - task-3252442 - https://github.com/odoo/odoo/pull/124606 Forward-Port-Of: odoo/enterprise#42499 Forward-Port-Of: odoo/enterprise#41777
The custom report handler for "PLE Sales 14.1" was inheriting from the one of the generic tax report, instead of inheriting from its parent, common to all tax reports. Because of that, the caret options couldn't get computed properly when trying to open the report from the UI, and a javascript error was raised. Forward-Port-Of: odoo/enterprise#42374
Original PR description
The custom report handler for "PLE Sales 14.1" was inheriting from the one of the generic tax report, instead of inheriting from its parent, common to all tax reports. Because of that, the caret options couldn't get computed properly when trying to open the report from the UI, and a javascript error was raised. Forward-Port-Of: odoo/enterprise#42374
column reference "tax_type" is ambiguous. ``` Traceback (most recent call last): File "/home/odoo/src/odoo/16.0/odoo/service/server.py", line 1299, in preload_registries registry = Registry.new(dbname, update_module=update_module) File "<decorator-gen-14>", line 2, in new File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 87, in locked return func(inst, *args, **kwargs) File "/home/odoo/src/odoo/16.0/odoo/modules/registry.py", line 90, in new odoo.modules.loa
Original PR description
column reference "tax_type" is ambiguous. ``` Traceback (most recent call last): File "/home/odoo/src/odoo/16.0/odoo/service/server.py", line 1299, in preload_registries registry =…
column reference "tax_type" is ambiguous.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/16.0/odoo/service/server.py", line 1299, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-14>", line 2, in new
File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/16.0/odoo/modules/registry.py", line 90, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 483, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 371, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 207, in load_module_graph
registry.init_models(cr, model_names, {'module': package.name}, new_install)
File "/home/odoo/src/odoo/16.0/odoo/modules/registry.py", line 527, in init_models
model.init()
File "/home/odoo/src/enterprise/16.0/l10n_ar_reports/report/account_ar_vat_line.py", line 74, in init
cr.execute(sql, params)
File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 313, in execute
res = self._obj.execute(query, params)
psycopg2.errors.AmbiguousColumn: column reference "tax_type" is ambiguous
LINE 62: ... account_move.id, art.name, rp.id, lit.id, tax_type
```
Forward-Port-Of: odoo/enterprise#42115The report layout has been improved with this following commit: https://github.com/odoo/odoo/pull/107714 Some xpaths needs to be properly adapted to render correctly the invoice template for the Mexican localization. This localization also has its own 'amount to words' function which is now generic. However, this localization has legal requirements concerning the feature, it is therefore adapted that the generic feature uses the Mexican one with the localization is used. task 3367243 Forward
Original PR description
The report layout has been improved with this following commit: https://github.com/odoo/odoo/pull/107714 Some xpaths needs to be properly adapted to render correctly the invoice template for the Mexican localization. This localization also has its own 'amount to words' function which is now generic. However, this localization has legal requirements concerning the feature, it is therefore adapted that the generic feature uses the Mexican one with the localization is used. task 3367243 Forward-Port-Of: odoo/enterprise#42452 Forward-Port-Of: odoo/enterprise#42382
The `serializeDateTime` now uses `luxon` objects, while, before this commit, the rental search snippet code reads the dates from the datepicker as `moment` objects. opw-3357391 Forward-Port-Of: odoo/enterprise#42447
Original PR description
The `serializeDateTime` now uses `luxon` objects, while, before this commit, the rental search snippet code reads the dates from the datepicker as `moment` objects. opw-3357391 Forward-Port-Of: odoo/enterprise#42447
Steps to reproduce: 1. Set up Sendcloud shipping method 2. Go to inventory -> delivery orders 3. Make a new delivery order, add a product, select sendcloud as carrier in additional info tab 4. validate the transfer Error appears: `Something went wrong. parcel not returned from Sendcloud` And in the logs: `"errors":{"total_order_value_currency": ["Not a valid string."]` The problem is the fact that the amount and currency of the order is filled using the sale order associated with the
Original PR description
Steps to reproduce:
1. Set up Sendcloud shipping method
2. Go to inventory -> delivery orders
3. Make a new delivery order, add a product, select sendcloud as carrier in additional info tab
4. validate the transfer
Error appears:
`Something went wrong. parcel not returned from Sendcloud` And in the logs: `"errors":{"total_order_value_currency": ["Not a valid string."]`
The problem is the fact that the amount and currency of the order is filled using the sale order associated with the delivery, and in this case there is no sale order, so it is sent as:
`"total_order_value":0.0,"total_order_value_currency":false`
opw-3354420
Forward-Port-Of: odoo/enterprise#42369This task aims to rework the wizard that creates a salary configurator and pre-fills the applicant's name, phone and email task - 3171707 Forward-Port-Of: odoo/enterprise#42375 Forward-Port-Of: odoo/enterprise#38202
Original PR description
This task aims to rework the wizard that creates a salary configurator and pre-fills the applicant's name, phone and email task - 3171707 Forward-Port-Of: odoo/enterprise#42375 Forward-Port-Of: odoo/enterprise#38202