Odoo Changelog — 2018-04-30

Monday, April 30, 2018

3 changes · master

Bug Fixes(3)

Resolved issues and error corrections

[FIX] website_sale: Use percentage function of scss. scss not supporting '100%/3' like less.

Coremasterwebsite_sale

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

#website#ecommerce#layout

Form buttons should always get a (correct) btn style class

PR #24443

Coremasterweb

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:

-> 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:

[IMP] helpdest: typo error

PR #2100

Enterprisemasterhelpdesk

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

#typo#helpdesk#user-interface

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

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: