Wednesday, August 26, 2020
19 changes · master
Enhancements to existing features
This improvement lets Odoo pass an optional loading preference through combined search-and-read operations. Businesses can avoid unnecessary display-name calculations in specific cases, improving performance for data-heavy processes without changing normal behavior.
Original PR description
The load parameter using 'classic_read' for method - read(fields, load='classic_read') it is computing name_get for each record. But what about if you don't want to optimize to avoid computing that value. You need to use 2 lines of code: records = self.search(...) records.read (..., load='') But there is a cleaner way using self.search_read(..., load='') But it was not supported the "load" parameter This change adds that support. cc @rco-odoo @odony @xmo-odoo
Businesses can now set a custom name for the Events Progressive Web App in each website's settings. If no custom name is provided, the app automatically uses the website name followed by “Events,” making branding clearer with minimal setup.
Original PR description
This commit adds a website-specific and customizable app name for the Events' Progressive Web Application, configurable through the website's settings. Defaults to '<website_name> Events'. X-original-commit: 423076ddf1da0fc61d9a18dc19bbbbf900e3dad6
The Planning Gantt view now keeps the employee list in the same order while users drag and drop schedule items. This reduces confusion by only refreshing the display order when the user next opens the relevant menu.
Original PR description
PURPOSE Currently, the way employees are sorted on the gantt view changes live, which is confusing because one second my employee is the first of the list, the next, he/she isn't anymore. SPEC The order in which employees are displayed on the gantt view should only be updated the next time the user opens these menus TASK 2129131
Resolved issues and error corrections
This update fixes an internal accounting test so it works consistently when local accounting configurations are installed. It helps maintain reliability of the onboarding flow checks without affecting day-to-day user behavior.
Original PR description
Use `AccountTestInvoicingHttpCommon` so that it is independent from demo data. We can now give the value `installed` to fetch the first installed chart of accounts instead of skipping th test. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
This commit reverts 0c075552f70381872d177f900ed00fbfab39be0e Task [2306265](https://www.odoo.com/web#id=2306265&action=333&active_id=967&model=project.task&view_type=form&cids=1&menu_id=4720) This had the side effect of blocking the group by label in the Journal Entry list view. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56344 Forward-Port-Of: odoo/odoo#55046
Original PR description
This commit reverts 0c075552f70381872d177f900ed00fbfab39be0e Task [2306265](https://www.odoo.com/web#id=2306265&action=333&active_id=967&model=project.task&view_type=form&cids=1&menu_id=4720) This had the side effect of blocking the group by label in the Journal Entry list view. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56344 Forward-Port-Of: odoo/odoo#55046
This page will be used in case of lost connection. The web page will be automatically fetched when you are back online. We also use this page when it's not possible to use the cache due to a redirection. Forward-Port-Of: odoo/odoo#56476 Forward-Port-Of: odoo/odoo#56136
Original PR description
This page will be used in case of lost connection. The web page will be automatically fetched when you are back online. We also use this page when it's not possible to use the cache due to a redirection. Forward-Port-Of: odoo/odoo#56476 Forward-Port-Of: odoo/odoo#56136
Purpose ======= The purpose of this commit is to add a test ensuring the number of request while creating a company leave for 100 employees, if 15 of them already have a leave during that period. It includes, the mass leave generation, and the conflicts resolutions. (Cancelling/Splitting the already existing one and adapting the dates accordingly). The aim of the next commits is to reduce the number of request for this test. Original profiler for the action_validate method. cal
Original PR description
Purpose ======= The purpose of this commit is to add a test ensuring the number of request while creating a company leave for 100 employees, if 15 of them already have a leave during that period. It…
Purpose
=======
The purpose of this commit is to add a test ensuring the number of request while creating
a company leave for 100 employees, if 15 of them already have a leave during that period.
It includes, the mass leave generation, and the conflicts resolutions. (Cancelling/Splitting the
already existing one and adapting the dates accordingly).
The aim of the next commits is to reduce the number of request for this test.
Original profiler for the action_validate method.
calls queries ms
hr.leave ---------------------------- /home/ybrant/odoo_dev/odoo/addons/hr_holidays/models/hr_leave.py, 888
1 0 0.03 @profile
def action_validate(self):
1 0 0.1 current_employee = self.env.user.employee_id
1 0 0.05 if any(holiday.state not in ['confirm', 'validate1'] for holiday in self):
raise UserError(_('Time off request must be confirmed in order to approve it.'))
1 7 26.99 self.write({'state': 'validate'})
1 0 2.65 self.filtered(lambda holiday: holiday.validation_type == 'both').write({'second_approver_id': current_employee.id})
1 0 4.69 self.filtered(lambda holiday: holiday.validation_type != 'both').write({'first_approver_id': current_employee.id})
1 0 0.06 for holiday in self.filtered(lambda holiday: holiday.holiday_type != 'employee'):
1 0 0.03 if holiday.holiday_type == 'category':
employees = holiday.category_id.employee_ids
1 0 0.03 elif holiday.holiday_type == 'company':
1 1 2.19 employees = self.env['hr.employee'].search([('company_id', '=', holiday.mode_company_id.id)])
else:
employees = holiday.department_id.member_ids
1 0 0.02 conflicting_leaves = self.env['hr.leave'].with_context(
1 0 0.01 tracking_disable=True,
1 0 0.01 mail_activity_automation_skip=True,
1 0 0.15 leave_fast_create=True
).search([
1 0 0.04 ('date_from', '<=', holiday.date_to),
1 0 0.03 ('date_to', '>', holiday.date_from),
1 0 0.01 ('state', 'not in', ['cancel', 'refuse']),
1 0 0.01 ('holiday_type', '=', 'employee'),
1 2 3.89 ('employee_id', 'in', employees.ids)])
1 0 0.01 if conflicting_leaves:
# YTI: More complex use cases could be managed in master
1 0 0.41 if holiday.leave_type_request_unit != 'day' or any(l.leave_type_request_unit == 'hour' for l in conflicting_leaves):
raise ValidationError(_('You can not have 2 leaves that overlaps on the same day.'))
17 0 0.25 for conflicting_leave in conflicting_leaves:
15 0 0.52 if conflicting_leave.leave_type_request_unit == 'half_day' and conflicting_leave.request_unit_half:
conflicting_leave.action_refuse()
continue
# Leaves in days
15 0 0.24 split_leaves = self.env['hr.leave']
15 0 0.33 target_state = conflicting_leave.state
15 45 105.25 conflicting_leave.action_refuse()
15 0 0.58 if conflicting_leave.date_from < holiday.date_from:
15 0 0.14 before_leave_vals = conflicting_leave.copy_data({
15 0 0.32 'date_from': conflicting_leave.date_from.date(),
15 0 15.83 'date_to': holiday.date_from.date() + timedelta(days=-1),
15 0 0.16 })[0]
15 0 8.1 before_leave = self.env['hr.leave'].new(before_leave_vals)
15 60 8945.0 before_leave._onchange_request_parameters()
# Could happen for part-time contract, that time off is not necessary
# anymore.
# Imagine you work on monday-wednesday-friday only.
# You take a time off on friday.
# We create a company time off on friday.
# By looking at the last attendance before the company time off
# start date to compute the date_to, you would have a date_from > date_to.
# Just don't create the leave at that time. That's the reason why we use
# new instead of create. As the leave is not actually created yet, the sql
# constraint didn't check date_from < date_to yet.
15 0 0.81 if before_leave.date_from < before_leave.date_to:
15 0 0.27 split_leaves |= self.env['hr.leave'].with_context(
15 0 0.13 tracking_disable=True,
15 0 0.12 mail_activity_automation_skip=True,
15 0 1.34 leave_fast_create=True
15 45 167.24 ).create(before_leave._convert_to_write(before_leave._cache))
15 0 0.59 if conflicting_leave.date_to > holiday.date_to:
after_leave_vals = conflicting_leave.copy_data({
'date_from': holiday.date_to.date() + timedelta(days=1),
'date_to': conflicting_leave.date_to.date(),
})[0]
after_leave = self.env['hr.leave'].new(after_leave_vals)
after_leave._onchange_request_parameters()
# Could happen for part-time contract, that time off is not necessary
# anymore.
if after_leave.date_from < after_leave.date_to:
split_leaves |= self.env['hr.leave'].with_context(
tracking_disable=True,
mail_activity_automation_skip=True,
leave_fast_create=True
).create(after_leave._convert_to_write(after_leave._cache))
45 0 0.53 for split_leave in split_leaves:
15 0 0.12 if target_state == 'draft':
continue
15 0 0.12 if target_state == 'confirm':
15 180 538.26 split_leave.action_confirm()
elif target_state == 'validate1':
split_leave.action_confirm()
split_leave.action_approve()
elif target_state == 'validate':
split_leave.action_confirm()
split_leave.action_validate()
1 303 2131.3 values = [holiday._prepare_holiday_values(employee) for employee in employees]
1 0 0.02 leaves = self.env['hr.leave'].with_context(
1 0 0.01 tracking_disable=True,
1 0 0.01 mail_activity_automation_skip=True,
1 0 0.08 leave_fast_create=True,
1 303 894.63 ).create(values)
leaves.action_approve()
# FIXME RLi: This does not make sense, only the parent should be in validation_type both
if leaves and leaves[0].validation_type == 'both':
leaves.action_validate()
employee_requests = self.filtered(lambda hol: hol.holiday_type == 'employee')
employee_requests._validate_leave_request()
if not self.env.context.get('leave_fast_create'):
employee_requests.filtered(lambda holiday: holiday.validation_type != 'no_validation').activity_update()
return True
Total:
1 946 12853.68
Original profiler for action_refuse
1 0 0.01 @profile
def action_refuse(self):
1 0 0.07 current_employee = self.env.user.employee_id
1 0 0.04 if any(holiday.state not in ['draft', 'confirm', 'validate', 'validate1'] for holiday in self):
raise UserError(_('Time off request must be confirmed or validated in order to refuse it.'))
1 0 0.04 validated_holidays = self.filtered(lambda hol: hol.state == 'validate1')
1 0 0.14 validated_holidays.write({'state': 'refuse', 'first_approver_id': current_employee.id})
1 2 3.86 (self - validated_holidays).write({'state': 'refuse', 'second_approver_id': current_employee.id})
# Delete the meeting
1 0 0.63 self.mapped('meeting_id').unlink()
# If a category that created several holidays, cancel all related
1 0 0.07 linked_requests = self.mapped('linked_request_ids')
1 0 0.01 if linked_requests:
linked_requests.action_refuse()
# Post a second message, more verbose than the tracking message
3 0 0.02 for holiday in self:
1 0 0.06 if holiday.employee_id.user_id:
holiday.message_post(
body=_('Your %s planned on %s has been refused') % (holiday.holiday_status_id.display_name, holiday.date_from),
partner_ids=holiday.employee_id.user_id.partner_id.ids)
1 1 0.93 self._remove_resource_leave()
1 0 0.57 self.activity_update()
1 0 0.01 return True
Total:
1 3 6.44
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#56477
Forward-Port-Of: odoo/odoo#55794PURPOSE Ease the configuration of external email servers by adding links to the documentation and by making errors more user friendly. SPECIFICATIONS This is done by catching more exceptions when testing incoming and outgoing mail servers. Some hints are given in the error message. A link to the documentation is also added in mail: Settings > External Email Servers feature: add a link to this doc: https://www.odoo.com/documentation/user/13.0/discuss/advanced/email_servers.html
Original PR description
PURPOSE Ease the configuration of external email servers by adding links to the documentation and by making errors more user friendly. SPECIFICATIONS This is done by catching more exceptions when testing incoming and outgoing mail servers. Some hints are given in the error message. A link to the documentation is also added in mail: Settings > External Email Servers feature: add a link to this doc: https://www.odoo.com/documentation/user/13.0/discuss/advanced/email_servers.html Task ID-22736 PR #54176 Forward-Port-Of: odoo/odoo#54176
Task-2250264 Forward-Port-Of: odoo/odoo#51752
Original PR description
Task-2250264 Forward-Port-Of: odoo/odoo#51752
In case `date_planned_finished` is `False`. opw-2326088 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#56566 Forward-Port-Of: odoo/odoo#56548
Original PR description
In case `date_planned_finished` is `False`. opw-2326088 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#56566 Forward-Port-Of: odoo/odoo#56548
PURPOSE There's a display issue of the web_ribbon when the state_selection dropdown is displayed SPEC Fix display issue when of ribbon when kanban selection widget is available in oe_title. TASK 2226237 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#49037
Original PR description
PURPOSE There's a display issue of the web_ribbon when the state_selection dropdown is displayed SPEC Fix display issue when of ribbon when kanban selection widget is available in oe_title. TASK 2226237 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#49037
We don't want to send the EDI for documents set to be posted automatically in the future. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56565
Original PR description
We don't want to send the EDI for documents set to be posted automatically in the future. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56565
The Form class already handles cases for attrs that contain boolean values, e.g.: `attrs="{'readonly': True}"` But it doesnt for integers, e.g.: `attrs="{'readonly': 1}"` This commit changes the expected non-domain value from boolean to integer, because both are valid cases and the former is a subset of the latter. [1] https://github.com/odoo/odoo/blob/b3d4938ba6b1/addons/repair/views/repair_views.xml#L54 -- I confirm I have signed the CLA and read the PR guidelines at www.od
Original PR description
The Form class already handles cases for attrs that contain boolean
values, e.g.:
`attrs="{'readonly': True}"`
But it doesnt for integers, e.g.:
`attrs="{'readonly': 1}"`
This commit changes the expected non-domain value from boolean to
integer, because both are valid cases and the former is a subset of the
latter.
[1] https://github.com/odoo/odoo/blob/b3d4938ba6b1/addons/repair/views/repair_views.xml#L54
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#54926Before this commit, Creating a new Credit Note will log `Refund Created` into the chatter, and creating a new Vendor Refund will log `Credit Note Created` chatter due to wrong types given in `_get_creation_message` method. With this commit, We use the correct type in this method. 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/su
Original PR description
Before this commit, Creating a new Credit Note will log `Refund Created` into the chatter, and creating a new Vendor Refund will log `Credit Note Created` chatter due to wrong types given in `_get_creation_message` method. With this commit, We use the correct type in this method. 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#50185
<a href="https://www.odoo.com/web#id=2320549&action=4043&model=project.task&view_type=form&cids=2&menu_id=4720">2320549</a> Forward-Port-Of: odoo/enterprise#12688 Forward-Port-Of: odoo/enterprise#12565
Original PR description
<a href="https://www.odoo.com/web#id=2320549&action=4043&model=project.task&view_type=form&cids=2&menu_id=4720">2320549</a> Forward-Port-Of: odoo/enterprise#12688 Forward-Port-Of: odoo/enterprise#12565
Task [2306265](https://www.odoo.com/web#id=2306265&action=333&active_id=967&model=project.task&view_type=form&cids=1&menu_id=4720) Forward-Port-Of: odoo/enterprise#12591 Forward-Port-Of: odoo/enterprise#12066
Original PR description
Task [2306265](https://www.odoo.com/web#id=2306265&action=333&active_id=967&model=project.task&view_type=form&cids=1&menu_id=4720) Forward-Port-Of: odoo/enterprise#12591 Forward-Port-Of: odoo/enterprise#12066
See: https://github.com/odoo/odoo/pull/51542 TaskID: 2256705 Forward-Port-Of: odoo/enterprise#12642 Forward-Port-Of: odoo/enterprise#12366
Original PR description
See: https://github.com/odoo/odoo/pull/51542 TaskID: 2256705 Forward-Port-Of: odoo/enterprise#12642 Forward-Port-Of: odoo/enterprise#12366
Usecase to reproduce: - Product A and Product B with route buy and a Vendor - A kit with Product A and Product B as components - Add Procut A and Kit in MPS - Go to MPS and set the demand forecast to 10 for both kit and product A - Product A needs to replenish 20 units (10 from demand + 10 from kit) - Click on replenish in the header The PO generated contains 2 lines: - Line 1 with Product A and qty 10 (due to kit) - Line 2 with Product B and qty 30 The 30 units come from the 2 pro
Original PR description
Usecase to reproduce: - Product A and Product B with route buy and a Vendor - A kit with Product A and Product B as components - Add Procut A and Kit in MPS - Go to MPS and set the demand forecast to 10 for both kit and product A - Product A needs to replenish 20 units (10 from demand + 10 from kit) - Click on replenish in the header The PO generated contains 2 lines: - Line 1 with Product A and qty 10 (due to kit) - Line 2 with Product B and qty 30 The 30 units come from the 2 procurements: - Procurement for Product B order 20 units - Proucrement for Kit order 10 prouct A and 10 product B However it should not order the quantity for B since it's already in the indirect demand. Fix the issue by only order the kit's components that are not present in a production schedule. opw-2301582 Forward-Port-Of: odoo/enterprise#12657
…ppointment This commit adds a few missing translation tags when confirming an online appointment on the website. Task ID 2325262 Forward-Port-Of: odoo/enterprise#12656 Forward-Port-Of: odoo/enterprise#12609
Original PR description
…ppointment This commit adds a few missing translation tags when confirming an online appointment on the website. Task ID 2325262 Forward-Port-Of: odoo/enterprise#12656 Forward-Port-Of: odoo/enterprise#12609