Wednesday, September 9, 2020
38 changes · master
Resolved issues and error corrections
Inventory records for the same product and location can now be merged even when their arrival dates differ. This prevents duplicate stock quantity records from lingering and helps keep inventory data cleaner and easier to reconcile.
Original PR description
**Description of the issue/feature this PR addresses:** When there are no sql conflict the same quant is used, even of `in_date` is different. `_update_available_quantity`…
**Description of the issue/feature this PR addresses:** When there are no sql conflict the same quant is used, even of `in_date` is different. `_update_available_quantity` https://github.com/odoo/odoo/blob/12.0/addons/stock/models/stock_quant.py#L209, Odoo use an existing quants without worring `in_date` (and use `min()` during python merge). Indeed `_gather` `in_date` is not used to find quant (only used to use in `ORDER BY`) https://github.com/odoo/odoo/blob/12.0/addons/stock/models/stock_quant.py#L111. It should be logical to don't group by `in_date` during merge quants. **Current behavior before PR:** Create two quants with same `product_id`, `location_id`, `company_id`, `lot_id`, `package_id`, `owner_id` but with different `in_date`. (it is possible if https://github.com/odoo/odoo/blob/12.0/addons/stock/models/stock_quant.py#L223) Try to merge quants --> issue quants is not merge Desired behavior after PR is merged: quants merge Note : can be merged in master. @amoyaux @nim-odoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Steps to reproduce the bug: - Let's create a new company C with the name = "Company.name" - Create a new journal in C Bug: A UserError was raised saying: You cannot use anything else than unaccented latin characters in the alias address. opw:2321023 Forward-Port-Of: odoo/odoo#56675 Forward-Port-Of: odoo/odoo#56575
Original PR description
Steps to reproduce the bug: - Let's create a new company C with the name = "Company.name" - Create a new journal in C Bug: A UserError was raised saying: You cannot use anything else than unaccented latin characters in the alias address. opw:2321023 Forward-Port-Of: odoo/odoo#56675 Forward-Port-Of: odoo/odoo#56575
When we send dates with website_form, if the language of the website is eg. in arabic we will send moment.js arabic dates that can't be parsed by the server. This also happens with norwegian and any language which doesn't use ascii numbers or textual format of month or days (and possibly RTL language). With this changeset, if we detect we are in a use case where this matter (an existing field and a date format that will fail) the date will be sent as odoo server format. Expected c
Original PR description
When we send dates with website_form, if the language of the website is eg. in arabic we will send moment.js arabic dates that can't be parsed by the server. This also happens with norwegian and any language which doesn't use ascii numbers or textual format of month or days (and possibly RTL language). With this changeset, if we detect we are in a use case where this matter (an existing field and a date format that will fail) the date will be sent as odoo server format. Expected change: - what worked still work with or without server restart - what didn't work works after server restart - special case such as "english" with custom format in res.language containing textual month might now not work with code update without server restart (probability of this is low). opw-2326882 Forward-Port-Of: odoo/odoo#57214 Forward-Port-Of: odoo/odoo#57042
Since the saas-13.3 account.move.type has been renamed to account.move.move_type, but there are still two places where move.type is missused. This commit will correct one of them. task id #2320980 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56229
Original PR description
Since the saas-13.3 account.move.type has been renamed to account.move.move_type, but there are still two places where move.type is missused. This commit will correct one of them. task id #2320980 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56229
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#56311
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#56311
- Install "purchase_requisition" - Go to Inventory > Settings and activate "Units of Measure" - Go to Purchase > Purchase Agreements and create one: * select a product and remove UOM - Confirm it and click on "NEW QUOTATION" An exception occurs with the following message: "ValueError: Expected singleton: uom.uom()" "product_uom_id" field of "purchase.requisition.line" model should be required. opw-2332654 Description of the issue/feature this PR addresses: Current behavior be
Original PR description
- Install "purchase_requisition" - Go to Inventory > Settings and activate "Units of Measure" - Go to Purchase > Purchase Agreements and create one: * select a product and remove UOM - Confirm it and click on "NEW QUOTATION" An exception occurs with the following message: "ValueError: Expected singleton: uom.uom()" "product_uom_id" field of "purchase.requisition.line" model should be required. opw-2332654 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#57209 Forward-Port-Of: odoo/odoo#57194
Removing default read/write access rights on Calendar Attendee Information for Portal User. opw-2325322 Forward-Port-Of: odoo/odoo#57180
Original PR description
Removing default read/write access rights on Calendar Attendee Information for Portal User. opw-2325322 Forward-Port-Of: odoo/odoo#57180
The helper message has been changed in the following menus: -My reports -Expense Reports To Approve -All Expense Reports -Expenses Analysis Task-2320205 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#56733
Original PR description
The helper message has been changed in the following menus: -My reports -Expense Reports To Approve -All Expense Reports -Expenses Analysis Task-2320205 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#56733
There is a bug where the currency field is always visible/editable in the account_move view, even when multi_currency is disabled. This commit fix that issue. Task id #2318610 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56222
Original PR description
There is a bug where the currency field is always visible/editable in the account_move view, even when multi_currency is disabled. This commit fix that issue. Task id #2318610 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56222
this commit removes unnecessary uppercase used under the favorites menu task - 2325684 Forward-Port-Of: odoo/odoo#56545
Original PR description
this commit removes unnecessary uppercase used under the favorites menu task - 2325684 Forward-Port-Of: odoo/odoo#56545
Let's assume a kanban view using a custom form view to quick create record: <kanban on_create="quick_create" quick_create_view="view_ref"> Before this commit, there was a raise condition that could lead to a crash. For instance, click to quick create a record in a given column, and while the form view is loading, fold the column. Issue reported on task 2323196 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Original PR description
Let's assume a kanban view using a custom form view to quick create record: <kanban on_create="quick_create" quick_create_view="view_ref"> Before this commit, there was a raise condition that could lead to a crash. For instance, click to quick create a record in a given column, and while the form view is loading, fold the column. Issue reported on task 2323196 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#57228
Steps to reproduce: - Let's consider a product.template TP with a kit - Let's consider the variants V1, the only variant of TP with a kit - The virtual_availalbe of V1 is 100 (smart button Forecasted in the form view) Bug: The virtual_available of TP was 0 instead of 100 The virtaul_available of a product.template must be the sum of virtual_available of all its variants with kit opw:2297226 Forward-Port-Of: odoo/odoo#57177 Forward-Port-Of: odoo/odoo#55575
Original PR description
Steps to reproduce: - Let's consider a product.template TP with a kit - Let's consider the variants V1, the only variant of TP with a kit - The virtual_availalbe of V1 is 100 (smart button Forecasted in the form view) Bug: The virtual_available of TP was 0 instead of 100 The virtaul_available of a product.template must be the sum of virtual_available of all its variants with kit opw:2297226 Forward-Port-Of: odoo/odoo#57177 Forward-Port-Of: odoo/odoo#55575
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#57225
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#57225
Some informations for the developpers do not fit in the technical documentation. To solve this, we opened a new documentation page on iap.odoo.com and this commit adds a reference to the said documentation. task - 2330046 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57169 Forward-Port-Of: odoo/odoo#57080
Original PR description
Some informations for the developpers do not fit in the technical documentation. To solve this, we opened a new documentation page on iap.odoo.com and this commit adds a reference to the said documentation. task - 2330046 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57169 Forward-Port-Of: odoo/odoo#57080
When we send dates with website_form, if the language of the website is eg. in arabic we will send moment.js arabic dates that can't be parsed by the server. This also happens with norwegian and any language which doesn't use ascii numbers or textual format of month or days (and possibly RTL language). With this changeset, if we detect we are in a use case where this matter (an existing field and a date format that will fail) the date will be sent as odoo server format. Expected c
Original PR description
When we send dates with website_form, if the language of the website is eg. in arabic we will send moment.js arabic dates that can't be parsed by the server. This also happens with norwegian and any language which doesn't use ascii numbers or textual format of month or days (and possibly RTL language). With this changeset, if we detect we are in a use case where this matter (an existing field and a date format that will fail) the date will be sent as odoo server format. Expected change: - what worked still work with or without server restart - what didn't work works after server restart - special case such as "english" with custom format in res.language containing textual month might now not work with code update without server restart (probability of this is low). opw-2326882 Forward-Port-Of: odoo/odoo#57161 Forward-Port-Of: odoo/odoo#57042
Steps to reproduce the bug: - On Safari, go to Module Repair - Create a Repair Order - Add a new line L - A default type Add was set - Set a product P on L Bug: The default value was reset opw:2319954 Forward-Port-Of: odoo/odoo#57291 Forward-Port-Of: odoo/odoo#57255
Original PR description
Steps to reproduce the bug: - On Safari, go to Module Repair - Create a Repair Order - Add a new line L - A default type Add was set - Set a product P on L Bug: The default value was reset opw:2319954 Forward-Port-Of: odoo/odoo#57291 Forward-Port-Of: odoo/odoo#57255
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56000
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#56000
This commit does 2 things: 1. When 'action_confirm' is triggered in a manufacturing order, any 'move_raw_ids' (components) that are unable to be fully reserved when `action_assign` is triggered will be checked for an automatic reordering rule (RR). If a rule exists it will be auto-triggered. This includes subcontractor manufacturing orders. Relevant test updated to match this. 2. When a MO is completed, auto check if there are corresponding confirmed stock moves that
Original PR description
This commit does 2 things: 1. When 'action_confirm' is triggered in a manufacturing order, any 'move_raw_ids' (components) that are unable to be fully reserved when `action_assign` is triggered will…
This commit does 2 things: 1. When 'action_confirm' is triggered in a manufacturing order, any 'move_raw_ids' (components) that are unable to be fully reserved when `action_assign` is triggered will be checked for an automatic reordering rule (RR). If a rule exists it will be auto-triggered. This includes subcontractor manufacturing orders. Relevant test updated to match this. 2. When a MO is completed, auto check if there are corresponding confirmed stock moves that can be populated by the completed products and trigger their 'action_assign' to reserve the completed products. This reuses similar logic as odoo/odoo#52433 from task 2244230. Originally this was done in the `action_assign`, but has been moved to `action_confirm` so as to imitate the now archived MTO process with RR. Overlapping logic has been moved into stock_move for easier reusability. Note moving auto-trigger logic to `action_confirm` means newly added move lines will have scheduler auto-trigger occur for them, but existing move lines with changed `product_uom_qty` (i.e. Demand) will not have a way to auto-trigger their RR Subcontracting test updated to match + new mrp test added for this new feature. Task: 2322496 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#57174
In this commit, we ensure that the vat is added to the company data if an error occured when contacting iap-services. task~2092378 Author: ndeodoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57233
Original PR description
In this commit, we ensure that the vat is added to the company data if an error occured when contacting iap-services. task~2092378 Author: ndeodoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57233
Orderpoint qtys were not updating when an already saved stock.move has its demand updated. This was leading to new orderpoints being created when there is already an existing one. This commit fixes this bug by adding the missing dependency. Steps to reproduce: - Create a product - Create a delivery with the product > Mark As Todo - Go to replenishment report (product should be added) - Go back to same delivery > unlock > increase the existing move line demand amount - Return to rep
Original PR description
Orderpoint qtys were not updating when an already saved stock.move has its demand updated. This was leading to new orderpoints being created when there is already an existing one. This commit fixes this bug by adding the missing dependency. Steps to reproduce: - Create a product - Create a delivery with the product > Mark As Todo - Go to replenishment report (product should be added) - Go back to same delivery > unlock > increase the existing move line demand amount - Return to replenishment report. product now has 2 orderpoints instead of just 1. Additionally this commit fixes a column mislabeling in the "Reordering Rules" tree so that it now matches the "Replenishment" tree Task: 2327726 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56722
This issue only occurred in community. Steps to produce: 1) Create/Edit any record. 2) Change the menu using menu switcher 3) You will get the discard dialog at the instance and after some time it will also display another duplicate discard dialog. So, we have one extra redundant discard dialog on menu switching. It is working fine when we have dirty form and then click on the breadcrumb or click on any internal child menu. Task : 2312437 Co-authored-by: Mohammed Shekha <msh@o
Original PR description
This issue only occurred in community. Steps to produce: 1) Create/Edit any record. 2) Change the menu using menu switcher 3) You will get the discard dialog at the instance and after some time it will also display another duplicate discard dialog. So, we have one extra redundant discard dialog on menu switching. It is working fine when we have dirty form and then click on the breadcrumb or click on any internal child menu. Task : 2312437 Co-authored-by: Mohammed Shekha <msh@odoo.com> Co-authored-by: Aaron Bohy <aab@odoo.com> 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#57343
Steps to reproduce: - Create a product P with route 'Resupply subcontractor on an order' - Let's consider a BOM for P with type 'Subcontracting' - Create a PO with subcontractor set on that product and process with Qty > 1, - Validate a receipt with partial Qty and no backorder Bug: An error was raised because no production_id was set when trying to create a mrp.product.produce When function _action_done is called with cancel_backorder = True, the function _action_cancel is called
Original PR description
Steps to reproduce: - Create a product P with route 'Resupply subcontractor on an order' - Let's consider a BOM for P with type 'Subcontracting' - Create a PO with subcontractor set on that product…
Steps to reproduce:
- Create a product P with route 'Resupply subcontractor on an order'
- Let's consider a BOM for P with type 'Subcontracting'
- Create a PO with subcontractor set on that product and process with Qty > 1,
- Validate a receipt with partial Qty and no backorder
Bug:
An error was raised because no production_id was set when trying to create a mrp.product.produce
When function _action_done is called with cancel_backorder = True, the function _action_cancel is called on the new_move
with no backorder and it called the function _action_cancel defined on model stock.move in module mrp_subcontracting
This function called _action_cancel on the mrp.production record MP
And finally this function called action_cancel on model stock.move on all finish_moves and raw_moves of MP
This line unlink MP of finish_moves and raw_moves
move.move_dest_ids.write({'move_orig_ids': [(3, move.id, 0)]})
That's why production_id was not set
opw:2322278
Forward-Port-Of: odoo/odoo#57198Since 0bee745c36c3cf8c411ffb65fab66ebd005ae274, flags images are not stored anymore on the res.country model. This commit adapts exhibitors templates to correctly use the new "image_url" field instead of the old "web/image/" route that tries to access the image on the model. Task ID: 2336225 Forward-Port-Of: odoo/odoo#57330
Original PR description
Since 0bee745c36c3cf8c411ffb65fab66ebd005ae274, flags images are not stored anymore on the res.country model. This commit adapts exhibitors templates to correctly use the new "image_url" field instead of the old "web/image/" route that tries to access the image on the model. Task ID: 2336225 Forward-Port-Of: odoo/odoo#57330
improve usability of empty screen -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#55910
Original PR description
improve usability of empty screen -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#55910
This commit fix a style issue with the button to edit the message displayed at the end of the countdown task-2312878 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#57354
Original PR description
This commit fix a style issue with the button to edit the message displayed at the end of the countdown task-2312878 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#57354
To transfer an order from one table to another, we first select the order, then we click the 'transfer button', then we are shown the table selection. The moment we click the 'transfer button', two simultaneous rpc's are made for the same method (`create_from_ui`). This method deletes and recreates the orderlines in database. The 2nd request fails because of the deletion. But despite the failure, the server retries the rpc after a random amount of time in sec: `wait_time = random.uniform(0
Original PR description
To transfer an order from one table to another, we first select the order, then we click the 'transfer button', then we are shown the table selection. The moment we click the 'transfer button', two…
To transfer an order from one table to another, we first select the order, then we click the 'transfer button', then we are shown the table selection. The moment we click the 'transfer button', two simultaneous rpc's are made for the same method (`create_from_ui`). This method deletes and recreates the orderlines in database. The 2nd request fails because of the deletion. But despite the failure, the server retries the rpc after a random amount of time in sec: `wait_time = random.uniform(0.0, 2 ** tries)`. If the user immediately (within the `wait_time`) clicks the new table where the order is to be placed, the problem happens - the transfer of order to the new table fails. This is because of the 3rd rpc whose result is used for the actual order transfer. If the 3rd rpc happens before the retry of the second, the transfer fails. The randomness of `wait_time` (time-to-retry rpc) results to the random runbot error. The solution is to prevent the 2nd (redundant) request because it is not actually needed. This commit tries to accomplish that. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57356
- Go to Timesheets > Configuration > Settings and select Days as Encoding Unit - Go to Project and create a Project with Timesheets activated - Open the created Project and create a Task - Edit the task and encode a timesheet line with 1 Day duration "Hours Spent" and "Remaining Hours" have incorrect values. The 1 day encoded is computed as 1 hour. Reverting: 2a7ec79 For the original issue (2301510), the UOM conversion is executed twice: - in "_compute_timesheet_total_duration" - in
Original PR description
- Go to Timesheets > Configuration > Settings and select Days as Encoding Unit - Go to Project and create a Project with Timesheets activated - Open the created Project and create a Task - Edit the…
- Go to Timesheets > Configuration > Settings and select Days as Encoding Unit - Go to Project and create a Project with Timesheets activated - Open the created Project and create a Task - Edit the task and encode a timesheet line with 1 Day duration "Hours Spent" and "Remaining Hours" have incorrect values. The 1 day encoded is computed as 1 hour. Reverting: 2a7ec79 For the original issue (2301510), the UOM conversion is executed twice: - in "_compute_timesheet_total_duration" - in "view_order_form_inherit_sale_timesheet" view via widget "timesheet_uom" As timesheets are always stored in Hours UOM, removing the conversion in "_compute_timesheet_total_duration" will always produce a total duration in Hours, without risk of mixing UOM issue. opw-2328603 opw-2301510 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#57361 Forward-Port-Of: odoo/odoo#57269
Remove this incoherent comment, and backport the dedicated section on bindings. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57375 Forward-Port-Of: odoo/odoo#57360
Original PR description
Remove this incoherent comment, and backport the dedicated section on bindings. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57375 Forward-Port-Of: odoo/odoo#57360
Forward-Port-Of: odoo/enterprise#13066 Forward-Port-Of: odoo/enterprise#13041
Original PR description
Forward-Port-Of: odoo/enterprise#13066 Forward-Port-Of: odoo/enterprise#13041
Improve empty screen usability Forward-Port-Of: odoo/enterprise#12414
Original PR description
Improve empty screen usability Forward-Port-Of: odoo/enterprise#12414
…ax base" This reverts commit 835086eb74ed67e66674975897ad9bf62182fa0d. In fact, this was all wrong. The rever is validated with our fiscal expert. Deducting partly the ONSS according to the IP rate is invalid a leads to a higher taxabled base (base imposable). The result is a more taxed wage, which is not a big deal, as this is an advance on the global taxes, and would result into a lower amount to reimburse to the state, or a higher amount to get back. But, as the goal is to st
Original PR description
…ax base" This reverts commit 835086eb74ed67e66674975897ad9bf62182fa0d. In fact, this was all wrong. The rever is validated with our fiscal expert. Deducting partly the ONSS according to the IP rate is invalid a leads to a higher taxabled base (base imposable). The result is a more taxed wage, which is not a big deal, as this is an advance on the global taxes, and would result into a lower amount to reimburse to the state, or a higher amount to get back. But, as the goal is to stick with what the employee is supposed to pay according to the laws, revert this commit in order to stick with how the other social secretariats are computing the payslips in Belgium. Forward-Port-Of: odoo/enterprise#13061 Forward-Port-Of: odoo/enterprise#12929
Issue - Install "Subscriptions" module. - Create Subscription; ensure 'Payment Mode' is set to 'Manually' and set 'End Date' to a date before now/today (these fields are invisible, use studio to make them visible). - Set to stage "In progress". - Click on "Close" button and give any reason. - Set back to stage "In progress". - Click on "Create Invoice". Stage change directly to "Closed" without generating an invoice. Cause If we reach the end date of the subscrip
Original PR description
Issue - Install "Subscriptions" module. - Create Subscription; ensure 'Payment Mode' is set to 'Manually' and set 'End Date' to a date before now/today (these fields are invisible, use studio to make them visible). - Set to stage "In progress". - Click on "Close" button and give any reason. - Set back to stage "In progress". - Click on "Create Invoice". Stage change directly to "Closed" without generating an invoice. Cause If we reach the end date of the subscription then we close it and avoid to charge it. This logic was implemented for cron process. Solution If not in cron, do not close subscription, even if date <= current_date. Related fix : https://github.com/odoo/enterprise/commit/d21fef5d10df80cc8e54c1f8b70f7902456ab2cf opw-2333068 Forward-Port-Of: odoo/enterprise#13038 Forward-Port-Of: odoo/enterprise#13022
A flush in _compute_from_moves() is flushing everything, instead of only the intended model. The commit will fix it. See pr : #12780 Forward-Port-Of: odoo/enterprise#13044
Original PR description
A flush in _compute_from_moves() is flushing everything, instead of only the intended model. The commit will fix it. See pr : #12780 Forward-Port-Of: odoo/enterprise#13044
[IMP] uom: change defualt rounding to two Change the defualt rouning digits of all UoMs to be two, also change the decimal.precision of UoM to be two. Adapt all the tests. com PR odoo/odoo#56000 Forward-Port-Of: odoo/enterprise#12454
Original PR description
[IMP] uom: change defualt rounding to two Change the defualt rouning digits of all UoMs to be two, also change the decimal.precision of UoM to be two. Adapt all the tests. com PR odoo/odoo#56000 Forward-Port-Of: odoo/enterprise#12454
…tal status box Currently, In salary configurator form when we select married in the marital status box then form can not be submited. So in this commit, we improved the variable of requiredEmptyInput. LINKS PR: #12445 Task-Id: 2314164 Forward-Port-Of: odoo/enterprise#12445
Original PR description
…tal status box Currently, In salary configurator form when we select married in the marital status box then form can not be submited. So in this commit, we improved the variable of requiredEmptyInput. LINKS PR: #12445 Task-Id: 2314164 Forward-Port-Of: odoo/enterprise#12445
Steps to reproduce the bug: - Let's consider a subscription template ST with invoice manually - Let's consider A, the delivery address of customer C - Let's consider B, an other delivery address - Create a SO with C and change its delivery address to B - Add ST on the SO and confirm it - Go to the generated subscription S and create the invoice I Bug: The delivery address set on I was A instead of B opw:2328920 Forward-Port-Of: odoo/enterprise#12900 Forward-Port-Of: odoo/enterp
Original PR description
Steps to reproduce the bug: - Let's consider a subscription template ST with invoice manually - Let's consider A, the delivery address of customer C - Let's consider B, an other delivery address - Create a SO with C and change its delivery address to B - Add ST on the SO and confirm it - Go to the generated subscription S and create the invoice I Bug: The delivery address set on I was A instead of B opw:2328920 Forward-Port-Of: odoo/enterprise#12900 Forward-Port-Of: odoo/enterprise#12850
Purpose ======= Fix some bugs related to the social application 1. Archive a Facebook or a Twitter account, then open a social post in the feed view. An error will be raised 2. When posting on multiple social accounts, a note is created in the chatter of the social post. This note is posted many time. 3. Sometimes, we can not fetch the author name/picture/id of a comment. In that case, when we try to open the comment, an error is raised. 4. On the feed view, you can upload one image with
Original PR description
Purpose ======= Fix some bugs related to the social application 1. Archive a Facebook or a Twitter account, then open a social post in the feed view. An error will be raised 2. When posting on multiple social accounts, a note is created in the chatter of the social post. This note is posted many time. 3. Sometimes, we can not fetch the author name/picture/id of a comment. In that case, when we try to open the comment, an error is raised. 4. On the feed view, you can upload one image with your comment. If you select nothing in the files manager, an error can be raised 5. An error on replies when editing a comment 6. Remove the "No Comment" message when posting a comment. 7. When we add a Twitter stream some errors might occurs. In that case, a traceback is raised instead of showing an error message. Task-2291254 Forward-Port-Of: odoo/enterprise#12877 Forward-Port-Of: odoo/enterprise#11941
Since the saas-13.3 account.move.type has been renamed to account.move.move_type, but there are still two places where move.type is missused. This commit will correct one of them. task id #2320980 Forward-Port-Of: odoo/enterprise#12545
Original PR description
Since the saas-13.3 account.move.type has been renamed to account.move.move_type, but there are still two places where move.type is missused. This commit will correct one of them. task id #2320980 Forward-Port-Of: odoo/enterprise#12545