Steps to reproduce the bug:
- Let's consider a sellable product P published on the shop
- Let's consider a portal user PU adding P in his wishlist W
- Set P with sale_ok = False (meaning unsellable)
- With PU try to see W
Bug:
A 430 error was raised because the product P was not sellable
opw:2362184
closesodoo/odoo#60540
X-original-commit: 8646b0049808036422fec200163a8a4ff1d0df43
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
*: website_sale, website_sale_wishlist
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
X-original-commit: 77d82cfbddb64cc7302672c7741eb65c9fc4a125
*: portal, website_sale, website_sale_wishlist
Portal-without-website header is now more basic, without the need of
a collapsed element. It is then entirely replaced when website is
installed with header templates, t-calling all the main parts.
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
X-original-commit: d3d5983e0a76eb6500e0d3f78f128879b50390e0
Co-authored-by: qsm-odoo <qsm@odoo.com>
1) Allow to enable the wishlist button on the shop page and the product
pages individually. Also remove the code which allowed to disabled
the feature entirely but keeping the module installed: if users don't
want it, just uninstall the app (the feature was in website_sale
directly at some point).
2) Add a new option to be able to show the wishlist counter even if no
item has been added in the wishlist yet.
3) Move the feature in external views to be able to be placed at a
different location depending on the header template.
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
X-original-commit: de97be253a54648ebd392f7f4f66ef16cc72b8af
Co-authored-by: Cocographique <nmi@odoo.com>
Allows accessing various keys, especially whether this is an
interactive login or not.
Also have the xml-rpc `login` delegate to `authenticate` instead of
having its own half-assed implementation.
And remove some dead code: as far as I can tell, Session.authenticate
is never called with a uid.
The ir.autovacuum model purpose is to run several garbage collecting
operations like removing files from the filestore when no attachment
references them anymore.
The precedent strategy to register new garbage collection tasks was to
override the `power_on` method and to imperatively execute a vacuum
cleaning method on a given model. All calls were executed in a single
SQL transaction without any error handling, meaning a single fail during
any call resulted in a complete failure of the entire vacuum cleaning
chain.
We introduce a new `@autovacuum` api decorator, its purpose it to
register garbage collecting methods that will be safely executed in
their own transaction by the vacuum cleaner. In order to ensure this
new strategy is used, we deprecate `power_on` extensions.
By the way, garbage-collecting methods can be quite heavy and we don't
want users to directly call them. We now ensure they are private.
closesodoo/odoo#47842
Task: 2154079
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.com>
*: portal
Adding a choice of several header behaviors (fixed, fade out with
scroll, etc.). Review the way those animations works in mobile/desktop
and now perform them without duplicating the header DOM element.
Also allow to hide of adapt the size of the logo when the page is
scrolled.
Part of https://github.com/odoo/odoo/pull/38950
task-2087641
Co-authored-by: qsm-odoo <qsm@odoo.com>
ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.
Currently, we are allowing to select the other company's product as
an alternative product or accessory products on the product.
For example,
website: W1, W2
company: C1, C2
W1-> C1
W2-> C2
Product: P1
===========
company: C1
Product: P2
===========
company: C2
alternative product: P1
And this will give a traceback because we are going to use another company's
products. And this is obviously a wrong behavior.
That's why put a specific domain on the alternative, accessory and optional
product fields to fix this multi-company issues.
Now product wishlist will be also a company-specific.
task-2070522
closesodoo/odoo#44011
X-original-commit: 800abfc7baa8461f6b7b5ece95fa7700d3cd872a
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Steps to reproduce:
- Install website_sale_wishlist,stock,sale_management,contacts
- General Settings>Sales>Multiple Sales Prices per Product
- Create or edit a product, assign 2 different prices in pricelists A and B
- Publish it to the website
- If your user is Mitchell Admin, go to its related res.partner, Sales &
Purchases tab/Pricelist, choose pricelist B
- Create a public user and assign it pricelist A
- Go to the website/shop
- Reach out the product and add to the wishlist
When the current user is internal the product page will display price of B,
but if you add the product to the wishlist, whishlist displays public price
Same for the portal user.
This happend because to avoid returning 500 when the product is
unpublished c93f371d67 the product is
filtered using sudo() but the recordset is also returned with the sudo
environment. Using it just to filter solve the issue
opw-2166484
closesodoo/odoo#43646
X-original-commit: 4335f9dbf21447f717874b2d65552dd67c634df0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When loading a page on an existing starting database, registry is not
fully loaded causing potential error when trying to access model
existing in database (views, menitem, ...) since model added in last
loaded module does not exist in registry.
Thus, executing browser js test may lead to errors when executed during
an update on a database with other modules installed.
HTTPCase should be executed post_install to ensure that registry is
fully loaded to avoid this problem.
Since HTTPCase are slower than other test, it is also a good idea to
execute them at the end, in order to prioritize fast fail.
With this commit, a warning is isued if such a test class is tagged to
run at install time.
While at it, remove deprecated at_install and post_install helpers and
remove the deprecated phantom_js alias.
closesodoo/odoo#39462
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Since 11.0 88b75f150 the wishlist can't contain duplicates: thus if we
remove an element from wishlist (by adding it to cart or removing) there
is an error next times it is added (since the product is already in
wishlist but archived until next garbage collection).
opw-2074843
closes#37255closesodoo/odoo#37287
X-original-commit: 0b085ce0800f410d5f88615fd18bd633c0d48fb5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
* = point_of_sale, sale_management, sale_product_configurator, stock,
website_sale, website_sale_comparison, website_sale_wishlist
- Remove Attribute Values menu to ease onboarding because everything can be done
more cleanly through Attributes menu.
- Remove unwanted new lines from help texts.
- Hide color fields when attribute type is not color.
- Move Attribute "Related Products" into a tab because it is less important than
the rest of fields.
The opportunity is also taken to rename the `type` field of `product.attribute`
to `display_type` to better convey its meaning.
task-2058142
closesodoo/odoo#36313
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*= website, website_livechat, website_rating
///// Tracking Product /////
Now when a user browse products in eCommerce, we keep track of the
products he looked at. We use the website_visitor
to store the products viewed. A cookie is added with a TTl of 30 min it
will prevent the RPC for that time. We track the page only if the
product view is tracked.
The recently viewed products are displayed as a snippet but also
with the customize option in product pages of website_sale.
Products that are in cart will not be returned as recently viewed.
It is possible to add a recently viewed product to the cart directly
from the carousel, it will not redirect to the cart. If we are on the
cart page, the product is displayed in the cart.
The Visitor page in website now references products viewed
///// Tracking Page /////
Feature to track a view was remove in: https://github.com/odoo/enterprise/pull/4834
That feature is now reintroduced and will use website_track instead of
leads to be stored.
The track field is now on the view instead of the page.
url field is added to website.track, it will store the url for pages and
views
The Visitor page in website now references urls viewed
Add some tests
task-1984575
closesodoo/odoo#35810
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Slovenian language, as many others languages, is not present in the
beta/master projects in Transifex.
For some reason, Transiflex removed all current translations, this was
already fixed in 12, but as there are not automatic forward-port for
translations, this is a manual forward-port.
opw-2060055
closesodoo/odoo#36374
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, every model having website_id would have the default
`set null` as ondelete value for that field. Exception for `ir.ui.view` and
`website.redirect` which are set to `cascade`.
This meant that deleting a website would basically transform all its specific
records into generic ones.
That would lead to unwanted behavior, such as multiple `ir.attachment` with
same URL, when 2 websites had been theme-customized. Deleting one of the
website would result in later crashes when trying to open theme customization
in the remaining website(s), since those website would find their specific scss
custom attachment as well as the generic one from the deleted website.
Probably more behavior might be problematic when deleting a website before this
commit.
To summarize the choice of this commit implementation, every model not existing
outside website module are set to `cascade` (website.redirect, website.menu,
product.wishlist..).
The rest should be in restrict, as we don't want to delete a whole forum, blog
or job, which should probably be managed case by case to decide what to do.
Thus, restrict is a good choice to notify user of what should be handled.
Some exception remains, ir.ui.view should be delete on cascade while sale.order
should be set to null.
opw-2038414
opw-2035249
closesodoo/odoo#35398
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Goffin Simon