<feed xmlns='http://www.w3.org/2005/Atom'>
<title>Odoo/addons/website_mail/static/src/js, branch 14.0</title>
<subtitle>The current checkout of upstream Odoo</subtitle>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/'/>
<entry>
<title>[FIX] website_mail: adjust the visibility of the (un)subscribe buttons</title>
<updated>2020-12-03T13:28:55+00:00</updated>
<author>
<name>Benoit Socias</name>
<email>bso@odoo.com</email>
</author>
<published>2020-12-03T13:28:17+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=486c445d2200d3805ffac30e84ff35a7a61bf0b7'/>
<id>486c445d2200d3805ffac30e84ff35a7a61bf0b7</id>
<content type='text'>
Before this commit the visibility of the blog (un)subscribe/(un)follow
buttons was behaving inconsistently because of a combination of specific
CSS based on data values and the adding and removal of d-none classes.

After this commit the visibility of the buttons is using only the CSS
mechanism based on data values. Also adjusted the alignment of the email
text input and its attached button (aligned in both blog &amp; forum).

Fixes https://github.com/odoo/odoo/issues/62714

closes odoo/odoo#62823

Signed-off-by: Romain Derie &lt;rdeodoo@users.noreply.github.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before this commit the visibility of the blog (un)subscribe/(un)follow
buttons was behaving inconsistently because of a combination of specific
CSS based on data values and the adding and removal of d-none classes.

After this commit the visibility of the buttons is using only the CSS
mechanism based on data values. Also adjusted the alignment of the email
text input and its attached button (aligned in both blog &amp; forum).

Fixes https://github.com/odoo/odoo/issues/62714

closes odoo/odoo#62823

Signed-off-by: Romain Derie &lt;rdeodoo@users.noreply.github.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[FIX] website_mail: avoid sending too many RPCs</title>
<updated>2020-02-27T16:54:25+00:00</updated>
<author>
<name>Romain Derie</name>
<email>rde@odoo.com</email>
</author>
<published>2020-02-20T12:56:51+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=c593e7d5985f2332d3d0534eb46a742d459d4fd1'/>
<id>c593e7d5985f2332d3d0534eb46a742d459d4fd1</id>
<content type='text'>
Before this commit, a JS widget would be instanciated for every `.js_follow` on
the page.
Every widget would then perform a RPC to know if the object was followed.
That would be an issue if there was too many `.js_follow` on the DOM.
Eg: on the forum tag page (/forum/1/tag), there might be unlimited tags. This
    is where the biggest issue is ATM, on Odoo.com we have over 5500 tags,
    which performs 5500 RPC.

Your browser will most of the time just crash.

This commit improves that behavior by sending only one RPC to get the tags info
in once.
With 5000 tags, there was 5000 RPCs, now there will only be one for the tags.
Also, each RPC were doing 8 requests each, so this will bring requests from
40.000 to 80.

Fixes #45576

closes odoo/odoo#46278

Signed-off-by: Quentin Smetz (qsm) &lt;qsm@odoo.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before this commit, a JS widget would be instanciated for every `.js_follow` on
the page.
Every widget would then perform a RPC to know if the object was followed.
That would be an issue if there was too many `.js_follow` on the DOM.
Eg: on the forum tag page (/forum/1/tag), there might be unlimited tags. This
    is where the biggest issue is ATM, on Odoo.com we have over 5500 tags,
    which performs 5500 RPC.

Your browser will most of the time just crash.

This commit improves that behavior by sending only one RPC to get the tags info
in once.
With 5000 tags, there was 5000 RPCs, now there will only be one for the tags.
Also, each RPC were doing 8 requests each, so this will bring requests from
40.000 to 80.

Fixes #45576

closes odoo/odoo#46278

Signed-off-by: Quentin Smetz (qsm) &lt;qsm@odoo.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[REF] {website_}mail: move and replace published field of mail.message to is_internal</title>
<updated>2019-12-02T15:18:44+00:00</updated>
<author>
<name>Thibault Delavallée</name>
<email>tde@odoo.com</email>
</author>
<published>2019-10-14T11:05:55+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=5649fc88e8f3022f4143400a124f2e3c1e5c0df8'/>
<id>5649fc88e8f3022f4143400a124f2e3c1e5c0df8</id>
<content type='text'>
PURPOSE

Clean posting process and improve mail.message definition and comprehension.

SPECIFICATIONS

