Monday, April 19, 2021
33 changes · master
Enhancements to existing features
Updates the new-user welcome wording so it no longer assumes a user's gender. This makes the sign-up experience more inclusive and improves the quality of the default English text.
Original PR description
Description of the issue/feature this PR addresses: As discussed and suggested by @mart-e in issue #67124. Current behavior before PR: Assumption that all new users arriving in Odoo can be addressed as "him" and "his" Desired behavior after PR is merged: The new text is gender neutral and appropriate English grammar. I'm new at this, but I've done my best to follow the guidelines. As requested by @mart-e I am creating this PR against master. The same male-oriented phrase exists in English in translation files such as: - auth_signup/i18n/az.po - auth_signup/i18n/gu.po - and others I don't know the process to suggest the same update to those. Help from another member would be appreciated. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website theme selection view now uses improved theme descriptions, making it easier for users to understand and compare available themes. This helps business users choose a suitable website look with less guesswork.
Original PR description
Task : https://tinyurl.com/8jse3wn2 This PR is linked to : https://github.com/odoo/design-themes/pull/461 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The event track proposal email template has been cleaned up to remove unnecessary blank areas and avoid repeating the track name in internal chatter messages. This makes event communication clearer for users, with only a minor tradeoff that some reply email subjects may reference the event name instead of the track name.
Original PR description
This commit slightly reworks the "event_track_template_new" template to format it a little better and get rid of unnecessary blank sections. The "subject" param was removed from the "message_post_with_view" call as we don't want the chatter to contain the name of the track twice. Indeed, since #61570, the "subject" is displayed in the chatter if it differs from the thread name (which is the case here). This causes a small regression for emails that will state "Re: EventName" in their subject instead of the track name, but it's deemed acceptable to have a nicer chatter message. We also remove the description of the "mt_event_track" mail.message.subtype as it's only used with a custom template and is redundant with that template's content. Task-2496444
Resolved issues and error corrections
The stock picking screen no longer includes a duplicated Detailed Operations tab that was previously used for styling. This prevents confusion and editing issues in tools like Odoo Studio while keeping the same business functionality.
Original PR description
Detailed Operations tab of a stock.picking was duplicated for style purpose in 30f2ad8c4. But this caused issue eg. in studio because the same field with very similary path was being edited. Since having duplicate fields with same path is not very well supported, this commit remove the duplication after a CSS fix has been done in web_enterprise after which it is no longer required. opw-2480311 note: enterprise PR that allow to do this change: https://github.com/odoo/enterprise/pull/17571
Documentation and clarification updates
This pull request adds a corporate Contributor License Agreement document for Odoo. It is a legal/compliance update that records contribution rights and has no direct effect on product features or users.
Original PR description
Signing the CLA
Miscellaneous changes
Description of the issue/feature this PR addresses: without the f-string literal the XML ID is not printed. Current behavior before PR: the deprecation warning message is not formatted and the actual XML ID is not printed (`{xml_id!r}` is printed instead). Desired behavior after PR is merged: the actual XML ID is printed in the deprecation warning. Opening a PR to `14.0` as noted by @xmo-odoo in the [original PR](https://github.com/odoo/odoo/pull/69349#issuecomment-820924551). -- I
Original PR description
Description of the issue/feature this PR addresses: without the f-string literal the XML ID is not printed.
Current behavior before PR: the deprecation warning message is not formatted and the actual XML ID is not printed (`{xml_id!r}` is printed instead).
Desired behavior after PR is merged: the actual XML ID is printed in the deprecation warning.
Opening a PR to `14.0` as noted by @xmo-odoo in the [original PR](https://github.com/odoo/odoo/pull/69349#issuecomment-820924551).
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#69359This fix prevents employee billing mappings from recalculating hourly prices just because the currency is updated. Users can now manually edit and keep the price on field service project forms when the related sales module is installed.
Original PR description
Before this commit, the currency_id field has the same compute method than the price_unit field in the employee mapping. When the industry_fsm_sale module is installed, the price_unit is recomputed because of the currency_id and then the user cannot manually edit the price_unit in fsm project form view. This commit adds a compute for the currency_id field to not unnecessarily recompute the price unit in the employee mapping. Related PR: odoo/odoo#66181 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When generating field completion, if there are no o2m or suggested fields, the method was returning the list of values without adding the regulars fields. This commit returns correctly the complete set of values. Task ID: 2508902 Forward-Port-Of: odoo/odoo#69406
Original PR description
When generating field completion, if there are no o2m or suggested fields, the method was returning the list of values without adding the regulars fields. This commit returns correctly the complete set of values. Task ID: 2508902 Forward-Port-Of: odoo/odoo#69406
Before this fix, the runbot would fails randomly during the nightly multi-build in test_accept_meeting_unauthenticated and test_accept_meeting_authenticated. ```py odoo.addons.calendar.tests.test_calendar_controller:36 FAIL: TestCalendarController.test_accept_meeting_unauthenticated Traceback (most recent call last): File "/data/build/odoo/addons/calendar/tests/test_calendar_controller.py", line 36, in test_accept_meeting_unauthenticated self.assertEqual(self.event.attendee_ids[1
Original PR description
Before this fix, the runbot would fails randomly during the nightly multi-build in test_accept_meeting_unauthenticated and test_accept_meeting_authenticated.
```py
odoo.addons.calendar.tests.test_calendar_controller:36
FAIL: TestCalendarController.test_accept_meeting_unauthenticated
Traceback (most recent call last):
File "/data/build/odoo/addons/calendar/tests/test_calendar_controller.py", line 36, in test_accept_meeting_unauthenticated
self.assertEqual(self.event.attendee_ids[1].state, "accepted", "Attendee should have accepted")
AssertionError: 'needsAction' != 'accepted'
- needsAction
+ accepted
: Attendee should have accepted
```
Similar traceback in test_accept_meeting_authenticated.
This commit tries to check if the redirection is causing the issue or if the write occurs before.
taskid: 2497816
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#68713This commit fixes two issues encountered during the visitor lifecycle. 1. When a visitor arrives on the website on a non tracked page, a website.visitor is not created yet, but the visitor can still start a livechat session. When navigating to a tracked page, a website.visitor is created but the lifechat session already started is not recovered and the discussion is lost at visitor's side. This commit links the already started livechat session to the newly created visitor to ensure that
Original PR description
This commit fixes two issues encountered during the visitor lifecycle. 1. When a visitor arrives on the website on a non tracked page, a website.visitor is not created yet, but the visitor can still…
This commit fixes two issues encountered during the visitor lifecycle. 1. When a visitor arrives on the website on a non tracked page, a website.visitor is not created yet, but the visitor can still start a livechat session. When navigating to a tracked page, a website.visitor is created but the lifechat session already started is not recovered and the discussion is lost at visitor's side. This commit links the already started livechat session to the newly created visitor to ensure that the conversation can still continue normally. 2. When a visitor logs in, his attributed visitor is linked to the partner. But there can be only one visitor per partner. If there was already a visitor linked to the partner, the later visitor's livechat session are updated with the partner and the visitor is then deleted. But the visitor's livechat sessions are not linked to the main partner visitor. So when looking at all the session the partner had, we can only see the main visitor's livechat session. This commit copy the livechat session of that later visitor to the main partner visitor to ensure keeping the complete livechat history for each partner. Task ID: 2460892 Forward-Port-Of: odoo/odoo#66179
When the pos session can't be balanced, a balancing account is used. First, we take the company balancing account, but if it is not set, we need to take the property. Here, it was the wrong method used to get the property. opw:2439889 Forward-Port-Of: odoo/odoo#65791
Original PR description
When the pos session can't be balanced, a balancing account is used. First, we take the company balancing account, but if it is not set, we need to take the property. Here, it was the wrong method used to get the property. opw:2439889 Forward-Port-Of: odoo/odoo#65791
Steps to reproduce the bug: - Install manufacturing app - Create a product A - Create a Bill of Materials for product A - Archive Product A (Only the final product not any of the components) - Print BOM or Print BOM Structure & Cost Bug: A traceback was raised opw:2447514 Forward-Port-Of: odoo/odoo#66007 Forward-Port-Of: odoo/odoo#65815
Original PR description
Steps to reproduce the bug: - Install manufacturing app - Create a product A - Create a Bill of Materials for product A - Archive Product A (Only the final product not any of the components) - Print BOM or Print BOM Structure & Cost Bug: A traceback was raised opw:2447514 Forward-Port-Of: odoo/odoo#66007 Forward-Port-Of: odoo/odoo#65815
**Description of the issue/feature this PR addresses:** When importing an XML UBL invoice, the partner is supposed to be automatically completed on the invoice. But, in my case, it is never found in the database, although it was previously created. In my database, the partner : * has a different name than the one in the XML file * has no phone or email completed * has a the correct VAT number I expect Odoo to find the partner based on the VAT number and to complete the invoice with
Original PR description
**Description of the issue/feature this PR addresses:** When importing an XML UBL invoice, the partner is supposed to be automatically completed on the invoice. But, in my case, it is never found in…
**Description of the issue/feature this PR addresses:**
When importing an XML UBL invoice, the partner is supposed to be automatically completed on the invoice.
But, in my case, it is never found in the database, although it was previously created.
In my database, the partner :
* has a different name than the one in the XML file
* has no phone or email completed
* has a the correct VAT number
I expect Odoo to find the partner based on the VAT number and to complete the invoice with it, but it never happens.
**Current behavior before PR:**
The function search for a partner using data form the invoice using a domain made of : partner name, phone, email or vat.
For the VAT part, this code looks for the VAT number in the invoice file :+1:
elements = partner_element.xpath('//cac:AccountingSupplierParty/cac:Party//cbc:ID', namespaces=namespaces)
if elements:
partner_id = elements[0].text
domains.append([('vat', 'like', partner_id)])
In odoo_l10n_be_edi, the text xml file is like this (see https://github.com/odoo/odoo/blob/14.0/addons/l10n_be_edi/test_xml_file/efff_test.xml) :
<cac:AccountingSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="GLN">BE0123456789</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeAgencyName="KBO" schemeAgencyID="BE">123456789</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>The best supplier</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Chemin de Odoo 34</cbc:StreetName>
<cbc:CityName>Odoo Ville</cbc:CityName>
<cbc:PostalZone>7777</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>BE</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>The best supplier</cbc:RegistrationName>
<cbc:CompanyID>12345689</cbc:CompanyID>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingSupplierParty>
In this file, //cac:AccountingSupplierParty/cac:Party//cbc:ID' is 123456789
Meaning that, in the previous function, we write a domain like this : domains.append([('vat', 'like', '123456789')])
But in some UBL 2.0 file (see http://www.datypic.com/sc/ubl20/e-ns19_Invoice.html for example), we may have :
<cac:AccountingSupplierParty>
<cbc:CustomerAssignedAccountID>CO001</cbc:CustomerAssignedAccountID>
<cac:Party>
<cac:PartyName>
<cbc:Name>Consortial</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Busy Street</cbc:StreetName>
<cbc:BuildingName>Thereabouts</cbc:BuildingName>
<cbc:BuildingNumber>56A</cbc:BuildingNumber>
<cbc:CityName>Farthing</cbc:CityName>
<cbc:PostalZone>AA99 1BB</cbc:PostalZone>
<cbc:CountrySubentity>Heremouthshire</cbc:CountrySubentity>
<cac:AddressLine>
<cbc:Line>The Roundabout</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode>GB</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyTaxScheme>
<cbc:RegistrationName>Farthing Purchasing Consortia</cbc:RegistrationName>
<cbc:CompanyID>175 269 2355</cbc:CompanyID>
<cbc:ExemptionReason>N/A</cbc:ExemptionReason>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
<cbc:TaxTypeCode>VAT</cbc:TaxTypeCode>
</cac:TaxScheme>
</cac:PartyTaxScheme>
<cac:Contact>
<cbc:Name>Mrs Bouquet</cbc:Name>
<cbc:Telephone>0158 1233714</cbc:Telephone>
<cbc:Telefax>0158 1233856</cbc:Telefax>
<cbc:ElectronicMail>bouquet@fpconsortial.co.uk</cbc:ElectronicMail>
</cac:Contact>
</cac:Party>
</cac:AccountingSupplierParty>
In this file, //cac:AccountingSupplierParty/cac:Party//cbc:ID' first occurence is in :
cac:AccountingSupplierParty / cac:Party / <cac:PartyTaxScheme>
=> <cbc: ID>VAT</cbc:ID>
Meaning that the domain will look like this : domains.append([('vat', 'like', 'VAT')])
**Desired behavior after PR is merged:**
We should base our search on CompanyID : //cac:AccountingSupplierParty/cac:Party//cbc:CompanyID
CompanyID is supposed to be the VAT identification of the partner / supplier.
--- update --
Fixing sample file l10n_be_edi/test_xml_file/efff_test.xml.
Company ID is 123456789.
A "7" is missing in <cbc:CompanyID>12345689</cbc:CompanyID> in the sample file efff_test.xml.
Also, note that the sample file is missing a <cac:PartyTaxScheme> part, and we are reading CompanyID in <cac:PartyLegalEntity>.
See also http://nw.e-fff.be/fichiers-dexemple/ for other sample files.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#69059
Forward-Port-Of: odoo/odoo#686661. Create a new user with only "Administration / Access Right" 2. Login as the user 3. Turn on debug mode (via plugin or by editing url) 4. Go to "Settings -> Users and Companies -> Groups" 5. Open any group form / Press "Create" button. Bug: Error "You are not allowed to access 'View' (ir.ui.view) records." A user who is managing "Access Right" must be able to create/edit groups opw:2492803 Co-authored-by: mart-e <mat@odoo.com> Forward-Port-Of: odoo/odoo#69306
Original PR description
1. Create a new user with only "Administration / Access Right" 2. Login as the user 3. Turn on debug mode (via plugin or by editing url) 4. Go to "Settings -> Users and Companies -> Groups" 5. Open any group form / Press "Create" button. Bug: Error "You are not allowed to access 'View' (ir.ui.view) records." A user who is managing "Access Right" must be able to create/edit groups opw:2492803 Co-authored-by: mart-e <mat@odoo.com> Forward-Port-Of: odoo/odoo#69306
Before this commit, when the user wants to create a timesheet in the list or form view of this model, the user can quick create a project and a task if he wishes. The problem is when the user wants to quick create a task without defining a project in the form view of timesheet, because the default_project_id of the task will be false and a task without project will be created. This commit checks when the user clicks on the task_id field if the default_project_id exists in the context an
Original PR description
Before this commit, when the user wants to create a timesheet in the list or form view of this model, the user can quick create a project and a task if he wishes. The problem is when the user wants to quick create a task without defining a project in the form view of timesheet, because the default_project_id of the task will be false and a task without project will be created. This commit checks when the user clicks on the task_id field if the default_project_id exists in the context and if the default_project_id is not false, then we allow to the user to quick create a task for this timesheet, otherwise he can just select a task. Moreover, the js file is updated to fit with the new syntax. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69241
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69320
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69320
          -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69378
Have a large number of attachments with res_field set Then go to Settings -> Technical -> Attachments -> add a filter "Res Field" is set. You will have traceback. This occur because the `_search` function will need to scan the whole table as records with res_field are omitted from results, forcing another run of _search opw-2463634 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have
Original PR description
Have a large number of attachments with res_field set Then go to Settings -> Technical -> Attachments -> add a filter "Res Field" is set. You will have traceback. This occur because the `_search` function will need to scan the whole table as records with res_field are omitted from results, forcing another run of _search opw-2463634 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#68471
On initialization, the website configurator makes a call to an external service (api_website) hosted on iap-services.odoo.com to retrieve a list of industries. This call might fail if the external service is done. This potential failure is now correctly handled: On '/api/website/1/configurator/industries' call failure, the configurator is silently skipped and the user is redirected to the view website.theme_view_kanban Description of the issue/feature this PR addresses: Current be
Original PR description
On initialization, the website configurator makes a call to an external service (api_website) hosted on iap-services.odoo.com to retrieve a list of industries. This call might fail if the external service is done. This potential failure is now correctly handled: On '/api/website/1/configurator/industries' call failure, the configurator is silently skipped and the user is redirected to the view website.theme_view_kanban 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#68927
Before this commit, the top position of a modal in website was always the height of the main menu navbar. Even if the main menu navbar was not displayed when the user is not logged. (see below) That bug was introduced in 6ef6227  After this commit, the top position of a modal is the height of
Original PR description
Before this commit, the top position of a modal in website was always the height of the main menu navbar. Even if the main menu navbar was not displayed when the user is not logged. (see below) That bug was introduced in 6ef6227  After this commit, the top position of a modal is the height of the main menu navbar but only if that navbar is displayed. task-2507949 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#69360
Before this commit, There would be Expected singleton error on changing Credit/Debit for multile account in single call. Now, We are proocess one record to set `_set_opening_debit_credit` 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#69435 Forward-Port-Of: odoo/odoo#69208
Original PR description
Before this commit, There would be Expected singleton error on changing Credit/Debit for multile account in single call. Now, We are proocess one record to set `_set_opening_debit_credit` 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#69435 Forward-Port-Of: odoo/odoo#69208
Odoo task : https://www.odoo.com/web#id=2497783&model=project.task&view_type=form&cids=1&menu_id= -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69460
Original PR description
Odoo task : https://www.odoo.com/web#id=2497783&model=project.task&view_type=form&cids=1&menu_id= -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69460
The /web/webclient/translations route's `lang` argument has had some changes in the last year: - before june 2020 (a9a756cf): very often it was set to null - after june 2020 (a9a756cf): it was more often correctly set or had en_US as fallback so never null - after 31 march 2021 (8cc06617) in saas-14.3: lang is not sent to server if it is null (which should never happen) - after 15 april 2021 (a93a0a3): en_US fallback is removed to prevent overriding server language if another language
Original PR description
The /web/webclient/translations route's `lang` argument has had some changes in the last year: - before june 2020 (a9a756cf): very often it was set to null - after june 2020 (a9a756cf): it was more often correctly set or had en_US as fallback so never null - after 31 march 2021 (8cc06617) in saas-14.3: lang is not sent to server if it is null (which should never happen) - after 15 april 2021 (a93a0a3): en_US fallback is removed to prevent overriding server language if another language is better But the fix in 31 march and 15 april are not compatible because the route /web/webclient/translations require a lang argument. With this changeset, lang argument is always sent to the server. Forward-Port-Of: odoo/odoo#69466
…ed taxes Before this commit, such configuration wasn't allowed. However, in some countries, this is mandatory, when dealing with eco-tax for example: Suppose t1, t2 being taxes where: - t1 is include_base_amount, price_excluded, fixed tax of 10 (eco-tax) - t2 is include_base_amount, price_included, percent of 21% The computation on 1210 should be: price_excluded: 1210 / 1.21 = 1000 price_included: (1000 + 10) * 1.21 = 1222.1 -- I confirm I have signed the CLA and read the PR g
Original PR description
…ed taxes Before this commit, such configuration wasn't allowed. However, in some countries, this is mandatory, when dealing with eco-tax for example: Suppose t1, t2 being taxes where: - t1 is include_base_amount, price_excluded, fixed tax of 10 (eco-tax) - t2 is include_base_amount, price_included, percent of 21% The computation on 1210 should be: price_excluded: 1210 / 1.21 = 1000 price_included: (1000 + 10) * 1.21 = 1222.1 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69271 Forward-Port-Of: odoo/odoo#69184
xe.com (https://www.xe.com/currencytables/?from=USD) now uses comma character as thousands separator (in english version which we are using) so we should ignore it when parsing the float values. opw-2502881 opw-2503161 opw-2504585 opw-2507051 opw-2503944 opw-2507736 opw-2507512 opw-2507967 opw-2507459 opw-2506940 Forward-Port-Of: odoo/enterprise#17797
Original PR description
xe.com (https://www.xe.com/currencytables/?from=USD) now uses comma character as thousands separator (in english version which we are using) so we should ignore it when parsing the float values. opw-2502881 opw-2503161 opw-2504585 opw-2507051 opw-2503944 opw-2507736 opw-2507512 opw-2507967 opw-2507459 opw-2506940 Forward-Port-Of: odoo/enterprise#17797
The message received from the server is "154: Client" which is not clear, you can receive the message: 154|El RUC del archivo no corresponde al RUC del usuario o El proveedor no esta autorizado a enviar comprobantes del contribuyente Detalle: ' ticket: 20210000000000119880357 error: Error en envio de documeto ' With this message we send a a clearer helper. Forward-Port-Of: odoo/enterprise#17716 Forward-Port-Of: odoo/enterprise#17641
Original PR description
The message received from the server is "154: Client" which is not clear, you can receive the message: 154|El RUC del archivo no corresponde al RUC del usuario o El proveedor no esta autorizado a enviar comprobantes del contribuyente Detalle: ' ticket: 20210000000000119880357 error: Error en envio de documeto ' With this message we send a a clearer helper. Forward-Port-Of: odoo/enterprise#17716 Forward-Port-Of: odoo/enterprise#17641
In a multi steps environment, a notification was sent to Amazon as soon as a delivery linked to an Amazon sales order is confirmed. Only the last step of delivery should send the notification to Amazon. opw:2469298 Forward-Port-Of: odoo/enterprise#17712
Original PR description
In a multi steps environment, a notification was sent to Amazon as soon as a delivery linked to an Amazon sales order is confirmed. Only the last step of delivery should send the notification to Amazon. opw:2469298 Forward-Port-Of: odoo/enterprise#17712
Timesheet_grid override inherit_id of: hr_timesheet.hr_timesheet_line_my_timesheet_search from: hr_timesheet.hr_timesheet_line_search to: timesheet_grid.timesheet_view_search So it would be removed on uninstall (inherit of view that is being removed) and on next installation, it would not be found preventing to install timesheet_grid. opw-2499226 Forward-Port-Of: odoo/enterprise#17774
Original PR description
Timesheet_grid override inherit_id of: hr_timesheet.hr_timesheet_line_my_timesheet_search from: hr_timesheet.hr_timesheet_line_search to: timesheet_grid.timesheet_view_search So it would be removed on uninstall (inherit of view that is being removed) and on next installation, it would not be found preventing to install timesheet_grid. opw-2499226 Forward-Port-Of: odoo/enterprise#17774
[FIX] account_reports: Allow editing date on bank reconciliation report This feature was available before 14.0 but has been removed since it was leading to some confusing amounts depending the date. Before this commit, the report_balance_end was computed as follow: report_balance_end = last_statement.balance_end_real After this commit: report_balance_end = last_statement.balance_start + sum(lines.mapped('amount')) where 'lines' are the bank statement lines having a date <= the report
Original PR description
[FIX] account_reports: Allow editing date on bank reconciliation report
This feature was available before 14.0 but has been removed since it was leading to some confusing amounts depending the date.
Before this commit, the report_balance_end was computed as follow:
report_balance_end = last_statement.balance_end_real
After this commit:
report_balance_end = last_statement.balance_start + sum(lines.mapped('amount'))
where 'lines' are the bank statement lines having a date <= the report date.
This avoid unconsistent amounts when the selected date is not the bank statement one.
Using the 'balance_end_real' is no longer necessary since a bank statement must be consistent to be posted and perform the reconciliation.
opw-2498103
Forward-Port-Of: odoo/enterprise#17731
Forward-Port-Of: odoo/enterprise#17709- added print payment receipt option into the bank statement line. Task- https://www.odoo.com/web#active_id=2422435&cids=2&id=2422435&menu_id=&model=project.task Forward-Port-Of: odoo/enterprise#17501
Original PR description
- added print payment receipt option into the bank statement line. Task- https://www.odoo.com/web#active_id=2422435&cids=2&id=2422435&menu_id=&model=project.task Forward-Port-Of: odoo/enterprise#17501
…ng the AFIP certificate Getting AFIP the certificate or private key can be called with a context containing "bin_size" at True which will return the size of the attachment and not his datas (eg. try to open a debit note that call a "_compute_highest_name") The system will try to decode the size returned as if it was the datas and result to an error. This complete the commit 472fad2b58303ac5ac9252117ada095872d2cbbe opw-2453951 Forward-Port-Of: odoo/enterprise#17588 Forward-Port-Of:
Original PR description
…ng the AFIP certificate Getting AFIP the certificate or private key can be called with a context containing "bin_size" at True which will return the size of the attachment and not his datas (eg. try to open a debit note that call a "_compute_highest_name") The system will try to decode the size returned as if it was the datas and result to an error. This complete the commit 472fad2b58303ac5ac9252117ada095872d2cbbe opw-2453951 Forward-Port-Of: odoo/enterprise#17588 Forward-Port-Of: odoo/enterprise#17572
Steps to reproduce the bug: - Install manufacturing app - Create a product A - Create a Bill of Materials for product A - Archive Product A (Only the final product not any of the components) - Print BOM or Print BOM Structure & Cost Bug: A traceback was raised opw:2447514 Forward-Port-Of: odoo/enterprise#16285 Forward-Port-Of: odoo/enterprise#16258
Original PR description
Steps to reproduce the bug: - Install manufacturing app - Create a product A - Create a Bill of Materials for product A - Archive Product A (Only the final product not any of the components) - Print BOM or Print BOM Structure & Cost Bug: A traceback was raised opw:2447514 Forward-Port-Of: odoo/enterprise#16285 Forward-Port-Of: odoo/enterprise#16258
to_tsquery is "less forgiving about its input": https://www.postgresql.org/docs/current/textsearch-controls.html#TEXTSEARCH-PARSING-QUERIES And less-than character (`<`) seems to always break it, from documentation it is used in some expression: https://www.postgresql.org/docs/current/functions-textsearch.html Also, the error is catched, but this break the transaction so if there is another query in the same request, the user will get an unrelated error that the transaction is closed due to
Original PR description
to_tsquery is "less forgiving about its input": https://www.postgresql.org/docs/current/textsearch-controls.html#TEXTSEARCH-PARSING-QUERIES And less-than character (`<`) seems to always break it, from documentation it is used in some expression: https://www.postgresql.org/docs/current/functions-textsearch.html Also, the error is catched, but this break the transaction so if there is another query in the same request, the user will get an unrelated error that the transaction is closed due to a previous error. opw-2499702 Forward-Port-Of: odoo/enterprise#17761