Monday, November 9, 2020
31 changes · master
New functionality added to Odoo
Point of Sale can now apply coupon and promotion programs during checkout, helping businesses offer consistent discounts across sales channels. The update also improves coupon validity setup, customer coupon generation, and notification feedback in the POS interface.
Original PR description
Allow the application of coupon and promotion programs in Point of Sale. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
CRM, Sales, and Purchase reporting now include dedicated dashboard menu entries and default to graph-based views for standard reports. This makes key business reports easier to find and quicker to interpret, with lead reports also opening with the relevant default filter.
Original PR description
We have add the menu dasboard in crm, sales, purchase and change the view mode of all the modules. task : 2311392 PR : 55598
Resolved issues and error corrections
Stock reservation assignment has been optimized to process operations in batches and filter inventory records more efficiently. This should improve performance for businesses handling larger volumes of warehouse movements, reducing delays during stock allocation.
Miscellaneous changes
Create and post an invoice ('Lock Posted Entries with Hash' on the journal) Edit also Bank journal enabling 'Lock Posted Entries with Hash' Create and post a corresponding bank statement: - same setting on the journal - same partner on the line Reconcile Action will be blocked because the system try to rewrite the partner on the posted line which is locked. For Bank/Cash journals should not be visible the lock setting. opw-2367688 Description of the issue/feature this PR addre
Original PR description
Create and post an invoice ('Lock Posted Entries with Hash' on the
journal)
Edit also Bank journal enabling 'Lock Posted Entries with Hash'
Create and post a corresponding bank statement:
- same setting on the journal
- same partner on the line
Reconcile
Action will be blocked because the system try to
rewrite the partner on the posted line which is locked.
For Bank/Cash journals should not be visible the lock setting.
opw-2367688
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#61222The website product catalog/pricelist snippet will now start with item descriptions turned off by default. This makes newly added pricelist sections cleaner and easier for visitors to scan, while still allowing descriptions to be enabled when needed.
Original PR description
task-2372330 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 forecasted stock report now lets users view and change sales or manufacturing order priority directly from the report, helping teams reorder and act on demand faster. It also improves readability with clearer labels, links to draft documents, rounded quantities, mobile layout tweaks, and added order/customer totals.
Original PR description
see and set priority on sales orders and manufacturing orders in forecasted report without having to go to the SO/MO add the priority star icon in front of the SO/MO reference changing priority should reload the page with reordered SO's/Mo add a unreserve button next to 'reserved from stock' in the replenishment column add total order and customer amount in used by column remove time in delivery/receipt dates change column headers (Quantity -> the UoM of the product, Expected Receipt -> Receipt, Expected Delivery -> Delivery) change 'Draft SO' -> 'Quotations' and 'Draft PO' -> 'Requests for quotation' and add links mobile view: display KPI's on new line check decimals on quantities, must be 2 task: 2349142 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
Belgian payroll now calculates employees' legal paid time off based on their actual working schedules and contract changes, rather than only worked days. This improves accuracy when employees change schedules, move to credit time, or have new contracts for the next year.
Original PR description
## Compute paid time off for the next year Before this PR, we computed the amount of the paid time off according to the number of worked days that employee has made during the year. Now, we compute…
## Compute paid time off for the next year Before this PR, we computed the amount of the paid time off according to the number of worked days that employee has made during the year. Now, we compute the correct number of legal leaves according to the working schedule in the contract(s) of each employee during the current year. ### Review allocated days according working schedule In the Paid Time Off Allocation wizard, we also need to compute the legal leaves according the current contract for the next period that the employees have. To find the contract for the next year, we need to search also in the incoming contract, because if we compute the legal leaves at the end of the period. Then it is possible that an employee finished his contract at the end of year and has another contract for the beginning of the next year (next period). We need to add a field named "max_leaves_allocated" in 'hr.leave.allocation' model to retain the maximum time offs that we can allocate to an employee for the next year when he changes his working schedule. Indeed, if in the current period, we compute 18 legal leaves for the following period of an employee, if his contract at the next period specifies that he works at mid-time, we need to allocate the half of legal leaves computed but we must retain the computed amount for the next period to not allocate too many legal leaves when the employee would want to change his working schedule. ### Remove the worked days field in Paid Time Off Allocation wizard Since we now compute the legal leaves with the working schedule in the contracts during the period, the worked days field is useless to keep in this wizard. ### Change date range of period to year The using of the Paid Time Off Allocation wizard is only when we need to allocate Paid Time Off for each employee in belgian. Therefore, the selection of a year of the reference period is more user-friendly then selected a date range. ### Filter employees for allocating time off When we allocate time offs for the next year to an employee, if we return to the wizard then we can even allocate time off to the same employee. This PR filters the employees based on the holiday_status_id selected by the user. We only display the employees which haven't got a time off allocation with this selected 'hr.leave.type' yet. ### Unit Tests Two tests have been created for allocating paid time off. In the first, we check if we correctly compute the right amount of leaves for the next year. In the next test, we check if we allocate the correct amount of paid time off (leaves) based on the working schedule of the employee for the next year. ## Reevaluate the right to time off ### Reevaluate the time off when a credit time is made for an employee When the employee needs to a credit to change his working schedule, we need to reevaluate the right to time off at each change of working schedule. ### reevaluate the time off when exit credit time When the user removes the credit time for an employee to create a new contract at full time, we need to reevaluate the paid time off to allocate. ### compute the old work time rate We need to compute the old work time rate of the employee because we must recompute the correct work time rate to compute correctly the paid time off. ### Unit Tests Some unit tests has been created to check if the implementation is correct. TaskId: 2314223
Sales, CRM, and purchasing now have clearer reporting navigation with dedicated dashboard menu items. Standard report menus now open graph views by default, helping teams spot trends and performance insights more quickly.
Original PR description
We have add the menu dasboard in crm, sales, purchase and change the view mode of all the modules. task : 2311392 PR : 12419
A previously skipped web editor test has been fixed by correcting how a WYSIWYG editor helper is mocked during automated testing. This helps ensure translated HTML fields continue to work reliably without changing day-to-day user behavior.
Original PR description
This fixes and unskips the test "field html translatable". -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a problem where newly created mega menus did not show their name and could cause an error when edited and saved. Website editors can now create and update menus reliably, avoiding interruptions while managing site navigation.
Original PR description
**PURPOSE** - producible in master - Create a megamenu and save, it's not showing name of the menu - click on edit, add name and save. - Showing traceback : https://youtu.be/VM2C-ho_71M **LINKS** TaskID: 2370575 Closes: https://github.com/odoo/odoo/pull/61530
This fixes where a Belgian HR contract view depends on the contract signing feature. The dependency is now handled by the salary contract module, reducing incorrect module coupling and avoiding setup or upgrade issues for payroll users.
Original PR description
…hr_contract_salary
Prior to this commit:
* The hr_contract_history_view_form view in l10n_be_hr_payroll was 'incorrectly' depending
on the module hr_contract_sign through the use of an xpath.
After this commit:
* The dependency to hr_contract_sign has been moved to l10n_be_hr_contract_salary
Bug intruduced in #13384This update fixes an issue in the Indian payroll contract form caused by a previous change. It helps ensure payroll contract information can be displayed or edited correctly for users working with India payroll.
Original PR description
Fix bug introduced in odoo/odoo#58120
Behavior prior to this commit: When editing a lead, if we log a note, it will refresh the record and cause the changes to be lost. In version 13, it would only refresh the record if `@` mentions were added. Behavior after this commit: The record will only refresh if it is not dirty. Note: It is not clear why the record would in fact ever need to refresh as there is no visible change on the lead form when a note is logged, whether or not followers are added (the message thread
Original PR description
Behavior prior to this commit: When editing a lead, if we log a note, it will refresh the record and cause the changes to be lost. In version 13, it would only refresh the record if `@` mentions were added. Behavior after this commit: The record will only refresh if it is not dirty. Note: It is not clear why the record would in fact ever need to refresh as there is no visible change on the lead form when a note is logged, whether or not followers are added (the message thread, which shows the number of followers, refreshes regardless). In this commit I chose the approach which would cause the least change. There is still a need for a longer term solution to orchestrate the refreshes, which will take place once the rest of the web application is converted to use Owl. opw-2369162 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60949
STEPS: * install pad * switch to a company different from res.users::company_id (Default Company for user) * set credentials for that company * Open a form with pad, e.g. project.task BEFORE: it doesn't work, pad_generate_url returns empty values AFTER: it works WHY: Since Odoo 13.0, current company is computed by context values provided by company swither, while user.company_id is default value https://github.com/odoo/odoo/blob/d6d26ea8ac0c160b1fa12f86083965a087aedc75/odoo/a
Original PR description
STEPS: * install pad * switch to a company different from res.users::company_id (Default Company for user) * set credentials for that company * Open a form with pad, e.g. project.task BEFORE: it doesn't work, pad_generate_url returns empty values AFTER: it works WHY: Since Odoo 13.0, current company is computed by context values provided by company swither, while user.company_id is default value https://github.com/odoo/odoo/blob/d6d26ea8ac0c160b1fa12f86083965a087aedc75/odoo/addons/base/models/res_users.py#L245-L246 https://github.com/odoo/odoo/blob/5c79992f1f0f1b5a8ac4c1f464347abc10a6d8d8/odoo/api.py#L555-L562 --- bug is founding during work on opw-2369677 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#61141
We extract the `price_unit` and `tax_ids` recomputation logic from the `_onchange_product_id` method. This way, it can be called programmatically. opw-2371934 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#61459
Original PR description
We extract the `price_unit` and `tax_ids` recomputation logic from the `_onchange_product_id` method. This way, it can be called programmatically. opw-2371934 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#61459
Small refactoring to allow calling the method to update the debug manager action independently from `current_action_updated`. Needed for https://github.com/odoo/enterprise/pull/14551. opw-2365539 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#61297 Forward-Port-Of: odoo/odoo#61229
Original PR description
Small refactoring to allow calling the method to update the debug manager action independently from `current_action_updated`. Needed for https://github.com/odoo/enterprise/pull/14551. opw-2365539 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#61297 Forward-Port-Of: odoo/odoo#61229
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#61348 Forward-Port-Of: odoo/odoo#61261
Original PR description
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#61348 Forward-Port-Of: odoo/odoo#61261
We can have payment.transaction references of >20 characters. This happens automatically if you have long sale.{order,subscription} sequences (especially through website_payment because it adds multiple suffixes, e.g. SO2020/1234567 could turn into SO2020/1234567-12-1-1-1). We POST the full reference via the x_invoice_num variable. Unfortunately Authorize specifies a maximum length of 20 for this field [1]. So when Authorize POSTs back to /payment/authorize/return it only specifies the fi
Original PR description
We can have payment.transaction references of >20 characters. This happens automatically if you have long sale.{order,subscription} sequences (especially through website_payment because it adds…
We can have payment.transaction references of >20 characters. This
happens automatically if you have long sale.{order,subscription}
sequences (especially through website_payment because it adds multiple
suffixes, e.g. SO2020/1234567 could turn into
SO2020/1234567-12-1-1-1). We POST the full reference via the
x_invoice_num variable. Unfortunately Authorize specifies a maximum
length of 20 for this field [1]. So when Authorize POSTs back to
/payment/authorize/return it only specifies the first 20 characters in
x_invoice_num. E.g. when POSTing
{
...
'x_invoice_num': 'SO2020/1234567-12-1-1-1',
...
}
we receive back in /payment/authorize/return:
{
...
'x_invoice_num': 'SO2020/1234567-12-1-',
...
}
This causes _authorize_form_get_tx_from_data() to not find the
transaction which results in a ValidationError.
To fix this also pass the reference in the x_description field. It has
a more generous 255 character limit [1]. Then search using both.
We can't get rid of x_invoice_num entirely because we cannot assume
the payment_authorize.authorize_form will be updated (even more so
because it's a noupdate="1" template). By still using it in
_authorize_form_get_tx_from_data() we ensure that everything keeps
working regardless of whether or not x_description is included in the
template.
[1] p39 in https://www.authorize.net/content/dam/anet-redesign/documents/AIM_guide.pdf
opw-2373433
Forward-Port-Of: odoo/odoo#61102- Activate UoM - Create 3 products: AB, A & B - Create a kit BoM for AB - 1 units of A - 1 kg of B - Sell 1 unit of AB, confirm The `qty_available_today` and the `free_qty_today` remains zero. We apply a logic which is similar to the computation of the delivered quantity of kits. 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 ww
Original PR description
- Activate UoM - Create 3 products: AB, A & B - Create a kit BoM for AB - 1 units of A - 1 kg of B - Sell 1 unit of AB, confirm The `qty_available_today` and the `free_qty_today` remains zero. We apply a logic which is similar to the computation of the delivered quantity of kits. 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#61058
task-2366680 Forward-Port-Of: odoo/odoo#60593
Original PR description
task-2366680 Forward-Port-Of: odoo/odoo#60593
This fixes a very obscure bug that happens on workers serving multiple databases. Consider two databases A and B with the same model M, that does not have a field 'name', but has a custom field 'x_name' only on database A. The bug can be reproduced with the module 'account' and its model 'account.register.payments'. Assume the server loads a registry for database A. In that registry, the model M uses 'x_name' as its _rec_name, and the field 'display_name' on model M determines its de
Original PR description
This fixes a very obscure bug that happens on workers serving multiple databases. Consider two databases A and B with the same model M, that does not have a field 'name', but has a custom field…
This fixes a very obscure bug that happens on workers serving multiple
databases. Consider two databases A and B with the same model M, that
does not have a field 'name', but has a custom field 'x_name' only on
database A. The bug can be reproduced with the module 'account' and its
model 'account.register.payments'.
Assume the server loads a registry for database A. In that registry,
the model M uses 'x_name' as its _rec_name, and the field 'display_name'
on model M determines its dependencies to be the field 'x_name'.
Now assume the server load a registry for database B. In that registry,
the model M has no _rec_name. However, an optimization reuses the field
'display_name' for the model M on the registry of A. The field's
attribute 'depends' is equal to the tuple ('x_name',). When the ORM
tries to resolve the field's dependencies, it does not find the field
'x_name' on M and crashes.
In order to avoid this situation, we forbid the usage of 'x_name' as
_rec_name on non-custom models.
OPW 2349238
Forward-Port-Of: odoo/odoo#61436
Forward-Port-Of: odoo/odoo#61395In some cases, the edit mode on the production form view is not already rendered when hte tour try to write '1' in the qty_producing field. This lead to a fail of the Main Flow Tour. This commit specifically trigger the input tag to be sure the text will be inserted in edit mode. 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
Original PR description
In some cases, the edit mode on the production form view is not already rendered when hte tour try to write '1' in the qty_producing field. This lead to a fail of the Main Flow Tour. This commit specifically trigger the input tag to be sure the text will be inserted in edit mode. 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#61437
Create a sale tax 100% included in price Create an invoice with the tax on the line Change unit price The total does not change This occur because when having 100% tax debit/credit are unchanged. So the onchange `_onchange_mark_recompute_taxes` is not triggered and the tax lines are not updated, thus not changing the total (as in this case the invoice total is just the tax value) opw-2370861 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Create a sale tax 100% included in price Create an invoice with the tax on the line Change unit price The total does not change This occur because when having 100% tax debit/credit are unchanged. So the onchange `_onchange_mark_recompute_taxes` is not triggered and the tax lines are not updated, thus not changing the total (as in this case the invoice total is just the tax value) opw-2370861 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#61356
Since the `sequence` field is used with a `widget="handle"`, we need to sort by sequence, otherwise the reordering has no effect visually. opw-2378255 Forward-Port-Of: odoo/enterprise#14657
Original PR description
Since the `sequence` field is used with a `widget="handle"`, we need to sort by sequence, otherwise the reordering has no effect visually. opw-2378255 Forward-Port-Of: odoo/enterprise#14657
- Install Subscriptions and Invoicing (not Accounting) - Go to Subscriptions > Configuration > Subscription Templates - Create or edit a Template (i.e. Mon - Monthly Subscription) with "Send" for "Create Invoice" - Create a Subscription: * Subscription Template: Mon - Monthly Subscription * Subscription Lines: [Any a product] - Switch Subscription state from "Draft" to "In Progress" - Click on "Generate Invoice" button An error is raised when trying to access "attachment_ids" field o
Original PR description
- Install Subscriptions and Invoicing (not Accounting) - Go to Subscriptions > Configuration > Subscription Templates - Create or edit a Template (i.e. Mon - Monthly Subscription) with "Send" for "Create Invoice" - Create a Subscription: * Subscription Template: Mon - Monthly Subscription * Subscription Lines: [Any a product] - Switch Subscription state from "Draft" to "In Progress" - Click on "Generate Invoice" button An error is raised when trying to access "attachment_ids" field of invoice because the field is defined in Accounting and not Invoicing. opw-2371417 opw-2373670 Forward-Port-Of: odoo/enterprise#14653 Forward-Port-Of: odoo/enterprise#14626
Since it is not possible to reconcile lines whose date is before the fiscal lock, they should be ignored by the query that selects the lines to show in the reconciliation widget. Forward-Port-Of: odoo/enterprise#14493
Original PR description
Since it is not possible to reconcile lines whose date is before the fiscal lock, they should be ignored by the query that selects the lines to show in the reconciliation widget. Forward-Port-Of: odoo/enterprise#14493
When getting the ir rules queries needed to be applied in `_get_bank_statement_line_partners` a simple `replace` is used to rename the table res_partner to p3. This can be an issue when there are fields or other tables with the string 'res_partner' within their names. The usage of a regex ensuring an exact match it is a more robust way to do it. X-original-commit: https://github.com/odoo/odoo/fe3a35006b8397425a702333cf4115a80171f94e Forward-Port-Of: odoo/enterprise#14648
Original PR description
When getting the ir rules queries needed to be applied in `_get_bank_statement_line_partners` a simple `replace` is used to rename the table res_partner to p3. This can be an issue when there are fields or other tables with the string 'res_partner' within their names. The usage of a regex ensuring an exact match it is a more robust way to do it. X-original-commit: https://github.com/odoo/odoo/fe3a35006b8397425a702333cf4115a80171f94e Forward-Port-Of: odoo/enterprise#14648
That option was only working with the bank reconciliation widget. Forward-Port-Of: odoo/enterprise#14631
Original PR description
That option was only working with the bank reconciliation widget. Forward-Port-Of: odoo/enterprise#14631
Behavior prior to the commit: When opening a dialog from the home menu (for example, the preference dialog), the home menu stays displayed. Then, when opening a window action from that dialog, the action can't display, since the home menu shadows the web client. For the actions that are triggered from the home menu itself, or the dropdown menu, there is already an override (do_action) in the Enterprise web client that turns off the home menu. But this override does not get invoked for
Original PR description
Behavior prior to the commit: When opening a dialog from the home menu (for example, the preference dialog), the home menu stays displayed. Then, when opening a window action from that dialog, the…
Behavior prior to the commit: When opening a dialog from the home menu (for example, the preference dialog), the home menu stays displayed. Then, when opening a window action from that dialog, the action can't display, since the home menu shadows the web client. For the actions that are triggered from the home menu itself, or the dropdown menu, there is already an override (do_action) in the Enterprise web client that turns off the home menu. But this override does not get invoked for actions that are triggered from within a form. Behavior after the commit: The home menu is toggled off when invoking a window action, even when this is not done directly under the web client. Note: - Correction of commit cce561e568ef9a1ff947c3f43d3688aca10e59e3 which did the override of current_action_updated incorrectly. - Depends on https://github.com/odoo/odoo/pull/61229 - See comments on https://github.com/odoo/enterprise/pull/14474 for the original PR which had to be corrected opw-2365539 Forward-Port-Of: odoo/enterprise#14576 Forward-Port-Of: odoo/enterprise#14551
See https://github.com/odoo/enterprise/commit/c28428d5d8b1edf7576130a05998d83ca22651c0 Forward-Port-Of: odoo/enterprise#14632
Original PR description
See https://github.com/odoo/enterprise/commit/c28428d5d8b1edf7576130a05998d83ca22651c0 Forward-Port-Of: odoo/enterprise#14632
- Install hr_payroll - Do not install hr_contract_salary - Go to Payroll > Payslips > All payslips - Create and confirm a payslip An error is raised. Payslip report template is trying to display "contract_type" field of "hr.contract", but this field is defined in "hr_contract_salary" module. opw-2370852 Forward-Port-Of: odoo/enterprise#14562
Original PR description
- Install hr_payroll - Do not install hr_contract_salary - Go to Payroll > Payslips > All payslips - Create and confirm a payslip An error is raised. Payslip report template is trying to display "contract_type" field of "hr.contract", but this field is defined in "hr_contract_salary" module. opw-2370852 Forward-Port-Of: odoo/enterprise#14562