Website mail defines a website_published field allowing to publish / unpublish
comments on the frontend of some modules. This field has several drawbacks :

  * it is used only for front-end people (portal, public) and has no real
    effect in chatter / classic discussions;
  * it is used only in some advanced front-end module and is not available
    in portal by default;
  * its naming is not really correct as it is not linked to fields coming
    from the website_published mixin and its behavior is not really
    the same;
  * its use is a bit duplicated with internal flag coming from subtype
    allowing to hide messages related to an internal subtype;
  * there are overrides of standard mail.message methods just to handle
    this flag;

In this commit we change that field by an is_internal flag directly on
mail.message model itself. It tells if share people (customers, share users)
are allowed to read the message. This field can be given through posting
API or set manually using widgets. It is also used in access rights custom
methods and managed like the internal flag of subtypes.

Mailgateway was already using an internal flag for internal note replies. It
is renamed to is_internal and propagated as it is now a standard field. It
also eases code understanding.

Portal is updated to allow managing the flag directly. It means customer portal
now natively allows to moderate customer comments without any need of website
modules.

Rating is updated accordingly. An is_internal field is added, replacing the
related on website published.

LINKS

Task ID 2071556
PR #38692</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
PURPOSE

Clean posting process and improve mail.message definition and comprehension.

SPECIFICATIONS

Website mail defines a website_published field allowing to publish / unpublish
comments on the frontend of some modules. This field has several drawbacks :

  * it is used only for front-end people (portal, public) and has no real
    effect in chatter / classic discussions;
  * it is used only in some advanced front-end module and is not available
    in portal by default;
  * its naming is not really correct as it is not linked to fields coming
    from the website_published mixin and its behavior is not really
    the same;
  * its use is a bit duplicated with internal flag coming from subtype
    allowing to hide messages related to an internal subtype;
  * there are overrides of standard mail.message methods just to handle
    this flag;

In this commit we change that field by an is_internal flag directly on
mail.message model itself. It tells if share people (customers, share users)
are allowed to read the message. This field can be given through posting
API or set manually using widgets. It is also used in access rights custom
methods and managed like the internal flag of subtypes.

Mailgateway was already using an internal flag for internal note replies. It
is renamed to is_internal and propagated as it is now a standard field. It
also eases code understanding.

Portal is updated to allow managing the flag directly. It means customer portal
now natively allows to moderate customer comments without any need of website
modules.

Rating is updated accordingly. An is_internal field is added, replacing the
related on website published.

LINKS

Task ID 2071556
PR #38692</pre>
</div>
</content>
</entry>
<entry>
<title>[MOV] website_mail: rename portal related files</title>
<updated>2019-08-21T12:50:51+00:00</updated>
<author>
<name>Thibault Delavallée</name>
<email>tde@odoo.com</email>
</author>
<published>2019-08-21T09:09:31+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=241453aaecfdd8e18aa3fe477cbc28c3f22601e7'/>
<id>241453aaecfdd8e18aa3fe477cbc28c3f22601e7</id>
<content type='text'>
PURPOSE

Fix frontend rating and clean a bit module organization

SPECIFICATIONS

In order to ease understanding of portal chatter dependencies let us name
files according to guidelines. In this commit we rename a bit files in
website mail to understand which widgets and portal parts are impacted by
website mail bridge module.

Assets are also moved in their own file to ease module discovering.

LINKS

Task 2057301
PR #35870</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
PURPOSE

Fix frontend rating and clean a bit module organization

SPECIFICATIONS

In order to ease understanding of portal chatter dependencies let us name
files according to guidelines. In this commit we rename a bit files in
website mail to understand which widgets and portal parts are impacted by
website mail bridge module.

Assets are also moved in their own file to ease module discovering.

LINKS

Task 2057301
PR #35870</pre>
</div>
</content>
</entry>
<entry>
<title>[REF] website_mail: adapt code after jQuery update</title>
<updated>2019-03-06T19:07:17+00:00</updated>
<author>
<name>Vincent Schippefilt</name>
<email>vsc@odoo.com</email>
</author>
<published>2019-03-06T13:02:36+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=5413686837e810925234e339724da13fba684790'/>
<id>5413686837e810925234e339724da13fba684790</id>
<content type='text'>
Part of task 1896658

