Wednesday, April 24, 2024
36 changes · saas-17.2
Resolved issues and error corrections
This fixes an internal service connection issue affecting Spain's SII electronic tax reporting, especially when using test environments. It ensures the system can correctly redirect to the configured test service, reducing failures in external validation tests and support cases.
Original PR description
`l10n_es_edi_sii` requires `Client.bind` as well as `_binding_options` in the service returned by this `bind` call.
```py
serv = client.bind('siiService', service_name)
if company.l10n_es_edi_test_env and connection_vals.get('test_url'):
serv._binding_options['address'] = connection_vals['test_url']
```
Can be tested with a external l1On unit test,
tested only in nightly builds,
not by regular runbot builds / mergebot.
`--test-tags=external_l10n:TestEdiWebServices`
opw-3888257
opw-3888559
opw-3888155
opw-3890269
opw-3889683
Manual forward port of odoo/odoo#163119 to expedite the merge as quick as possible.This fix corrects a configuration issue in the sales stock quantity popover. It prevents the screen from crashing in debug mode, making troubleshooting and validation more reliable for teams working with sales and inventory data.
Original PR description
This commit simply corrects the static props declaration of the QtyAtDatePopover so that it doesn't crash in debug mode. OPW-3867784
This update fixes and modernizes internal automated tests for the Gantt view, especially around date, timezone, service mocking, and test result checks. It helps maintain product quality while keeping the changes limited to the testing layer, reducing risk for end users.
Original PR description
## Pull Request HOOT (PRHOOT) - part 15 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 15 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Community: https://github.com/odoo/odoo/pull/160292 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an error that occurred when users duplicated Accounting follow-up levels. The change also prevents duplicate naming or scheduling conflicts when copying one or more follow-up levels, making configuration maintenance smoother.
Original PR description
This traceback occurs when the user tries to duplicate a follow-up level record. To reproduce this issue: 1) Install `Accounting` 2) Open `Accounting/configuration/follow-up levels` 3) Select any one…
This traceback occurs when the user tries to duplicate a follow-up level record. To reproduce this issue: 1) Install `Accounting` 2) Open `Accounting/configuration/follow-up levels` 3) Select any one record and try to `duplicate` it. Error:- ``` TypeError: argument of type 'NoneType' is not iterable ``` https://github.com/odoo/enterprise/blob/a1921fb9a27e5da3592dbc3d9c34e41776b6c8d4/account_followup/models/account_followup.py#L47-L51 When the user tries to duplicate any record, the default value is None, which leads to the above traceback as there is no fallback for default. Because of refactoring in [1] After applying this commit, the issue will be resolved by giving a fallback value. Additionally, an SQL unique name constraint was encountered when attempting to duplicate it because of [2], so this commit also fixed by adding 15 days to the `highest delay in that company + the record name`. Previously duplicating `several levels` at the same time leads to `days_uniq` constraint because of the same delay. This commit will allow duplication several levels at the same time by offsetting `highest existing delay + 15 arbitrary days`. [1] https://github.com/odoo/enterprise/commit/e27a20d2e9a909260f28b18b0643b8205470236b [2] https://github.com/odoo/enterprise/blob/278290dd220e7ca8d4b9909d1bc48a93ac14c0eb/account_followup/models/account_followup.py#L44 sentry-5134878308
Turning off the Rental Transfers option now also archives the related Rental route. This prevents rental transfer workflows from staying active when the business has chosen to disable them.
Original PR description
When we desactivate the 'Rental Transfers' option, it should archive the Rental route.
This update fixes and improves Odoo's internal test tooling, especially around the HOOT test framework used to validate web, mail, live chat, and discussion features. It helps developers catch issues more accurately and prevents several test-interface problems, without intended changes to everyday product behavior.
Original PR description
## Pull Request HOOT (PRHOOT) - part 15 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 15 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Enterprise: https://github.com/odoo/enterprise/pull/59971 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
[FIX] hr_expense: select the right employee for an expense created with alias Current behavior: When trying to create an expense using alias, if there's several `hr.employee` linked to a user, it select the first one instead of this with the right company Steps to reproduce the error : - Create different employee's profiles for a same user - Put the default one on the user's profile (don't put the first that you created because it will select the first for the expense) - Try to send an
Original PR description
[FIX] hr_expense: select the right employee for an expense created with alias Current behavior: When trying to create an expense using alias, if there's several `hr.employee` linked to a user, it select the first one instead of this with the right company Steps to reproduce the error : - Create different employee's profiles for a same user - Put the default one on the user's profile (don't put the first that you created because it will select the first for the expense) - Try to send an email to the expense's alias and check at the logs After this commit: The right employee (this one in the default company) will be selected and no error will be triggered opw-3754015 Forward-Port-Of: odoo/odoo#162923 Forward-Port-Of: odoo/odoo#161853
Context: in 17.0 we enabled mass download for invoices. We expect this download to create a zip with all PDF invoices and their related xml files. Steps to reproduce: 1. Install l10n_fr 2. Create two invoices to french partners 3. Send & Print the two invoices and select 'Factur-x" and "Download" 4. A .zip file is generated with two PDF but only **one** XML file "factur-x.xml" Cause: The name of the XML file for the factur-x XML file is not specific to related invoice, it gets overrid
Original PR description
Context: in 17.0 we enabled mass download for invoices. We expect this download to create a zip with all PDF invoices and their related xml files. Steps to reproduce: 1. Install l10n_fr 2. Create two invoices to french partners 3. Send & Print the two invoices and select 'Factur-x" and "Download" 4. A .zip file is generated with two PDF but only **one** XML file "factur-x.xml" Cause: The name of the XML file for the factur-x XML file is not specific to related invoice, it gets overriden each time it is generated. See: https://github.com/odoo/odoo/pull/137382 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#162406
Until now, it is impossible to do <g:title>xxx</title> because qweb will autoclose the <g:link> because it checks if link is a void element instead to check g:link. Now we check the el_tag instead of unqualified_tag. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159476
Original PR description
Until now, it is impossible to do <g:title>xxx</title> because qweb will autoclose the <g:link> because it checks if link is a void element instead to check g:link. Now we check the el_tag instead of unqualified_tag. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159476
A previous commit broke the smtp authentication using a TLS certificate and we only figured it out after that a client created a support ticket several weeks later. It turns out that there are actually no test that do validate the various ways outgoing mail servers can be configured. In this work we add a test suite where a local smtp server is started and controlled during the test execution. This makes it possible to test all the possible outgoing mail server configurations, including TLS.
Original PR description
A previous commit broke the smtp authentication using a TLS certificate and we only figured it out after that a client created a support ticket several weeks later. It turns out that there are actually no test that do validate the various ways outgoing mail servers can be configured. In this work we add a test suite where a local smtp server is started and controlled during the test execution. This makes it possible to test all the possible outgoing mail server configurations, including TLS. We chose [aiosmtpd](https://aiosmtpd.readthedocs.io) which is a pure-python lightweight SMTP server that aims at providing a programming API that is well suited to be used inside unittests. [task-3703209](https://www.odoo.com/web#id=3703209&menu_id=4722&action=333&active_id=4872&model=project.task&view_type=form) [opw-3640374](https://www.odoo.com/web#id=3640374&menu_id=6444&action=5050&model=project.task&view_type=form&cids=1) Forward-Port-Of: odoo/odoo#151483
Issue: ====== If you have some tabs in a html_field, opening with a different browser may cause an issue when saving the document layout. Steps to reproduce the issue: ============================= - Open with firefox - Go to settings , document layout - Added some `tab` in the footer or any html field - save - Open with chrome - Go to settings , document layout - click save without doing anything - error Origin of the issue: ==================== When calling sanitize in the
Original PR description
Issue: ====== If you have some tabs in a html_field, opening with a different browser may cause an issue when saving the document layout. Steps to reproduce the issue: ============================= -…
Issue: ====== If you have some tabs in a html_field, opening with a different browser may cause an issue when saving the document layout. Steps to reproduce the issue: ============================= - Open with firefox - Go to settings , document layout - Added some `tab` in the footer or any html field - save - Open with chrome - Go to settings , document layout - click save without doing anything - error Origin of the issue: ==================== When calling sanitize in the constructor, the tabs size doesn't change because we didn't add the class `odoo-editor-editable` which doesn't make the `editable` dirty since no changes has been made. When calling save, `cleanForSave` will be called with a clone of the `editable` so in sanitize it won't matter since the element is not connected to the dom so again no changes and the edtior still no dirty, after that , `onWillUpdateProps` of `Wysiwyg` will be called and we will set the value of the editor by the new value which will call `resetContent` of `odooEditor` and it will sanitize the editable but this time it has the class `odoo-editor-editable` so the finally the sizes of the tabs will be changed and the editable will become dirty. Now `onWillUnmount` in `html_field` will be called and since the field is dirty it will commit changes as a normal save , but a traceback will occur since the component is already destroyed. Solution: ========= Add the class `odoo-edtior-editable` before the call to sanitize to mark the field as dirty from the start and will be updated with the new sizes of tabs on the first commit and not in the commit of `onWillUnmount`. opw-3742423 Forward-Port-Of: odoo/odoo#156898
Create a Vendor Bill Add on the invoice line a vehicle Confirm In "Journal Items" tab hit 'Cut-Off' Fill the necessary info and create journal items Issue: Created journal items will not have the vehicle id opw-3802919 Forward-Port-Of: odoo/odoo#162914 Forward-Port-Of: odoo/odoo#159434
Original PR description
Create a Vendor Bill Add on the invoice line a vehicle Confirm In "Journal Items" tab hit 'Cut-Off' Fill the necessary info and create journal items Issue: Created journal items will not have the vehicle id opw-3802919 Forward-Port-Of: odoo/odoo#162914 Forward-Port-Of: odoo/odoo#159434
Original issue: 1) Create a company "main", with 2 branches: "A" and "B" 2) Create a sub-branch for "A": "A1" 3) Archive company A 4) In the company selector, make "main" the active company. It will auto-select branch B as well. 5) Open the tax report, and try clicking the "Closing Entry" button ==> The button is disabled ; it shouldn't be. This happens because Odoo considers the full hierachy of branches to submit together is not selected. The problem originates in the way _get_branches
Original PR description
Original issue: 1) Create a company "main", with 2 branches: "A" and "B" 2) Create a sub-branch for "A": "A1" 3) Archive company A 4) In the company selector, make "main" the active company. It will…
Original issue:
1) Create a company "main", with 2 branches: "A" and "B" 2) Create a sub-branch for "A": "A1"
3) Archive company A
4) In the company selector, make "main" the active company. It will auto-select branch B as well. 5) Open the tax report, and try clicking the "Closing Entry" button ==> The button is disabled ; it shouldn't be.
This happens because Odoo considers the full hierachy of branches to submit together is not selected. The problem originates in the way _get_branches_with_same_vat searches for sub-branches, doing
self.env['res.company'].sudo().search([('id', 'child_of', current.root_id.ids)])
In our example, this search will return main, B and A1. We then compare that with the company selector, which only contains main and B.
This configuration of companies does not make sense functionally speaking, as a branch whose parent is inactive will not be usable anyway. Therefore, we now archive all the sub-branches when archiving a company.
opw-3877368
task-3878070
Forward-Port-Of: odoo/odoo#162638Description of the issue/feature this PR addresses: This commit is a performance fix to improve the speed of opening the pos kiosk or QR code. `_get_attributes` method of pos_self_order's product.product extension will call `self.env["pos.session"]._get_attributes_by_ptal_id()` every time it is called. For *N* products, `_get_attributes` is called *N* times. This can lead to slow performance for high enough *N*, because `_get_attributes_by_ptal_id` method is slow, because it makes many `read
Original PR description
Description of the issue/feature this PR addresses: This commit is a performance fix to improve the speed of opening the pos kiosk or QR code. `_get_attributes` method of pos_self_order's…
Description of the issue/feature this PR addresses: This commit is a performance fix to improve the speed of opening the pos kiosk or QR code. `_get_attributes` method of pos_self_order's product.product extension will call `self.env["pos.session"]._get_attributes_by_ptal_id()` every time it is called. For *N* products, `_get_attributes` is called *N* times. This can lead to slow performance for high enough *N*, because `_get_attributes_by_ptal_id` method is slow, because it makes many `read` calls to product.attribute.value This commit lifts the call to `_get_attributes_by_ptal_id` higher in the call stack, so that it is only called once as opposed to *N* times. It passes its result into `_get_attributes` via context, which will re-call `_get_attributes_by_ptal_id` if it wasn't in context for backwards compatibility reasons. attributes must be deep copied within `_get_attributes`, because `_add_price_info_to_attributes` mutates the values within, which would invalidate future calls. The deep copy gives a fresh instance for each call, and only copies the applicable attributes so it shouldn't be large. In this particular customer's DB they have 1376 product.product records and their pos config's pricelist (id 36) has 1572 rules in it. Overall, based on the benchmarks below, this commit makes loading the pos about 4-5 times faster. Benchmarks: __Before commit__ _Customer DB_ product.product count == 1376 SQL query count ~= 5034 Time to load pos ~= 44 sec _Customer DB with more products_ product.product count == 3792 SQL query count ~= 9359 Time to load pos ~= 96 sec __After commit__ _Customer DB_ product.product count == 1376 SQL query count ~= 2360 Time to load pos ~= 8 sec _Customer DB with more products_ product.product count == 3792 SQL query count ~= 3906 Time to load pos ~= 22 sec Current behavior before PR: Slow loading of pos kiosk/QR code Desired behavior after PR is merged: Faster loading of pos kiosk/QR code opw-3758923 Forward-Port-Of: odoo/odoo#162962 Forward-Port-Of: odoo/odoo#159551
Those were broken by the theme update for 17.0, in particular at [1]. Indeed the underline colors were defined using `text-XXX` classes to use the theme colors, relying on the fact that the default color of HR elements used the `currentColor`. Now they use the `currentColor` but very faded... making those underline colors uglier and for one of them, basically invisible. As a stable fix, this updates the XML to make the border use the `currentColor` as before in new mega menus... although they
Original PR description
Those were broken by the theme update for 17.0, in particular at [1]. Indeed the underline colors were defined using `text-XXX` classes to use the theme colors, relying on the fact that the default color of HR elements used the `currentColor`. Now they use the `currentColor` but very faded... making those underline colors uglier and for one of them, basically invisible. As a stable fix, this updates the XML to make the border use the `currentColor` as before in new mega menus... although they do not work as well in 17.0 as they did in 16.0. This will be reviewed in master to use better colors and a more reliable and beautiful way. [1]: https://github.com/odoo/odoo/commit/fad514ebdc25b9de03fd387a0c07dbbc274c364e Forward-Port-Of: odoo/odoo#163011
…countries All these countries use the chart of accounts that is defined in l10n_syscohada. The system for the loading of chart template wasn't planned to inherit from another module, and so the loading of the templates had to be adapted. This commit add the tax report for each localization, and taxes to be able to fill it. task-2841655 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I
Original PR description
…countries All these countries use the chart of accounts that is defined in l10n_syscohada. The system for the loading of chart template wasn't planned to inherit from another module, and so the loading of the templates had to be adapted. This commit add the tax report for each localization, and taxes to be able to fill it. task-2841655 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#136155
**Step to reproduce:** - Go to /jobs (install website_hr_recruitment) - Go on a job offer - Click on the "Apply" button - Edit the form **Purpose:** Since the implementation of commit [1], our system employs alerts resembling `this field 'partner_name' is mandatory for the action 'actionName'`. However, this alteration has led to a bug where in certain forms exhibit an undefined action name value, particularly evident when users attempt to modify specific forms containing
Original PR description
**Step to reproduce:** - Go to /jobs (install website_hr_recruitment) - Go on a job offer - Click on the "Apply" button - Edit the form **Purpose:** Since the implementation of commit [1], our system…
**Step to reproduce:** - Go to /jobs (install website_hr_recruitment) - Go on a job offer - Click on the "Apply" button - Edit the form **Purpose:** Since the implementation of commit [1], our system employs alerts resembling `this field 'partner_name' is mandatory for the action 'actionName'`. However, this alteration has led to a bug where in certain forms exhibit an undefined action name value, particularly evident when users attempt to modify specific forms containing required fields. The bug manifests when an alert is triggered, and the action name becomes undefined due to the condition `this.modelCantChange` evaluating to `true` within the `willStart` function. Consequently, invoking `_super` results in the return of `willStart` without assigning a value to `currentActionName`. **After this commit:** Now, before returning the function, it sets a value for `currentActionName` and then proceeds with the necessary steps. This prevents the issue where an action was `undefined`. [1]: https://github.com/odoo/odoo/pull/120874/commits/491a25b2baaa415a9bc26340eba5a11af8605411 task-3680483 Forward-Port-Of: odoo/odoo#162468 Forward-Port-Of: odoo/odoo#157501
Reduce the survey questions page in every display mode and the print page display to be the half screen size. This is done to match the previous results page improvements. Also reducing the font size of the "Thank you" message and the print page questions and sections titles to best match the new half screen display. related odoo/odoo#152263 Task-3789479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156665
Original PR description
Reduce the survey questions page in every display mode and the print page display to be the half screen size. This is done to match the previous results page improvements. Also reducing the font size of the "Thank you" message and the print page questions and sections titles to best match the new half screen display. related odoo/odoo#152263 Task-3789479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156665
Current behavior: When an order is invoided after the session has been closed, a reversed payment is created. This payment is not reconciled correctly with the invoice. This is creating an aged receivable for the partner. Steps to reproduce: - Change the bank payment method to "Identify customer" - Create an order in the PoS and pay with bank and specify a partner - Close the session - Open the session again, and create an invoice for the order - Go to the accounting module and look for
Original PR description
Current behavior: When an order is invoided after the session has been closed, a reversed payment is created. This payment is not reconciled correctly with the invoice. This is creating an aged receivable for the partner. Steps to reproduce: - Change the bank payment method to "Identify customer" - Create an order in the PoS and pay with bank and specify a partner - Close the session - Open the session again, and create an invoice for the order - Go to the accounting module and look for the aged receivable report you should see some entries under the partner you selected. - You can also go to the partner form and see that he has some due invoices. opw-3678298 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162857 Forward-Port-Of: odoo/odoo#156527
The test needs to set `product_id` field in order to check user's access. However, the field is not visible without enabling product variants, which makes the test fail in an environment with no demo data. This commit fixes the issue by adding the MRP manager to the 'product.group_product_variant' group. The issue was introduced in #162107 . Related build error: https://runbot.odoo.com/web#id=61998&cids=1&menu_id=405&action=573&model=runbot.build.error&view_type=form Description of t
Original PR description
The test needs to set `product_id` field in order to check user's access. However, the field is not visible without enabling product variants, which makes the test fail in an environment with no demo data. This commit fixes the issue by adding the MRP manager to the 'product.group_product_variant' group. The issue was introduced in #162107 . Related build error: https://runbot.odoo.com/web#id=61998&cids=1&menu_id=405&action=573&model=runbot.build.error&view_type=form Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162814
Before this commit when we have a synced event with google and then we toggle the all-day field changes didn't reflect on google side This happened because google uses two separate fields for start/end. 1. dateTime (used for normal events) 2. date (used for all-day events) when one of them is set, the other must be null. Before this commit when we did a patch update, we set only one, but forget about the other which raises an error. Task: 3681668 ============================== I
Original PR description
Before this commit when we have a synced event with google and then we toggle the all-day field changes didn't reflect on google side This happened because google uses two separate fields for…
Before this commit when we have a synced event with google and then we toggle the all-day field
changes didn't reflect on google side
This happened because google uses two separate fields for start/end.
1. dateTime (used for normal events)
2. date (used for all-day events)
when one of them is set, the other must be null.
Before this commit when we did a patch update, we set only one, but forget about the other which raises an error.
Task: 3681668
==============================
I couldn't find it in google calendar api documentation supporting my claim. But I based my conclusion on these facts:
1. when sending a get request to google API for all-day events it would look like this, we can observe that for both start/end it doesn't have a `dateTime` but only `date`.
```js
{
"kind": "calendar#event",
"etag": "\"3420874125486000\"",
"id": "11qeiguv96iei6nkd4helg421b",
"status": "confirmed",
"htmlLink": "https://www.google.com/calendar/event?eid=MTFxZWlndXY5NmllaTZua2Q0aGVsZzQyMWIgYWxhaEBvZG9vLmNvbQ",
"created": "2024-03-14T10:39:50.000Z",
"updated": "2024-03-14T17:24:22.743Z",
"summary": "all day from google",
"creator": {
"email": "alah@odoo.com",
"self": true
},
"organizer": {
"email": "alah@odoo.com",
"self": true
},
"start": {
"date": "2024-03-20"
},
"end": {
"date": "2024-03-21"
},
"transparency": "transparent",
"iCalUID": "11qeiguv96iei6nkd4helg421b@google.com",
"sequence": 2,
"reminders": {
"useDefault": false
},
"eventType": "default"
}
```
2. When doing the same for an event that is not marked as all-day. we would get this
```js
{
"kind": "calendar#event",
"etag": "\"3420880154840000\"",
"id": "6ngnlju6nofaa0h478nkqgrhna",
"status": "confirmed",
"htmlLink": "https://www.google.com/calendar/event?eid=Nm5nbmxqdTZub2ZhYTBoNDc4bmtxZ3JobmEgYWxhaEBvZG9vLmNvbQ",
"created": "2024-03-14T18:14:37.000Z",
"updated": "2024-03-14T18:14:37.420Z",
"summary": "aaa",
"creator": {
"email": "alah@odoo.com",
"self": true
},
"organizer": {
"email": "alah@odoo.com",
"self": true
},
"start": {
"dateTime": "2024-03-14T15:00:00+02:00",
"timeZone": "Africa/Cairo"
},
"end": {
"dateTime": "2024-03-14T16:00:00+02:00",
"timeZone": "Africa/Cairo"
},
"iCalUID": "6ngnlju6nofaa0h478nkqgrhna@google.com",
"sequence": 0,
"reminders": {
"useDefault": true
},
"eventType": "default"
}
```
so on google side, it's either `date` or `dateTime` but not both. Hence when doing a patch update for either `date` or `dateTime` we should unset the other.
Forward-Port-Of: odoo/odoo#157664Forward-Port-Of: odoo/odoo#162864
Original PR description
Forward-Port-Of: odoo/odoo#162864
Problem --------- Because of this PR: 155896, the customer default value for the UBL export values has been modified from commercial partner to partner. However, in 16.0+, some constraints have been added to verify that some fields were properly set up before generating the XML. Those restrictions clash with the said changes. Indeed: 1 - Create NO company 2 - Set up UBL on invoice journal 3 - Create a new NO customer and set up UBL in the same way 4 - Create an invoicing address for t
Original PR description
Problem --------- Because of this PR: 155896, the customer default value for the UBL export values has been modified from commercial partner to partner. However, in 16.0+, some constraints have been added to verify that some fields were properly set up before generating the XML. Those restrictions clash with the said changes. Indeed: 1 - Create NO company 2 - Set up UBL on invoice journal 3 - Create a new NO customer and set up UBL in the same way 4 - Create an invoicing address for that customer 5 - Create an invoice for with the customer set as the invoice address set up in step 3. 6 - Send & Print with UBL selected >> An error is added to the export errors while it should not. Solution --------- Use the commercial partner when checking constrains of all fields other than addresses. OPW-3848367 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162366 Forward-Port-Of: odoo/odoo#160523
Surveys cannot be created in batch without `session_code` because it must be unique across surveys. Technically, using a 5-digit codes makes it unlikely that a collision occurs with records created without explicit session_code (see Survey._get_default_session_code's iterative process). See runbot 55709 See also related runbot 25041 Task-3829536 Forward-Port-Of: odoo/odoo#159882
Original PR description
Surveys cannot be created in batch without `session_code` because it must be unique across surveys. Technically, using a 5-digit codes makes it unlikely that a collision occurs with records created without explicit session_code (see Survey._get_default_session_code's iterative process). See runbot 55709 See also related runbot 25041 Task-3829536 Forward-Port-Of: odoo/odoo#159882
This commit fixes a bug where the value of an autocomplete with autoselect could go into an undefined state where the model value doesn't match the input value but no change is detected. This would happen on escape press, scroll and more recently due to https://github.com/odoo/odoo/pull/159333 on click out. To fix this issue, the commit introduces some change in the autocomplete behavior so that it will no longer select the active option on click out (blur) when autoselect is active and instead
Original PR description
This commit fixes a bug where the value of an autocomplete with autoselect could go into an undefined state where the model value doesn't match the input value but no change is detected. This would…
This commit fixes a bug where the value of an autocomplete with autoselect could go into an undefined state where the model value doesn't match the input value but no change is detected. This would happen on escape press, scroll and more recently due to https://github.com/odoo/odoo/pull/159333 on click out. To fix this issue, the commit introduces some change in the autocomplete behavior so that it will no longer select the active option on click out (blur) when autoselect is active and instead it will revert the input value to the one stored into the model. Also applies this behavior on escape key press and scroll for the before mentioned reasons. Steps to reproduce: - Go to CRM form view - Edit the salesperson name to some non existant one and click out (or scroll or press escape) Before the fix, the name was stuck to the invalid one but no change was detected so we couldnt save it. Before https://github.com/odoo/odoo/pull/159333, click out would select the active option of the dropdown instead (and launch a dialog for quick create). This is removed because the behavior is neither intuitive nor practical. After the fix, the name is reset to its previous valid value instead. This applies to all autocomplete components with autoselect prop set to true. Forward-Port-Of: odoo/odoo#162265 Forward-Port-Of: odoo/odoo#161251
Before this fix, any XRechnung xml will raise a warning when being submitted on https://erechnungsvalidator.service-bw.de/. The warning states: "[BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen." This is because the version 3.0.1 has been released. issue-160644 Forward-Port-Of: odoo/odoo#162187
Original PR description
Before this fix, any XRechnung xml will raise a warning when being submitted on https://erechnungsvalidator.service-bw.de/. The warning states: "[BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen." This is because the version 3.0.1 has been released. issue-160644 Forward-Port-Of: odoo/odoo#162187
This test can sometimes fail randomly ``` FAIL: TestProfiling.test_sync_recorder Traceback (most recent call last): File "/data/build/odoo/odoo/addons/base/tests/test_profiler.py", line 440, in test_sync_recorder self.assertEqual(stacks_methods, [ AssertionError: Lists differ: [['a'[114 chars]], ['__exit__', '_remove'], ['__exit__'], ['__exit__', 'stop']] != [['a'[114 chars]], ['__exit__', 'stop']] First differing element 11: ['__exit__', '_remove']
Original PR description
This test can sometimes fail randomly ``` FAIL: TestProfiling.test_sync_recorder Traceback (most recent call last): File "/data/build/odoo/odoo/addons/base/tests/test_profiler.py", line 440, in…
This test can sometimes fail randomly
```
FAIL: TestProfiling.test_sync_recorder
Traceback (most recent call last):
File "/data/build/odoo/odoo/addons/base/tests/test_profiler.py", line 440, in test_sync_recorder
self.assertEqual(stacks_methods, [
AssertionError: Lists differ: [['a'[114 chars]], ['__exit__', '_remove'], ['__exit__'], ['__exit__', 'stop']] != [['a'[114 chars]], ['__exit__', 'stop']]
First differing element 11:
['__exit__', '_remove']
['__exit__', 'stop']
First list contains 2 additional elements.
First extra element 12:
['__exit__']
[['a'],
['a', 'b'],
['a'],
['a', 'c'],
['a', 'c', 'd'],
['a', 'c'],
['a', 'c', 'd'],
['a', 'c'],
['a'],
[],
['__exit__'],
- ['__exit__', '_remove'],
- ['__exit__'],
['__exit__', 'stop']]
```
Since we don't care about the last lines, just remove them from the assertion.
Forward-Port-Of: odoo/odoo#163016When the module "sale_product_configurator" is not installed, an AttributeError is raised Steps to reproduce: - Install the "point_of_sale" app, the "pos_self_order_sale" module and remove the "sale_product_configurator" module - Go to settings -> point of sale -> Self ordering: QR Menu -> preview web interface Cause: The field "optional_product_ids" is provided by the module "sale_product_configurator" which is not a dependency of this module opw-3850421 --- I confirm I have s
Original PR description
When the module "sale_product_configurator" is not installed, an AttributeError is raised Steps to reproduce: - Install the "point_of_sale" app, the "pos_self_order_sale" module and remove the "sale_product_configurator" module - Go to settings -> point of sale -> Self ordering: QR Menu -> preview web interface Cause: The field "optional_product_ids" is provided by the module "sale_product_configurator" which is not a dependency of this module opw-3850421 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161921
In some databases, customers have changed the `reconcile` value of an account from its standard `False` value to `True`. This action causes related journal items, which are partially reconciled, to raise the following constraint error. during the upgrade process: ``` You cannot switch an account to prevent the reconciliation if some partial reconciliations are still pending ``` so we delete changes in the `reconcile` values from the reload to avoid overriding user customer setting & t
Original PR description
In some databases, customers have changed the `reconcile` value of an account from its standard `False` value to `True`. This action causes related journal items, which are partially reconciled, to raise the following constraint error. during the upgrade process: ``` You cannot switch an account to prevent the reconciliation if some partial reconciliations are still pending ``` so we delete changes in the `reconcile` values from the reload to avoid overriding user customer setting & triggering the constraint error. 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#160086
Issue: Have a grouped list view with several page, go to the next page, open a group and click on a record to open it in form view. Click on the breadcrumb to go back to the list: the offset is lost, and we're back in page 1. After this commit, the offset is correctly kept. opw~3851390 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.
Original PR description
Issue: Have a grouped list view with several page, go to the next page, open a group and click on a record to open it in form view. Click on the breadcrumb to go back to the list: the offset is lost, and we're back in page 1. After this commit, the offset is correctly kept. opw~3851390 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#162969 Forward-Port-Of: odoo/odoo#162844
In the VAT listing report, a customer might have a turnover of more than 250€ but wasn't added in the report due to missing information such as country or a VAT number. This commit adds a warning with those customers on top of the report with a link to view and edit them. task-3249107 Forward-Port-Of: odoo/enterprise#61018 Forward-Port-Of: odoo/enterprise#53550
Original PR description
In the VAT listing report, a customer might have a turnover of more than 250€ but wasn't added in the report due to missing information such as country or a VAT number. This commit adds a warning with those customers on top of the report with a link to view and edit them. task-3249107 Forward-Port-Of: odoo/enterprise#61018 Forward-Port-Of: odoo/enterprise#53550
## Description: Previously, the list reinsertion dialog overlooked converting user input to integers, causing JavaScript to treat numbers as strings. Consequently, unintended concatenation occurred, resulting in excessive record insertion. This PR addresses the issue by enforcing integer conversion on user input, ensuring precise record insertion. Task ID: [3833909](https://www.odoo.com/web#id=3833909&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forw
Original PR description
## Description: Previously, the list reinsertion dialog overlooked converting user input to integers, causing JavaScript to treat numbers as strings. Consequently, unintended concatenation occurred, resulting in excessive record insertion. This PR addresses the issue by enforcing integer conversion on user input, ensuring precise record insertion. Task ID: [3833909](https://www.odoo.com/web#id=3833909&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#61295 Forward-Port-Of: odoo/enterprise#60642
Before this commit, subscription tour didn't work due to technical changes. This commit aims to fix the tour, by adapting to the new changes. Task: 3679337 Forward-Port-Of: odoo/enterprise#61060 Forward-Port-Of: odoo/enterprise#58613
Original PR description
Before this commit, subscription tour didn't work due to technical changes. This commit aims to fix the tour, by adapting to the new changes. Task: 3679337 Forward-Port-Of: odoo/enterprise#61060 Forward-Port-Of: odoo/enterprise#58613
Current behavior: When an order is invoided after the session has been closed, a reversed payment is created. This payment is not reconciled correctly with the invoice. This is creating an aged receivable for the partner. Steps to reproduce: - Change the bank payment method to "Identify customer" - Create an order in the PoS and pay with bank and specify a partner - Close the session - Open the session again, and create an invoice for the order - Go to the accounting module and look for
Original PR description
Current behavior: When an order is invoided after the session has been closed, a reversed payment is created. This payment is not reconciled correctly with the invoice. This is creating an aged receivable for the partner. Steps to reproduce: - Change the bank payment method to "Identify customer" - Create an order in the PoS and pay with bank and specify a partner - Close the session - Open the session again, and create an invoice for the order - Go to the accounting module and look for the aged receivable report you should see some entries under the partner you selected. - You can also go to the partner form and see that he has some due invoices. opw-3678298 Forward-Port-Of: odoo/enterprise#61249 Forward-Port-Of: odoo/enterprise#60248
Forward-Port-Of: odoo/enterprise#61065 Forward-Port-Of: odoo/enterprise#60776
Original PR description
Forward-Port-Of: odoo/enterprise#61065 Forward-Port-Of: odoo/enterprise#60776
Welcome missing report 1.1 (For Cash) and 1.2 (For bank) This reports are generated from `cash flow statement` report and is based on `bank.statement.line` closes odoo/enterprise#60974 Forward-Port-Of: odoo/enterprise#61093
Original PR description
Welcome missing report 1.1 (For Cash) and 1.2 (For bank) This reports are generated from `cash flow statement` report and is based on `bank.statement.line` closes odoo/enterprise#60974 Forward-Port-Of: odoo/enterprise#61093