Wednesday, April 14, 2021
32 changes · master
New functionality added to Odoo
This change adds location categories so warehouses can guide where products should be stored based on capacity, weight, mixing rules, and whether a location must be empty. It also improves automatic putaway decisions by reusing suitable previous destinations or selecting an allowed location category, while avoiding incorrect parent-location rule matches.
Original PR description
Add a new model stock.location.category, now we can assign a category to
a location. The category can contain information like max product
weight, whether the location can store mixed product, and if we only
want to use the location when it's empty.
On the product and product category form, we can assign them allowed
location categoty (with sequence). For product, we can also specify the
max number we can store in the allowed categories.
Now the putaway rule can be automatic, when a automatic putaway rule is
applied, it will first find previous destination location. If there is
none or all are full (according to the setting on the product and
location categoty), we use the allowed location category to find a
suitable location.
Task 2341820
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prEnhancements to existing features
Survey session hosts can now move back to the previous question or results screen during a live session. This helps recover from misclicks or redisplay results without restarting the question, and works independently of the survey's participant back button setting.
Original PR description
PURPOSE ======= For now, even if the setting "Back Button" is activated, the host, can't go back to the previous screen on a live session. Why would he want to go back? Misclick, want to display again the result, other SPECIFICATION ============= On a live session, let the host go back to the previous screen. Do not "restart" the questions but display the graph with the results. Task ID: 2351759
Resolved issues and error corrections
The CRM Leads report now uses the correct list view and lets users open individual lead records directly from that list. This makes the Leads Analysis experience consistent with graph, pivot, and dashboard views and reduces friction when reviewing lead details.
Original PR description
PURPOSE When we go to CRM -> Reporting -> Leads, It shows the analysis of leads. We can open the form view of every leads from the different views wise 'Graph', 'Pivot' and 'Dashboard' except the 'List" view and its a bit odd. We should be able to open form view from corresponding leads from the list view Also Currently the view which is coming in the current 'List' view is not correct and should be replaced by the same view which is rendered by action 'crm_lead_all_leads' SPECIFICATIONS 1. Initially we have to fix the correct list view to be rendered and that is 'crm_case_tree_view_leads' instead of 'crm_case_tree_view_oppor' 2. Next we have added the form view in addition to list view in view_ids of the corresponding action. This is the goal of this commit. LINKS PR #69174 Task 2497936
Code cleanup and technical improvements
This change rewrites an internal part of the base system that loads view definitions from files, making the code easier to understand and maintain. It should not change day-to-day user behavior, but it can help reduce future maintenance risk for the platform.
Original PR description
I had troubles understanding how was the function working, I decided to rework it a bit, ended up rewritting much of it. I hope this new implementation is easier to understand. Task: 2463632
The CRM lead list can now include each lead's probability as a quality indicator, replacing the visibility previously provided by lead scores. The field is hidden by default but available to show, helping sales teams prioritize leads more easily.
Original PR description
PURPOSE With the removal of lead scores, the probability is now the tool we want users to see as their "quality indicator" for their leads. We thus need to display it. CURRENT In crm probability field is not displaying in lead tree view. TO BE With this commit, we now display probability field (optional="hide") in lead tree view. **TaskID: 2496347** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Ingenico payments can now be handled in two steps: first reserving the money on the customer's card, then charging it later when appropriate, such as at shipment. This gives businesses more flexibility and avoids taking full payment before goods are delivered.
Original PR description
Rather than doing a complete payment, first authorize payment then proceed (capture) payment later (when shipping by example). Odoo only does full and manual capture at the moment as 1 - Odoo doesn't support partial payment 2 - Order could be sent in multiple delivery (would be a shame to capture full amount when you didn't send everything) 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
Stripe payments can now be authorized first and captured later, instead of charging the full amount immediately. This helps businesses align payment collection with order fulfillment, especially when deliveries happen in stages.
Original PR description
Rather than doing a full payment upon payment intent creation, Stripe offers to authorize the payment first, and then capture the (full/partial) amount later, when order is sent, by example. Odoo only does full and manual capture at the moment as 1 - Odoo doesn't support partial payment 2 - Order could be sent in multiple delivery (would be a shame capture full amount when you didn't send everything) 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
This fix prevents automatic prediction from running when invoices are imported through electronic invoicing formats. This helps avoid incorrect suggested values being applied during imports, improving reliability for accounting teams.
Original PR description
X-original-commit: 1502612c5d7f7516091e7e9dd2dba47cb0fccf25 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
This fixes an issue that prevented users from changing a product category's reference unit of measure in stock-related workflows. It helps businesses correct unit setup mistakes without workarounds, improving consistency across sales, purchasing, inventory, and localization screens.
Original PR description
stock: allow change of reference unit of measure -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Products can now have their reference unit of measure changed when needed. This fixes a restriction that could block correct product setup and helps keep inventory and product data aligned with business needs.
Rental orders now set the default return date based on the rental duration configured for the product, instead of always using the next day. This helps staff and customers start with more accurate rental periods and reduces manual date corrections.
Original PR description
In the Rental module When a customer tries to add a product there is an
issue that at first-time default, pickup_date and return_date's difference
is one day only. So I fixed its return_date according to rental.pricing
model's fields which are unit and duration.
**Task-id : 2345323**The CRM Leads reporting list now uses the correct lead list view and lets users open individual lead records from it. This makes the list view behave consistently with graph, pivot, and dashboard views, reducing confusion when reviewing lead analysis.
Original PR description
PURPOSE
When we go to CRM -> Reporting -> Leads, It shows the analysis of leads. We
can open the form view of every leads from the different views wise 'Graph',
'Pivot' and 'Dashboard' except the 'List" view and its a bit odd. We should be able
to open form view from corresponding leads from the list view
Also Currently the view which is coming in the current 'List' view is not correct
and should be replaced by the same view which is rendered by action
'crm_lead_all_leads'
SPECIFICATIONS
1. Initially, we have to fix the correct list view to be rendered and that is
'crm_case_tree_view_leads' instead of 'crm_case_tree_view_oppor'
2. Next we have added the form view in addition to the list view in view_ids of
the corresponding action.
I addition to this, we have added a sequence for ensuring the order of the existing view
switchers.
LINKS
PR #17655
Task 2497936What are the steps to reproduce your issue ? 1. Create Product with Purchase Vendor(s) set 2. Create Units of Measure that are bigger than (10kg/50kg in tests) What is currently happening ? If you put a vendor that is listed in product form, when changing purchase unit from kg to 10/50kg price is updated If you put a vendor not listed, it gives cost price which is correct, but does not update price according to unit of measure. What are you expecting to happen ?
Original PR description
What are the steps to reproduce your issue ?
1. Create Product with Purchase Vendor(s) set
2. Create Units of Measure that are bigger than (10kg/50kg in tests)
What is currently happening ?
If you put a vendor that is listed in product form, when changing purchase unit from kg to 10/50kg price is updated
If you put a vendor not listed, it gives cost price which is correct, but does not update price according to unit of measure.
What are you expecting to happen ?
Update correctly the unit of measure when the vendor is not listed
opw-2494769
Forward-Port-Of: odoo/odoo#69148Necessary Corrections for benefit in kind (ATN 17%) & Tax Report task-[2500543](https://www.odoo.com/web#id=2500543&model=project.task&view_type=form&cids=1&menu_id=) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69029 Forward-Port-Of: odoo/odoo#68969
Original PR description
Necessary Corrections for benefit in kind (ATN 17%) & Tax Report task-[2500543](https://www.odoo.com/web#id=2500543&model=project.task&view_type=form&cids=1&menu_id=) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69029 Forward-Port-Of: odoo/odoo#68969
Beforehand, if two users independently opened a draft invoice on their respective sessions, then both of them clicked on the "Post" button, then the invoice was posted twice. On a more general aspect, the view currently "prevents" users from posting moves several times, but technically speaking, nothing stops users from posting moves several times. Now, after checking that the user indeed has the right to post a move, the next check is about verifying that the move is not already post
Original PR description
Beforehand, if two users independently opened a draft invoice on their respective sessions, then both of them clicked on the "Post" button, then the invoice was posted twice. On a more general aspect, the view currently "prevents" users from posting moves several times, but technically speaking, nothing stops users from posting moves several times. Now, after checking that the user indeed has the right to post a move, the next check is about verifying that the move is not already posted. opw-2479201 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#69108 Forward-Port-Of: odoo/odoo#68473
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69183
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69183
Commit [1] recently fixed an issue with nested x2many fields and onchanges: in some cases, all field values weren't sent to the server as they should. However, there is a small issue with this fix. We didn't correctly apply the default value to option `changesOnly`: when not given, it was considered false, whereas in this particular function it should have been true. It caused an issue in the following scenario: Have a form view with an x2many field (say A) displayed as a list. In
Original PR description
Commit [1] recently fixed an issue with nested x2many fields and onchanges: in some cases, all field values weren't sent to the server as they should. However, there is a small issue with this fix.…
Commit [1] recently fixed an issue with nested x2many fields and onchanges: in some cases, all field values weren't sent to the server as they should. However, there is a small issue with this fix. We didn't correctly apply the default value to option `changesOnly`: when not given, it was considered false, whereas in this particular function it should have been true. It caused an issue in the following scenario: Have a form view with an x2many field (say A) displayed as a list. In the list, there is another x2many field (say B), and (whatever its type) a field C with an onchange. When the user changes C, the onchange is performed, and we send to the server the value of all fields. In particular, in the row, we send the value for the many2one field pointing to the main record (the inverse field of the x2many relation). The value for that field is basically the whole record, containing itself field A. For field A, the value is a list of commands, and for the updated record, it is a command 1 Before this commit, in the values sent for this command, field B was the empty array, even if it wasn't empty. This issue was reproducible in account.move, on an existing record having already a line in invoice_line_ids (this is field A). In that line, tax_ids (this is field B) must have a tax which is included in the price. When changing the quantity of the product, the subtotal wasn't correctly computed. [1] https://github.com/odoo/odoo/commit/a8b43d02066b2299ac2f4b88056c37725e9ce6cd opw~2489755 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#69167
https://github.com/odoo/odoo/pull/68253 fixed a bug in check_vat that caused it not to run any check when called on a partner with no country. However, doing this caused another issue because of an ORM limitation: when writing vat and country_id with a single write() on the res.company, two distinct write are triggered on the related res.partner, one for each field. Both those write trigger the check_vat constraint. Depending on the order in which the keys of the dictionnary passed to res.
Original PR description
https://github.com/odoo/odoo/pull/68253 fixed a bug in check_vat that caused it not to run any check when called on a partner with no country. However, doing this caused another issue because of an…
https://github.com/odoo/odoo/pull/68253 fixed a bug in check_vat that caused it not to run any check when called on a partner with no country. However, doing this caused another issue because of an ORM limitation: when writing vat and country_id with a single write() on the res.company, two distinct write are triggered on the related res.partner, one for each field. Both those write trigger the check_vat constraint. Depending on the order in which the keys of the dictionnary passed to res.company's write were ordered, country_id could or could not be written before vat. If vat was written first and did not start with a country code, the write() on res.partner failed the constraint, because country_id wasn't set yet. This was wrong, but used to pass as there was no country_id on the partner, before https://github.com/odoo/odoo/pull/68253 fixed that. To circumvent the issue, we now allow entering any vat number without performing any check if it does not start with a country code and no country_id is set on the partner. 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#69054 Forward-Port-Of: odoo/odoo#68896
This commit fixes an invalid leaf in join route Follows up: https://github.com/odoo/odoo/pull/68022 LINKS: TaskID: 2499471 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69103
Original PR description
This commit fixes an invalid leaf in join route Follows up: https://github.com/odoo/odoo/pull/68022 LINKS: TaskID: 2499471 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69103
PURPOSE currently, in fetchmail while create an incoming mail server, Set a server name while being in POP or IMAP server type and Switch to "Local" server type the server name is erased. SPECIFICATION for this we are removing server name field from the onchange_server_type method. with this commit, the value of the server name should not be erase with onchange. TaskId: 2258523 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwa
Original PR description
PURPOSE currently, in fetchmail while create an incoming mail server, Set a server name while being in POP or IMAP server type and Switch to "Local" server type the server name is erased. SPECIFICATION for this we are removing server name field from the onchange_server_type method. with this commit, the value of the server name should not be erase with onchange. TaskId: 2258523 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69125
In a subcontracting flow, a production order is created to reflect the subcontractor work. An extra cost is set on this production order corresponding to the purchase order line price unit. If the subcontracting product is tracked, we may create some backorder to save all the lot/serial numbers. As the extra_cost is not copied, the first lot/serial number will have the corresponding stock valuation layer with the correct quantity. The following ones will only have the cost of the componen
Original PR description
In a subcontracting flow, a production order is created to reflect the subcontractor work. An extra cost is set on this production order corresponding to the purchase order line price unit. If the subcontracting product is tracked, we may create some backorder to save all the lot/serial numbers. As the extra_cost is not copied, the first lot/serial number will have the corresponding stock valuation layer with the correct quantity. The following ones will only have the cost of the components as value. opw: 2487450 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#69195
Issue - Install "Sale" app - Activate "Discounts" feature in settings - Create a quotation to a portal user (ex: Joel Willis) - Add a product with a discount then send - Logout then login as 'Joel Willis' - Go to 'My account' then 'Quotations' - Select the quotation just created and print it Discount not display in pdf file. Cause The current env.user when rendering pdf is the portal user. To display discount, current env.user must have group 'product.group_discoun
Original PR description
Issue - Install "Sale" app - Activate "Discounts" feature in settings - Create a quotation to a portal user (ex: Joel Willis) - Add a product with a discount then send - Logout then login as 'Joel Willis' - Go to 'My account' then 'Quotations' - Select the quotation just created and print it Discount not display in pdf file. Cause The current env.user when rendering pdf is the portal user. To display discount, current env.user must have group 'product.group_discount_per_so_line' who is not the case even when using sudo() on report template. Solution Since Odoo 13.0, the sudo() function does not return the superuser by default but instead the current user with a bypass on access rights. Therefore, must add `.with_user(SUPERUSER_ID)` on report. opw-2501337 Forward-Port-Of: odoo/odoo#69143
Inspired from http://www.datypic.com/sc/ubl21/e-cac_PaymentMeans.html opw:2468492 Forward-Port-Of: odoo/odoo#69168 Forward-Port-Of: odoo/odoo#69124
Original PR description
Inspired from http://www.datypic.com/sc/ubl21/e-cac_PaymentMeans.html opw:2468492 Forward-Port-Of: odoo/odoo#69168 Forward-Port-Of: odoo/odoo#69124
opw-[2504435](https://www.odoo.com/web#action=333&active_id=49&cids=1&id=2504435&menu_id=4720&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#17614
Original PR description
opw-[2504435](https://www.odoo.com/web#action=333&active_id=49&cids=1&id=2504435&menu_id=4720&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#17614
Main - Most of the time Banxico, in the latest dates is only providing the USD currency rate and leaving out the other currencies. This PR will allow to skip the All-or-Nothing approach in updating Banxico currency rates The cron runs only once a day and won't run again if manually run until next date or if you have some technical skills. This PR addresses the problem arisen by the commit: https://github.com/odoo/enterprise/commit/795aeaee63f that was merged from PR: https://gi
Original PR description
Main - Most of the time Banxico, in the latest dates is only providing the USD currency rate and leaving out the other currencies. This PR will allow to skip the All-or-Nothing approach in updating Banxico currency rates The cron runs only once a day and won't run again if manually run until next date or if you have some technical skills. This PR addresses the problem arisen by the commit: https://github.com/odoo/enterprise/commit/795aeaee63f that was merged from PR: https://github.com/odoo/enterprise/pull/8704 This is a more aggresive change that the proposed one in the commit https://github.com/odoo/enterprise/commit/1366e621bdbf91d76723903f486169fc49599844 OPW - V13: 2495093 2495095 2495100 V12 2495096 2495098 2488924 Forward-Port-Of: odoo/enterprise#17217
account.generic.tax.report's _get_options() removes the multicompany key from the options if a config parameter is not set (by default, tax report is monocompany ; this parameter is only there to support VAT units). It's done after calling super(), so the filters are initialized with the multicompany key (by the super call); we can't rely on it in them. Forward-Port-Of: odoo/enterprise#17676
Original PR description
account.generic.tax.report's _get_options() removes the multicompany key from the options if a config parameter is not set (by default, tax report is monocompany ; this parameter is only there to support VAT units). It's done after calling super(), so the filters are initialized with the multicompany key (by the super call); we can't rely on it in them. Forward-Port-Of: odoo/enterprise#17676
Due to this missing parameter, trying to cancel an event that is due too soon to be cancelled would cause a missing parameter error. This fix follows up this PR: https://github.com/odoo/enterprise/pull/17141 LINKS: TaskID: 2499471 Forward-Port-Of: odoo/enterprise#17498
Original PR description
Due to this missing parameter, trying to cancel an event that is due too soon to be cancelled would cause a missing parameter error. This fix follows up this PR: https://github.com/odoo/enterprise/pull/17141 LINKS: TaskID: 2499471 Forward-Port-Of: odoo/enterprise#17498
Beforehand, if two users independently opened a draft invoice on their respective sessions, then both of them clicked on the "Post" button, then the invoice was posted twice. On a more general aspect, the view currently "prevents" users from posting moves several times, but technically speaking, nothing stops users from posting moves several times. Now, after checking that the user indeed has the right to post a move, the next check is about verifying that the move is not already post
Original PR description
Beforehand, if two users independently opened a draft invoice on their respective sessions, then both of them clicked on the "Post" button, then the invoice was posted twice. On a more general aspect, the view currently "prevents" users from posting moves several times, but technically speaking, nothing stops users from posting moves several times. Now, after checking that the user indeed has the right to post a move, the next check is about verifying that the move is not already posted. opw-2479201 Forward-Port-Of: odoo/enterprise#17615 Forward-Port-Of: odoo/enterprise#17503
Currently, when go to project > edit 'office design' > change its name > save. the user is blocked because the timesheet product is not set. So in this commit, Make the timesheet product required based on condition as it's not always required. now the timesheet_product_id field is only required for fsm project which is billable and allows timesheets. TaskID: 2459782 Forward-Port-Of: odoo/enterprise#17584 Forward-Port-Of: odoo/enterprise#17252
Original PR description
Currently, when go to project > edit 'office design' > change its name > save. the user is blocked because the timesheet product is not set. So in this commit, Make the timesheet product required based on condition as it's not always required. now the timesheet_product_id field is only required for fsm project which is billable and allows timesheets. TaskID: 2459782 Forward-Port-Of: odoo/enterprise#17584 Forward-Port-Of: odoo/enterprise#17252
Forward-Port-Of: odoo/enterprise#17468 Forward-Port-Of: odoo/enterprise#17273
Original PR description
Forward-Port-Of: odoo/enterprise#17468 Forward-Port-Of: odoo/enterprise#17273
The issue: 'FRST' is the code use for the first transaction. Every following transaction should have the code 'RCUR'. Moreover, since 2016, 'FRST' isn't even required anymore. The fix: Simply replace 'FRST' by 'RCUR' Ticket: \#2490238 Forward-Port-Of: odoo/enterprise#17640 Forward-Port-Of: odoo/enterprise#17595
Original PR description
The issue: 'FRST' is the code use for the first transaction. Every following transaction should have the code 'RCUR'. Moreover, since 2016, 'FRST' isn't even required anymore. The fix: Simply replace 'FRST' by 'RCUR' Ticket: \#2490238 Forward-Port-Of: odoo/enterprise#17640 Forward-Port-Of: odoo/enterprise#17595