Daily updates from Odoo
Navigate
Branch
Wednesday, December 18, 2019
22 changes
Enhancements to existing features
Product demonstration data has been updated to use more realistic sales settings. The three-seat sofa now has a more sensible demo price, and invoicing is aligned with ordered quantities to better reflect common sales workflows.
Original PR description
Task: https://www.odoo.com/web#id=2153140&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.c8cc199a03a278bd8a75d8c4578f88d2 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
Batch payment validation now shows a dedicated error window instead of stopping with a generic error message. Users can see grouped payment issues, open the affected payments, or remove them from the batch directly, making SEPA and direct debit batch processing easier to correct.
Original PR description
[IMP] account_batch_payment: introduce a new API to report report batch validation errors.
We don't just trigger a UserError anymore. Instead, we open a custom wizard listing the different errors that occured and allowing to directly remove from the batch or see all the payments causing each of them. This allows easier use of the batches, since it does not require them to go through the payments in error on by one manually to either remove or fix them.
[IMP] account_sepa, account_sepa_direct_debit: make use of the new batch payment validation error API.
Task: https://www.odoo.com/web#id=1873936&action=333&active_id=967&model=project.task&view_type=form&menu_id=4720The Gantt planning view now shows unavailable time more accurately, including smaller quarter-period planning blocks. This helps users spot scheduling conflicts and availability gaps more reliably when planning work.
Resolved issues and error corrections
Odoo Studio now shows the proper filter icon in search views. This removes a small visual inconsistency, making the interface clearer for users configuring or reviewing filters.
Original PR description
Pad: https://pad.odoo.com/p/r.05ec591dd7a17698746cecaf381c7406 Task: https://www.odoo.com/web#id=2151425&action=327&model=project.task&view_type=form&menu_id=4720
Code cleanup and technical improvements
The website module’s page building blocks have been reorganized into a clearer folder structure. This makes it easier to manage the growing library of standard website snippets and prepares the product for future snippet versioning without changing the end-user experience.
Original PR description
Reorganize the website folder to gather the large amount of snippets that will become standard. Also prepare for a new system of snippet versioning. Note: this merge contains a lot of commits because the files were split in such a way the history is not lost. A better way could exist to achieve this with less commits but in the end all the commits are gathered in an unique merge commit anyway. task-2158361
Miscellaneous changes
- Create a move line from stock to shelf1 with PACK1 - Create a move line from stock to shelf2 with PACK1 - Validate It should be be blocked. The contents of a package should all be in the same location since the pack itself is in a location. It's due to commit 78d6f4607496da06b574c02ab545ffc562a35bb3 that fix a rounding error. However it should check for quants that have quantity since they represents the package content. Forward-Port-Of: odoo/odoo#41932 Forward-Port-Of: odoo/odoo#3
Original PR description
- Create a move line from stock to shelf1 with PACK1 - Create a move line from stock to shelf2 with PACK1 - Validate It should be be blocked. The contents of a package should all be in the same location since the pack itself is in a location. It's due to commit 78d6f4607496da06b574c02ab545ffc562a35bb3 that fix a rounding error. However it should check for quants that have quantity since they represents the package content. Forward-Port-Of: odoo/odoo#41932 Forward-Port-Of: odoo/odoo#38465
Previously, increasing the number of columns on the tabs snippet would cause the newly created tabs to toggle the original tabs instead of its own, this was caused by an oversight where the onClone method was not called on the newly created tab. This commit fixes that issue. task-ID: 2070643 Forward-Port-Of: odoo/odoo#42109 Forward-Port-Of: odoo/odoo#41125
Original PR description
Previously, increasing the number of columns on the tabs snippet would cause the newly created tabs to toggle the original tabs instead of its own, this was caused by an oversight where the onClone method was not called on the newly created tab. This commit fixes that issue. task-ID: 2070643 Forward-Port-Of: odoo/odoo#42109 Forward-Port-Of: odoo/odoo#41125
The attribute "groups" on filters and fields in a search view arch was not taken into account anymore. Now items that should be invisible are not anymore available for selection in the interface (as expected) but are still activable as search defaults (and the corresponding facets appear if needed). Forward-Port-Of: odoo/odoo#42116
Original PR description
The attribute "groups" on filters and fields in a search view arch was not taken into account anymore. Now items that should be invisible are not anymore available for selection in the interface (as expected) but are still activable as search defaults (and the corresponding facets appear if needed). Forward-Port-Of: odoo/odoo#42116
If a long-running transaction holds a write-lock on any row in ir.attachment, the GC job can wait an indefinite amount of time to acquire its table-wise SHARE LOCK. While sitting in the queue for this lock, it will conflict with any future transaction that tries to acquire a write-lock on any row [1]. So the GC transaction, which would normally execute very fast and immediately release its lock, will start to block other transactions and cause severe delays in response time. It basically depe
Original PR description
If a long-running transaction holds a write-lock on any row in ir.attachment, the GC job can wait an indefinite amount of time to acquire its table-wise SHARE LOCK. While sitting in the queue for…
If a long-running transaction holds a write-lock on any row in ir.attachment, the GC job can wait an indefinite amount of time to acquire its table-wise SHARE LOCK.
While sitting in the queue for this lock, it will conflict with any future transaction that tries to acquire a write-lock on any row [1]. So the GC transaction, which would normally execute very fast and immediately release its lock, will start to block other transactions and cause severe delays in response time. It basically depends on how long the tx holding the lock takes to complete... which is unknown.
As a workaround, we force an arbitrary (but short) lock_timeout in the GC tx before attempting the lock. If it fails to acquire it, it will fail and raise, causing the whole operation to abort. The cron job will be rescheduled quickly because it failed to complete, giving the GC another chance to complete.
10 seconds seems a reasonable compromise, as it gives the blocking transaction(s) some time to complete before bailing out, yet should not be long enough to bring the system to a halt due to other transactions locked by the GC one. I have no hard data to back this claim, though.
I'm targeting 13.0 as the problem is fairly rare apparently, so it may not need to be backported further at this point.
[1] See the LOCK conflict table in the documentation:
https://www.postgresql.org/docs/10/explicit-locking.html
Forward-Port-Of: odoo/odoo#41816If getLangDateFormat is called right in loading the js file, it returns default format. We now call it when translations are ready. Forward-Port-Of: odoo/odoo#40447
Original PR description
If getLangDateFormat is called right in loading the js file, it returns default format. We now call it when translations are ready. Forward-Port-Of: odoo/odoo#40447
The background position snippet option makes a copy of the snippet to use in the overlay, such that it is over all content and the user can easily see the end result of dragging the background. However, an oversight in the CSS didn't account for the possibility of the copied element to have a relative max-width (% of its container), because of this, the overlay for those items was incorrect. This commit fixes that issue by overriding the max-width and max-height properties of the copied i
Original PR description
The background position snippet option makes a copy of the snippet to use in the overlay, such that it is over all content and the user can easily see the end result of dragging the background. However, an oversight in the CSS didn't account for the possibility of the copied element to have a relative max-width (% of its container), because of this, the overlay for those items was incorrect. This commit fixes that issue by overriding the max-width and max-height properties of the copied item. Forward-Port-Of: odoo/odoo#42018
opw-2157568 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#42086
Original PR description
opw-2157568 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#42086
When running multiple odoo on the same machine (in order to test multiple things concurrently, etc...) it's easily enough to start them on 8069, 8070, 8071, ... and that *seems* to work, but then they start walking on one another and *losing* chromes entirely, so you end up with hundreds of chrome processes: right now with 2 Odoo running tests my machine is at 365 Chrome processes, 550 process and 3180 threads total (should be ~160 and ~700 with 2 chrome processes at most). Instead, ask the
Original PR description
When running multiple odoo on the same machine (in order to test multiple things concurrently, etc...) it's easily enough to start them on 8069, 8070, 8071, ... and that *seems* to work, but then…
When running multiple odoo on the same machine (in order to test multiple things concurrently, etc...) it's easily enough to start them on 8069, 8070, 8071, ... and that *seems* to work, but then they start walking on one another and *losing* chromes entirely, so you end up with hundreds of chrome processes: right now with 2 Odoo running tests my machine is at 365 Chrome processes, 550 process and 3180 threads total (should be ~160 and ~700 with 2 chrome processes at most). Instead, ask the OS to ask for a devtools port, then close the socket and pass that to the child process. There's a race of sort for the instant between closing the socket and Chrome reopening it, but: * the window is very short * we got a random port from the ephemeral range, it's possible somebody else gets it inbetween but unlikely (the 50% on a birthday attack is 200 for Linux's ephemeral range, it's a somewhat lower 150 for the IANA range used by BSDs and Windows) Forward-Port-Of: odoo/odoo#42071
Description of the issue/feature this PR addresses: new email signature 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#42068
Original PR description
Description of the issue/feature this PR addresses: new email signature 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#42068
Before this commit, the log displayed "set as done" before actually trying to put the transaction in done. If an error then occurred in the'_set_transaction_done' function and the transaction could not be processed, this could lead to a misinterpretation of these logs. This log is therefore moved after the transaction is processed and is only displayed if it is actually successful. This is valid for'done','pending' and'cancel'. Forward-Port-Of: odoo/odoo#39364
Original PR description
Before this commit, the log displayed "set as done" before actually trying to put the transaction in done. If an error then occurred in the'_set_transaction_done' function and the transaction could not be processed, this could lead to a misinterpretation of these logs. This log is therefore moved after the transaction is processed and is only displayed if it is actually successful. This is valid for'done','pending' and'cancel'. Forward-Port-Of: odoo/odoo#39364
We are looking for the "Bom Count" stat-button, which can be hidden behind the "More" dropdown, depending on the number of installed modules and views inheritance order loading. This is what causes the failure of odoo/enterprise#6973 Forward-Port-Of: odoo/odoo#42064
Original PR description
We are looking for the "Bom Count" stat-button, which can be hidden behind the "More" dropdown, depending on the number of installed modules and views inheritance order loading. This is what causes the failure of odoo/enterprise#6973 Forward-Port-Of: odoo/odoo#42064
opw-2157386 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#42044 Forward-Port-Of: odoo/odoo#41995
Original PR description
opw-2157386 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#42044 Forward-Port-Of: odoo/odoo#41995
This PR only changes the multi-company dropdown but the theme need more improvements/fixes to looks properly on mobile phones. Description of the issue/feature this PR addresses: Without this PR the multi-company dropdown breaks the page on mobile Current behavior before PR:  Desired behavior after PR is merged:  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#38146
Linked to odoo/documentation-user#487 Forward-Port-Of: odoo/odoo#41801
Original PR description
Linked to odoo/documentation-user#487 Forward-Port-Of: odoo/odoo#41801
…r invoices" This commit revert the 'out_invoice' behaviour as the right fix is to deactivate invoice_ocr on out_invoices and out_refund This reverts commit fe15da52d35bb90ecefc106ed51ae9c4ad61b585. Forward-Port-Of: odoo/enterprise#7297 Forward-Port-Of: odoo/enterprise#7236
Original PR description
…r invoices" This commit revert the 'out_invoice' behaviour as the right fix is to deactivate invoice_ocr on out_invoices and out_refund This reverts commit fe15da52d35bb90ecefc106ed51ae9c4ad61b585. Forward-Port-Of: odoo/enterprise#7297 Forward-Port-Of: odoo/enterprise#7236
This avoid depending on view loading order. Forward-Port-Of: odoo/enterprise#6973
Original PR description
This avoid depending on view loading order. Forward-Port-Of: odoo/enterprise#6973
Depending on the locale, the ISO year of January 1st might be the previous year. For example: ``` >>> d = datetime.datetime(2017, 1, 1) # 1st of january 2017 >>> babel.dates.format_date(d, format='MMM YYYY', locale=babel.Locale.parse('fr_FR')) 'janv. 2016' >>> babel.dates.format_date(d, format='MMM YYYY', locale=babel.Locale.parse('en_US')) 'Jan 2017' >>> babel.dates.format_date(d, format='MMM yyyy', locale=babel.Locale.parse('fr_FR')) 'janv. 2017' ``` We use the regular year to
Original PR description
Depending on the locale, the ISO year of January 1st might be the
previous year. For example:
```
>>> d = datetime.datetime(2017, 1, 1) # 1st of january 2017
>>> babel.dates.format_date(d, format='MMM YYYY', locale=babel.Locale.parse('fr_FR'))
'janv. 2016'
>>> babel.dates.format_date(d, format='MMM YYYY', locale=babel.Locale.parse('en_US'))
'Jan 2017'
>>> babel.dates.format_date(d, format='MMM yyyy', locale=babel.Locale.parse('fr_FR'))
'janv. 2017'
```
We use the regular year to avoid this.
opw-2122637
Forward-Port-Of: odoo/enterprise#7332