Monday, June 21, 2021
27 changes · master
Enhancements to existing features
Email templates can now use Odoo's QWeb view system for their message bodies instead of relying only on embedded Jinja HTML. This makes template design easier to extend, translate, test, and maintain, helping businesses create more consistent automated emails.
Inventory processing now acquires required locks with a simpler and faster approach. This reduces internal overhead and can help stock operations run more smoothly, especially when multiple processes handle inventory at the same time.
Original PR description
It makes code more readable, doesn't use savepoing and use just a single query to acquire the lock 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
Website editors can now apply a selection of decorative shapes around images, making pages and email content more visually dynamic. The update also adds internal tooling to help prepare new shape designs more efficiently, supporting faster future design additions.
Original PR description
With this improvement, user can now choose between a set of shapes to clip around an image. This allows for more dynamic representation of images. This pull request also contains a tool that allows for a faster conversion of SVGs coming from Illustrator into usable shapes inside this feature.
Scheduled social media posts are now published much closer to the exact time selected by the user. Push notifications sent immediately are also delivered right away, improving time-sensitive communication such as event reminders or ticket sale announcements.
Original PR description
This commit implements 2 main changes related to the usage of CRON triggers: 1. When scheduling a social.post, we create a CRON trigger so that the post is published on the social media as close to…
This commit implements 2 main changes related to the usage of CRON triggers: 1. When scheduling a social.post, we create a CRON trigger so that the post is published on the social media as close to the selected date as possible. This is important for example when you schedule a post on the 05/05/2021 at exactly 9 AM, where you advertise that online ticketing for your online event is now open for sale. You want this post to be published as close as possible to 9 AM, and not whenever the CRON job decides to run after that time. 2. When posting push notifications "immediately", they are now sent immediately. Push notifications implementation is a bit special because we force the send method to pass through the CRON job. As opposed to other social media where the API calls are made immediately when you press on the "Post" button. This is done to avoid having the user wait for a long period of time as push notifications can quickly generate numerous HTTP calls (one for each visitor you are trying to reach). Now, with the usage of CRON trigger, we can actually send the push notifications very close to when you press the "Post" button, by creating a trigger "at=now()". This also allows us to remove the overrides/workarounds done in "website_event_social" that were used to send the track reminders "on time" with manual buttons such as "Send Push Reminders" on the event and the "action_post_immediate" method on the social.post that messed with the context. Task-2336219 UPG PR odoo/upgrade#2417
This update improves payroll handling, especially salary attachments, by moving them into the main payroll app and tying them to employees for better continuity and tracking. It also fixes several country-specific accounting, tax, invoicing, and point-of-sale issues to reduce errors in local compliance workflows.
Resolved issues and error corrections
This fix ensures that legacy client actions correctly update the browser URL with the right context and parameters. It helps users land on and share the correct page state, especially in Discuss, reducing navigation confusion.
Original PR description
Before this commit, the push state from client actions to the URL did not work properly: 1. the action.params key was ignored 2. some "reserved" keys (active_id) were not handled properly 3. within a legacy client action, the call to parent.do_push_state did not work After this commit, all of those work properly letting discuss in particular have the right URL It is worth noting that in the full wowl stack, that the right way to push something in the URL from a component is always to call the router service's pushState when the component is mounted
Features or functions removed from Odoo
This update removes an obsolete field reference from an accounting reversal screen because the field no longer exists. It also cleans up related filtering syntax, reducing the chance of confusion or errors in that workflow.
Original PR description
There is no reason to have attribute reason
Miscellaneous changes
See oddo task : https://www.odoo.com/web#id=2522564&action=333&active_id=1695&model=project.task&view_type=form&cids=1&menu_id=4720 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#72224
Original PR description
See oddo task : https://www.odoo.com/web#id=2522564&action=333&active_id=1695&model=project.task&view_type=form&cids=1&menu_id=4720 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#72224
This update fixes an internal automated test so it matches recent changes in how the web interface loads menu information. It helps keep quality checks reliable without changing the user experience.
Original PR description
With the rewrite of the webclient in OWL 29731b404fe the load_menus method now returns all menus instead of the root menu. This commit adapts the click_everywhere tests to the change.
A previously skipped automated test for Documents Spreadsheet has been re-enabled after the underlying issue was already fixed. This helps ensure future changes are checked properly without affecting day-to-day users.
Original PR description
The test was skipped in commit 6be4fbb because the test was wrong. But it was fixed in the mean time by ea4c9ec Probably a rebase error :)
Before this commit, fields in calendar popover were added to the $fieldsList after they were appended but appending is async and so fields could be disordered. Now, we add fields before the append to have the right order. Forward-Port-Of: odoo/odoo#72214 Forward-Port-Of: odoo/odoo#72060
Original PR description
Before this commit, fields in calendar popover were added to the $fieldsList after they were appended but appending is async and so fields could be disordered. Now, we add fields before the append to have the right order. Forward-Port-Of: odoo/odoo#72214 Forward-Port-Of: odoo/odoo#72060
**Description of the issue/feature this PR addresses:** In some screen it is very hard to edit the factor. **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.c
Original PR description
**Description of the issue/feature this PR addresses:** In some screen it is very hard to edit the factor. **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#66323
Steps to reproduce the bug: - Go to sales app > create two SO with different price lists - Go to expense app > create a new expense - Add two expense lines related to the two SO - Click on the “Submit to Manager” button - Approve the expense - Click on “Post journal entries” - An error is triggered Problem: We call the onchange_discount on all SO lines together in the “_sale_create_reinvoice_sale_line function”, while it should be called on each created line separately Bug introduc
Original PR description
Steps to reproduce the bug: - Go to sales app > create two SO with different price lists - Go to expense app > create a new expense - Add two expense lines related to the two SO - Click on the “Submit to Manager” button - Approve the expense - Click on “Post journal entries” - An error is triggered Problem: We call the onchange_discount on all SO lines together in the “_sale_create_reinvoice_sale_line function”, while it should be called on each created line separately Bug introduced by this commit : https://github.com/odoo/odoo/commit/8815f4d9ab8620428d50abbe603c7f6c63076d6c opw-2571247 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#72355 Forward-Port-Of: odoo/odoo#72299
There is a function allowing to close the quick create if we click outside the element. `RecordQuickCreate._onWindowClicked` https://github.com/odoo/odoo/blob/1942e3cb70726cbb14d609e26348f5c8695165fc/addons/web/static/src/js/views/kanban/kanban_record_quick_create.js#L261-L301 Except that this function is triggered in a "click" event, so if we click on the quick create element and drag the mouse outside, it will detect that we are outside and close the quick create. This manipulation c
Original PR description
There is a function allowing to close the quick create if we click outside the element. `RecordQuickCreate._onWindowClicked` https://github.com/odoo/odoo/blob/1942e3cb70726cbb14d609e26348f5c8695165fc/addons/web/static/src/js/views/kanban/kanban_record_quick_create.js#L261-L301 Except that this function is triggered in a "click" event, so if we click on the quick create element and drag the mouse outside, it will detect that we are outside and close the quick create. This manipulation can happen when you want to select text with the mouse. This PR prevents this behavior by detecting when a click is from the quick create opw-2558932 Forward-Port-Of: odoo/odoo#72069 Forward-Port-Of: odoo/odoo#71958
**Current behavior before PR:** Suppose we have a scenario like below, - Task-A: - Activity-1: name: Email ( Today ) assigned to: User-1 - Task-B: - Activity-1: name: Email ( Today ) assigned to: User-2 - Activity-2: name: Call ( Due in 3 Days ) assigned to: User-1 Here, when user-1 go through the systray 'Today' filter shortcut, that time user gets Task-A and Task-B both in the list instead of only Task-A. Currently,
Original PR description
**Current behavior before PR:** Suppose we have a scenario like below, - Task-A: - Activity-1: name: Email ( Today ) assigned to: User-1 - Task-B: - Activity-1: name: Email ( Today ) assigned to:…
**Current behavior before PR:**
Suppose we have a scenario like below,
- Task-A:
- Activity-1:
name: Email ( Today )
assigned to: User-1
- Task-B:
- Activity-1:
name: Email ( Today )
assigned to: User-2
- Activity-2:
name: Call ( Due in 3 Days )
assigned to: User-1
Here, when user-1 go through the systray 'Today' filter shortcut, that time user
gets Task-A and Task-B both in the list instead of only Task-A.
Currently, activities are not filtered based on users with its deadlines.
**Desired behavior after PR is merged:**
Now activities will be filtered based on deadlines as well as the current user
To achieve this behavior we needed to pass the domain like,
[
('activity_ids.date_deadline','=', fields.Date.today()),
('activity_ids.user_id','=', 1)
]
And for that, we introduced a non-stored compute field with a search method.
**LINKS**
Task-2438822
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#71986
Forward-Port-Of: odoo/odoo#67730When importing a facturx file, the shipping_partner_id on account.move is now processed if it's present in the xml. 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#72360 Forward-Port-Of: odoo/odoo#72345
Original PR description
When importing a facturx file, the shipping_partner_id on account.move is now processed if it's present in the xml. 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#72360 Forward-Port-Of: odoo/odoo#72345
Fix https://github.com/odoo/odoo/issues/71242 by dropping requirement of plus addressing. Since f4524f03c32a27b1899562a71cad6f491bfe44ce, plus addressing is not really used for handling bounces. Thus, still forcing everyone to use it is unnecessary. To preserve backwards compatibility for stable versions, old behavior is retained unless a new `mail.bounce.alias.static` ICP is set with a truthy value. @Tecnativa TT29827 Forward-Port-Of: odoo/odoo#72371 Forward-Port-Of: odoo/odoo#72347
Original PR description
Fix https://github.com/odoo/odoo/issues/71242 by dropping requirement of plus addressing. Since f4524f03c32a27b1899562a71cad6f491bfe44ce, plus addressing is not really used for handling bounces. Thus, still forcing everyone to use it is unnecessary. To preserve backwards compatibility for stable versions, old behavior is retained unless a new `mail.bounce.alias.static` ICP is set with a truthy value. @Tecnativa TT29827 Forward-Port-Of: odoo/odoo#72371 Forward-Port-Of: odoo/odoo#72347
Improve `res.partner._compute_on_time_rate` performances by calling `mapped('quantity_done')` once on all the `order_lines.move_ids`. Moving it out of the for loop allows to befinit from the performance gains of the read_group call in `stock.move._quantity_done_compute`. ##### speedup Client DB with 10k purchase.order.line and 111k stock_moves. `res_partner._compute_on_time_rate` time by purchase.order.line. | purchase.order.line | before PR | after PR | |:-------------------:|:-
Original PR description
Improve `res.partner._compute_on_time_rate` performances by calling
`mapped('quantity_done')` once on all the `order_lines.move_ids`.
Moving it out of the for loop allows to befinit from the performance
gains of the read_group call in `stock.move._quantity_done_compute`.
##### speedup
Client DB with 10k purchase.order.line and 111k stock_moves.
`res_partner._compute_on_time_rate` time by purchase.order.line.
| purchase.order.line | before PR | after PR |
|:-------------------:|:-----------:|:--------:|
| 20 | 0.091s | 0.055s |
| 80 | 0.041s | 0.040s |
| 175 | 0.125s | 0.057s |
| 904 | 0.322s | 0.086s |
| 7982 | 7.794s | 0.777s |
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#72068Fixes #71691 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71858
Original PR description
Fixes #71691 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71858
…iced kit Activate anglo saxon accounting Have a [DEMO] KIT product in a category using automated Inventory Valuation with costing method AVCO The KIT is composed by C1 and C2 in the same product category Define a cost on both C1 and C2 Open a POS session, order [DEMO], Invoice and complete the order Close Session, Validate and display Journal Items COGS entries will be missing. This does not occur when making the order without invoicing opw-2481518 opw-2545758 Description of
Original PR description
…iced kit Activate anglo saxon accounting Have a [DEMO] KIT product in a category using automated Inventory Valuation with costing method AVCO The KIT is composed by C1 and C2 in the same product category Define a cost on both C1 and C2 Open a POS session, order [DEMO], Invoice and complete the order Close Session, Validate and display Journal Items COGS entries will be missing. This does not occur when making the order without invoicing opw-2481518 opw-2545758 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#71509
Description of the issue/feature this PR addresses: To compute the amout don't use canceled invoice. Go to runbot - create sale order, confirm - create full invoice - cancel invoice - in SO action/ generate payment link --> Error The value of the payment amount must be positive. @tde-banana-odoo @oco-odoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#72423 Forward-Port-Of: odoo/odoo#72350
Original PR description
Description of the issue/feature this PR addresses: To compute the amout don't use canceled invoice. Go to runbot - create sale order, confirm - create full invoice - cancel invoice - in SO action/ generate payment link --> Error The value of the payment amount must be positive. @tde-banana-odoo @oco-odoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#72423 Forward-Port-Of: odoo/odoo#72350
…nvoiced kit - Activate anglo saxon accounting - Have a [DEMO] KIT product in a category using automated Inventory Valuation with costing method AVCO - The KIT is composed by C1 and C2 in the same product category - Define a cost on both C1 and C2 - Open a POS session, order [DEMO], Invoice and complete the order - Close Session, Validate and display Journal Items COGS entries will be missing. This does not occur when making the order without invoicing opw-2481518 opw-2545758
Original PR description
…nvoiced kit - Activate anglo saxon accounting - Have a [DEMO] KIT product in a category using automated Inventory Valuation with costing method AVCO - The KIT is composed by C1 and C2 in the same product category - Define a cost on both C1 and C2 - Open a POS session, order [DEMO], Invoice and complete the order - Close Session, Validate and display Journal Items COGS entries will be missing. This does not occur when making the order without invoicing opw-2481518 opw-2545758 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#72404
The company is not mandatory on the analytic account, and the currency on it is a related field to the currency of that company, if set. In case it is not set, we should add a default fallback on the currency of the company of the manufacturing order. Description of the issue/feature this PR addresses: opw-2574461 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
Original PR description
The company is not mandatory on the analytic account, and the currency on it is a related field to the currency of that company, if set. In case it is not set, we should add a default fallback on the currency of the company of the manufacturing order. Description of the issue/feature this PR addresses: opw-2574461 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#72344
The current ldap implementation does not handle correctly all error conditions, this PR attempts to make the behavior well-defined in all situations. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#72348
Original PR description
The current ldap implementation does not handle correctly all error conditions, this PR attempts to make the behavior well-defined in all situations. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#72348
**Current behavior before PR:** Suppose we have a scenario like below, - Task-A: - Activity-1: name: Email ( Today ) assigned to: User-1 - Task-B: - Activity-1: name: Email ( Today ) assigned to: User-2 - Activity-2: name: Call ( Due in 3 Days ) assigned to: User-1 Here, when user-1 go through the systray 'Today' filter shortcut, that time user gets Task-A and Task-B both in the list instead of only Task-A.
Original PR description
**Current behavior before PR:** Suppose we have a scenario like below, - Task-A: - Activity-1: name: Email ( Today ) assigned to: User-1 - Task-B: - Activity-1: name: Email ( Today ) assigned to:…
**Current behavior before PR:**
Suppose we have a scenario like below,
- Task-A:
- Activity-1:
name: Email ( Today )
assigned to: User-1
- Task-B:
- Activity-1:
name: Email ( Today )
assigned to: User-2
- Activity-2:
name: Call ( Due in 3 Days )
assigned to: User-1
Here, when user-1 go through the systray 'Today' filter shortcut, that time user
gets Task-A and Task-B both in the list instead of only Task-A.
Currently, activities are not filtered based on users with its deadlines.
**Desired behavior after PR is merged:**
Now activities will be filtered based on deadlines as well as the current user
To achieve this behavior we needed to pass the domain like,
[
('activity_ids.date_deadline','=', fields.Date.today()),
('activity_ids.user_id','=', 1)
]
And for that, we introduced a non-stored compute field with a search method.
**LINKS**
Task-2438822
Forward-Port-Of: odoo/enterprise#18926
Forward-Port-Of: odoo/enterprise#17016Before this commit, the columns of a newly inserted pivot were not auto-resized. This was due to a change in the command "RESIZE_COLUMNS", which is now "RESIZE_COLUMNS_ROWS" with a new argument "dimension" (COL or ROW). opw 2572007 Forward-Port-Of: odoo/enterprise#19016
Original PR description
Before this commit, the columns of a newly inserted pivot were not auto-resized. This was due to a change in the command "RESIZE_COLUMNS", which is now "RESIZE_COLUMNS_ROWS" with a new argument "dimension" (COL or ROW). opw 2572007 Forward-Port-Of: odoo/enterprise#19016
Before this commit, a CSS rule adds '/ ' when we have many fields in the group by for the grid view. The problem is the selector CSS of this rule. When the rule selects the following element in this selector: `.o_view_grid > tbody > th > div > div:before`, we don't check the div with a class and thus, when we use the `Many2OneAvatar` widget in the timesheet grid, the rule is satisfied and add padding but the div of the avatar is displayed as a block and thus, the avatar div go down in next
Original PR description
Before this commit, a CSS rule adds '/ ' when we have many fields in the group by for the grid view. The problem is the selector CSS of this rule. When the rule selects the following element in this…
Before this commit, a CSS rule adds '/ ' when we have many fields in the group by for the grid view. The problem is the selector CSS of this rule. When the rule selects the following element in this selector: `.o_view_grid > tbody > th > div > div:before`, we don't check the div with a class and thus, when we use the `Many2OneAvatar` widget in the timesheet grid, the rule is satisfied and add padding but the div of the avatar is displayed as a block and thus, the avatar div go down in next line because of this added padding. This commit adds a class to the div concerned for the CSS rule, to only apply the CSS rule when needed. Step to see the additional padding before this commit: ===================================================== 1) Go to Timesheets App 2) Go to grid view in `Timesheet > All Timesheets` menu Actual behaviour: ================ Above each avatar, we have an added padding. Expected behaviour: ================== The row containing the avatar should not have an additional padding, all rows in the `tbody` should keep the same height. X-original-commit: 5a0a1e76b372d80adc1bad6ad29a20bedf764100 Forward-Port-Of: odoo/enterprise#18992