Friday, February 21, 2020
30 changes · master
Enhancements to existing features
Several CRM, Events, and Gamification screens now show shorter, clearer labels and wider columns so information is easier to read. Opportunity lists also focus on more useful date information by showing creation dates in a date format and removing phone details from those embedded lists.
Original PR description
PURPOSE In various views, the min width of some columns is too short for the label of the field. This task aims at fixing this by increasing some minimal widths, and relabelling some fields. SPECIFICATIONS Increase the default minimal width of Boolean field from 50px to 70px to avoid readability issue. in the inline treeview of event_ticket_ids - set string of field seats_max to 'Available' - set string of field seats_reserved to 'Reserved' - set string of field seats_unconfirmed 'Unconfirmed' - set width='105px' for each of those 3 fields In views crm.view_crm_lead2opportunity_partner_mass AND crm.view_crm_lead2opportunity_partner - in the inline treeview of opportunity_ids, drop the phone field and add a date widget on the create_date In model gamification.challenge.line - relabel 'target_goal' to 'Target' In model event.mail - relabel 'mail_sent' to 'Sent' LINKS PR #43401 Task 2166865
When multiple companies need default stock locations created, the process now handles them together instead of one by one. This improves setup efficiency without changing day-to-day inventory workflows.
Original PR description
Use the fact that `create_missing_*_location` methods supports multi recordsets. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes an outdated calendar validation that referred to a date field no longer used in Odoo. It helps keep calendar behavior aligned with the current system and avoids unnecessary checks that no longer serve a purpose.
Original PR description
Description of the issue/feature this PR addresses: Date field doesn't exist since v9, So this validation doesn't make any sense. Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The XML editor now shows the no-update warning only for standard views, not custom Studio views. This reduces unnecessary alerts for users editing views that can safely be changed through the interface.
Original PR description
PURPOSE Update warning in ace editor is displayed in all views, it should only be displayed in standard views, custom views(studio views) should not have that warning as a user can change those view from UI. SPECIFICATION Display update warning only in standard view Task 2167570
Resolved issues and error corrections
This fixes typos that caused an error when opening the vendor refunds area in Invoicing. Users can now access that menu without encountering a traceback, improving reliability for refund workflows.
Original PR description
Two typos were introduced with d675dbaa4c71. Discovered by the click_all test, just click on the Invoicing/Vendors/Refunds menu leads to a Traceback.
Miscellaneous changes
Before d00c0e317, `Datetime` fields would be editable in frontend but would have unexpected results, especially in non-English languages, for when the english lang format had been changed. It would also crash when saving non-English strings, such as `Lundi`. For more details, see https://github.com/odoo/odoo/pull/44484#issuecomment-586850490 Since d00c0e317, only date displayed in lang format would be editable, which case is Event page in Odoo 12.0. Everywhere else, the format is changed
Original PR description
Before d00c0e317, `Datetime` fields would be editable in frontend but would have unexpected results, especially in non-English languages, for when the english lang format had been changed. It would…
Exports made in import-compatible mode now handle many-to-many field names in a format that can be imported back more reliably. This reduces failed or incomplete re-imports when users export related records through the standard export interface.
Original PR description
Description of the issue/feature this PR addresses: https://pad.odoo.com/p/r.0453fa1a55f93d0b0a8d545c9f502267 task - 2065428 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website editor now recognizes when JavaScript or SCSS resources are custom-created and avoids showing the “No Update” warning for them. This reduces confusion for users editing custom website resources, since the warning is only relevant to standard resources that may be overwritten by updates.
Original PR description
Pad: https://pad.odoo.com/p/r.2d7e52f153e37972b74fafb45f2879f8 Task: https://www.odoo.com/web#id=2167570&action=327&model=project.task&view_type=form&menu_id=4720
The tax report audit option now uses the updated tax tag field name, restoring access to the expected audit details. This prevents errors when users review tax report lines by tag after the underlying accounting field was renamed.
Original PR description
Field tag_ids of account.move.line has been renamed tax_tag_ids by https://github.com/odoo/odoo/pull/44835 .
Before d00c0e317, `Datetime` fields would be editable in frontend but would
have unexpected results, especially in non-English languages, for when the
english lang format had been changed.
It would also crash when saving non-English strings, such as `Lundi`.
For more details, see https://github.com/odoo/odoo/pull/44484#issuecomment-586850490
Since d00c0e317, only date displayed in lang format would be editable, which
case is Event page in Odoo 12.0. Everywhere else, the format is changed for a
nicer layout, either with `widget=XXX` or `t-options=YYY`, such as:
`<time t-field="record.date" t-options='{"format": "MMM d, yyyy"}'/>`
`<time t-field="record.date" t-options="{'time_only': 'true', 'format': 'short'}"/>`
When a date parsing crashes during editor save, the problem is not only that
the date can be saved, but the whole changes of the page are lost, as they
won't be saved either.
This commit attempts to fix every languages cases, regardless of the website
lang or user lang.
To do so, we store the date in the user lang format in a data attribute of
every date field in the DOM. Once the field is clicked (to edit probably),
that value will replace the one displayed according to the widget/options.
That way, dates will always be sent to the server in the user lang format,
avoiding any possible mismatch.
This whole fix apply to `Datetime` and `Date` fields.
opw-2183055
Closes #44484
Closes #45555
Fixes #44047
closes odoo/odoo#45725
X-original-commit: 251b880de1caeeef1f27447d4ad69e1abeffde19
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Forward-Port-Of: odoo/odoo#45986
Forward-Port-Of: odoo/odoo#45929Add documentation for development of new Drivers for the IoT Box. TaskID: 2092878 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45495
Original PR description
Add documentation for development of new Drivers for the IoT Box. TaskID: 2092878 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45495
Before this commit, in mobile, the input to handle the input event of scanner was visible but with a negative z-index to be in the back of Odoo viewport. After this commit, in mobile, the input is transparent (opacity 0) and so is not visible anymore but it's still present. Steps to reproduce: * Go to app switcher (in mobile) * Scan a barcode with a hardware scanner BUG -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o
Original PR description
Before this commit, in mobile, the input to handle the input event of scanner was visible but with a negative z-index to be in the back of Odoo viewport. After this commit, in mobile, the input is transparent (opacity 0) and so is not visible anymore but it's still present. Steps to reproduce: * Go to app switcher (in mobile) * Scan a barcode with a hardware scanner BUG -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45955
The image illustrating some kanban cards (like "Employees" or "Contacts") has a weird scaling and rendering on smaller screen sizes. Step to reproduce (on small screen): 1. Open Employee 2. Apply a filter 3. Picture is ugly (shape changes to get something pretty weird) This commit fixes it by: 1. removing the rounding which was only applied (sic) on smaller screens 2. adjusting the size and/or the margins of the image to keep its ratio and the alignment with the other kanban card
Original PR description
The image illustrating some kanban cards (like "Employees" or "Contacts") has a weird scaling and rendering on smaller screen sizes. Step to reproduce (on small screen): 1. Open Employee 2. Apply a filter 3. Picture is ugly (shape changes to get something pretty weird) This commit fixes it by: 1. removing the rounding which was only applied (sic) on smaller screens 2. adjusting the size and/or the margins of the image to keep its ratio and the alignment with the other kanban cards. Task ID: 2198419 Forward-Port-Of: odoo/odoo#45517
misc fix on blog -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45529 Forward-Port-Of: odoo/odoo#45424
Original PR description
misc fix on blog -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45529 Forward-Port-Of: odoo/odoo#45424
Steps to reproduce: - install calendar - create a recurring event with 0 repetitions - save Previous behavior: raises an UserError, this prevents sync with google calendar in some cases Current behavior: the event is handled like a punctual event but remains recurrent opw-2185699 Forward-Port-Of: odoo/odoo#45920 Forward-Port-Of: odoo/odoo#45647
Original PR description
Steps to reproduce: - install calendar - create a recurring event with 0 repetitions - save Previous behavior: raises an UserError, this prevents sync with google calendar in some cases Current behavior: the event is handled like a punctual event but remains recurrent opw-2185699 Forward-Port-Of: odoo/odoo#45920 Forward-Port-Of: odoo/odoo#45647
Forward-Port-Of: odoo/odoo#45898
Original PR description
Forward-Port-Of: odoo/odoo#45898
Since PR 45225 hw_blackbox_be is no longer a module in the IOT but a driver. It should therefore no longer be executed 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#45833
Original PR description
Since PR 45225 hw_blackbox_be is no longer a module in the IOT but a driver. It should therefore no longer be executed 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#45833
Missing part of #44947 of task 2160847 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45758
Original PR description
Missing part of #44947 of task 2160847 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45758
When applying the selected date range using the widget the tip wasn't consumed. This commit fixes it by listening on the event triggered when clicking on button apply. Forward-Port-Of: odoo/odoo#45895
Original PR description
When applying the selected date range using the widget the tip wasn't consumed. This commit fixes it by listening on the event triggered when clicking on button apply. Forward-Port-Of: odoo/odoo#45895
Before this commit: Some tracebacks could appear in case when sharable pop-up in forums was enable by clicking on some elements (such as an accordion card header). OPW - 2197227 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45796
Original PR description
Before this commit: Some tracebacks could appear in case when sharable pop-up in forums was enable by clicking on some elements (such as an accordion card header). OPW - 2197227 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45796
- In some cases when trying to open a discuss conversation a traceback can occur because of the usage of a local variable before its assignation. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45807 Forward-Port-Of: odoo/odoo#45784
Original PR description
- In some cases when trying to open a discuss conversation a
traceback can occur because of the usage of a local variable
before its assignation.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#45807
Forward-Port-Of: odoo/odoo#45784When more than one user are linked to the same res.partner and this user is assigned to a task or a sale.order as many email notifications will be created as there are users linked to the same res.partner. This won't send more than 1 email, but multiple mail.notification records will be created. This causes duplicate entries in the mail.notification table, and can crash when an old unique constraint is still present in that table (from earlier Odoo versions) To prevent this, we deduplicate
Original PR description
When more than one user are linked to the same res.partner and this user is assigned to a task or a sale.order as many email notifications will be created as there are users linked to the same…
When more than one user are linked to the same res.partner and this user is assigned to a task or a sale.order as many email notifications will be created as there are users linked to the same res.partner.
This won't send more than 1 email, but multiple mail.notification
records will be created. This causes duplicate entries in the mail.notification table, and can crash when an old unique constraint is still present in that table (from earlier Odoo versions)
To prevent this, we deduplicate the notifications and order by notification type to get 'email' first in case the user have different notification type ('email', 'inbox').
How to reproduce:
- Create a first user test1
- Create a second user test2
- Merge the contact test1 and test2
- Create a customer customer
- Set the user test1 as salesman
- Create a new sale.order with customer as partner
Add a test to reproduce the pathological scenario
Solution
add distinct on partner.id and order by partner.id, users.notification_type
Forward-Port-Of: odoo/odoo#45034
Forward-Port-Of: odoo/odoo#43862Steps to reproduce: -duplicate resonanceinc.odoo.com -look for the order with the ref SQInv/OUT/00983 -click "send confirmation email" previous behavior: the template does not handle multiple package references and the associated link is wrong current behavior: each reference is set in a separated link opw-2167037 Forward-Port-Of: odoo/odoo#45320 Forward-Port-Of: odoo/odoo#44174
Original PR description
Steps to reproduce: -duplicate resonanceinc.odoo.com -look for the order with the ref SQInv/OUT/00983 -click "send confirmation email" previous behavior: the template does not handle multiple package references and the associated link is wrong current behavior: each reference is set in a separated link opw-2167037 Forward-Port-Of: odoo/odoo#45320 Forward-Port-Of: odoo/odoo#44174
- Activate 2 currencies - Create a landed cost product - Create a Vendor Bill in a currency different from the company currency - Add the landed cost product - Click on 'Create Landed Costs' The landed cost is created in the company currency, but with the amounts in the vendor bill currency. This happens because the currency conversion is missing. opw-2200500 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged
Original PR description
- Activate 2 currencies - Create a landed cost product - Create a Vendor Bill in a currency different from the company currency - Add the landed cost product - Click on 'Create Landed Costs' The landed cost is created in the company currency, but with the amounts in the vendor bill currency. This happens because the currency conversion is missing. opw-2200500 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#45828
Some of the implicit side-effects got missed, namely that under some conditions (e.g. using an odoo subcommand) `initialize_sys_path` can be called before the config has been loaded at all, resulting in the first call not properly setting up things, and one of the subsequent calls fixing things up. Since this breaks workflows right now, quickly fix it, we'll re-investigate how to fixup the entire thing in order to restrict & enforce a single call. Forward-Port-Of: odoo/odoo#45806 Forward
Original PR description
Some of the implicit side-effects got missed, namely that under some conditions (e.g. using an odoo subcommand) `initialize_sys_path` can be called before the config has been loaded at all, resulting in the first call not properly setting up things, and one of the subsequent calls fixing things up. Since this breaks workflows right now, quickly fix it, we'll re-investigate how to fixup the entire thing in order to restrict & enforce a single call. Forward-Port-Of: odoo/odoo#45806 Forward-Port-Of: odoo/odoo#45780
- Activate multi-step routes - Set Incoming Shipments: Receive goods in input, then quality and then stock (3 steps) - Create an Immediate Transfer from 'WH/Input' to 'WH/Quality Control' - Add 2 products, set a quantity - Validate Two immediate transfers are created, one for each product, while a single planned transfer is expected. This is because the `default_immediate_transfer` is polluting the context. opw-2180556 opw-2197720 Description of the issue/feature this PR ad
Original PR description
- Activate multi-step routes - Set Incoming Shipments: Receive goods in input, then quality and then stock (3 steps) - Create an Immediate Transfer from 'WH/Input' to 'WH/Quality Control' - Add 2 products, set a quantity - Validate Two immediate transfers are created, one for each product, while a single planned transfer is expected. This is because the `default_immediate_transfer` is polluting the context. opw-2180556 opw-2197720 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#45822 Forward-Port-Of: odoo/odoo#45803
`product_uom_id` is not mandatory: https://github.com/odoo/odoo/blob/dd5db84464998b45d0524055f9c96bcad894c4c9/addons/mrp/models/mrp_abstract_workorder.py#L317 Therefore, `float_round` may crash because of the rounding set to zero. opw-2201919 Forward-Port-Of: odoo/enterprise#8644
Original PR description
`product_uom_id` is not mandatory: https://github.com/odoo/odoo/blob/dd5db84464998b45d0524055f9c96bcad894c4c9/addons/mrp/models/mrp_abstract_workorder.py#L317 Therefore, `float_round` may crash because of the rounding set to zero. opw-2201919 Forward-Port-Of: odoo/enterprise#8644
The field to use is `line['filter_'+line.mode]`, as set in `changeFilter()`. This cause the actual value of the filter to never be taken into account. Manual forward port of https://github.com/odoo/odoo/pull/45785/ Forward-Port-Of: odoo/enterprise#8592
Original PR description
The field to use is `line['filter_'+line.mode]`, as set in `changeFilter()`. This cause the actual value of the filter to never be taken into account. Manual forward port of https://github.com/odoo/odoo/pull/45785/ Forward-Port-Of: odoo/enterprise#8592
For multi-company setup, it is annoying to require the language_code if the employee is not in Belgium and does not speak French, Dutch or German. As this field is quite specific for Belgium, make it required only if the company of the employee is located in Belgium. Forward-Port-Of: odoo/enterprise#8532
Original PR description
For multi-company setup, it is annoying to require the language_code if the employee is not in Belgium and does not speak French, Dutch or German. As this field is quite specific for Belgium, make it required only if the company of the employee is located in Belgium. Forward-Port-Of: odoo/enterprise#8532
When creating a Deferred Revenue/Expense Model the first one between account_depreciation_id (Revenue Account) or account_depreciation_expense_id (Deferred Revenue Account) which get filled in the form will determine the hidden variable 'account_asset_id' Future modifications to the variable are blocked, so, when the user will create a deferred revenue will not be able to switch model in a clear way. This reverts commit 147abd5492ffc0931958ae556d694b1a0de863e3. opw-2160761 Forward
Original PR description
When creating a Deferred Revenue/Expense Model the first one between account_depreciation_id (Revenue Account) or account_depreciation_expense_id (Deferred Revenue Account) which get filled in the form will determine the hidden variable 'account_asset_id' Future modifications to the variable are blocked, so, when the user will create a deferred revenue will not be able to switch model in a clear way. This reverts commit 147abd5492ffc0931958ae556d694b1a0de863e3. opw-2160761 Forward-Port-Of: odoo/enterprise#8617 Forward-Port-Of: odoo/enterprise#8605
Creating an app can take some time, since it reloads the registry entirely (possibly multiple times). While we may, at some point, start to really improve these perfs, this remains a really rare operation from a user's PoV and thus does not warrant a huge optimization effort at the moment. The current timing is sufficient during normal operations, but some slower CI builds (e.g. coverage, pyflame) could encounter a timeout on these steps which is not, in fact, a real problem. Forward
Original PR description
Creating an app can take some time, since it reloads the registry entirely (possibly multiple times). While we may, at some point, start to really improve these perfs, this remains a really rare operation from a user's PoV and thus does not warrant a huge optimization effort at the moment. The current timing is sufficient during normal operations, but some slower CI builds (e.g. coverage, pyflame) could encounter a timeout on these steps which is not, in fact, a real problem. Forward-Port-Of: odoo/enterprise#8625