Daily updates from Odoo
Friday, January 25, 2019
3 changes · master
Resolved issues and error corrections
This fixes a styling issue that caused mass mailing email templates to lose their intended layout after a previous editor update. Businesses using email campaigns should see templates render as expected again, improving consistency for marketing communications.
Original PR description
Following the new editor's merge at #29775, the classes 'o_mail_wrapper' and 'o_mail_wrapper_td' were renamed to 'o_mailWrapper' and 'o_mailWrapper_td' because of what appears to be a JS-variable-search-replace fail. Strange enough, the scss was not impacted which allowed to see the bug in master.
Fleet managers can now open employee records and view company car counts even when an employee has no linked user account. The fix prevents access errors by using the correct fleet manager permissions and safely retrieving the private employee address information needed for car matching.
Original PR description
Commit 55a48e3 added support for computing car count and car reports for employees without a linked user. It is computed by accessing the field `address_home_id` (res.partner) to find the driver. However, this field is private. Thus, a user in `fleet_group_manager` has an ACL error when accessing an employee form view which contains a stat button with the car count. This commit compute the car count and the car report with `address_home_id` as sudo to fix the issue. Also the group attribute on the `employee_cars_count` field was wrongly set to `fleet_manager` instead of `fleet_group_manager`. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix stops new order changes from disrupting warehouse pickings that operators have already started processing. When extra items are added, Odoo now creates a separate picking for the new product instead of resetting the existing warehouse operations, helping avoid rework and delays.
Original PR description
Description of the issue/feature this PR addresses: When a new procurement order occurs, pack operations on existing picking that is in the same procurement group and being processed by operators are…
Description of the issue/feature this PR addresses:
When a new procurement order occurs, pack operations on existing picking that is in the same procurement group and being processed by operators are reset.
Operator has to reprocess from the beginning all the operations.
The function assign_picking in stock.move model does not filter correctly the stock pickings (Moreover the comment in the function does not reflect the filter domain...)
Current behavior before PR:
Create a sale order (Assuming you have products with good routes).
Reserve the stock picking
Begin the stock operations (quantities, packages, ...)
Save
Add a line in sale order and save (that creates a procurement order and chained moves)
Go back to your picking. The state has changed ('Waiting Availability')
Stock Operations are reset.
Desired behavior after PR is merged:
Create a sale order (Assuming you have products with good routes).
Reserve the stock picking
Begin the stock operations (quantities, packages, ...)
Save
Add a line in sale order and save (that creates a procurement order and chained moves)
Go back to your picking. It's in the state you let it before.
A new stock picking is created (with the new product)
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr