Daily updates from Odoo
Navigate
Branch
Monday, April 30, 2018
7 changes
Enhancements to existing features
This update renames and aligns key sales order date fields so users can better understand expected, committed, and completed delivery timing. It also ties the effective date to the actual completed delivery date, improving consistency between sales orders and stock operations.
Original PR description
Task : https://www.odoo.com/web#id=34343&view_type=form&model=project.task&action=333&active_id=131&menu_id=4720 Pad : https://pad.odoo.com/p/r.0827fde0087f4d4e0efcf754a2941ab1 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
The live chat settings were reorganized to make configuration easier for users. A clearer tooltip now explains the chat input placeholder so teams can better understand what customers will see when starting a conversation.
Original PR description
task : https://www.odoo.com/web?#id=1837812&view_type=form&model=project.task&action=327&menu_id=4720 pad : https://pad.odoo.com/p/r.0df29f2015f5cd978414ab53e2854521
Event attendees can now add confirmed event dates directly to Google Calendar or download an Outlook-compatible calendar file after registering. This makes it easier for customers to remember events and reduces missed attendance.
Original PR description
Task : https://www.odoo.com/web#id=39315&view_type=form&model=project.task&action=333&active_id=131&menu_id= Pad : https://pad.odoo.com/p/r.4dce07daab55c55cfb3c26bc312dfefc -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Inter-company sales rules were updated to match renamed order date fields in the base sales functionality. This keeps date information flowing correctly between related company orders and prevents confusion from outdated field names.
Original PR description
Task : https://www.odoo.com/web#id=34343&view_type=form&model=project.task&action=333&active_id=131&menu_id=4720 Pad : https://pad.odoo.com/p/r.0827fde0087f4d4e0efcf754a2941ab1 commitment_date to expected_date and expected_date to requested_date hence adapting the code here. related community PR: https://github.com/odoo/odoo/pull/18325
Resolved issues and error corrections
This update corrects how the online shop stylesheet calculates column widths. It helps ensure product layouts render consistently after the styling files are processed.
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
Form buttons now receive the correct visual style automatically, especially in form headers where custom-class buttons could appear incorrectly. This keeps Odoo screens visually consistent and adds safeguards so the behavior does not regress unnoticed.
Original PR description
Related to task-49276 Here is the story of the problem: back in 10.0, everything *seemed* fine with button rendering except it was very messy duplicated codes. The system was still not consistent: ->…
Related to task-49276 Here is the story of the problem: back in 10.0, everything *seemed* fine with button rendering except it was very messy duplicated codes. The system was still not consistent: -> In Header, button with: no class -> btn-default btn-primary -> btn-default btn-primary oe_highlight -> btn-primary btn-default -> btn-default btn-link -> btn-default btn-link oe_link -> btn-default oe_link btn-danger -> btn-default btn-danger some_class -> btn-default some_class -> Not in header, button with: no class -> no class btn-primary -> btn-primary oe_highlight -> btn-primary btn-default -> btn-default btn-link -> btn-link oe_link -> oe_link btn-danger -> btn-danger some_class -> some_class So, outside the header, the system seemed to not process anything except transforming the oe_highlight class. In the header, the btn-default was always added, except if using the oe_highlight class. The style is fine for those, except for .btn-default.btn-link and .btn-default.oe_link where the link class has no effect (which is fine as header are not supposed to contain links). In 11.0, the new views were introduced alongside websitepocalypse. The new system led to: -> In Header, button with: no class -> btn-default btn-primary -> btn-default btn-primary oe_highlight -> btn-default oe_highlight btn-default -> btn-default btn-link -> btn-default btn-link oe_link -> btn-default oe_link btn-danger -> btn-default btn-danger some_class -> btn-default some_class -> Not in header, button with: no class -> btn-default btn-primary -> btn-primary oe_highlight -> oe_highlight btn-default -> btn-default btn-link -> btn-link oe_link -> oe_link btn-danger -> btn-danger some_class -> some_class So, it worsened the header button by not processing the oe_highlight class and adding the btn-default class in all cases. This is even worse since in 11.0 .btn-default.btn-link do have a specific style and thus not appear as .btn-default anymore. Those may be invisible "bugs" though as .btn-link are not supposed to be in header and oe_highlight is styled correctly in css. For buttons outside the header, a little processing was added to add "btn-default" class for buttons which did not specified a class (and oe_highlight is not processed anymore there too). In master, with the less2scss task, the system had to change again but led this time to visible bugs: -> In Header, button with: no class -> btn-default btn-primary -> btn-primary oe_highlight -> btn-primary btn-default -> btn-default btn-link -> btn-link oe_link -> btn-link btn-danger -> btn-danger some_class -> some_class -> Not in header, button with: no class -> btn-default btn-primary -> btn-primary oe_highlight -> btn-primary btn-default -> btn-default btn-link -> btn-link oe_link -> btn-link btn-danger -> btn-danger some_class -> some_class As you can see, the system is now the same for both header button and normal buttons. The system is also better for all cases as it produce only *one* *bootstrap* class for all cases. However, the problematic case is the last one for header buttons: it did not receive the btn-default class automatically. Even though this is the API for the rest of odoo (dialogs, renderButton (old WidgetButton), ...), this is a problem here as fixing this would require to add the 'btn-default' class in every view which is using this case. => This commit is fixing that, see the commit message :smile:
A small wording mistake was corrected in the Helpdesk interface. The text now says “your website visitors,” making the message clearer and more professional for users configuring visitor contact options.
Original PR description
task : https://www.odoo.com/web?#id=1837812&view_type=form&model=project.task&action=327&menu_id=4720 pad : https://pad.odoo.com/p/r.0df29f2015f5cd978414ab53e2854521