Before this commit, copying a template with variants would not copy the
attributes lines, so it didn't work as expected.
closesodoo/odoo#34128
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Create a new product, but don't save it just yet
give it a name,
Add some packagings
Save
Before this commit:
- the form to create the packaging had a mandatory product_id field
which is useless in a x2m context (fixed in v11.5 with a6557a2306)
- the packages disappeared after save
This was because at template creation, all "real" fields that are on
its variants must be manually set after the creation, including packaging_ids
OPW 1970589
closesodoo/odoo#32925
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
we have changed the product name from Sale Description to
Description For Customers considering the same logic used in
other product namings and to make it more readable.
task-1987076
closesodoo/odoo#33554
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the code would try to loop over all possible combinations
following their sequences, until it found the requested one, which could be
extremely slow if there was a lot of combinations.
Now if the given combination is possible, we skip that useless looping and
yield it directly.
To reproduce this: create a product template with millions of possible
combinations (using dynamic attributes) and try to add to cart a combination
that would be found late in the looping. Before the commit, the request would
take too much time.
opw-1958623
closesodoo/odoo#32433
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This has several advantages:
- make the code easier to maintain by having the logic only on the python model
- prevent price flickering when changing from/to an impossible combination
- fix the UI for the issue mentioned in the previous commit/the opw
- make the code much faster when using many combinations, by not requiring to
browse and to return every existing and every archived variants
The opportunity is also taken to properly throttle the rpc and to use
"DropMisordered" on its result:
- fix all the other remaining flickering when changing quantity or combination
- fix the server being spammed of rpc when using the configurator modal, but
also in a lot of other cases such as incrementing the quantity, ...
- fix UI consistency by ensuring the result of the last rpc is always the one
displayed, obsolete rpc returns are ignored
By computing the possibility of the combination asynchronously, the two
drawbacks are:
- the UI is a bit less reactive than in the previously the best case scenario,
but this almost completely mitigated by debouncing with a leading call
- it is possible for a quick user to click on "add to cart" on an impossible
combination before the return of the rpc, but this is not really an issue
because when the product will be added to cart there will a check and the
closest possible combination will be selected automatically instead
Finally the event of the configurator mixin and the widgets using it have been
cleaned to avoid the duplication of the rpc in the first place.
opw-1959317
PR: #32691
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, if multiple variants exist for the same combination it would
consider the combination impossible if any of the variants was archived.
After this commit, it will consider the combination impossible only if all the
corresponding variants are archived.
opw-1959317
PR: #32691
When you import a variant or when you archive variants to only leave
one tied to the template, the image of the variant can't be changed.
If the variant has a picture and you archive all the other variants,
when you change the image on the variant, it's the template
image which is modified.
opw 1974727
Task#1963256
Some fixes for the product configurator recently introduced a bug
in the product template's _name_search method.
Commit: 99bae2cdb7
This commit correctly handles the fact that the "limit" parameter
can be None.
closesodoo/odoo#32363
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = website_partner, website_profile, website_sale, website_slides
Before
======
Since commit: 2e3848b394
The images that are resized have additional borders if the target ratio is
different than the image ratio. Those borders are transparent if the image
format supports it, and are white otherwise.
With that current solution, if the background where the image is displayed is
another color than white, it is looking really bad.
Moreover, most images are stored resized like this, so it is not even possible
to decide if it should have borders or not depending on the context, the
original image and ratio is forever lost.
It is also inconsistent because if the image is already smaller than the target
size then it doesn't include borders. In that case it keeps the original ratio
instead of the target ratio. So it isn't even guaranteed that the target
ratio is going to be respected.
After
=====
This commit will solve all of those problems by always keeping the ratio of the
original image.
This implies the views should be taking care of adding borders when necessary.
task-1958000
PR: #31811
- Create 2 companies A & B
- For a product P, create a supplier info for each company using the
same partner, with a different price and delay.
- Order the supplier so that the one for A has a higher priority than
the one for B.
- Create a reordering rule for P in company B.
- Run the scheduler as admin (e.g. thanks to the cron).
The price taken is the price for company A instead of B.
`_select_seller` is not company-aware, therefore the first matching
supplier is chosen.
opw-1959263
closesodoo/odoo#32328
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When a new `product.template` is imported with `active` set to `False`,
the associated `product.product` is active.
This is not consistent with what happens in the UI: when a template is
archived, all variants are archived.
At variant creation, we keep the `active` value of the template.
opw-1955116
closesodoo/odoo#32461
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Targets commit d3530eb07e
Purpose
=======
- The _name_search of product.template fallbacks by default on product.product
In case there are no product.products yet (dynamic product variants configuration), we need to
include the base product.template _name_search in the results
With the demo data:
- Go to Sale > Products > Products, search for 'Customizable Desk'
- Click on 'Configure Variants'
- For variant 'Legs: Steel', remove the attribute values for the
'Conference Chair'
- Create a SO, add a line with 'Configure Product'
- Select the 'Customizable Desk' with 'Legs: Steel', add
The 'Conference Chair' is displayed in the 'Available Options', while it
shouldn't.
The methods `_get_own_attribute_exclusions` and
`_get_parent_attribute_exclusions` compute the exclusions based on the
attribute values. Since there is no values in our case, the exclusion is
not taken into account.
We add a specific case to search for exclusions without values.
opw-1945460
Before this commit the flow of using wishlist with dynamic attributes was not
tested, and it also wasn't tested when combinations were not possible.
Those cases are now tested too.
closes#29859
PR: #31752
task-1920065
Signed-off-by: Sébastien Theys <seb-odoo@users.noreply.github.com>
Before this commit, if the website's company was different than the user
company, the ecommerce would use the user's company instead of its own
pricelists.
Step to reproduce:
- Set company2 to website1
- Create a pricelist1 for company1 and a pricelist2 for company2
- With an user from company1, visit the website1.
- The pricelist used will be the one from the user, pricelist1 and not the
pricelist2 from company2 which is the website1 company.
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
When creating several attribute lines for the same attribute, the function _update_product_template_attribute_values
in model 'product.template.attribute.line' only kept the product.template.attribute.value records of the last
created line. So it generated issues with the product configurator because no value was founded for certain attribute line
in function _get_possible_combinations defined in model 'product.template'.
Now it's forbidden to create several attribute lines for the same attribute.
opw:1950786
closesodoo/odoo#32086
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Backport of d3d58b60dc
Only the variant is using this code, so it was a bad idea to make the mixin
more complicated than it had to be.
Update the image tests to make sure this is working correctly. The test were
only testing the size of the images, now they also test the actual content.
Part of task-1949729
Original PR: odoo/odoo#32253closesodoo/odoo#32814
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Only the variant is using this code, so it was a bad idea to make the mixin
more complicated than it had to be.
Update the image tests to make sure this is working correctly. The test were
only testing the size of the images, now they also test the actual content.
Part of task-1949729
closesodoo/odoo#32253
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Task #1891970
Original p. configurator commit d3530eb
Purpose
=======
- The p. configurator now comes with a widget that is "o2m" like in the SO lines view.
The widget is only used on the added "product_template_id" field on the SO line.
This widget controls the opening of the configuration window and removes the need of a "Configure a product" button.
The "SectionAndNoteListRenderer" is now cleaned from p. configurator specific code.
The widget is also responsible for handling the configuration provided by the p. configurator form
and applying it on the SO line with a 'field_changed' event that updates all the necessary fields.
- Added support for 'MULTI' and 'DELETE_ALL' operations on X2Many fields in basic_model.js
- 'MULTI' allows to batch multiple operations at once
- 'DELETE_ALL' behaves like 'DELETE' with all the current data of the field
Spec
=======
- remove "configure a product" from sale order lines
When the product configurator is active, replace the product_product_id by a product_template_id
in the sale order line. When we select a template without variants, it sets the variant automatically,
but when we select a product template having variants, it opens the configurator dialog.
- add a widget to modify the product configuration in the sale order line (next to product template field)
- UX improvements:
- Invert image and configuration in the main screen
- If the product doesn't have an image, hide it instead of showing the placeholder (only for first screen?)
- new independent option in sales settings to activate product configurator.
(same in e-commerce)
- demo data: Change demo data to set Customizable Desk & Conference Chair as make to order
- If only one attribute value that is Custom, don't display radio, selection or even color box
Purpose
=======
- Moved the product_configurator into its own module now that we have a specific option for it.
The option only enables the p. configurator in the SO form.
The e-commerce should always allow customer to configure their products, even if the option is not checked.
This allows moving some of the code specific to the p. configurator into its own module.
However, a lot of the code has to remain in "sale" module since the e-commerce does not require the option
checked and needs the "configure product" feature in the shop by default.
(This is why the fields "product_custom_attribute_value_ids" and "product_no_variant_attribute_value_ids"
are still in the "sale" module)
Targets commit d3530eb07e
References task id 1891970
Purpose
=======
- A message will be displayed when hovering a disabled attribute value's input to explain why it's disabled.
e.g: Not available with Color: Black
This works for both exclusions within the product and exclusions from a reference product.
- The exclusions will work in both sides, if "black" excludes "metal", "metal" will also exclude "black".
Christophe Simonis