Wednesday, September 23, 2020
36 changes · master
Enhancements to existing features
Approval requests now use a shared Odoo mechanism to show approve and refuse actions in activity areas such as chatter and kanban. This makes the feature easier to maintain while preserving the same user-facing workflow for handling approvals.
Original PR description
Task ID : https://www.odoo.com/web#id=1919303&action=333&active_id=131&model=project.task&view_type=form&menu_id=4720 Pad Link : https://pad.odoo.com/p/r.9e70128cbe09aa2e354cc50fcaad4f92 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Deleting a currency now also removes its related exchange rate records. This prevents leftover rate data that no longer has a valid currency, keeping business data cleaner and reducing confusion.
Original PR description
Also, what the point of a rate without currency?
Miscellaneous changes
This was removed in https://github.com/odoo/odoo/commit/5275f16f2497c2a7c50d9f9b225b7b51b4885384 due to `addons/web_editor/static/src/js/editor/rte.summernote.js` file has been removed in f296992 the `addons/web_editor/static/src/js/editor/rte.summernote.js` file has reverted in this commit https://github.com/odoo/odoo/commit/35b61822a8b12ebbdb455495479df6f2e13db03e due to these reverted changes, we have to restore the onUpload option. now, the user will be able to add a record into the
Original PR description
This was removed in https://github.com/odoo/odoo/commit/5275f16f2497c2a7c50d9f9b225b7b51b4885384 due to `addons/web_editor/static/src/js/editor/rte.summernote.js` file has been removed in f296992 the `addons/web_editor/static/src/js/editor/rte.summernote.js` file has reverted in this commit https://github.com/odoo/odoo/commit/35b61822a8b12ebbdb455495479df6f2e13db03e due to these reverted changes, we have to restore the onUpload option. now, the user will be able to add a record into the "ir.attachment" field found in the view, when an image is uploaded via the media dialog. this allows people to add an attachment with the content editor interfaces and that they appear in the attachment list. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#58230 Forward-Port-Of: odoo/odoo#54964
The employee form now hides the chat icon when a record is being edited. This prevents visual clutter under the employee name and keeps the editing experience cleaner for HR users.
Original PR description
Currently, the chat icon is displayed underneath the name when employees record is in edit mode. So in this commit, when employee record is in edit mode the chat icon should be hidden. Links PR #58320 TaskID: 2344588
Before that, making a misc operation with cash basis taxes always set the move lines as tax_exigible=False (or at least, it was supposed to, see below). This was wrong, as if the move did not contain any payable/receivable account, it would result in no cash basis move being ever created, and so the entry would never affect the tax report. Additionnally, the tax line was wrongly managed for cash basis taxes on misc entries, as vals.get('tax_ids') returned an ORM command, so a non-False value,
Original PR description
Before that, making a misc operation with cash basis taxes always set the move lines as tax_exigible=False (or at least, it was supposed to, see below). This was wrong, as if the move did not contain any payable/receivable account, it would result in no cash basis move being ever created, and so the entry would never affect the tax report.
Additionnally, the tax line was wrongly managed for cash basis taxes on misc entries, as vals.get('tax_ids') returned an ORM command, so a non-False value, even when the tax_ids field was empty. this caused the condition to execute and to reassign taxes to an empty list, which then caused tax_exigible not to be set to False, even when it should.
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#58231
Forward-Port-Of: odoo/odoo#57456This commit fixes a bunch of small issues on the session manager. - Use container-fluid to optimise the screen usage. - Align survey link to the survey container. - Reduce the size of progress bar to optimise available room for title. - Ensure attendees count is also updated when refreshing the results and progress bar. - Ensure the graph is correctly setup when there is no attendee yet. - Update y axis in chart when new attendee join the survey in the middle of a session. Task ID: 23
Original PR description
This commit fixes a bunch of small issues on the session manager. - Use container-fluid to optimise the screen usage. - Align survey link to the survey container. - Reduce the size of progress bar to optimise available room for title. - Ensure attendees count is also updated when refreshing the results and progress bar. - Ensure the graph is correctly setup when there is no attendee yet. - Update y axis in chart when new attendee join the survey in the middle of a session. Task ID: 2343508 Forward-Port-Of: odoo/odoo#58121
due to breaking changes in https://github.com/odoo/odoo/commit/bf32b22ce247c19fda94ded74e37f7c6120ce2c4 and especially the part: "NOTE 1. If the default_get within the onchange returns a value for a field that is not in the view, we ignore it, and it won't be saved. Before, that value was kept and sent upon save. This change in behavior may prove problematic, although the overall risk is small. Decision has been made to keep heavy comments and code snippets if we were to revert back
Original PR description
due to breaking changes in https://github.com/odoo/odoo/commit/bf32b22ce247c19fda94ded74e37f7c6120ce2c4 and especially the part: "NOTE 1. If the default_get within the onchange returns a value for a field that is not in the view, we ignore it, and it won't be saved. Before, that value was kept and sent upon save. This change in behavior may prove problematic, although the overall risk is small. Decision has been made to keep heavy comments and code snippets if we were to revert back somehow to the previous situation." the wizard to sending failures sms was broken as the field notification_id which is required was not present in the view and was thus ignored by to web client when calling 'create'. Task: https://www.odoo.com/web#id=2335273&action=4043&model=project.task&view_type=form&cids=2&menu_id=4720 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57912
The field `invoice_partner_bank_id` was renamed `partner_bank_id` 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#58238 Forward-Port-Of: odoo/odoo#58227
Original PR description
The field `invoice_partner_bank_id` was renamed `partner_bank_id` 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#58238 Forward-Port-Of: odoo/odoo#58227
If an user that only has access to accounting but not to sale, tries to validate an invoice created from a sale order, an access error will be raised. That's because, when the invoice status changes, the invoiced quantity on the related sale order is recomputed using the current user, which may not have access to read sale order lines. This commit fixes the above by ensuring the recomputation is performed with superuser access rights. -- I confirm I have signed the CLA and read the P
Original PR description
If an user that only has access to accounting but not to sale, tries to validate an invoice created from a sale order, an access error will be raised. That's because, when the invoice status changes, the invoiced quantity on the related sale order is recomputed using the current user, which may not have access to read sale order lines. This commit fixes the above by ensuring the recomputation is performed with superuser access rights. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#58239 Forward-Port-Of: odoo/odoo#57985
Passing a field containing `undefined` should lead to the same result as not passing the field. Fields that relied on `undefined` as a value have been changed to use the newly introduced `clear` command, that resets a field to its default value (often that is equal to `undefined`). task-2336491 Forward-Port-Of: odoo/odoo#57368
Original PR description
Passing a field containing `undefined` should lead to the same result as not passing the field. Fields that relied on `undefined` as a value have been changed to use the newly introduced `clear` command, that resets a field to its default value (often that is equal to `undefined`). task-2336491 Forward-Port-Of: odoo/odoo#57368
- The balance operation is performed automatically at the end of the day but it doesn't print any receipt. We add the possibility to perform the balance manually to get a receipt showing all the transactions of the day. - By default, DCC is set to true, but it requires a different implementation. As we don't support it, Six asked us to changed the variable to False, to make it clearer in case of debugging. -- I confirm I have signed the CLA and read the PR guidelines at www.odo
Original PR description
- The balance operation is performed automatically at the end of the day but it doesn't print any receipt. We add the possibility to perform the balance manually to get a receipt showing all the transactions of the day. - By default, DCC is set to true, but it requires a different implementation. As we don't support it, Six asked us to changed the variable to False, to make it clearer in case of debugging. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57957
Many customers wonder "Why does my filestore take so much disk space?". We display the size of the file (if available) in the technical list view available under Settings > Technical > Database > Attachments opw-2338830 Forward-Port-Of: odoo/odoo#58215
Original PR description
Many customers wonder "Why does my filestore take so much disk space?". We display the size of the file (if available) in the technical list view available under Settings > Technical > Database > Attachments opw-2338830 Forward-Port-Of: odoo/odoo#58215
task-2171885 Forward-Port-Of: odoo/odoo#57459
Original PR description
task-2171885 Forward-Port-Of: odoo/odoo#57459
Also, what the point of a rate without currency? Forward-Port-Of: odoo/odoo#58303
Original PR description
Also, what the point of a rate without currency? Forward-Port-Of: odoo/odoo#58303
task-2312878 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56276
Original PR description
task-2312878 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56276
Seems copy paste error from v12 Fix issue https://github.com/odoo/odoo/issues/58282 introduced by commit https://github.com/odoo/odoo/commit/95a6ef42a1f9bb53a074e906c9bd028dc182c686 in this PR https://github.com/odoo/odoo/pull/57724 @Tecnativa -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#58283
Original PR description
Seems copy paste error from v12 Fix issue https://github.com/odoo/odoo/issues/58282 introduced by commit https://github.com/odoo/odoo/commit/95a6ef42a1f9bb53a074e906c9bd028dc182c686 in this PR https://github.com/odoo/odoo/pull/57724 @Tecnativa -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#58283
task-2282327 Forward-Port-Of: odoo/odoo#58100
Original PR description
task-2282327 Forward-Port-Of: odoo/odoo#58100
- The balance operation is performed automatically at the end of the day but it doesn't print any receipt. We add the possibility to perform the balance manually to get a receipt showing all the transactions of the day. - By default, DCC is set to true, but it requires a different implementation. As we don't support it, Six asked us to changed the variable to False, to make it clearer in case of debugging. -- I confirm I have signed the CLA and read the PR guidelines at www.odo
Original PR description
- The balance operation is performed automatically at the end of the day but it doesn't print any receipt. We add the possibility to perform the balance manually to get a receipt showing all the transactions of the day. - By default, DCC is set to true, but it requires a different implementation. As we don't support it, Six asked us to changed the variable to False, to make it clearer in case of debugging. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#58311 Forward-Port-Of: odoo/odoo#57957
[FIX] mrp: installation on very large inventories Before this commit, installation of MRP in a database with 4.8M stock.move + 4.8M stock.move.line was not possible at all. The process lasted for a very long time (>90 min in our tests) then eventually failed after using the whole RAM of your server. This commit allows installing MRP in databases with large stock.move /stock.move.line tables by bootstrapping the slow parts in SQL. (A more general fix regarding the time complexity of som
Original PR description
[FIX] mrp: installation on very large inventories Before this commit, installation of MRP in a database with 4.8M stock.move + 4.8M stock.move.line was not possible at all. The process lasted for a…
[FIX] mrp: installation on very large inventories Before this commit, installation of MRP in a database with 4.8M stock.move + 4.8M stock.move.line was not possible at all. The process lasted for a very long time (>90 min in our tests) then eventually failed after using the whole RAM of your server. This commit allows installing MRP in databases with large stock.move /stock.move.line tables by bootstrapping the slow parts in SQL. (A more general fix regarding the time complexity of some parts of the prefetching algorithm is coming later in 13.0-init-computed-fields-rco) ----- [FIX] mrp: more Voodoo magic It appears that if you update a record more than once in the same PostgreSQL transaction, PostgreSQL is going to re-check all the constraints on the table. ** THIS IS THE PART WHERE THE BLACK MAGIC HAPPENS ** We combine the setting of the default value of stock.move.unit_factor in the same UPDATE query to avoid the constraint re-check; it saves approximately 60% of the SQL running time in my case. ** ... AND NOW YOU CAN SAY: WHAT THE F...?! ** Thanks to @rco-odoo for the tip; he knows it from the wise @nseinlet. ----- opw-[2281585](https://www.odoo.com/web?debug=1#id=2281585&action=3531&model=project.task&view_type=form&cids=&menu_id=4720) Forward-Port-Of: odoo/odoo#57850
Using this partner will copy his phone number on the lead. However, the lead and the partner don't have the same country, which will lead to ad invalid phone number (for the lead country). It avoids a warning emitted by the `phone_validator` module, while browsing the lead. Forward-Port-Of: odoo/odoo#58329 Forward-Port-Of: odoo/odoo#58301
Original PR description
Using this partner will copy his phone number on the lead. However, the lead and the partner don't have the same country, which will lead to ad invalid phone number (for the lead country). It avoids a warning emitted by the `phone_validator` module, while browsing the lead. Forward-Port-Of: odoo/odoo#58329 Forward-Port-Of: odoo/odoo#58301
When a bad promo code is entered on the "Extra steps" page, we are redirected on the "Confirm Order" (/shop/payment) page which might make the user miss extra steps page. opw-2339906 Forward-Port-Of: odoo/odoo#58338
Original PR description
When a bad promo code is entered on the "Extra steps" page, we are redirected on the "Confirm Order" (/shop/payment) page which might make the user miss extra steps page. opw-2339906 Forward-Port-Of: odoo/odoo#58338
Forward-Port-Of: odoo/odoo#58343
Original PR description
Forward-Port-Of: odoo/odoo#58343
task-2270731 Forward-Port-Of: odoo/odoo#58297
Original PR description
task-2270731 Forward-Port-Of: odoo/odoo#58297
When the pending value is the same as the current server value, the pending value should be ignored and no RPC should be done. In particular this prevents a non-main tab from calling the RPC when receiving a bus notification that would lead to closing a chat window, which in turn used to call the close RPC again before this commit. This led to inconsistencies especially on the main tab, if the chat window was requested to be open again after the initial close, but before the "secondary"
Original PR description
When the pending value is the same as the current server value, the pending value should be ignored and no RPC should be done. In particular this prevents a non-main tab from calling the RPC when…
When the pending value is the same as the current server value, the pending value should be ignored and no RPC should be done. In particular this prevents a non-main tab from calling the RPC when receiving a bus notification that would lead to closing a chat window, which in turn used to call the close RPC again before this commit. This led to inconsistencies especially on the main tab, if the chat window was requested to be open again after the initial close, but before the "secondary" close, it would end up closing instead of opening. The current commit reduces the issue and prevents as many unnecessary RPC as there are tabs open, which is a good improvement. But it does not negate it completely. Indeed, when quickly closing then opening the same chat window, it might still happen for network reasons that the RPC or the corresponding bus notifications are received in the wrong order. This is less frequent both functionally (to click so fast) and technically (to have the network that slow) at the same time, so it is considering acceptable / out of scope. The opportunity is taken to clean up the code by removing unnecessary fields and making use of compute and flux specific RPC instead of `_updateAfter`. task-2273658 task-2329521 Forward-Port-Of: odoo/odoo#56964
Those were misaligned since the merge of the right-panelization. Forward-Port-Of: odoo/odoo#58347
Original PR description
Those were misaligned since the merge of the right-panelization. Forward-Port-Of: odoo/odoo#58347
task-2322135 Forward-Port-Of: odoo/odoo#58122
Original PR description
task-2322135 Forward-Port-Of: odoo/odoo#58122
(in message seen indicators) task-2335647 Forward-Port-Of: odoo/odoo#58018
Original PR description
(in message seen indicators) task-2335647 Forward-Port-Of: odoo/odoo#58018
Forward-Port-Of: odoo/odoo#57204
Original PR description
Forward-Port-Of: odoo/odoo#57204
The test does not make use of it and the field was made "read-only" in task-2322135 Forward-Port-Of: odoo/enterprise#13475
Original PR description
The test does not make use of it and the field was made "read-only" in task-2322135 Forward-Port-Of: odoo/enterprise#13475
…scal_regime following SAT update TASK ID: 2342655 Forward-Port-Of: odoo/enterprise#13416
Original PR description
…scal_regime following SAT update TASK ID: 2342655 Forward-Port-Of: odoo/enterprise#13416
When selecting a RTL language, direction of Gantt pills are not inverted, unlike the calendar layout, making them overlaying the wrong date slots. opw-2335066 Forward-Port-Of: odoo/enterprise#13422
Original PR description
When selecting a RTL language, direction of Gantt pills are not inverted, unlike the calendar layout, making them overlaying the wrong date slots. opw-2335066 Forward-Port-Of: odoo/enterprise#13422
Only invoice lines must be shown into the intrastat report. Tax lines and payable/receivable ones were already ignored before this fix, as they had no product_id and were excluded by the inner join. However, anglosaxon lines were not, as they do have a product. We solve this by adding a more explicit condition. Solves https://github.com/odoo/odoo/issues/57182 Forward-Port-Of: odoo/enterprise#13425 Forward-Port-Of: odoo/enterprise#13415
Original PR description
Only invoice lines must be shown into the intrastat report. Tax lines and payable/receivable ones were already ignored before this fix, as they had no product_id and were excluded by the inner join. However, anglosaxon lines were not, as they do have a product. We solve this by adding a more explicit condition. Solves https://github.com/odoo/odoo/issues/57182 Forward-Port-Of: odoo/enterprise#13425 Forward-Port-Of: odoo/enterprise#13415
Total des produits (I+III+V+VII)" formula must be: balance = I.balance + III.balance + V.balance + VII.balance Total des charges (II+IV+VI+VIII+IX+X)" formula must be: balance = II.balance + IV.balance + VI.balance + VIII.balance + IX.balance + X.balance opw:2334148 Forward-Port-Of: odoo/enterprise#13426 Forward-Port-Of: odoo/enterprise#13116
Original PR description
Total des produits (I+III+V+VII)" formula must be: balance = I.balance + III.balance + V.balance + VII.balance Total des charges (II+IV+VI+VIII+IX+X)" formula must be: balance = II.balance + IV.balance + VI.balance + VIII.balance + IX.balance + X.balance opw:2334148 Forward-Port-Of: odoo/enterprise#13426 Forward-Port-Of: odoo/enterprise#13116
After e1306066026649acd388b49d7429337d87cf819a when reconciling payments in multicurrency it may happens that journal items like the following are created |Journal| Ref |Debit|Credit|Amount Currency| |-------|---------------|-----|------|---------------| | EXCH| EXCH/2020/21-x| 0| 0| 4.20| These type of entries are creating a lot of "noise" in the partner ledger as they do not affect debit/credit of the partner but several are registered depending on the
Original PR description
After e1306066026649acd388b49d7429337d87cf819a when reconciling payments in multicurrency it may happens that journal items like the following are created |Journal| Ref |Debit|Credit|Amount Currency| |-------|---------------|-----|------|---------------| | EXCH| EXCH/2020/21-x| 0| 0| 4.20| These type of entries are creating a lot of "noise" in the partner ledger as they do not affect debit/credit of the partner but several are registered depending on the lines of the original record opw-2276550 Forward-Port-Of: odoo/enterprise#13401 Forward-Port-Of: odoo/enterprise#13363
- Create a Subscription Template with automatic invoice sending - Create a subscription with the template - Make sure the next invoice date is in the past / not set - Run the cron 'Sale Subscription: generate recurring invoices and payments' The invoice is sent, but the flag `invoice_sent` remains `False`. We set the flag at the appropriate step of the process. opw-2341177 Forward-Port-Of: odoo/enterprise#13409 Forward-Port-Of: odoo/enterprise#13356
Original PR description
- Create a Subscription Template with automatic invoice sending - Create a subscription with the template - Make sure the next invoice date is in the past / not set - Run the cron 'Sale Subscription: generate recurring invoices and payments' The invoice is sent, but the flag `invoice_sent` remains `False`. We set the flag at the appropriate step of the process. opw-2341177 Forward-Port-Of: odoo/enterprise#13409 Forward-Port-Of: odoo/enterprise#13356
- Set a bank account on the partner related to the company - Create a subscription, generate the invoice The bank account of the company is not set on the invoice. When creating an invoice manually, the invoice is set in: https://github.com/odoo/odoo/blob/71d42842b1ed4ad50e49a90a52aa4195ae9defe2/addons/account/models/account_move.py#L362 However, in this case we don't trigger the `_onchange_partner_id` method. The solution is to set the account manually at invoice creation. opw
Original PR description
- Set a bank account on the partner related to the company - Create a subscription, generate the invoice The bank account of the company is not set on the invoice. When creating an invoice manually, the invoice is set in: https://github.com/odoo/odoo/blob/71d42842b1ed4ad50e49a90a52aa4195ae9defe2/addons/account/models/account_move.py#L362 However, in this case we don't trigger the `_onchange_partner_id` method. The solution is to set the account manually at invoice creation. opw-2336229 Forward-Port-Of: odoo/enterprise#13410 Forward-Port-Of: odoo/enterprise#13360