Daily updates from Odoo
Navigate
Branch
Monday, June 5, 2023
19 changes
Enhancements to existing features
Users can now search signed documents by a signer's display name, which includes both the person and their company. This makes it easier to answer business questions like whether an NDA exists for a specific company when the individual signer is unknown.
Original PR description
With large Companies, it is common for people to want to answer the question "Do we have a signed NDA from YourCompany?" It is easy to find a signed document by Individual, it is not possible (easily) to find a signed document by unknown Individual at a Company. As the display name correspond to both the name and the company, this change allow the search on both the user and the company task-id : 3265745
India Payroll now supports a dedicated salary structure type for interns receiving stipends. This helps businesses calculate intern pay using relevant components such as gross pay, reimbursements, salary attachments or assignments, child support, and net salary.
Original PR description
- Add Intern Structure Type
- The intern employee will get salary based on the following components.
- GROSS
- Attachment of Salary
- Assignment of Salary
- Child Support
- Reimbursement
- Net Salary
task-3284080Recruitment job page links have been renamed to use a shorter, cleaner web address. This makes shared job links easier to read and aligns the salary package recruitment pages with the updated route.
Original PR description
In this commit we renamed jobs/detail/job_position route to jobs/job_position. task-3339118
Subscription options such as whether customers can close subscriptions and key contract dates are now managed in a dedicated settings area instead of being hidden in quotation templates. Companies can also define default values for new subscriptions and templates, making setup more consistent when no template is used.
Original PR description
Since the merge of Subscriptions with Sales orders, the concept of "quotation template" has been distorted. It's no longer used only to pre-fill the SO, one information required in the life cycle of the subscription is saved in the template and only in the template: "closable by customer". There is also a problem when no template is defined. Information is hidden for confirmed SO because the template reference is not visible anymore. Solutions : We create a section for subscription settings that contains the following settings : - Closable by customer - Start date - First contract date In addition, multiple company dependant settings will by available to pre-fill SO properties when created without templates. Those settings will also be used as default values when creating new quotation template. task-id : 2877341 community : odoo/odoo#112433
This update makes small usability improvements across project-related workflows. It reduces the size of certain confirmation and ticket conversion dialogs, and reorganizes project card menu actions so commonly used options are easier to find.
Original PR description
** => project,helpdesk,timesheet_grid The purpose of this PR is to improve the generic usage of the project app. So, in this PR done following changes: - Reduced the size of confirm time spent, convert to ticket wizard - switched Sales Orders button and planning button from their place in the project kanban card burger menu task-2989828
Project planning now limits planned-hour sales order actions to sales orders linked to the relevant project. Scheduling tasks from the Gantt view also preserves existing assignees when assigning work to one of them, reducing accidental assignment changes.
Original PR description
**[IMP] project: improve ux** **Before this commit:** - project.updates 'hours planned' stat button: the 'plan orders' button take into account all SOs. - Given a task assigned to user A and B. If we schedule the task to user A, user B is removed. **After these changes:** - project.updates 'hours planned' stat button: the 'plan orders' button should only take into account the SOs that are linked to the project. - When scheduling the task using the magnifying glass icon of the Gantt view, the task should remain assigned to users A and B if it is scheduled for either one of them. If the task is scheduled for user C, the task should be assigned to user C and users A and B should be removed from the assignees. task-2929871
Resolved issues and error corrections
Manufacturing planning now calculates work center availability correctly even when schedules are grouped in different ways, such as by stage or production order. This prevents misleading totals in planning views and also avoids a Firefox-only display error when hovering over total indicators.
Code cleanup and technical improvements
Several Point of Sale-related modules were updated to follow a recent internal file reorganization. This keeps German, Mexican, IoT, restaurant, preparation display, HR mobile, and settlement features working correctly without changing business workflows.
Original PR description
pos*: l10n_de_pos_cert, l10n_de_pos_res_cert, l10n_mx_edi_pos, pos_hr_mobile, pos_iot, pos_l10n_se, pos_preparation_display, pos_restaurant_preparation_display, pos_settle_due A commit in community reorganizes the files in the pos, this commit renames all of the imports of those files to match their new location. Linked-to: https://github.com/odoo/odoo/pull/123498
Miscellaneous changes
When the Cron runs to reconcile bank statement lines we have a limit on the date of statements for performances considerations. Instead of using the date set on the statement minus 3 months, we now use the `create_date` of the record. This way, if the user creates a statement more than 3 months in the past it will now be taken into account by the Cron. opw-3318732 Forward-Port-Of: odoo/enterprise#41875
Original PR description
When the Cron runs to reconcile bank statement lines we have a limit on the date of statements for performances considerations. Instead of using the date set on the statement minus 3 months, we now use the `create_date` of the record. This way, if the user creates a statement more than 3 months in the past it will now be taken into account by the Cron. opw-3318732 Forward-Port-Of: odoo/enterprise#41875
With this commit, if a RPC is pending but the search terms change, the current RPC is aborted and a new one with the updated search terms is made instead. This commit also fixes a bug introduced in https://github.com/odoo/enterprise/pull/41704: sending two RPCs in a row could desynchronise the state of the interface, displaying the spinner when it shouldn't. Part of task-3343258. Forward-Port-Of: odoo/enterprise#41921 Forward-Port-Of: odoo/enterprise#41785
Original PR description
With this commit, if a RPC is pending but the search terms change, the current RPC is aborted and a new one with the updated search terms is made instead. This commit also fixes a bug introduced in https://github.com/odoo/enterprise/pull/41704: sending two RPCs in a row could desynchronise the state of the interface, displaying the spinner when it shouldn't. Part of task-3343258. Forward-Port-Of: odoo/enterprise#41921 Forward-Port-Of: odoo/enterprise#41785
add `hr_holidays_gantt` module as depends to `hr_payroll_holidays` we defined gantt mode in one of the window action of `hr_payroll_holidays` and that gantt view defined in `hr_holidays_gantt`. some customer uninstalled `hr_holidays_gantt` module then will got this error , 'no default gantt_view' found. so added `hr_holidays_gantt` as depends to `hr_payroll_holidays` step: 1. installed `hr_payroll_holidays 2. uninstalled `hr_holidays_gantt` gantt view id : hr_leave_gantt_view view_mode
Original PR description
add `hr_holidays_gantt` module as depends to `hr_payroll_holidays` we defined gantt mode in one of the window action of `hr_payroll_holidays` and that gantt view defined in `hr_holidays_gantt`. some customer uninstalled `hr_holidays_gantt` module then will got this error , 'no default gantt_view' found. so added `hr_holidays_gantt` as depends to `hr_payroll_holidays` step: 1. installed `hr_payroll_holidays 2. uninstalled `hr_holidays_gantt` gantt view id : hr_leave_gantt_view view_mode gantt in action : hr_leave_work_entry_action Forward-Port-Of: odoo/enterprise#41641 Forward-Port-Of: odoo/enterprise#41232
have a form view like: ```xml <form> <field name='product_ids'> <form> <field name="po2m" context="{'context_key': 'value'}"> <form> <field name="display_name" /> </form> </field> </form> </field> </form> ``` In studio, try to edit the form view of po2m (it has a context). Before this commit, it crashed, as we wanted to evaluate the field's context, but the pa
Original PR description
have a form view like:
```xml
<form>
<field name='product_ids'>
<form>
<field name="po2m" context="{'context_key': 'value'}">
<form>
<field name="display_name" />
</form>
</field>
</form>
</field>
</form>
```
In studio, try to edit the form view of po2m (it has a context).
Before this commit, it crashed, as we wanted to evaluate the field's context, but the parent record (or more precisely, the datapoints that it had in its data) was not in the scope for the evaluation anymore.
After this commit, we evaluate the parent record's context right away. That way it has all the required data to be used by an another datapoint down the x2many chain.
This is fix was made in an unrelated fix in 16.3: 9d458f8771f507aa9c386530b03db155448b0323
opw-3179365
Forward-Port-Of: odoo/enterprise#41914
Forward-Port-Of: odoo/enterprise#41880## Current behaviour When selling a service where the billing address is different than the shipping address of the service (on create = task in project), the sale order is linked to the task, but the task is not linked to the SO, preventing us from invoicing the task. ## Expected behaviour You should be able to invoice the task, even when the shipping address is different than the billing address. ## Steps to reproduce - Install Sales, FSM - Settings > Check "Customer Delivery Address
Original PR description
## Current behaviour When selling a service where the billing address is different than the shipping address of the service (on create = task in project), the sale order is linked to the task, but…
## Current behaviour When selling a service where the billing address is different than the shipping address of the service (on create = task in project), the sale order is linked to the task, but the task is not linked to the SO, preventing us from invoicing the task. ## Expected behaviour You should be able to invoice the task, even when the shipping address is different than the billing address. ## Steps to reproduce - Install Sales, FSM - Settings > Check "Customer Delivery Address" - Duplicate the "Field Service" product, set the invoicing to "Prepaid/Fixed". - Create a new SO, set customer and billing address to A, delivery address to B, add a line with the new field service. Confirm the SO. - Go to the linked Task, observe there is no SO smart button on it, and when we click on "Mark as Done", no "Create Invoice" button is present. It's also impossible to invoice the task from the list view. ## Reason for the problem When confirming the SO, the customer set on the task is the one from the "delivery address", which fails the integrity check of the sale_order_id's compute of the task (customer on task != customer on sale order) -> the sale_order_id on the task is set to False. ## Fix Relax the condition to also check in case that the customer on the task can be the customer of the delivery address of the sale order. ## Affected versions - 15.0 - saas-15.2 - 16.0 - saas-16.1 - saas-16.2 - master --- opw-3253218 Forward-Port-Of: odoo/enterprise#41902 Forward-Port-Of: odoo/enterprise#40929
`group.record_ids._original_records()` returns an error if record_ids is null. Instead, we return an empty dictionary which queues the group for deletion. opw-3263829 Forward-Port-Of: odoo/enterprise#41650 Forward-Port-Of: odoo/enterprise#40484
Original PR description
`group.record_ids._original_records()` returns an error if record_ids is null. Instead, we return an empty dictionary which queues the group for deletion. opw-3263829 Forward-Port-Of: odoo/enterprise#41650 Forward-Port-Of: odoo/enterprise#40484
=== ISSUE === Before we introduced the Milk new design, the navbar component used to have a background-color based on the $o-brand-odoo SCSS variable. This variable would use the primary color on both Community and Enterprise. With the introduction of Milk, the UI received a fresh upgrade including (in our case) a white navbar rather than using the primary-color. === AFTER === Since we cannot rely on the $o-brand-odoo to make the component anatomy consistent across Community/Enterpri
Original PR description
=== ISSUE === Before we introduced the Milk new design, the navbar component used to have a background-color based on the $o-brand-odoo SCSS variable. This variable would use the primary color on both Community and Enterprise. With the introduction of Milk, the UI received a fresh upgrade including (in our case) a white navbar rather than using the primary-color. === AFTER === Since we cannot rely on the $o-brand-odoo to make the component anatomy consistent across Community/Enterprise and the darkmode, we refactored the navbar using the `border-image` CSS property and adjust the height of the menu to fit its content. - Requires: https://github.com/odoo/odoo/pull/123021 task-3337789 part of task-332626 Forward-Port-Of: odoo/enterprise#41707
**Summary :** When viewing a work order in tablet view, you may miss information as you're not able to scroll **Before :** If you have a **quality step** on the operation, you **cannot** scroll up and down meaning vital information may be missed. **After :** If you have a **quality step** on the operation, you **can** scroll. **Additional Note :** If there's a bunch of instructions, pictures... in the same time as a document on the QCP, the div of the pdf/google slide shrink to 0p
Original PR description
**Summary :** When viewing a work order in tablet view, you may miss information as you're not able to scroll **Before :** If you have a **quality step** on the operation, you **cannot** scroll up and down meaning vital information may be missed. **After :** If you have a **quality step** on the operation, you **can** scroll. **Additional Note :** If there's a bunch of instructions, pictures... in the same time as a document on the QCP, the div of the pdf/google slide shrink to 0px. It explains why **.o_tablet_document** now has a min-height as well. opw-3326557 Forward-Port-Of: odoo/enterprise#41737
Task ID: 3324924 Forward-Port-Of: odoo/enterprise#41661
Original PR description
Task ID: 3324924 Forward-Port-Of: odoo/enterprise#41661
When the report uses a custom handler we can't call the caret option directly since it's not defined in the account_reports model. What we can do instead is call `dispatch_report_action` that will check if the custom handler has the action first. Forward-Port-Of: odoo/enterprise#41480
Original PR description
When the report uses a custom handler we can't call the caret option directly since it's not defined in the account_reports model. What we can do instead is call `dispatch_report_action` that will check if the custom handler has the action first. Forward-Port-Of: odoo/enterprise#41480
Reports batch expressions to evaluate, in order to minimize the number of queries to be ran. To do so, they rely on a grouping key containing various parameters to be used when evaluating a report. All computations with similar parameters are batched. However, in some cases, it was possible that some of these values, while actually different, would lead to the exact same computation. What happened then is that multiple batches were created, and the same query was ran multiple times. On big da
Original PR description
Reports batch expressions to evaluate, in order to minimize the number of queries to be ran. To do so, they rely on a grouping key containing various parameters to be used when evaluating a report.…
Reports batch expressions to evaluate, in order to minimize the number of queries to be ran. To do so, they rely on a grouping key containing various parameters to be used when evaluating a report. All computations with similar parameters are batched. However, in some cases, it was possible that some of these values, while actually different, would lead to the exact same computation. What happened then is that multiple batches were created, and the same query was ran multiple times. On big databases, this could delay the report for entire seconds. This occurred for example in the Belgian Balance Sheet, because of line 149 (BE_UNAFFECTED_EARNINGS). This line had two problems that caused the creation of a new batch just for it: 1) Its date_scope was "from_beginning", while all other expressions from the same engine were "strict_range" on that report. The Balance Sheet uses a single date, not a range ; so 'strict_range' and 'from_beginning' will give similar results for it. 2) It did not have a groupby value. All other account_codes lines of the report have groupby='account_id', so their grouping key receives next_groupby='account_id', while line 149 gets next_groupby=None. This commits introduces a generic solution for both of these problems: 1) All reports not using a date_range will now force the date scopes 'strict_range' and 'normal' to 'from_beginning' in their computation. 2) The engines not using the next_groupby value at all can now be declared in a constant (NO_NEXT_GROUPBY_ENGINES). The engines in this constant will always receive None as their next_groupby. Because of this standardization, engines can now more often be batched, hence improving the performance. Forward-Port-Of: odoo/enterprise#41874