Wednesday, January 10, 2024
82 changes · master
Enhancements to existing features
The Settings page now shows QR codes for the iOS and Android mobile apps when viewed on desktop. This makes it easier for users to open the correct app store page on their phone without manually searching or typing links.
Original PR description
In the settings page, there are two link as images to go to the respective app stores for the mobile apps. This commit replace in desktop mode the images by qrcodes. Task ID 3642497 Result: 
Online sales orders now determine payment terms in one place instead of repeating the same logic. This reduces unnecessary processing and helps keep checkout-related order data more consistent and easier to maintain.
Original PR description
Since `sale_get_payment_term` is already called in the compute for the SO payment terms, its whole logic can be handled directly in the compute, and we do not need to call it manually anymore. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes an obsolete condition from the custom payment page template that was accidentally left behind after a previous change. It helps keep the payment customization code simpler and aligned with the intended behavior, with no expected visible impact for users.
Original PR description
Following commit f61b159618c690db40519a66961ce5bcc919dc64 the t t-if should have been removed in master but was forgotten. See also: - https://github.com/odoo/enterprise/pull/53723
The web charting library used by Odoo has been updated to a newer version. This helps keep chart displays current and maintainable, with no expected change to day-to-day workflows.
Original PR description
In this commit, Chart.js library is updated from 4.3.0 to 4.4.1[1]
Note:
This version of Chart.js is build from the source repo[2] because there
is only a minified prebuild umd version.
To make this build:
1. Clone the repo[2] and checkout the 4.4.1 tagged version
2. Install the build dependencies: `pnpm install`
3. Change the umd build's config at [3] by :
```js
{
input: 'src/index.umd.ts',
plugins: plugins(),
output: {
name: 'Chart',
file: 'dist/chart.umd.js',
format: 'umd',
indent: true,
banner,
sourcemap: false,
},
}
```
4. Build the lib: `pnpm run build` ; the unminified umd version is
located at `./dist/chart.umd.js`
[1]: https://github.com/chartjs/Chart.js/compare/v4.3.0...v4.4.1
[2]: https://github.com/chartjs/Chart.js
[3]: https://github.com/chartjs/Chart.js/blob/v4.4.1/rollup.config.js#L50
task-3600470This update adds automated checks for the sales order line field used in timesheet-related task workflows, helping ensure it behaves consistently. It also removes an older unused widget, reducing maintenance overhead without changing expected user workflows.
Original PR description
After this commit, tests have been implemented for so_line_field widget. Additionally, so_line_one2many widget has been removed as it is no more needed. task-3660978 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update aligns the SEPA direct debit payment page with a recent platform change by removing an outdated display condition. It helps keep the payment experience consistent and avoids template mismatches after the related core update.
Original PR description
Following commit f61b159 the t t-if should have been removed in master but was forgotten. See also: - https://github.com/odoo/odoo/pull/147657
This update adds automated checks for the sales order line selection used in timesheet-related workflows. It also removes an obsolete related widget, reducing maintenance needs while helping keep helpdesk and project task sales links reliable.
Original PR description
After this commit, tests have been implemented for so_line_field widget. Additionally, so_line_one2many widget has been removed as it is no more needed. task-3660978 related-https://github.com/odoo/odoo/pull/148176
Resolved issues and error corrections
This update fixes intermittent failures in automated web tests by ensuring location changes are handled at the right time. It helps keep the testing pipeline more reliable, reducing false failures and delays in validating changes.
Original PR description
Before this commit, the tests that modify the hash of the location sometimes failed on runbot, because it might happen that the hashchange event is triggered in the next animation frame (the event isn't triggered synchronously). Now, a helper function was created that modify the location, and wait\ for the next animation frame. Fixes runbot issue 54918 Fixes runbot issue 54917
Features or functions removed from Odoo
The India localization module no longer includes its own duplicate audit trail screens and data models, since that functionality is now handled by a separate audit trail module. This reduces overlap and helps keep maintenance and upgrades cleaner without changing the intended audit trail capability when the dedicated module is used.
Original PR description
Before this commit ================== As the `account_audit_trail` module was separated from the `l10n_in` module, but there were duplicate views and models of the audit trail feature in the `l10n_in` module. After this commit ================= Removed duplicate views and models of the audit trail feature from the `l10n_in` module. Related upgrade PR: odoo/upgrade#5462 task_id: 3326258
Code cleanup and technical improvements
This change removes an internal duplicate access-checking mechanism and relies on more consistent permission checks instead. It helps keep user and project task data protected while reducing complexity and avoiding accidental access errors in project task handling.
Original PR description
_read_group_check_field_access_rights() is a superfluous hook of the _read_group() refactor (https://github.com/odoo/odoo/pull/110737). But this hook isn't very useful compared to check_field_access_rights(), it only checks the usage of fields used in _read_group(). - For 'res.users': Check the security in _read_group_select() and _read_group_groupby() instead. We cannot forbid USER_PRIVATE_CHECK in check_field_access_rights() because we want to obfuscate this field, and not throw an AccessError when reading it. - For 'project.task': override check_field_access_rights() to cover all cases and override _determine_fields_to_fetch() to avoid reading an inaccessible field and having an accidental AccessError. https://github.com/odoo/enterprise/pull/53409
Miscellaneous changes
Currently in calendar views in mobile it is possible to create events selecting the time of the event by dragging. However, in calendar we also have the action swiper responsible for moving between weeks when swiping close to the borders. The issue is that when trying to create events by dragging close to the border will cause the action swiper to trigger a swipe, therefore switching to the next week. This commit fixes this by adding a swipeInvalid prop to the action swiper that will be checked
Original PR description
Currently in calendar views in mobile it is possible to create events selecting the time of the event by dragging. However, in calendar we also have the action swiper responsible for moving between weeks when swiping close to the borders. The issue is that when trying to create events by dragging close to the border will cause the action swiper to trigger a swipe, therefore switching to the next week. This commit fixes this by adding a swipeInvalid prop to the action swiper that will be checked during the touch move event handler. If the swipeInvalid is executed at any move and returns true, the swipe is cancelled. task-3635841 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#146346
Indian point-of-sale receipts now correctly show the HSN code on tickets, helping businesses provide more complete tax-related information to customers. The receipt template was also updated to use the current supported output method, reducing future maintenance risk.
Original PR description
In this PR ------------- - **[FIX] l10n_in_pos: resolve HSN Code not showing up on ticket** - **[IMP] l10n_in_pos: replace t-esc with t-out** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mail app no longer shows or allows the call action when a user is chatting with themselves. This prevents confusing or unnecessary call attempts in self-conversation threads.
Original PR description
**Before this PR:** When a user is in conversation with himself, the user had the option of calling as the call button is visible in that particular thread. **After this PR:** Now, the when the user is in conversation with himself, in that case, the self call is restricted for that thread. task- 3502904
A fragile automated test was updated so it no longer depends on a specific capitalization of a demo user name. This helps keep nightly checks reliable when demo data varies, reducing false build failures for the mail area.
Original PR description
The original test is breaking during no demo nightly build. https://runbot.odoo.com/web#id=55136&view_type=form&model=runbot.build.error&menu_id=405&cids=1 The problem was the hard coded `@Mitchell Admin` in the expected result. The case can be different when the demo data changes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A payroll contract salary test was updated so it no longer depends on demo employee data. This helps keep the Belgian payroll accounting test suite reliable when demo data is not installed.
Original PR description
Marc Demo is used in a contract salary tour and shouldnt because he is part of demo data
A failing automated test for Amazon sales integration was corrected so it no longer relies on optional demo data. This helps keep nightly quality checks reliable without changing customer-facing functionality.
Original PR description
The test was failing on the nodemo nightly build because it was using demo data. The dependency on the demo data has now been removed.
The appointment performance tests were updated to reflect an extra image lookup added to appointment pages. This keeps automated checks aligned with the current appointment display behavior and prevents false test failures.
Original PR description
Following: e02ec53a9e91343423b3f54a766bce4919631328 We introduced a new image_1920 field on the appointment.type model. This field is read on the main appointment route, to show the appointment image on the right side panel containing the meeting information. Meaning we have an additional request towards the "attachment" model to fetch that extra image. We forgot to increment all query counters that hit that route by one. This commit fixes it. Task-3607606
This update fixes how the VoIP feature reads its settings after a recent internal change to the Discuss settings structure. It helps prevent VoIP behavior from breaking due to outdated settings access, with no expected change to normal user workflows.
Original PR description
Follow-up of https://github.com/odoo/enterprise/pull/50720 PR above turned Settings into a model, to ease inserting data from the server. To accomodate from this change, accessing to settings has to go to `store`. Some LOCs were not properly adapted, which this commit fixes.
This fix prevents payroll updates from unnecessarily rewriting existing payslip line details. It helps module updates run more efficiently and reduces the risk of avoidable changes to historical payroll records.
Original PR description
Purpose ======= Avoid writing on all the existing payslip lines on module update.
This change makes internal web client tests more stable by ensuring page address changes are fully processed before checks continue. It helps reduce random automated test failures, improving confidence in build results without changing user-facing behavior.
Original PR description
Before this commit, the tests that modify the hash of the location sometimes failed on runbot, because it might happen that the hashchange event is triggered in the next animation frame (the event isn't triggered synchronously). Now, a helper function was created that modify the location, and wait\ for the next animation frame. Fixes runbot issue 54918 Fixes runbot issue 54917
This change updates HR Referral and HR Appraisal to use the newer standard way of checking access to sensitive fields. It keeps field-level protections aligned with the main Odoo platform while simplifying the referral logic and preserving record-specific security for appraisals.
Original PR description
…_rights() Since _read_group_check_field_access_rights() is removed in the community version, then remove the remaining occurrences of it. - For hr.referral: Simplify each check by overriding only check_field_access_rights(). - For hr.appraisal: We actually want security checks on fields depending on the record itself. Then change the paradigm with 2 new compute/inverse fields that manage the security during the read and the write. https://github.com/odoo/odoo/pull/146438
Steps to reproduce: - Install `survey` module - Go to survey and open any survey - Click on 'Test' button Issue: Navbar is visible in survey mode (and therefore able to edit the survey with web editor). Cause: At some point, the XML has been refactored and the concerned `nav` element as been replaced by a `div` element, but the related CSS that hide the navbar has not been updated. opw-3369894 Forward-Port-Of: odoo/odoo#148434
Original PR description
Steps to reproduce: - Install `survey` module - Go to survey and open any survey - Click on 'Test' button Issue: Navbar is visible in survey mode (and therefore able to edit the survey with web editor). Cause: At some point, the XML has been refactored and the concerned `nav` element as been replaced by a `div` element, but the related CSS that hide the navbar has not been updated. opw-3369894 Forward-Port-Of: odoo/odoo#148434
After revamping the calendar event form view, the warning that is shown when an attendee doesn't have an email set started being rendered in a single column, making the warning be super shrunk. This commit fixes this by forcing the renderer to use 2 columns for the warning. task-3613118 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.odo
Original PR description
After revamping the calendar event form view, the warning that is shown when an attendee doesn't have an email set started being rendered in a single column, making the warning be super shrunk. This commit fixes this by forcing the renderer to use 2 columns for the warning. task-3613118 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#144514
Before this PR, I guest searching in discuss would get an access error. This is because the search is searching in the attachments that the guest can't access. task-3637314 Forward-Port-Of: odoo/odoo#146110
Original PR description
Before this PR, I guest searching in discuss would get an access error. This is because the search is searching in the attachments that the guest can't access. task-3637314 Forward-Port-Of: odoo/odoo#146110
`res.users.company_ids` returns only active companies, while `res.users.company_id` may be inactive. This leads to a situation where `self.env.company` is inactive but still associated to `self.env.user`. Since in multiple cases the default value for relational fields pointing to `res.users` is `self.env.user`, we may get an error in this check: `self.env.company` is not in `self.env.user.company_ids`. See https://github.com/odoo/odoo/blob/5506ca7/odoo/addons/base/models/res_users.py#L281-
Original PR description
`res.users.company_ids` returns only active companies, while `res.users.company_id` may be inactive. This leads to a situation where `self.env.company` is inactive but still associated to `self.env.user`. Since in multiple cases the default value for relational fields pointing to `res.users` is `self.env.user`, we may get an error in this check: `self.env.company` is not in `self.env.user.company_ids`. See https://github.com/odoo/odoo/blob/5506ca7/odoo/addons/base/models/res_users.py#L281-L282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147127
The range widget doesn't work with Serbian language, because language locale subtag contains `@`. Steps to reproduce: 1. Activate Serbian Latin language (sr@latin) on your website 2. Go to /shop 3. Switch to Serbian lang The price ranger slider (which can be disabled) will throw this TB: "RangeError: Incorrect locale information provided". The fix is to do as other places in the code: replace this specific lang code with the expected one. Ideally, a util method should be used at
Original PR description
The range widget doesn't work with Serbian language, because language locale subtag contains `@`. Steps to reproduce: 1. Activate Serbian Latin language (sr@latin) on your website 2. Go to /shop 3. Switch to Serbian lang The price ranger slider (which can be disabled) will throw this TB: "RangeError: Incorrect locale information provided". The fix is to do as other places in the code: replace this specific lang code with the expected one. Ideally, a util method should be used at all those places. Forward-Port-Of: odoo/odoo#148279
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#148351
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#148351
In this commit we add a line on the receipt with the text "Odoo Point of Sale" or "Odoo Restaurant". ( depending on the case) This is done for marketing reasons. Task: 3635645 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148094
Original PR description
In this commit we add a line on the receipt with the text "Odoo Point of Sale" or "Odoo Restaurant". ( depending on the case) This is done for marketing reasons. Task: 3635645 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148094
Current behavior before PR: The editor's code was unnecessarily adding an access token to attachments created from external URLs. This addition of a query string with an access token to an external URL made no sense and could lead to issues. Desired behavior after PR is merged: This commit prevents such behavior by adding a condition to check if the attachment is created from an external URL. If so, it will not generate and add an access token, ensuring the integrity of the external URL
Original PR description
Current behavior before PR: The editor's code was unnecessarily adding an access token to attachments created from external URLs. This addition of a query string with an access token to an external URL made no sense and could lead to issues. Desired behavior after PR is merged: This commit prevents such behavior by adding a condition to check if the attachment is created from an external URL. If so, it will not generate and add an access token, ensuring the integrity of the external URL. task-3470982 Forward-Port-Of: odoo/odoo#146834 Forward-Port-Of: odoo/odoo#132506
Before this commit, when trying to remove a format of a `data-oe-zws-empty-inline` of an empty block, the attribute was added to that block and would never be removed. How to reproduce the original bug: - put the selection inside an emtpy p - ctrl+b (in windows/linux) or cmd+b (in mac) => The zws attribute data-oe-zws-empty-inline is added on the P rather than creating a span. - The next letter that will be typed will not be bold but should be bold - That attribute should
Original PR description
Before this commit, when trying to remove a format of a `data-oe-zws-empty-inline` of an empty block, the attribute was added to that block and would never be removed. How to reproduce the original bug: - put the selection inside an emtpy p - ctrl+b (in windows/linux) or cmd+b (in mac) => The zws attribute data-oe-zws-empty-inline is added on the P rather than creating a span. - The next letter that will be typed will not be bold but should be bold - That attribute should not exists in a block, that could lead to unexpected bug task-3628480 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148089 Forward-Port-Of: odoo/odoo#146186
Following odoo/odoo@2a8dd6011, if a db has `web.max_file_upload_size` ICP set to any value, the request would have been wrongly limited to 1 byte --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148617
Original PR description
Following odoo/odoo@2a8dd6011, if a db has `web.max_file_upload_size` ICP set to any value, the request would have been wrongly limited to 1 byte --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148617
Before this commit, for a barcode rule with the UPC-A encoding, the condition's checking if we should convert an EAN-13 to an UPC-A was always false because the key `upc_ean_conv` was checked on the wrong object (`this` instead of `this.nomenclature`.) task-3472884 Forward-Port-Of: odoo/odoo#147955 Forward-Port-Of: odoo/odoo#142163
Original PR description
Before this commit, for a barcode rule with the UPC-A encoding, the condition's checking if we should convert an EAN-13 to an UPC-A was always false because the key `upc_ean_conv` was checked on the wrong object (`this` instead of `this.nomenclature`.) task-3472884 Forward-Port-Of: odoo/odoo#147955 Forward-Port-Of: odoo/odoo#142163
In odoo@98ca5140baf96, a test using a product of type 'product' was added. Since this type is introduced in stock, stock needs be installed. Since the delivery module was split in saas-16.2 to remove the dependency to stock, this test needs to be moved in website_sale_stock. Build error 48757 Forward-Port-Of: odoo/odoo#148645 Forward-Port-Of: odoo/odoo#148547
Original PR description
In odoo@98ca5140baf96, a test using a product of type 'product' was added. Since this type is introduced in stock, stock needs be installed. Since the delivery module was split in saas-16.2 to remove the dependency to stock, this test needs to be moved in website_sale_stock. Build error 48757 Forward-Port-Of: odoo/odoo#148645 Forward-Port-Of: odoo/odoo#148547
The jsconfig.json file is used by editors to provide autocompletion but the paths were not updated when it's used in the enterprise path. 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#148618 Forward-Port-Of: odoo/odoo#148605
Original PR description
The jsconfig.json file is used by editors to provide autocompletion but the paths were not updated when it's used in the enterprise path. 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#148618 Forward-Port-Of: odoo/odoo#148605
Steps: 1. install project ,website,saleorder 2. open project ,share a saleorder project to admin from the share button 3.then go to website,click on projects 4.open the shared project 5. In that the size of the chatter is small Issue: - The size of the chatter is abnormally small Cause : - The problem occurs because the width of the chatter is less Solution: - By increasing the chatter size the problem can be solved task-3549279 Description of the issue/feature this PR ad
Original PR description
Steps: 1. install project ,website,saleorder 2. open project ,share a saleorder project to admin from the share button 3.then go to website,click on projects 4.open the shared project 5. In that the size of the chatter is small Issue: - The size of the chatter is abnormally small Cause : - The problem occurs because the width of the chatter is less Solution: - By increasing the chatter size the problem can be solved task-3549279 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#138657
When `test_display_name_for_empty_payment_details` was tested around midnight, the test would fail because it compares the current date with the token's create date, which would be the day before. Forward-Port-Of: odoo/odoo#148698 Forward-Port-Of: odoo/odoo#148624
Original PR description
When `test_display_name_for_empty_payment_details` was tested around midnight, the test would fail because it compares the current date with the token's create date, which would be the day before. Forward-Port-Of: odoo/odoo#148698 Forward-Port-Of: odoo/odoo#148624
A class s_turnstile added to the script tag was missing. Without it, the function cleanTurnstile called by the destroyed cannot clean the script tag. So would result in the script being present several times in the DOM after some manipulation. Forward-Port-Of: odoo/odoo#148720
Original PR description
A class s_turnstile added to the script tag was missing. Without it, the function cleanTurnstile called by the destroyed cannot clean the script tag. So would result in the script being present several times in the DOM after some manipulation. Forward-Port-Of: odoo/odoo#148720
Issue: - When you have analytic plans but no analytic accounts you got a traceback when you tab through the fields on a vendor bill. Steps to reproduce: - In accounting app create a vendor bill where analytic plans exist without associated analytic accounts. - Use the key 'Tab' to move through the fields on the vendor bill. - Notice Traceback error. Solution: - Checking if the dropdown is not empty before proceeding with the Tab key logic. OPW-3648815 --- I confirm I have signed
Original PR description
Issue: - When you have analytic plans but no analytic accounts you got a traceback when you tab through the fields on a vendor bill. Steps to reproduce: - In accounting app create a vendor bill where analytic plans exist without associated analytic accounts. - Use the key 'Tab' to move through the fields on the vendor bill. - Notice Traceback error. Solution: - Checking if the dropdown is not empty before proceeding with the Tab key logic. OPW-3648815 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147807
### [FIX] point_of_sale: invoice refunds after session closing How to reproduce: - Open a PoS session - Create an order, pay it and validate - In the same session, find the order in `Orders` (filter on Paid) and make a full refund - Close the session - Open a new session and open the "refund" order in Orders - Click the "Invoice" button to invoice this order Observed behavior: - We get a UserError saying the reversal entry is unbalanced, where the credit side equals 0.00 and the cre
Original PR description
### [FIX] point_of_sale: invoice refunds after session closing How to reproduce: - Open a PoS session - Create an order, pay it and validate - In the same session, find the order in `Orders` (filter…
### [FIX] point_of_sale: invoice refunds after session closing How to reproduce: - Open a PoS session - Create an order, pay it and validate - In the same session, find the order in `Orders` (filter on Paid) and make a full refund - Close the session - Open a new session and open the "refund" order in Orders - Click the "Invoice" button to invoice this order Observed behavior: - We get a UserError saying the reversal entry is unbalanced, where the credit side equals 0.00 and the credit note is not generated. Expected behavior: - We are able to generate the credit note correctly. When computing the reversal entry, it seems we inverted the sign of the quantity field of each order line when reversing a refund. However, that did not make sense because the actual amounts are already reversed for a refund. task-3611296 ### [FIX] point_of_sale: multiple taxes duplicated on invoicing We have two taxes on a product, for which the first tax is affecting the base of the second tax. We create a PoS order with that product, pay and validate it and close the session. In a new session, we try to invoice that order. When looking at the reversal entry for that order we can see that the last tax has an additional line, computing it's tax on the first tax as a base amount. Because of that an automatic balacing line is added as well, since the move is not balanced anymore. It turns out that when generating the reversal entry, we go through the `_sync_dynamic_lines` function which is the culprit for computing the second tax again on the first tax. Since we already have all the lines needed from the invoice generated, we can actually skip invoice synchronization and prevent this issue. task-3611296 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147934 Forward-Port-Of: odoo/odoo#145890
Instead of replacing the default taxes, the key has been duplicated in the dict. (https://github.com/odoo/odoo/commit/0870357cc48ba0a7f7ce18ac32ecb677ee579498) So, instead of assigning the new tax, it is overriden by the old keys. So, the old tax is still the one referenced in the template. l10n_ee: the old tax has been deactivated, and the default_tax hasn't been changed. Added the tag to the test so it will be seen on merge next time. Linked to runbot error 52792 Description of
Original PR description
Instead of replacing the default taxes, the key has been duplicated in the dict. (https://github.com/odoo/odoo/commit/0870357cc48ba0a7f7ce18ac32ecb677ee579498) So, instead of assigning the new tax, it is overriden by the old keys. So, the old tax is still the one referenced in the template. l10n_ee: the old tax has been deactivated, and the default_tax hasn't been changed. Added the tag to the test so it will be seen on merge next time. Linked to runbot error 52792 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#146652
Commit [1] allowed restricted editor to use the optimize seo dialog: - When they have write access on the record, they can fill the form and save changes - when they don't have the write access, the form is in readonly and a warning is shown to explain it. But a mistake was made: the restricted editor, when opening the SEO dialog on a website.page, would receive an access error directly, instead of the expected readonly SEO dialog without a save button. Step to reproduce: - Login with
Original PR description
Commit [1] allowed restricted editor to use the optimize seo dialog: - When they have write access on the record, they can fill the form and save changes - when they don't have the write access, the form is in readonly and a warning is shown to explain it. But a mistake was made: the restricted editor, when opening the SEO dialog on a website.page, would receive an access error directly, instead of the expected readonly SEO dialog without a save button. Step to reproduce: - Login with a restricted editor with no extra rights - Go to / homepage - Open the optimize seo dialog - An access right error is shown [1]: https://github.com/odoo/odoo/commit/891162574eead15cf64a4f934e5f12346cbcfbbf Forward-Port-Of: odoo/odoo#148280
Since 461d311b7357d, the manufacture rule lead time is taken into account in the date computation for the procurement. The issue comes from the fact we assume there is only one warehouse related to the stock rules chain. 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#147261
Original PR description
Since 461d311b7357d, the manufacture rule lead time is taken into account in the date computation for the procurement. The issue comes from the fact we assume there is only one warehouse related to the stock rules chain. 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#147261
targeted versions: 15,16,master When a customer with a sale portal link confirms the order, the registrations in the order won't have the data for the partner of the order which would be the expected default. In 6cfdf64a86ef5c10422910734d7356a86c0c1dd6 (#69810) the intention is to avoid that registrations made on the website by anonymous users are registered with the public user. There's a side effect to this in the portal workflow though. We can reproduce it like this: - We need a p
Original PR description
targeted versions: 15,16,master When a customer with a sale portal link confirms the order, the registrations in the order won't have the data for the partner of the order which would be the expected…
targeted versions: 15,16,master When a customer with a sale portal link confirms the order, the registrations in the order won't have the data for the partner of the order which would be the expected default. In 6cfdf64a86ef5c10422910734d7356a86c0c1dd6 (#69810) the intention is to avoid that registrations made on the website by anonymous users are registered with the public user. There's a side effect to this in the portal workflow though. We can reproduce it like this: - We need a payment aqcquire wich confirms our sale order (we can use payment demo) - In backend, create a sale order with the desired partner and a registration to an event. - Send the quotation to the partner. - With the link portal (and without being logged in) sign and pay the order with the demo payment aquirer. Result: - The order gets confirmed. - The registrations are created with no partner (booked by). So this fix avoids the original issue (having a public user as the registration partner) but saving the case where we are confident about the booked by value. cc @Tecnativa TT44782 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#132959
This commit ensures that elements returned by the getTabableElements method of the ui utils does not return invisibe elements. This fixes an issue with the trapFocus method of the ui service which could set an invisible element as lastTabableEl therefore making it impossible to loop back to the firstTabableEl when the actual last tabable element is focused and the client presses tab. Also fix a side effect of these changes in list renderer where focusCell would be called before the cell width c
Original PR description
This commit ensures that elements returned by the getTabableElements method of the ui utils does not return invisibe elements. This fixes an issue with the trapFocus method of the ui service which…
This commit ensures that elements returned by the getTabableElements method of the ui utils does not return invisibe elements. This fixes an issue with the trapFocus method of the ui service which could set an invisible element as lastTabableEl therefore making it impossible to loop back to the firstTabableEl when the actual last tabable element is focused and the client presses tab. Also fix a side effect of these changes in list renderer where focusCell would be called before the cell width computations which would work by chance before since getTabableElements took into account elements with 0 width but is now no longer the case. This is fixed by moving down the onPatched method which calls focusCell underneath the useEffect method which performs column style computations. Steps to reproduce: - Go to any dialog with mail installed - Press tab multiple times - At some point, the address bar should be focused instead of the dialog buttons Explanation: the chatter is present in the DOM but not displayed so the last tabable element that is detected by getTabableElements is a child node of the chatter which cannot be reached. OPW-3584847 Forward-Port-Of: odoo/odoo#148382 Forward-Port-Of: odoo/odoo#147978
The adaptation made in commit 037e5b8, related to this [commit](https://github.com/odoo/o-spreadsheet/commit/17ba12211) forgot to account for non-fomula cells. 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#148510
Original PR description
The adaptation made in commit 037e5b8, related to this [commit](https://github.com/odoo/o-spreadsheet/commit/17ba12211) forgot to account for non-fomula cells. 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#148510
The problem was the hard coded `@Mitchell Admin` in the expected result. The case can be different when the demo data changes. Change the test and make it fixed in all cases. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148710
Original PR description
The problem was the hard coded `@Mitchell Admin` in the expected result. The case can be different when the demo data changes. Change the test and make it fixed in all cases. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148710
**Steps to Reproduce** 1). Create an opportunity, and give it a new contact 2). Set Joel Willis as the reseller (needs a partner grade for that) 3). Log in as Joel, and try to open this opportunity through the portal -> Access Error 403 **Technical** We are trying to show the avatar of the partner because a portal user doesn't have access to see the avatar so 403 forbidden errors occur. This problem occurred after this commit: https://github.com/odoo/odoo/commit/df8535fbd40e1e5c09
Original PR description
**Steps to Reproduce** 1). Create an opportunity, and give it a new contact 2). Set Joel Willis as the reseller (needs a partner grade for that) 3). Log in as Joel, and try to open this opportunity through the portal -> Access Error 403 **Technical** We are trying to show the avatar of the partner because a portal user doesn't have access to see the avatar so 403 forbidden errors occur. This problem occurred after this commit: https://github.com/odoo/odoo/commit/df8535fbd40e1e5c09dbe616a3332c76c23525c8 **After this PR** Now portal user can see the opportunity. Task-3580254 Forward-Port-Of: odoo/odoo#144113
[FIX] stock: assign partner on return outgoing stock moves Issue: When printing delivery slip report the warehouse address is shown instead of the delivery address. Steps to Reproduce: 1. Install Purchase App. 2. Install Inventory App. 3. Create Purchase Order. 4. Receive Purchase Order. 5. Return the transfer. 6. print delivery slip Solution: Issue was that upon creating the return stock moves that will be outgoing we copy the attributes from the original incoming stock move w
Original PR description
[FIX] stock: assign partner on return outgoing stock moves Issue: When printing delivery slip report the warehouse address is shown instead of the delivery address. Steps to Reproduce: 1. Install Purchase App. 2. Install Inventory App. 3. Create Purchase Order. 4. Receive Purchase Order. 5. Return the transfer. 6. print delivery slip Solution: Issue was that upon creating the return stock moves that will be outgoing we copy the attributes from the original incoming stock move which does not have a partner assigned, So the solution was to assign the partner on the outgoing stock moves right away from the stock picking. opw-3623451 Forward-Port-Of: odoo/odoo#148398 Forward-Port-Of: odoo/odoo#146273
Before this commit, the mockServer didn't respect the unity specification for many2one fields. When you do a mockWebRead and you want to read other fields than "id" and "display_name" for a many2one field, the mockServeur ignores this part of the specification. The goal of this commit is to ensure that the mockWebRead respects the full specification for many2one fields. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged
Original PR description
Before this commit, the mockServer didn't respect the unity specification for many2one fields. When you do a mockWebRead and you want to read other fields than "id" and "display_name" for a many2one field, the mockServeur ignores this part of the specification. The goal of this commit is to ensure that the mockWebRead respects the full specification for many2one fields. 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#148483
Before this commit, it was possible that an attempt to update peer connections made right at the moment the connection was swapped from peer-to-peer to server mode. Which would cause a traceback. This commit fixes this issue by checking if there is a `RTCPeerConnection` before trying to update it. Forward-Port-Of: odoo/odoo#148505
Original PR description
Before this commit, it was possible that an attempt to update peer connections made right at the moment the connection was swapped from peer-to-peer to server mode. Which would cause a traceback. This commit fixes this issue by checking if there is a `RTCPeerConnection` before trying to update it. Forward-Port-Of: odoo/odoo#148505
Todo: unit test Forward-Port-Of: odoo/odoo#148630
Original PR description
Todo: unit test Forward-Port-Of: odoo/odoo#148630
task-3611153 Forward-Port-Of: odoo/odoo#148570 Forward-Port-Of: odoo/odoo#146158
Original PR description
task-3611153 Forward-Port-Of: odoo/odoo#148570 Forward-Port-Of: odoo/odoo#146158
opw-3614919 Forward-Port-Of: odoo/odoo#148571 Forward-Port-Of: odoo/odoo#146490
Original PR description
opw-3614919 Forward-Port-Of: odoo/odoo#148571 Forward-Port-Of: odoo/odoo#146490
[FIX] sale: always lock confirmed order when auto-lock activated Steps to reproduce: 1- Install Sales module 2- Activate Lock Confirmed Sales from Sales settings 3- Create a new order as a Public user and make the payment 4- Check the state of this order in backend Current behavior before PR: Upon creating and confirming an order as a public user the order does not get locked even if the 'Lock Confirmed Sales' setting is turned on. This is happening because when checking if the 'L
Original PR description
[FIX] sale: always lock confirmed order when auto-lock activated Steps to reproduce: 1- Install Sales module 2- Activate Lock Confirmed Sales from Sales settings 3- Create a new order as a Public…
[FIX] sale: always lock confirmed order when auto-lock activated Steps to reproduce: 1- Install Sales module 2- Activate Lock Confirmed Sales from Sales settings 3- Create a new order as a Public user and make the payment 4- Check the state of this order in backend Current behavior before PR: Upon creating and confirming an order as a public user the order does not get locked even if the 'Lock Confirmed Sales' setting is turned on. This is happening because when checking if the 'Lock Confirmed Sales' group is on or not we check if it is there for the current user which if he is a public user by default will not have this group. Desired behavior after PR is merged: Before we had this condition checking if self.env.user has the 'Lock Confirmed Sales' but this won't work if the SO is coming from eCommerce with public user env So now we are checking the creator of the SO that in the eCommerce scenario will be OdooBot and if the SO is created from the backend it will be one of the users who already has the group. opw-3595964 Forward-Port-Of: odoo/odoo#148162 Forward-Port-Of: odoo/odoo#146188
# Issue: The query for the Tax Report Account>Tax is slow. # Analyze: The query for the Tax Report is huge, and exceeds the join_collapse_limit threshold (https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-JOIN-COLLAPSE-LIMIT) of postgresql (8 by default and on our servers). It is then needed to help the query planner to optimize this query. Running the query with increased join_collapse_limit and checking the explain analyze, helps in this process. # Fix: The q
Original PR description
# Issue: The query for the Tax Report Account>Tax is slow. # Analyze: The query for the Tax Report is huge, and exceeds the join_collapse_limit threshold…
# Issue: The query for the Tax Report Account>Tax is slow. # Analyze: The query for the Tax Report is huge, and exceeds the join_collapse_limit threshold (https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-JOIN-COLLAPSE-LIMIT) of postgresql (8 by default and on our servers). It is then needed to help the query planner to optimize this query. Running the query with increased join_collapse_limit and checking the explain analyze, helps in this process. # Fix: The query planer with increased join_collapse_limit made the res_currency joins at the very end of a truncated query. Moving the res_currency join help as the inner join is made on AM^2 on current position. Moving it after the base_line reduce it back to AM^1. # Benchmark: | # Input data | Before PR | After PR | |:-------------:|:----------:|:---------:| | 271000 AM | 900 s | 13.24 s| | 25000 AM | 180 s | 1.5 s | | 51 AM (demo data) |52ms | 80ms | # Related task: opw-3581671 Co-authored-by: Julien Launois (jula) <jula@odoo.com> Forward-Port-Of: odoo/odoo#148340 Forward-Port-Of: odoo/odoo#145904
When a user connects to its database that has been freshly upgraded to 17.0 database, he gets the following JS crash: ``` TypeError: can't access property "defineLocale", moment is undefined @http://www.odoo.test/web/webclient/locale/fr_FR:13:10 @http://www.odoo.test/web/webclient/locale/fr_FR:9:4 @http://www.odoo.test/web/webclient/locale/fr_FR:10:2 ``` Before 17.0, the `/web/webclient/locale/<string:lang>` route was used to get the appropriate `momentjs` locale and was c
Original PR description
When a user connects to its database that has been freshly upgraded to 17.0 database, he gets the following JS crash:
```
TypeError: can't access property "defineLocale", moment is undefined
@http://www.odoo.test/web/webclient/locale/fr_FR:13:10
@http://www.odoo.test/web/webclient/locale/fr_FR:9:4
@http://www.odoo.test/web/webclient/locale/fr_FR:10:2
```
Before 17.0, the `/web/webclient/locale/<string:lang>` route was used to get the appropriate `momentjs` locale and was cached for a duration of 1 week.
So when connecting to the upgraded database we will get the cached file, but as `momentjs` has been removed (see odoo/odoo@4327c062d820) it will crash.
Now as `luxon` is using browser's `Intl` to get the translations, we can safely remove the call to that endpoint (it will always return an empty file anyway)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#145733On website (with “developer” mode enabled), The “Model Pages” menu item is accessible even when there are no created module page records, which is not relevant in most use cases. The code from [1] introduced a way to expose models (both manual and existing models) publicly on the website by creating pages for them, these records are accessible through the model pages' menu (which is currently visible in debug mode only). A first spec aimed to make this menu item visible only when modu
Original PR description
On website (with “developer” mode enabled), The “Model Pages” menu item is accessible even when there are no created module page records, which is not relevant in most use cases. The code from [1] introduced a way to expose models (both manual and existing models) publicly on the website by creating pages for them, these records are accessible through the model pages' menu (which is currently visible in debug mode only). A first spec aimed to make this menu item visible only when module pages are created for the current website, But since we need to perform async calls for that (to check if some module page records exist), and after further discussion, it was decided to remove it completely. [1]: https://github.com/odoo/odoo/commit/198e226f5bd66dba6598d1ef85e5fa5fb82b38b2 task-3659626 Forward-Port-Of: odoo/odoo#148175
Current behavior: When an order total is rounded, if you refund it from the backend. The refund amount is not correct, and you will not be able to close your pos session. Steps to reproduce: - Create a rounding of 0.05 HALF UP and activate it on the PoS - Create a product with a price of 49.99 - Sell the product in the PoS - Go back to the backend without closing the session - Refund the order from the backend - Try to close the session opw-3574913 --- I confirm I have signed the
Original PR description
Current behavior: When an order total is rounded, if you refund it from the backend. The refund amount is not correct, and you will not be able to close your pos session. Steps to reproduce: - Create a rounding of 0.05 HALF UP and activate it on the PoS - Create a product with a price of 49.99 - Sell the product in the PoS - Go back to the backend without closing the session - Refund the order from the backend - Try to close the session opw-3574913 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146474
Purpose ======= With an empty contract, the end user is in front of a page with no information (wage, advantages, etc), which gives the feeling that the configurator is broken. Return an error instead of trying to display the page at all costs. task-3663181 Forward-Port-Of: odoo/enterprise#53540
Original PR description
Purpose ======= With an empty contract, the end user is in front of a page with no information (wage, advantages, etc), which gives the feeling that the configurator is broken. Return an error instead of trying to display the page at all costs. task-3663181 Forward-Port-Of: odoo/enterprise#53540
Before this commit, the digits options (eg: in FloatField) was of type string. This means that when editing the value with studio, the user could type anything. The FloatField would then fail when being instanciated after leaving studio when editing a record. When passing the digits option, it should only contain an array of two ints. The first number is supposed to represent the total number of digits and the second one represent the decimal precision. The total number isn't actual
Original PR description
Before this commit, the digits options (eg: in FloatField) was of type string. This means that when editing the value with studio, the user could type anything. The FloatField would then fail when being instanciated after leaving studio when editing a record. When passing the digits option, it should only contain an array of two ints. The first number is supposed to represent the total number of digits and the second one represent the decimal precision. The total number isn't actually used in the JS codebase. Solution ======== - Introduce a new option type: digits - Only allow integers between 0 and 20 as that value is passed to `toFixed` - If the entered value is invalid, set a red border on the input and do nothing opw-3614919 Forward-Port-Of: odoo/enterprise#53865 Forward-Port-Of: odoo/enterprise#52889
Display the appointment resource avatar for public user. Before this changes, the grey camera placeholder was displayed for appointment resource. Like the staff user we now bypass the access rights for appointment resource to get its avatar (if it belongs to the appointment type) task-3611307 Forward-Port-Of: odoo/enterprise#53760 Forward-Port-Of: odoo/enterprise#51832
Original PR description
Display the appointment resource avatar for public user. Before this changes, the grey camera placeholder was displayed for appointment resource. Like the staff user we now bypass the access rights for appointment resource to get its avatar (if it belongs to the appointment type) task-3611307 Forward-Port-Of: odoo/enterprise#53760 Forward-Port-Of: odoo/enterprise#51832
Before this commit, in the table of the followup report the first column header had no label which was confusing for the user. This commit will add a name to the column ("Reference"). task: 3630022 Forward-Port-Of: odoo/enterprise#53720 Forward-Port-Of: odoo/enterprise#52768
Original PR description
Before this commit, in the table of the followup report the first column header had no label which was confusing for the user. This commit will add a name to the column ("Reference").
task: 3630022
Forward-Port-Of: odoo/enterprise#53720
Forward-Port-Of: odoo/enterprise#52768Steps to reproduce: - have an instance with no invoice posted - run the test `test_merge_partner_in_hashed_entries` Issue: The error message generated will not match the one specified in the test. Cause: The message discrepancy is dependent on whether all invoices or only a portion of them are hashed. https://github.com/odoo/odoo/blob/2023b96c725617cb8b403cd89769e5dbc07e1ddc/addons/account/models/company.py#L626 Solution: Post an invoice before restricting the journal runbot-544
Original PR description
Steps to reproduce: - have an instance with no invoice posted - run the test `test_merge_partner_in_hashed_entries` Issue: The error message generated will not match the one specified in the test. Cause: The message discrepancy is dependent on whether all invoices or only a portion of them are hashed. https://github.com/odoo/odoo/blob/2023b96c725617cb8b403cd89769e5dbc07e1ddc/addons/account/models/company.py#L626 Solution: Post an invoice before restricting the journal runbot-54407 Forward-Port-Of: odoo/enterprise#53899
[FIX] account_accountant: include parent companies accounts Issue: When listing accounts options for deferred entries of a branch it doesn't show the the accounts of the parent company Steps to reproduce: 1. Install Accounting App 2. Go to settings 3. Go to Users&Companies 4. Go to Companies 5. Choose a company 6. Branches 7. Create a new branch 8. Go to accounting app 9. Go to settings 10. Change current company to be the new branch 11. Go to default accounts 12. list deferre
Original PR description
[FIX] account_accountant: include parent companies accounts Issue: When listing accounts options for deferred entries of a branch it doesn't show the the accounts of the parent company Steps to reproduce: 1. Install Accounting App 2. Go to settings 3. Go to Users&Companies 4. Go to Companies 5. Choose a company 6. Branches 7. Create a new branch 8. Go to accounting app 9. Go to settings 10. Change current company to be the new branch 11. Go to default accounts 12. list deferred entries options Solution: The domain on these fields was defining a criteria that the account's company should be the same as the current company while the current company can be a branch of another company, so we changed the criteria opw-3633186 Forward-Port-Of: odoo/enterprise#53366
Re-activate the mentions ======================== In 0cccfe3 , we automatically removed the mentions if we are not mentioning the user we reply to, because we had some issues with Twitter. Now that we have an enterprise subscription, we want to re-activate them. An option has been added to disable users mention again. Remove the anti-spam system =========================== In e09d8aa , we added a system to prevent the users from spamming in the feed view. Now that we have an enterp
Original PR description
Re-activate the mentions ======================== In 0cccfe3 , we automatically removed the mentions if we are not mentioning the user we reply to, because we had some issues with Twitter. Now that we have an enterprise subscription, we want to re-activate them. An option has been added to disable users mention again. Remove the anti-spam system =========================== In e09d8aa , we added a system to prevent the users from spamming in the feed view. Now that we have an enterprise subscription, we want to remove that restriction by default (it is still possible to enable it with a system parameter). Can not add a stream for the tweets of a user === When trying to add the tweets of a specific users, we get an error because the field `twitter_followed_account_search` is never set (only `twitter_followed_account_id`). Task-3615860 Forward-Port-Of: odoo/enterprise#51752
Issue: Encountering a traceback error when attempting to stop the timer on an existing record in the timesheet kanban view. Steps to Reproduce: Navigate to the timesheet kanban view. Use the group-by search option. Click on the start timer button for an existing record and stop the timer. Cause: The traceback is triggered due to an undefined timesheet value. The cause lies in a conditional check that restricts setting the timesheet value only for dynamic records. Solution: Remove
Original PR description
Issue: Encountering a traceback error when attempting to stop the timer on an existing record in the timesheet kanban view. Steps to Reproduce: Navigate to the timesheet kanban view. Use the group-by search option. Click on the start timer button for an existing record and stop the timer. Cause: The traceback is triggered due to an undefined timesheet value. The cause lies in a conditional check that restricts setting the timesheet value only for dynamic records. Solution: Remove the conditional check that limits timesheet value assignment to dynamic records. and add a new condition to ensure the timesheet value is set for both dynamic and existing records. task-3555184 Forward-Port-Of: odoo/enterprise#53769 Forward-Port-Of: odoo/enterprise#49709
Steps: - Install Timesheet app. - Open timesheet. Issue: - Timesheet are not order the way it was before grid owl conversion. Cause: - After grid view owl converion grid is fetching data from server side and it was not taking any orderby into account so it was getting data according to default order on timesheets which is `date desc, id desc`. Fix: - Added a method to get order according to section and row fields so it will display data according to user pref and it'll be more conv
Original PR description
Steps: - Install Timesheet app. - Open timesheet. Issue: - Timesheet are not order the way it was before grid owl conversion. Cause: - After grid view owl converion grid is fetching data from server side and it was not taking any orderby into account so it was getting data according to default order on timesheets which is `date desc, id desc`. Fix: - Added a method to get order according to section and row fields so it will display data according to user pref and it'll be more convenient for users. task-3610476 Forward-Port-Of: odoo/enterprise#51547
l10n_account_* = l10n_account_customer_statements Steps: - Install `web_studio` - Install `l10n_account_customer_statements` - Open Studio from anywhere - Go to Reports and remove default filter - Select `Customer Statements` report - Traceback `CustomerStatementReport:_get_report_values` function was using `data['context']['active_ids']` to get `res.partner` records. We can just use `_get_report_values`'s params `docids` Forward-Port-Of: odoo/enterprise#53626
Original PR description
l10n_account_* = l10n_account_customer_statements Steps: - Install `web_studio` - Install `l10n_account_customer_statements` - Open Studio from anywhere - Go to Reports and remove default filter - Select `Customer Statements` report - Traceback `CustomerStatementReport:_get_report_values` function was using `data['context']['active_ids']` to get `res.partner` records. We can just use `_get_report_values`'s params `docids` Forward-Port-Of: odoo/enterprise#53626
Steps to reproduce: - Install Accounting - Create a customer payment of $100 - Go to "Accounting / Accounting / Journals / Journal Items" - Set a Group By Account - Under "Outstanding Receipts" account, you should find the payment - Select the payment and reconcile it - Use the same account for the write-off (i.e. Outstanding Receipts) - Reconcile => The payment and the write-off are partially reconciled. They should be fully reconciled. Cause: The write-off is created with "Outst
Original PR description
Steps to reproduce: - Install Accounting - Create a customer payment of $100 - Go to "Accounting / Accounting / Journals / Journal Items" - Set a Group By Account - Under "Outstanding Receipts"…
Steps to reproduce: - Install Accounting - Create a customer payment of $100 - Go to "Accounting / Accounting / Journals / Journal Items" - Set a Group By Account - Under "Outstanding Receipts" account, you should find the payment - Select the payment and reconcile it - Use the same account for the write-off (i.e. Outstanding Receipts) - Reconcile => The payment and the write-off are partially reconciled. They should be fully reconciled. Cause: The write-off is created with "Outstanding Receipts" account for both the write-off line and the counterpart line. Once created, a filter on the reconciliation account (i.e. Outstanding Receipts) is performed on the write-off lines to reconciled them with the payment line. As both write-off lines are using the same account, we try to reconcile the payment line (100), the write-off line (100) and its counterpart (-100) together, which cannot be fully reconciled. Solution: The first line of the write-off should contain the counterpart line. So we can just select that line for reconciliation. opw-3553008 Forward-Port-Of: odoo/enterprise#51892
### Steps to reproduce: - Install **helpdesk** _app_ and the **Helpdesk Merge action** _module_. - Open **helpdesk** app. - Open **Customer Care** tickets in **list** view - Select the two tickets: - Where can I download a catalog ? - Wood Treatment - Click on **Action** button and choose **Merge** - Click **MERGE** - Open the ticket **Where can I download a catalog ?** - In the chatter log, notice how the **description** is not formatted properly ### Investigation: - The
Original PR description
### Steps to reproduce: - Install **helpdesk** _app_ and the **Helpdesk Merge action** _module_. - Open **helpdesk** app. - Open **Customer Care** tickets in **list** view - Select the two tickets: -…
### Steps to reproduce:
- Install **helpdesk** _app_ and the **Helpdesk Merge action** _module_.
- Open **helpdesk** app.
- Open **Customer Care** tickets in **list** view
- Select the two tickets:
- Where can I download a catalog ?
- Wood Treatment
- Click on **Action** button and choose **Merge**
- Click **MERGE**
- Open the ticket **Where can I download a catalog ?**
- In the chatter log, notice how the **description** is not formatted properly
### Investigation:
- The `changes` are rendered using `t-esc` https://github.com/odoo/enterprise/blob/385c20dc2328cf146698195cac65c93a1b2fd480/data_merge/data/mail_templates.xml#L14
- Which comes from the `merge_records()` method https://github.com/odoo/enterprise/blob/fd309b8ce3649bdd3f86fb3a6723d398a58570ad/data_merge/models/data_merge_group.py#L161
- using `_record_snapshot()` method that uses `_render_values()` method that converts the formatted value into a string https://github.com/odoo/enterprise/blob/fd309b8ce3649bdd3f86fb3a6723d398a58570ad/data_merge/models/data_merge_record.py#L193 hence when the marked safe description coming from https://github.com/odoo/odoo/blob/49df26564203d2d836308828965d8bffff27b364/odoo/fields.py#L2026-L2030 is converted to a string making it not safe any more and escaped when rendered.
opw-3627171
Forward-Port-Of: odoo/enterprise#53095Similarly to this [commit], but for the `/calendar` command, when closing the dialog, the article scrolls to the top. This is because the focus is forcibly given back to the `editable` and the selection was not put back inside at the position where the command was executed: it is reset to the top instead. This commit restores the selection when closing the dialog so that when the focus is given back to the `editable`, no scrolling is done. [commit]: https://github.com/odoo/enterpris
Original PR description
Similarly to this [commit], but for the `/calendar` command, when closing the dialog, the article scrolls to the top. This is because the focus is forcibly given back to the `editable` and the selection was not put back inside at the position where the command was executed: it is reset to the top instead. This commit restores the selection when closing the dialog so that when the focus is given back to the `editable`, no scrolling is done. [commit]: https://github.com/odoo/enterprise/commit/09af240b59c16264060765accbad6fde0102fc16 task-3620947 Forward-Port-Of: odoo/enterprise#53916
This PR fixes 3 issues in `stock_barcode`: 1. Using the default barcode nomenclature, it's possible to convert EAN-13 to UPC-A and vice versa, but until now, it didn't work in the Barcode App; 2. In the Barcode App, it was possible to scan products who belong to another company thant the user's one; 3. While using the GS1 nomenclautre, it's possible some records barcode (like product's barcode or package's name) are interpreted as GS1 barcode because they match an AI rule. In case those parse
Original PR description
This PR fixes 3 issues in `stock_barcode`: 1. Using the default barcode nomenclature, it's possible to convert EAN-13 to UPC-A and vice versa, but until now, it didn't work in the Barcode App; 2. In the Barcode App, it was possible to scan products who belong to another company thant the user's one; 3. While using the GS1 nomenclautre, it's possible some records barcode (like product's barcode or package's name) are interpreted as GS1 barcode because they match an AI rule. In case those parsed AI rule is not relevant and does nothing, we should also search records by their barcode to see if the barcode is simply a product or package. See commits for more information. task-3472884 Forward-Port-Of: odoo/enterprise#53600 Forward-Port-Of: odoo/enterprise#50715
Currently, an error appears if you try to change the expected date of an Aged Payable/Receivable line. ### Steps to reproduce * install `account_accountant` * open the Aged Payable report * unfold a partner * click on a move and select 'Change expected payment date' You should be met with an error. opw-3647341 Forward-Port-Of: odoo/enterprise#53709
Original PR description
Currently, an error appears if you try to change the expected date of an Aged Payable/Receivable line. ### Steps to reproduce * install `account_accountant` * open the Aged Payable report * unfold a partner * click on a move and select 'Change expected payment date' You should be met with an error. opw-3647341 Forward-Port-Of: odoo/enterprise#53709
**Steps:** - Open Timesheet > To Validate > All Timesheets - Switch to Kanban View - Click on the validate button > Traceback occurs **Issue:** - The extra layer of the list prevents proper unpacking, leading to an 'unhashable type list' error. **Cause:** - The error occurs because the method 'action_validate_timesheet' expects unpacked values, but it receives a nested list instead of individual elements **Fix:** - Remove the additional list layer by passing 'resIds' directly to a
Original PR description
**Steps:** - Open Timesheet > To Validate > All Timesheets - Switch to Kanban View - Click on the validate button > Traceback occurs **Issue:** - The extra layer of the list prevents proper unpacking, leading to an 'unhashable type list' error. **Cause:** - The error occurs because the method 'action_validate_timesheet' expects unpacked values, but it receives a nested list instead of individual elements **Fix:** - Remove the additional list layer by passing 'resIds' directly to allow proper unpacking and resolve the error. **Task**-3646472 Forward-Port-Of: odoo/enterprise#53855 Forward-Port-Of: odoo/enterprise#53134
Steps to Reproduce ================== 1) Create a new appointment type. 2) Assign a location to it. 3) Access the front-end. - It is displayed as being online. Technical Details ================= Following this commit https://github.com/odoo/enterprise/commit/5ed8ea8e5fa65af700484aeab7745f127166d00a, the xpath in the file `appointment_templates_appointments.xml` within the `appointment_account_payment` module is causing it to fall within the if-else statement. To resolve this, chang
Original PR description
Steps to Reproduce ================== 1) Create a new appointment type. 2) Assign a location to it. 3) Access the front-end. - It is displayed as being online. Technical Details ================= Following this commit https://github.com/odoo/enterprise/commit/5ed8ea8e5fa65af700484aeab7745f127166d00a, the xpath in the file `appointment_templates_appointments.xml` within the `appointment_account_payment` module is causing it to fall within the if-else statement. To resolve this, change the class position from "else div" to "if div". After this PR ================= The "Online" status will only be shown if the location is not set. Task-3668128 Forward-Port-Of: odoo/enterprise#53640
In 16.3 and 16.4 we worked a lot on making the report more readable but the SIG report was forgotten during those changes. Commit: - https://github.com/odoo/enterprise/commit/d2d4f5e04042eb420f0f4c566269d1148baf84f7 - https://github.com/odoo/odoo/commit/56a7f7745c5df9b70e6fe5b78f401085ce46284c - https://github.com/odoo/enterprise/commit/538294661a5c0c748b55ad2d335448cd14700886 This commit will change the report to be more consistent with the other by changing the disposition of the sectio
Original PR description
In 16.3 and 16.4 we worked a lot on making the report more readable but the SIG report was forgotten during those changes. Commit: - https://github.com/odoo/enterprise/commit/d2d4f5e04042eb420f0f4c566269d1148baf84f7 - https://github.com/odoo/odoo/commit/56a7f7745c5df9b70e6fe5b78f401085ce46284c - https://github.com/odoo/enterprise/commit/538294661a5c0c748b55ad2d335448cd14700886 This commit will change the report to be more consistent with the other by changing the disposition of the section and changing the hierarchy level either by removing it and take advantage of the children_ids or changing to 0 to have the css highlight. task: 3669714 Forward-Port-Of: odoo/enterprise#53698
If a user has a timezone in his cookies that is unknows by the server To reproduce: - modify the browser cookies to a random string (or `Etc/Unknown`) - access an appointment at `/appointment/<id>` where id is an appointment without a location configured (e.g. "Technical Demo") --> crash Task-id: 3623583 Forward-Port-Of: odoo/enterprise#52007
Original PR description
If a user has a timezone in his cookies that is unknows by the server To reproduce: - modify the browser cookies to a random string (or `Etc/Unknown`) - access an appointment at `/appointment/<id>` where id is an appointment without a location configured (e.g. "Technical Demo") --> crash Task-id: 3623583 Forward-Port-Of: odoo/enterprise#52007
hr_payroll does not depend on sign. This change was introduced in https://github.com/odoo/enterprise/commit/98ff57513dce2673cd6a64bbeb5cfb84b7921dff task-3660141 Forward-Port-Of: odoo/enterprise#53474
Original PR description
hr_payroll does not depend on sign. This change was introduced in https://github.com/odoo/enterprise/commit/98ff57513dce2673cd6a64bbeb5cfb84b7921dff task-3660141 Forward-Port-Of: odoo/enterprise#53474
The reports ICP and Tax Report that have to be sent to the Dutch authorities did not pass the validation tests anymore on the authorities' server. They have been updated to the new taxonomy rules. For further maintenance on the taxonomy, see https://www.taxonomie-viewer.nl/ We also add a rounding down option to the Dutch Tax Report to be consistent with the values to export/send. Forward-Port-Of: odoo/enterprise#53456 Forward-Port-Of: odoo/enterprise#50939
Original PR description
The reports ICP and Tax Report that have to be sent to the Dutch authorities did not pass the validation tests anymore on the authorities' server. They have been updated to the new taxonomy rules. For further maintenance on the taxonomy, see https://www.taxonomie-viewer.nl/ We also add a rounding down option to the Dutch Tax Report to be consistent with the values to export/send. Forward-Port-Of: odoo/enterprise#53456 Forward-Port-Of: odoo/enterprise#50939
Fix the alignment between the questions labels and the questions inputs in the attendee form when booking an appointment. Task-3648160 Forward-Port-Of: odoo/enterprise#53191
Original PR description
Fix the alignment between the questions labels and the questions inputs in the attendee form when booking an appointment. Task-3648160 Forward-Port-Of: odoo/enterprise#53191
When the user inputs the "/link" command and subsequently closes the dialog for article selection, the cursor currently relocates to the start of the document, disrupting the editing flow. To address this issue, this commit will restore the cursor to its original position upon dialog closure. Steps to reproduce the issue: 1. Open an article you can edit 2. Put your cursor in a text block 3. Enter the "/link" command 4. Press `enter` to validate the command 5. Close the dialog for article
Original PR description
When the user inputs the "/link" command and subsequently closes the dialog for article selection, the cursor currently relocates to the start of the document, disrupting the editing flow. To address this issue, this commit will restore the cursor to its original position upon dialog closure. Steps to reproduce the issue: 1. Open an article you can edit 2. Put your cursor in a text block 3. Enter the "/link" command 4. Press `enter` to validate the command 5. Close the dialog for article selection (-> "CANCEL" button) => The cursor will be relocate to the start of the document. TO BE: The cursor should be restored to its original position upon dialog closure. task-3620947 Forward-Port-Of: odoo/enterprise#53732 Forward-Port-Of: odoo/enterprise#53048
Steps to reproduce: - Install subscriptions - Create an automation rule with: - Stage goes from "In Progress" to "Churned" - "Create next activity" for the action to do - With activity type set as "To-Do" for example - Save Issues: Infinite recursion occurs as configure_alerts call configure_alerts with the same arguments. Solution: We need to see if we went into _configure_alerts, this is done using a flag in the context. opw-3620679 Forward-Port-Of: odoo/enterprise#52605
Original PR description
Steps to reproduce: - Install subscriptions - Create an automation rule with: - Stage goes from "In Progress" to "Churned" - "Create next activity" for the action to do - With activity type set as "To-Do" for example - Save Issues: Infinite recursion occurs as configure_alerts call configure_alerts with the same arguments. Solution: We need to see if we went into _configure_alerts, this is done using a flag in the context. opw-3620679 Forward-Port-Of: odoo/enterprise#52605