Co-authored-by: Aaron Bohy &lt;aab@odoo.com&gt;
Co-authored-by: Christophe Matthieu &lt;chm@odoo.com&gt;
Co-authored-by: Mathieu Duckerts-Antoine &lt;dam@odoo.com&gt;
Co-authored-by: David Monjoie &lt;dmo@odoo.com&gt;
Co-authored-by: Martin Geubelle &lt;mge@odoo.com&gt;
Co-authored-by: svs-odoo &lt;svs@odoo.com&gt;
Co-authored-by: Vincent Schippefilt &lt;vsc@odoo.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Part of task 1896658

Co-authored-by: Aaron Bohy &lt;aab@odoo.com&gt;
Co-authored-by: Christophe Matthieu &lt;chm@odoo.com&gt;
Co-authored-by: Mathieu Duckerts-Antoine &lt;dam@odoo.com&gt;
Co-authored-by: David Monjoie &lt;dmo@odoo.com&gt;
Co-authored-by: Martin Geubelle &lt;mge@odoo.com&gt;
Co-authored-by: svs-odoo &lt;svs@odoo.com&gt;
Co-authored-by: Vincent Schippefilt &lt;vsc@odoo.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[REF] website, *: use public widgets instead of website animations</title>
<updated>2019-02-26T17:09:23+00:00</updated>
<author>
<name>qsm-odoo</name>
<email>qsm@odoo.com</email>
</author>
<published>2019-02-12T13:20:23+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=d946b7a85d2c1bbc20ace8e2b269be56a63876fd'/>
<id>d946b7a85d2c1bbc20ace8e2b269be56a63876fd</id>
<content type='text'>
* website_blog, website_crm_partner_assign, website_event,
  website_event_track, website_form, website_forum, website_links,
  website_mail, website_mail_channel, website_mass_mailing,
  website_sale, website_sale_comparison, website_sale_delivery,
  website_sale_stock, website_sale_wishlist, website_slides,
  website_twitter

While using the 'Animation' class of website instead of the frontend
'Widget' class leads to the same behaviors, this refactoring is done for
two reasons:
- Stop using the confusing 'Animation' name for non-animated behaviors
- Instantiation of 'Widget' is slightly faster than 'Animation'

Part of https://github.com/odoo/odoo/pull/29442
task-1932066</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* website_blog, website_crm_partner_assign, website_event,
  website_event_track, website_form, website_forum, website_links,
  website_mail, website_mail_channel, website_mass_mailing,
  website_sale, website_sale_comparison, website_sale_delivery,
  website_sale_stock, website_sale_wishlist, website_slides,
  website_twitter

While using the 'Animation' class of website instead of the frontend
'Widget' class leads to the same behaviors, this refactoring is done for
two reasons:
- Stop using the confusing 'Animation' name for non-animated behaviors
- Instantiation of 'Widget' is slightly faster than 'Animation'

Part of https://github.com/odoo/odoo/pull/29442
task-1932066</pre>
</div>
</content>
</entry>
<entry>
<title>[REF] website, *: move and review the notion of edit mode</title>
<updated>2019-02-26T17:09:22+00:00</updated>
<author>
<name>qsm-odoo</name>
<email>qsm@odoo.com</email>
</author>
<published>2019-02-07T16:41:52+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=335a505d1f9b6a978c0fe0f6ea760a45b0d0a67f'/>
<id>335a505d1f9b6a978c0fe0f6ea760a45b0d0a67f</id>
<content type='text'>
* portal, sale, web, website_blog, website_crm_partner_assign,
  website_forum, website_event_track, website_links, website_mail,
  website_slides, website_mail_channel, website_mass_mailing,
  website_sale, website_sale_comparison, website_sale_delivery,
  website_sale_wishlist

The `editableMode` option and its related options in public widget
should only be part of website, this commit moves them there. This is
also the occasion to implement something that is long overdue: stop
creating 'animations' / public widgets in edit mode by default. Indeed,
lots of 'animations' were defined by beginning with 'if not edit mode'.
Now, if a public widget should be considered in edit mode, it must be
defined explicitely through a property at *definition* of the widget.

Part of https://github.com/odoo/odoo/pull/29442
task-1932066</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* portal, sale, web, website_blog, website_crm_partner_assign,
  website_forum, website_event_track, website_links, website_mail,
  website_slides, website_mail_channel, website_mass_mailing,
  website_sale, website_sale_comparison, website_sale_delivery,
  website_sale_wishlist

