Purpose
=======
The fields are not used, don't work correctly and there is a specific
report to generate the product prices according to the pricelist and
the ordered quantities
Prior to this commit, any add 2 cart would rerender the dynamic
snippet, making it flicker and in the case of the carousel, resetting
to page 1.
With this commit, only filters that require the snippet to reload will
do so.
task-2654924
X-original-commit: 7f84a10cc5ff7ba4c65c249dfb2fe546968e2a7c
Part-of: odoo/odoo#80867
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
Dyanmic filters uses ir.filters.
But domain is not exactly the same syntax.
e.g. time.strftime() vs context_today()
So we add a fake action_id to avoid to display these filters on each action
of this model into the backend.
task-2654131
closesodoo/odoo#77021
X-original-commit: f92cfa96b9337fce8451080bffd9b7e40bdedc0d
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit adds new templates for the s_dynamic_snippet_products
and improves the current templates for a better reading of the product’s
title and a better management of space when the content have different
width.
Part of https://github.com/odoo/odoo/pull/75623
task-2602978
X-original-commit: 49bd79b0bdca76415780bdfa199195371c2692e5
Part-of: odoo/odoo#77153
Be safe when we check if data have has_dicounted_price set or not.
In case of sample e.g. in product snippet, it could be missing.
task-2641360
X-original-commit: 0e1d1d519b962476113ae8553f10f85b22561824
Part-of: odoo/odoo#76290
Now you can specify into the dynamic_filter_template the number of record to
use for desktop, mobile, and the number of record to fetch.
Some template have only sense to be shown with 1 record e.g. a full width.
Syntax:
Add on root element one or more of these attributes:
data-number-of-elements="2" -> number of record on Desktop
data-number-of-elements-sm="2" -> number of record on Mobile
data-number-of-elements-fetch="2" -> number of record to fetch
closesodoo/odoo#75662
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This module allows users to be notified by email when a product out of
stock comes back in stock. For that they can add it to their wishlist
and select the appropriate option.
We show out-of-stock warning in all case whatever the show availibility option.
You cannot custom you 'in stock' message ot free message.
Spec of Pde and Fp
Part of https://github.com/odoo/odoo/pull/68221
task-2458165
closesodoo/odoo#68221
Related: odoo/upgrade#2405
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Kersten Jeremy <jke@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
Show discount on product for the dynamic product snippet. The discount is
displayed the same way it is for website_sale.product_item: the price with the
discount and the price without discount in red and strikethroughed next to the
other price. The discount is displayed for all the snippet templates displaying
a price: 'Add Product to Cart', 'Detailed Product' and 'Image with price'.
task-2519662
closesodoo/odoo#73059
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Right now, for notifications handled by odoo (which are being displayed on
discuss app / object chatter), few of the buttons have unexpected scroll
(mostly the CTAs that redirect to record / portal views) and ruins the UI.
This commit fixes the issue by improving such templates by using proper
paddings on the button.
TaskId:2518863
closesodoo/odoo#70083
Related: odoo/enterprise#18225
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to have all mail template into a mail_template_data.xml file
when possible. It eases maintenance and update when having to work globally
on template records.
Also update some ``body_html`` declarations still using ``xml`` instead of
``html``.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Before this commit the recently viewed products were handled differently
from the dynamic product snippet.
After this commit the dynamic product snippet supports the functionality
of the recently viewed products snippet:
- its template used to show each product
- its filter of displayed products
- its "Add to cart" feature (with the animation)
- its "Forget" feature (only applicable when viewing recently viewed)
Also added "Accessories" and "Recently Sold With" filterings.
Several kinds of filtering can be combined.
- Products can be restricted to a given category
- Pseudo categories for all products or current category can be used
- Products can be restricted to matching names
- Products can be obtained from one of the following:
- Newest
- Latest sold: ordered by descending frequency in last 8 orders
- Latest viewed
- Accessories (of the current product)
- Recently sold with (the current product)
Accessories and recently sold with are only available in product pages.
Also, generic templates have been considered useless and the whole
mechanism allowing them has been removed (this includes the
pre-rendering mechanism for the fields specified in the filter).
task-2453416
https://github.com/odoo/odoo/pull/65554
Call _get_filter_meta_data when needed instead to compute it only once and
give it from function to function, it is really trivial to compute and the
api of functions are simple from this way.
Avoid to use h4/h5 taf for styling bug use bootstrap feature for it.
The semantic of <div class='h4'/> vs <h4/> is not the same for SEO
Don't make call_to_action_url required
+ small typo
task-2446024
https://github.com/odoo/odoo/pull/65176
Before this commit the filtering code for the Dynamic Products snippet
was rendering all its values.
After this commit the filtering code for the Dynamic Products snippet
mostly returns the values to be rendered.
Because the list_price still needs to be rendered with the correct
currency, the general rendering mechanism is being informed through the
field meta-data that the escaping was already done.
task-2446024
https://github.com/odoo/odoo/pull/65176
Made the website_id non mandatory on website snippet filters and adapted
the fetching route so that it interprets an unspecified website_id as
the filter being available on any website.
Before this commit website snippet filters had to be limited to one
single website.
After this commit website snippet filters can be made available on all
websites by setting their website_id to no value (this is the new
default of the pre-defined filters).
https://github.com/odoo/odoo/pull/59831
task-2355369
closesodoo/odoo#59831
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Issue
To do on Community:
- Install website_sale (eCommerce)
- Go into Website app
- Navigate through Product/Products
- Edit 'Customizable Desk (CONFIG)' and add '&' and/or '<' and/or '>'
characters into the name
- Save
- Go to the Website app Dashboard and click on 'Go to Website'
- Click on 'Edit' button
- Drag and drop the 'Dynamic Product' snippet into the website
- Click on the block 'Your Dynamic Snippet wil be ...'
- In the right panel, in the 'Dynamic Product' snippet options,
chose a 'Template' and a 'Product Category'
A traceback is shown
Cause
the '&' character crashes lxml.etree.fromstring
Solution
ensure no '&' is sent to lxmx.etree.fromstring by using
odoo.tools.html_escape (in order to ensure no other problematic
characters are sent to the front) on the field values except when
not applicable (widget rendering with record_to_html should not be
escaped).
It is important to note here that this is applicable
to action servers that are used by the dynamic filter.
opw-2357027
closesodoo/odoo#59805
X-original-commit: f91422115c09be484f2868347566b6392ed0effd
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* Prior to this commit, images were only managed when being an image
field. No widget were used either.
* After this commit, image stored in model as url (as res.country.image_url)
can be used when specifying ':image' after the field name. The fields are
now rendered using their corresponding default widget. If there is a need
to force another widget and if the developer is sure that it is compatible,
he/she can specify it using the notation: 'field_name:widget_name'.
closesodoo/odoo#57645
X-original-commit: 18d4e3327c7152b4c3a86ba377e3357f213b703c
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* Implement new snippets that allow the user to choose a filter
and a template.
Three snippets have been created:
- Dynamic Snippet: Displays the data in a grid format
- Dynamic Carousel: Displays the date in a carousel
- Dynamic Products: Let the user pick a product category and
displays the products in a carousel
task-2276740
PR #53175
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Purpose of the task is, we have added the activities on various
listviews, the goal of this task is to update SO/PO/invoice demo data
with activities and also set tags on sales orders.
So in this commit, We added the activity on several SO/PO/Invoices and
also added the some tags one sales order and set the user as False
where the user is set as 'Odoobot'.
closes odoo/odoo#51799
Taskid: 2254708
Closes: #51799
Related: odoo/enterprise#10743
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Previously, there was only one static "Sale" ribbon. Users might want to
have many types of ribbons, for different levels of sales, or to
indicate that a product is sold out. This commit lets the user create
custom ribbons and use them on prodcuts on the shop page. Additionally,
setting a ribbon on a product used to require a reload, this is no
longer the case. All ribbon modifications are stored in a cache and the
RPCs to put them into effect are only done on save.
task-1981170
Part of odoo/odoo#47574
Related: odoo/upgrade#1079
Related: odoo/design-themes#219
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Previously, the "Image full" option was on a per product basis. This is
very strange, because in most cases you either want all of your product
images to take up the entire card space, or none of them. This commit
makes the option into a global option for the shop page, so it can be
toggled for all products at once.
task-1981170
Part of odoo/odoo#47574
Sub categories were missing and will be usefull to test the incoming
enhanced categories filtering.
task-2071602
closesodoo/odoo#37297
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Website sale order confirmation email is broken by design. Indeed it has
jinja markers between html elements that do not allow them, like between
table and tr, between tr, ...
In this commit we completely rewrite the structure to correctly include
jinja markers where they are not moved or stripped by standard browsers
and editors.
Translations are updated accordingly as changing a mail template content
imply updating the whole body translation.
Followup of 74c5c00
website_sale: add website on some demo orders
Purpose is to showcase orders using website field, used notably for some
template rendering.
Forward port of afd173652214000ed and f74c86d448246b796d
closesodoo/odoo#48228
X-original-commit: d3bdb0a42eb052281b4652bf78e82b1c6c1c1d24
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
*: web_editor, website_crm, website_form_project,
website_hr_recruitment, website_sale
The form builder is now using the left panel option system. Many new
options are introduced to build better forms more quickly.
The tests are now running with the new website_form implementation.
Part of: https://github.com/odoo/odoo/pull/42189
task-2092425
closesodoo/odoo#42189
Related: odoo/enterprise#7365
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the cart recovery email displayed all lines of the order
After this commit, the email only shows relevant lines, that is
excluding deliveries for example
OPW 2072814
closesodoo/odoo#37025
X-original-commit: 234c3f56f4c03281f068981cd5af6bc8f5956334
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* account, hr_expense, mrp, sale, sale_product_configurator, stock_account,
website_sale, website_sale_comparison
Before this commit, the `product.attribute.value` were stored on the variants.
This required filtering of attribute lines to find the appropriate matching
`product.template.attribute.value` that were used in most of the business code,
such as when computing the `price_extra`.
This also prevented to have multiple attribute lines for the same attribute,
which is needed to handle use cases such as grape varieties for wine products.
This will be done in the following commit.
After this commit, the combination of `product.template.attribute.value` will be
directly stored on the product variant.
Other changes
=============
Add `combination_indices` on product, which allows to quickly find a variant
matching a combination (1 simple indexed equality query as opposed to 1 query
with as many joins as there are attribute lines), and to add an easy
SQL constraint to ensure active combination uniqueness.
Add active field on `product.template.attribute.line` and
`product.template.attribute.value`, with the same behavior as variants:
They become archived if they can't be unlinked. This allows to keep the database
consistent, such as archived variants correctly keeping all their values, sales
order lines keeping their custom and no_variant. This is done with the help of
`ondelete=restrict` on the corresponding m2m fields, and the `unlink` methods
falling back to archiving when `unlink` is restricted.
Part of task-1912579
PR: #32946
* pos_sale, sale, sale_crm, sale_management, sale_stock, website_sale
Purpose of this commit is replace the confirmation date field with
order date from sale. As order_date and confirmation_date of sale order
are having same value so no need to keep two fields, remove confirmation
field and instead use order date.
cretae_date use as order Date and replace the order_date on confirmation
of the order as confirmation date.
task-2027274
closes: #34571
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
The `website_published` field from the website's mixins is basically a readonly
from `is_published` field.
On read, this field will simply read `is_published` and check if the record's
website_id is accessible (only for the multi mixin).
On write, it will always write on `is_published`.
This commit improves a few things:
- A lot of code was writting on website_published which was just then writting
on is_published. Writting directly on is_published makes more sense.
- Some backend fields would still reference `website_published` instead of
`is_published` which would just go through the related for no reason.
Plus, using `is_published` will make the field tooltip more accurate as we
are not in a website context ('Visible on current website' to 'Is Published')
- Filter and search on tree view were still using the `website_published`
related field, which is just a readonly when we are not in a frontend
context.
- Some create and write function would have security check on
`website_published` value but that was wrong as the user could bypass that by
simply writting on `is_published`. For the write method, check `is_published`
is more accurate as it will cover both case since `website_published` will
then call the write method on `is_published`
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
* = account, mrp, purchase_stock, sale, sale_product_configurator,
stock_account, website_sale
It is always better to create the product template attribute lines before
creating the variants. In a following commit, this will become mandatory.
The variants that are created should always match the combination of attributes
set on the template.
Finally explicitly call `create_variant_ids` when possible instead of reassigning
the attribute lines to implicitly call `create_variant_ids`.
closesodoo/odoo#34122
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Purpose of this commit is to send the order and payment details email to user
when they purchase any order from ecommerce or when do the payment from
portal. Currently it was sending quotation mail when the payment is processed.
Now it send an email for quotation, and one email for sale confirmation that
may contain more detailed content if coming from website (eCommerce).
In sale
* create new confirmation template and set the default template in sales
settings;
* when payment enabled in sales settings then display template option to send
default confirmation mail when payment is processed or order signed;
* add tool method to find the right template to use when sending the
quotation / SO by email;
* ensure email is sent everytime SO is confirmed;
In website_sale
* add option in website setting in order, to set the confirmation mail
template;
* ensure email is sent everytime SO is confirmed;
Related to task ID 1873634
Linked to PR #28781
Since 2d970942ba it is possible among other improvments to have a
pricelist on all website if it has a "code" or is "selectable" and has
no specified website.
Following this, the default "Public Pricelist" is not associated to a
website but since it is not selectable and has no code, we would get no
pricelist on the website on default installation without demo data.
With this changeset, the "Public Priclist" is set to selectable when
website_sale is installed.
opw-1961069
closes#32254
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Romain Derie <rdedoo@users.noreply.github.com>
Purpose
=======
Since we now have the product_configurator in its own module, we can add a bridge module for the website_sale
to override the necessary controller routes in a cleaner way.
This commit just adds the bridge module and move files and code around, there should not be any functional change.
Before this commit:
1. Non Public User would get the main company pricelist returned when calling
`get_current_pricelist`. As this is saved in an `ir.property`
(`property_product_pricelist`) that is not website dependant, that pricelist
would always be returned on every website.
This is a problem if that pricelist is website limited, you should not be
able to use it on other websites.
2. Public User would not have a valid pricelist on other website than the
default one. Indeed, every pricelists are restricted that default website.
It would result in prices shown as "0" (without currency symbol) on the shop
3. Pricelists set as selectable without a website_id set would not be
selectable
4. Public User would not get a fallback pricelist when reading its
`property_product_pricelist`. Indeed, the public user's partner is not
active and since the refactoring of this field compute method to be a multi,
it would end up doing a search() instead of a browse(). Thus, it would find
a pricelist for the public user but it would not set it.
This commit:
1. We override and check that pricelists returnes by the `ir.property` are
indeed available on the current website.
2. Remove the website restriction on `Public Pricelist` so other websites have
at least one pricelist available.
3. `pricelist_ids` on `website` now return all available pricelists including
the ones that are generic (no website set)
4. We search for inactive partners too.
Part of this commit fixes part of 27861
Github-25109
Yannick Tivisse