Friday, February 5, 2021
22 changes · master
Enhancements to existing features
The contact form now groups sales-related fields more logically by moving the delivery carrier field alongside the other sales information. This makes the form easier to scan and helps users find related settings in one place.
HR users can now open the list of contracts linked to a specific working calendar directly from that calendar. This makes it faster to understand where a calendar is used and manage related employee contract information.
Original PR description
Purpose ======= Currently there's no easy way to retrieve all the contract using a given calendar. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The contact form now keeps sales-related fields grouped together more logically. This small layout change makes it easier for users to find and review Mexican external trade information in the right section.
When a product has no rental-specific pricing, the rental screen now shows the actual list price that will be used instead of a vague fallback message. This helps sales users understand the charge immediately and reduces pricing confusion for rental orders.
Original PR description
When there are no rental pricing defined, it falls back on the list price of the product. Before this commit it was showing "Fallback on list price" without indication of that list price. Here we display "<amount> (fixed)" instead. TaskID: 2378808
Online appointment list and kanban screens now include sample data, making empty views more informative and easier to understand. This helps users see how appointment information will appear before they create real records.
Original PR description
in this commit we have added sample data in online appointments kanban and list view. task-id: 2326227
Resolved issues and error corrections
Corrects how depreciation schedule report lines are identified so users are directed to the right asset details. This prevents confusion when opening report line actions after recent reporting changes.
Original PR description
This is needed with 8ceeb7df4a350f89d7480a1d652ec3178345fe7b Even though there is a fallback for legacy report line ids in _get_caret_option_target_id, it is not working with the Depreciation Schedule since it is a string too.
Miscellaneous changes
PR [1] introduced the auto save feature (changes in form and list views are automatically saved when the view is left, e.g. with the pager, breadcrumbs, stat buttons, menus...). However, there was one case that had been left aside: when we close the tab or browser. This commit ensures that we also save the changes in this case. The record is saved only if it is valid, otherwise the changes are simply lost (we don't block the tab/browser from closing itself). Moreover, the beforeunl
Original PR description
PR [1] introduced the auto save feature (changes in form and list views are automatically saved when the view is left, e.g. with the pager, breadcrumbs, stat buttons, menus...). However, there was…
PR [1] introduced the auto save feature (changes in form and list views are automatically saved when the view is left, e.g. with the pager, breadcrumbs, stat buttons, menus...). However, there was one case that had been left aside: when we close the tab or browser. This commit ensures that we also save the changes in this case. The record is saved only if it is valid, otherwise the changes are simply lost (we don't block the tab/browser from closing itself). Moreover, the beforeunload handler must be *almost* sync (a few ms setTimeout seems ok, but definitely not an rpc roundtrip). For that reason, we cannot wait for onchanges to apply before saving. part of task 2330101 [1] https://github.com/odoo/odoo/pull/60693 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#65506
Some test of cleaning up bad translations, to be propagated on Transifex when the language is available cc @yelizariev Forward-Port-Of: odoo/odoo#64557
Original PR description
Some test of cleaning up bad translations, to be propagated on Transifex when the language is available cc @yelizariev Forward-Port-Of: odoo/odoo#64557
In case of bad translation that doesn't contain the placeholder Context: A bad Japanese translation was inserted ```po #. module: mail #: code:addons/mail/models/mail_thread.py:0 #, python-format msgid "Create new %(document)s" msgstr "新しい%(ドキュメント)を作成する" ``` The translation has been corrected but use the 14.0 syntax of _ method to include placeholders and fallback on the English source term in case of bad translation cf odoo/odoo#52155 Forward-Port-Of: odoo/odoo#65558 Forward-P
Original PR description
In case of bad translation that doesn't contain the placeholder Context: A bad Japanese translation was inserted ```po #. module: mail #: code:addons/mail/models/mail_thread.py:0 #, python-format msgid "Create new %(document)s" msgstr "新しい%(ドキュメント)を作成する" ``` The translation has been corrected but use the 14.0 syntax of _ method to include placeholders and fallback on the English source term in case of bad translation cf odoo/odoo#52155 Forward-Port-Of: odoo/odoo#65558 Forward-Port-Of: odoo/odoo#65517
Behavior before the commit -------------------------- find_or_create define in mail module called super if no partner is found based on the email_normalized super call find_or_create define in base that make a search again on the email before the creation This cost two search every time a new partner should be created and the search on email is less efficient than the search on email_normalized after the commit ---------------- Only the search on email_normalized is done before
Original PR description
Behavior before the commit -------------------------- find_or_create define in mail module called super if no partner is found based on the email_normalized super call find_or_create define in base that make a search again on the email before the creation This cost two search every time a new partner should be created and the search on email is less efficient than the search on email_normalized after the commit ---------------- Only the search on email_normalized is done before the creation drawback: if a module that does not depends on mail module override find_or_create the code will not be triggered anymore the module should depends on mail module -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#65278
**Current behavior before PR:** Currently, the subtype checked selection is not saved when user add and remove subtypes. **Desired behavior after PR is merged:** The subtype checked selection will be saved when user add and remove subtypes. **LINKS** PR https://github.com/odoo/odoo/pull/56775 Task-2241688 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#65587 Forward-Port-Of: odoo/odoo#56775
Original PR description
**Current behavior before PR:** Currently, the subtype checked selection is not saved when user add and remove subtypes. **Desired behavior after PR is merged:** The subtype checked selection will be saved when user add and remove subtypes. **LINKS** PR https://github.com/odoo/odoo/pull/56775 Task-2241688 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#65587 Forward-Port-Of: odoo/odoo#56775
Before this commit, the page can be set in cache with some data pre-filled. Now we don't cache anymore the contactus page if you have GET params. 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#65538
Original PR description
Before this commit, the page can be set in cache with some data pre-filled. Now we don't cache anymore the contactus page if you have GET params. 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#65538
The below case is not working before this commit: when Bill to Ship to where Delivery address partner is not registered and not have GSTIN -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#65270
Original PR description
The below case is not working before this commit: when Bill to Ship to where Delivery address partner is not registered and not have GSTIN -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#65270
When syncing with a Google account, if user's email is different from Google account, the server creates a new partner. Moreover, the synced event are not linked to the current partner. To reproduce the error: 1. Have two Google accounts GA01 and GA02 2. With GA01, add an event to Google Calendar and add GA02 to guests 3. In Odoo, sync with Google Calendar using GA02 - The partner linked to the current Odoo user must have an email different from GA02's email Error: The calendar is
Original PR description
When syncing with a Google account, if user's email is different from Google account, the server creates a new partner. Moreover, the synced event are not linked to the current partner. To reproduce…
When syncing with a Google account, if user's email is different from Google account, the server creates a new partner. Moreover, the synced event are not linked to the current partner. To reproduce the error: 1. Have two Google accounts GA01 and GA02 2. With GA01, add an event to Google Calendar and add GA02 to guests 3. In Odoo, sync with Google Calendar using GA02 - The partner linked to the current Odoo user must have an email different from GA02's email Error: The calendar is synced, but the user needs to check "Everybody's calendars" to see the synced events. A new partner has been created using GA02's email. The synced events are linked to this new partner instead of current user's partner (`self.env.user.partner_id`). Moreover, Google event's organizer is always added to attendees but, if it this is indeed the case (so if the organizer is also an attendee), `google_event.attendees` already contains this organizer. OPW-2440033 Forward-Port-Of: odoo/odoo#65216
Description of the issue/feature this PR addresses: missing CLA for the user `os-ia` -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#65590
Original PR description
Description of the issue/feature this PR addresses: missing CLA for the user `os-ia` -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#65590
When retrieving company dependant values, the computed domain called `search_multi` method of `ir.property` as normal user. Since odoo/odoo@8f578637076d4b65 ir.property records are no longer readable by a normal classical user. To reproduce: Add a domain using a `company_dependant` field e.g. on `res.partner`, with purchase installed, modify the `parent_id` field in form view to ```xml <field name="parent_id" ... domain="[('property_purchase_currency_id','=',property_purchase_currency_
Original PR description
When retrieving company dependant values, the computed domain called `search_multi` method of `ir.property` as normal user.
Since odoo/odoo@8f578637076d4b65 ir.property records are no longer readable by a normal classical user.
To reproduce:
Add a domain using a `company_dependant` field
e.g. on `res.partner`, with purchase installed, modify the `parent_id` field in form view to
```xml
<field name="parent_id" ... domain="[('property_purchase_currency_id','=',property_purchase_currency_id)]" />
```
When clicking on the parent_id with a low priviledge user, an access-right error is raised, as the user doesn't have access to ir.property records
Fixes odoo/odoo#65450
Forward-Port-Of: odoo/odoo#65552Forward-Port-Of: odoo/odoo#65620
Original PR description
Forward-Port-Of: odoo/odoo#65620
The Lesotho Loti has the symbol M and not L Example of use: http://lestimes.com/businessman-xie-in-m27-million-scandal/ http://lra.org.ls/sites/default/files/2020-10/LRA%20Integrated%20Annual%20Report%202019.pdf Fixes odoo/odoo#62807 Forward-Port-Of: odoo/odoo#65633
Original PR description
The Lesotho Loti has the symbol M and not L Example of use: http://lestimes.com/businessman-xie-in-m27-million-scandal/ http://lra.org.ls/sites/default/files/2020-10/LRA%20Integrated%20Annual%20Report%202019.pdf Fixes odoo/odoo#62807 Forward-Port-Of: odoo/odoo#65633
This change reverses a previous update so actual hours are hidden again on the planning slot form. It reflects a product decision change and keeps the planning view focused on the information business users are expected to see.
Original PR description
…ot form view This reverts commit b1cb102d3c1a0ab7517f34270e9d70e97942c8f2. Reverting this commit since PO changed his/her mind.
Forward-Port-Of: odoo/enterprise#16155
Original PR description
Forward-Port-Of: odoo/enterprise#16155
Steps to reproduce: Go to Accounting -> Journal Entries -> Create -> Reset the name, add some lines on account XX in the move, and save in draft Go to General Ledger -> check "Include unposted entries" -> expand the lines under account XX --> Traceback opw:2448998 Forward-Port-Of: odoo/enterprise#16093
Original PR description
Steps to reproduce: Go to Accounting -> Journal Entries -> Create -> Reset the name, add some lines on account XX in the move, and save in draft Go to General Ledger -> check "Include unposted entries" -> expand the lines under account XX --> Traceback opw:2448998 Forward-Port-Of: odoo/enterprise#16093
Steps: - Go to Sales > Configuration > Sales Orders / Shipping Methods - Create - Name: (1) - Provider: Easypost - Delivery Product: - Name: Easypost - Product Category: All / Deliveries - Product Type: Service - Enter your API keys - Click "Load your Easypost carrier accounts" - Select FedEx - Default Package Type: FexExTube - Go to Orders > Quotations - Create a quotation with one product - Confirm - Click the "Delivery" smart button - Edit - Addit
Original PR description
Steps: - Go to Sales > Configuration > Sales Orders / Shipping Methods - Create - Name: (1) - Provider: Easypost - Delivery Product: - Name: Easypost - Product Category: All / Deliveries - Product…
Steps:
- Go to Sales > Configuration > Sales Orders / Shipping Methods
- Create
- Name: (1)
- Provider: Easypost
- Delivery Product:
- Name: Easypost
- Product Category: All / Deliveries
- Product Type: Service
- Enter your API keys
- Click "Load your Easypost carrier accounts"
- Select FedEx
- Default Package Type: FexExTube
- Go to Orders > Quotations
- Create a quotation with one product
- Confirm
- Click the "Delivery" smart button
- Edit
- Additional Info tab:
- Carrier: (1)
- Tracking Reference: Any valid tracking code
- Click the "Tracking" smart button
Bug:
Error: Easypost returned an error: The requested resource could not be
found.
Explanation:
When entering the tracking reference manually, the Easypost order ID is
not present. This ID is only added when shipping through Odoo. However,
we can see that the Tracking smart button is still appearing when saving
the `stock.picking`. Clicking this smart button calls Easypost on the
path `/orders/False`. This returns an error.
This commit calls the correct route, which is `/trackers`, when there is
no Easypost order ID on the `stock.picking`.
The fix also takes into account the fact that there could be multiple
tracking references in this field. These are separated by `+` signs as
seen here:
https://github.com/odoo/enterprise/blob/616bc667b52ea6b0a3b5c304dc59c05f0c9b7fb1/delivery_easypost/models/delivery_carrier.py#L99
opw:2439976
Forward-Port-Of: odoo/enterprise#16010