The `editableMode` option and its related options in public widget
should only be part of website, this commit moves them there. This is
also the occasion to implement something that is long overdue: stop
creating 'animations' / public widgets in edit mode by default. Indeed,
lots of 'animations' were defined by beginning with 'if not edit mode'.
Now, if a public widget should be considered in edit mode, it must be
defined explicitely through a property at *definition* of the widget.

Part of https://github.com/odoo/odoo/pull/29442
task-1932066</pre>
</div>
</content>
</entry>
<entry>
<title>[REF] *: use 'frontend' system in non-website apps</title>
<updated>2019-02-26T17:09:22+00:00</updated>
<author>
<name>qsm-odoo</name>
<email>qsm@odoo.com</email>
</author>
<published>2019-02-06T14:29:07+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=27fca749af30d7dce448f6632132422df8d8a7c1'/>
<id>27fca749af30d7dce448f6632132422df8d8a7c1</id>
<content type='text'>
* account, auth_signup, payment, portal, project, sale, sale_management,
  web_unsplash, website, website_mail, website_rating, website_sale

This commit does probably not do what is stated for all non-website apps
but it is a first step. It also uses the system in apps which could have
already used it but did not.

Part of https://github.com/odoo/odoo/pull/29442
task-1932066</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* account, auth_signup, payment, portal, project, sale, sale_management,
  web_unsplash, website, website_mail, website_rating, website_sale

This commit does probably not do what is stated for all non-website apps
but it is a first step. It also uses the system in apps which could have
already used it but did not.

Part of https://github.com/odoo/odoo/pull/29442
task-1932066</pre>
</div>
</content>
</entry>
<entry>
<title>[REF] *: BS4, adapt forms</title>
<updated>2018-07-27T10:36:54+00:00</updated>
<author>
<name>qsm-odoo</name>
<email>qsm@odoo.com</email>
</author>
<published>2018-05-22T13:30:36+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=93b0001df6766fe905ee69c25ec8d846e4551064'/>
<id>93b0001df6766fe905ee69c25ec8d846e4551064</id>
<content type='text'>
The 'form-horizontal' class have been removed; the '.form-group'
elements must now use the 'row' class for an horizontal layout.

The 'control-label' class was renamed to 'col-form-label'.

The 'help-block' class was renamed to 'form-text'.

The 'has-error' and 'has-success' classes have been removed and
replaced by a new system using the :valid and :invalid pseudo-classes,
when a parent has the 'was-validated' class. While this system is great,
it is not straightforward to use it in Odoo. Fortunately, BS4 provides
the 'is-valid' and 'is-invalid' classes as fallback. This commit
replaces the 'has-error' and 'has-success' classes by 'o_has_error' and
'o_has_success' classes (for JS compatibility) and use the 'is-*'
fallback classes. (The 'has-warning' class has no equivalent but was
unused in Odoo anyway).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The 'form-horizontal' class have been removed; the '.form-group'
elements must now use the 'row' class for an horizontal layout.

The 'control-label' class was renamed to 'col-form-label'.

The 'help-block' class was renamed to 'form-text'.

The 'has-error' and 'has-success' classes have been removed and
replaced by a new system using the :valid and :invalid pseudo-classes,
when a parent has the 'was-validated' class. While this system is great,
it is not straightforward to use it in Odoo. Fortunately, BS4 provides
the 'is-valid' and 'is-invalid' classes as fallback. This commit
replaces the 'has-error' and 'has-success' classes by 'o_has_error' and
'o_has_success' classes (for JS compatibility) and use the 'is-*'
fallback classes. (The 'has-warning' class has no equivalent but was
unused in Odoo anyway).
</pre>
</div>
</content>
</entry>
<entry>
<title>[REF] *: BS4, adapt input-group structure</title>
<updated>2018-07-27T10:36:54+00:00</updated>
<author>
<name>qsm-odoo</name>
<email>qsm@odoo.com</email>
</author>
<published>2018-05-22T10:07:42+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=b437808f6696a8d202dac079fe8e40ade9779704'/>
<id>b437808f6696a8d202dac079fe8e40ade9779704</id>
<content type='text'>
The input-group-addon class has been replaced by a combination of the
input-group-text and the input-group-append/prepend classes. The
input-group-btn class is replaced by the input-group-append/prepend
classes.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The input-group-addon class has been replaced by a combination of the
input-group-text and the input-group-append/prepend classes. The
input-group-btn class is replaced by the input-group-append/prepend
classes.
</pre>
</div>
</content>
</entry>
</feed>
