Steps to reproduce the bug:
- Let's consider two companies C1, C2 and a website W1 in C1
- Set C2 on the payment term Immediate payment
- Go to the shop
- Add a product in the cart
Bug:
A traceback was raised because Immediate was not in company C1
opw:2431705
closesodoo/odoo#65066
X-original-commit: 48ec6f2e4f91e4d1317b246b7017f78746161450
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
1. Create a shipping address
2. Place a SO through backend, and choose that specific delivery
address.
3. Archive that address
4. Place an Order through the website
It is defaulting to the previously archived address, and not to the active one.
opw-2411438
closesodoo/odoo#63668
X-original-commit: 3963e5f6d133eb367e5b24976aa4aff1bdd5d066
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Before this commit Odoo tries to compare an 'account.fiscal.position' id with an 'account.fiscal.position' record.
This causes a 'Comparing apples and oranges' warning in the logs and is not the right way to do this.
This is a fix for d89fa970e8e5b07f1b9a396e6ee02db7fdd136e4 where this issue was introduced
closesodoo/odoo#63029
X-original-commit: d9a1b28144523ece2c6fa4329f3ae4b7ff4a38ec
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Install eCommerce
- Enable debug mode
- Go to Website > Configuration > Websites
- Configure Website by adding a Selection field in "Product Page Extra Fields" (i.e. Product Type)
- Go to Website and from Shop, open a Product
- In Customize menu, enable "Show Extra Fields" options
A KeyError is raised with "selection" key.
By using "selection" widget, the value is processed by SelectionConverter, which tries
to retrieve the text linked to the value by accessing missing "selection" dict in options.
As the feature was originally designed to support "char" and "binary" types, the selection
of extra fields displayable on eCommerce Product page will be restricted to these 2 types.
opw-2378753
closesodoo/odoo#62151
X-original-commit: 87ea687169c9a0047b41b11ab143544142c82aae
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
An AccessError can be raised when checking Fiscal Position of user's last order
if connected user belongs to a different company than the company of the order.
opw-2370903
closesodoo/odoo#61022
X-original-commit: 1b602c1fef0f2d05c94a9547e203ae8ecd24e87b
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
- Install website_sale
- Go to Website > Products > Products and create a Product with "Tax 15.00%" (i.e. Product X)
- Publish the Product on Website
- Go to Invoicing > Configuration > Fiscal Positions
- Create a first Fiscal Position:
* Fiscal Position (Name): Fiscal Position A
* Tax Mapping: Tax 15.00% => Tax 15.00%
- Create a second Fiscal Position:
* Fiscal Position (Name): Fiscal Position B
* Tax Mapping: Tax 15.00% => Tax 0.00%
- Create a Portal User (i.e. User X)
- Go to Contacts and edit User X to set his Fiscal Position to Fiscal Position A
- Connect with User X
- Go to online Shop and add Product X in the cart
- Open "My Cart" => Taxes are displayed correctly
- Process checkout and enter an address, but do not pay
- Disconnect
- Change Fiscal Position of User X to Fiscal Position B
- Reconnect with User X and open "My cart"
- Open "My Cart" => Taxes are displayed as if the Fiscal Position has not been changed
The prices and taxes in the cart are still based on the previous fiscale position.
To fix that, fiscale position of SO will be compared to fiscale position of user,
even if user has not changed.
Howerver, as it is a specific use case, it will only be done if "sale_order_id" is not
in session anymore.
Also the cart from user's last visit will not be reloaded, but a new one will be created,
as it is done when used pricelist is not available anymore.
opw-2300330
closesodoo/odoo#60587
X-original-commit: bd77d0ca35a0ab724d235aca989b9c2357a25caf
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
You can in website's settings, add some extra fields to be shown on the product
page.
E.G. if you want to have the internal code, the barcode, or even a custom field
In case of a binary field, 'Technical documentation' or 'Catalog', you will
have a dowload link.
closesodoo/odoo#55872
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
To reproduce (V12) using a fresh database with demo data:
1. Install eCommerce and Sales
2. Change Mitchell Admin settings so that he can see the 3 companies
3. Go into Settings and set a distinct "Terms and Conditions" text for each companies
4. Go the Website > Configuration, set "My website" to "Company_1" and save
5. Go to the website shop and buy any items
6. Find its corresponding Sale order (should be on Company_1)
=> "Terms and Conditions" used in the SO is the one of "YourCompany"
Analysis:
The terms and conditions are not specified in the SO creation,
so it runs the default value code to determine its value.
However the default code just ask to use the OdooBot company "Terms and Conditions".
https://github.com/odoo/odoo/blob/b6bf91d26b8fb45997b266c16be620d834a97cc7/addons/sale/models/sale.py#L121
OPW-2297114
closesodoo/odoo#55424
X-original-commit: 60565b5cd42da080e36fee5a94bcf8eafd15934d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When a user with access to company A tried to make a purchase on the
website of company B, he would face a traceback upon calling `_get_pricelist_available`.
This happens because we eventually try to access to the current company
(B) while forcing environment of the user (in company A), thus
forfeiting the superuser privileges, which triggers
an access error.
closesodoo/odoo#54891
X-original-commit: 0c38d7f55a48175938803012907a66d394f6c5b3
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
1. Install eCommerce
2. Enable Pricelist settings
3. Choose a product P and enable it in the ecommerce view
4. Create 2 pricelists, for P with:
- PL1: One with "Benelux" as country group with a price of X
- PL2: One with a price of Y
5. Assign PL2 to the portal user (Joel Wilis) through "Website > Customer"
6. Connect as the portal user
7. Go into the ecommerce page of the product P
The pricelist PL1 is used instead of PL2, this occur because
geoIp localisation take priority over customer assigned pricelists.
Fixing filter by allowing pricelist with no country defined to be used
opw-2242152
closesodoo/odoo#51115
X-original-commit: aab3c03b2bdab97796e678d3f876ff64d5ecc4d9
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this fix, in case you try to compute the pricelist_id with another
context, the computed value is set to the website with the new context,
and so another cache.
Now with compute for the env from self, and assign the computed value with the
website with ot without another context.
Before this commit, you was unable to add fields pricelist_id or currency_id in
a tree view.
opw-2233122
closesodoo/odoo#50705
X-original-commit: 2f83c5bad94775a8f85e65c129afdcf503995ecb
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Some apps, once installed, automatically create a menuitem in website.
What complexify the UI and create useless menu withtout plusvalue.
It is not because you install livechat to make support online, that you want
a link in your menu to show stats e.g.
Now we remove the default menu created, and help user to find it when he create
a link. The autocomplete suggest most of the main App's controllers
task-2189613
closesodoo/odoo#49081
Related: odoo/enterprise#9733
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before 13.0, when there is no salesperson on the customer or company or
website, when a ecommerce sale order is done we get the OdooBot as
salesperson because we update partner on sale order in superuser.
In 13.0, since superuser doesn't change UID, the salesperson will be
assigned to "Public User" or the customer that create this order.
opw-2232201
closes#49141closesodoo/odoo#49161
X-original-commit: 0b6a2569920b6584652c39b3465998649fe305b4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- install e-commerce;
- In the website settings, orders followup, set a salesperson;
- By something as a public user;
- Pay the order.
Before this commit:
- 2 emails where create to assign the salesperson to the SO, but these
emails didn't have a from and the salesperson didn't receive the
emails.
- 1 email was also create to assign the salesperson to the contact, this
mail is not necessary.
Now, only one email that assigns the salesperson to the SO is sent,
with a correct from address.
opw-2189683
closesodoo/odoo#44861
X-original-commit: 7c08eb158858b9573d3d84a0b54df0bfca754105
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Steps to reproduce the bug:
- Go to Settings > General Settings
- Set "Customer Account" on "Free sign up"
- Go to Website > configuration
- Activate "Digital Content"
- Create a fiscal position FP with a coutry group CG and applied automatically
- Create a service product P with digital content DC at sales price = 0
- Publish P on the website
_ Log out and go to the shop with public user
- Add P in your cart
- Process the your Order in the shop
- When the order is confirmed, click on "Downloads"
- You will be redirected to the login page
- Click on "Don't have an account?"
- Fill in the form and sign up
Bug:
Nothing happened because in function sale_get_order in model 'website'
the partner on the confirmed SO was not the same as the new one and so
update_pricelist was set to True and a call to function _cart_update was
done on a confirmed SO. Inspired from function _cart_update in model
'sale.order'.
opw:2146902
closesodoo/odoo#43362
X-original-commit: 1f6a4e56442ba5531f87269ab032f99218fc45a2
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
PURPOSE
Test frontend and UI tools of eLearning.
SPECIFICATIONS
Commit fe518f1fea introduced a search on sale order model in checkout
process. However this may fail as access rights are not always granted
* portal users can see orders linked to their company;
* salesman and a lot of specific groups (accounting, ...) can see their own
orders, all orders, or depending on some condition;
* BUT standard users (employee only for example) cannot see any sale order.
Indeed they do not even have right to read, meaning a search fail. Let us
sudo the search as this is contained in a sub method used to fetch some
data.
LINKS
Task ID 1937768
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Since forward-port, `/sale/get_combination_info_website` and `_cart_update`
would lead to a concurrency error.
Indeed, the session would not have an order_id at first. Then both rpc would
be sent at the same time:
- `cart_update` would create an order and add it in the session
- `/sale/get_combination_info_website` would end up calling `_compute_cart_qty`
which would call `sale_get_order` and would set the `sale_order_id` to none,
just aftet the `_compute_cart_qty` would actually add an order in the
session, simultaneously.
closesodoo/odoo#33993
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
1. Encapsulate `show_visible` to avoid duplicate same code in filtered and to
make it more easy to read.
2. When GEOIP is enabled, `_get_pl_partner_order` would retrive the available
pricelists for that country group.
We should also ensure the returned pricelists are also available on that
website
3. Rewrite the `country_code` condition in one line thanks to 1.
4. !! Do not use `property_product_pricelist` in the method as it is not cached
and now it depends website. Anyway it was useless as it was a duplicate of
`partner_pl`.
5. Add `is_public` to the if condition as it was actually implicit as if not
public it and no pricelists it would go in previous condition and set the
pricelist from `property_product_pricelist`.
6. The last if condition (`not country_code`) has always been subject to fixes
and always broke a flow to fix another one (see 60300fc2 and e11908d42, both
were wrong).
This condition refactoring should still preserves the beavior fixes
mentionned in both commits and fix the flow where a logged in user would not
get selectable pricelists if he has a partner_pl (property_product_pricelist)
before entering the all_pl filtered.
closesodoo/odoo#28301
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, when accessing an user's pricelist, it would raise a 500
error in multi-company environment.
Indeed, when doing `self.env.user.partner_id.property_product_pricelist`, even
if self.env is not un sudo mode, the compute from `property_product_pricelist`
is executed as sudo. Since this method is then doing a `search()`, it won't use
the multi-company pricelist ir.rule. It will return all the pricelist,
including the ones from other companies.
Then, when trying to read that pricelist, it will raise an access error.
Now, we correctly execute the compute (and so the search) in the user env, it
won't get pricelists from other companies.
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
The `_get_pl()` method introduced with bcb395616 was replaced by
`_get_pl_partner_order()` in afe1d20dac.
After that, it looks like this method was never called again.
Plus, add a missing ensure_one() (not critical).
Before this commit, at multiple places to check if we were in a frontend
context we would check if `request and hasattr(request, 'website')` and
then access `request.website`.
Now, we call an utility method to get that website if we are in a frontend
context. If not the method will return False.
This method will be usefull for incoming pricelist fixes & tests.
Indeed, we will have more check of that kind and this will be easier to mock as
mocking this method will be enough, instead of mocking every method doing that
if condition to simulate a frontend context (to do website tests in python
wihout having to go frontend with a tour).
Reason:
*Sales team configuration is too complex with fields you
don't understand and that bring no added value
*Remove the team type, every team should be able to handle
a POS or a website for example
Contains:
*Removal of the team_type, use_quotations, use_leads fields
*Removal of the graph configuration fields
*Adapting the filters that were based on the team_type
*Clear distinction between the team dashboard behavior in crm
from the one in sales
*Cleansing of now dead code due to the removal of the previously
mentionned fields
Task: #1830105
Enterprise PR: #3006Closes: #28063
- When creating an eCommerce cart using the Public User, the code tries
to access all the sale orders linked to it.
Depending on the count of sale orders linked to the partner, the
loading can take a lot of time.
To avoid this, we only search for the sale orders of connected users
and we only retrieve the last one.
Goffin Simon