This reverts commit 3b9401c354.
It shouldn't have been merged in the first place. The PR was `r-` but it
seems like the mergebot bugged and still merged it because there was an
occurence of `r+` in the sentence which asked robodoo to `r-`.
> robodoo r- just to be sure, since there was a random r+ not [...]
Rationale of the revert:
- Bad field name:
- "ecommerce" in product module
- "ecommerce" but used in POS
- Arguably very low value to share the field -> This field is used in
ecommerce to add info exactly between the price and the name of a
product. There is low chance that you want to share that exact
information with the POS.
- Technically, it couldn't work. What you design in website builder on
the product page is related to website assets JS and CSS, which are
not loaded neither in the backend and neither in the POS.
It was leading to multiple critical issues, mainly:
- Losing the whole style of the content (CSS)
- Breaking completly the snippets (visually and design wise) (CSS/JS)
- Not even show (JS is in charge of showing the content eg)
Note that the same issues were already existing in that field in the
backend (it's shown in the product form view). The ecommerce team was
looking for a solution to make it work, but it's impossible as to work,
it would need the website / frontend assets, which can't be loaded in
the backend / POS.
The cancel of this PR was validated with PO of POS and ecommerce
following those explanation, which they weren't aware of.
Apart from this revert, further PR will be done to:
1. Remove the field from the product form view (ecommerce app)
2. Create a new field for POS
Revert of https://github.com/odoo/odoo/pull/136906
task-3524272
closesodoo/odoo#137514
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit adds a popup to show product information when clicking on an
info button in the product card in the self order app. The popup shows
the ecommerce description and the name of the product.
The ecommerce description field has thus been moved from website_sale to
the product module so that the pos_self_order module can use it.
closesodoo/odoo#136906
Task-id: 3524272
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Several reports don't include product packing info on them. This is
useful for customers to see that what they bought matches what they
expected and for pickers who need to know which product packaging they
should be selecting from stock. Reports this was added to are:
- Sales orders,
- purchase orders (including RFQs),
- picking operations,
- delivery slips.
Note that we purposely exclude backordered moves since they weren't
deemed to be necessary at the time this feature was created.
Also includes light refactoring to remove repeated code for conversion
of product qty to packaging qty and to make it easier to do this
conversion in the future (i.e. can pass product.packaging without
original record that it was assigned to)
Task id 2927379
closesodoo/odoo#96858
Signed-off-by: Steve Van Essche <svs@odoo.com>
Some clients use the same barcode for products in different companies,
with different configuration. It is inconvenient for those users to have
to ensure the uniqueness of barcodes across all companies.
This commit will allow products to have duplicated barcodes, as long as
they are assigned to different companies. Products without a company are
treated as belonging to all companies. Product variants require unique barcodes.
The validation needs to be triggered both on barcode and company_id, so
product template (where company_id is stored) was also adjusted.
NOTE: when a barcode is duplicated in 2 companies, an attempt to remove
both the company and the barcode from a product will result in an
error, despite the fact that a product without a company and a barcode
would have a correct configuration. This happens because the barcode
uniqueness check is performed before changing the barcode, but after
changing the company. A workaround for this problem is to remove the
barcode first, save the product, and remove the company.
Task: 3290154
Related task: 3270732
Related: odoo/enterprise#42541
Part-of: odoo/odoo#122511
[A previous
commit](https://github.com/odoo/odoo/commit/5ca1da8ab33d4dd6a9ed0b6737e5d19f1a3ac9d2)
introduces a new attribute `display_type`, `multi`, which allows users
to define extra-options to products. But this option was only available
in Sales.
This commit allows eCommerce users to use this new attribute in the
online shop.
task-3497046
closesodoo/odoo#135174
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In this commit
==============
- Added the discount fields to the vendor pricelist and PO line models,
making them optional and hidden.
- Implemented automatic filling of the discount field on the PO line when
the unit price is sourced from the vendor pricelist.
- Implemented a mechanism to automatically populate the discount field on the
PO line when the unit price is fetched from the vendor pricelist.
- Modified the pricing logic to ensure the discount is applied to the
tax-excluded price.
- PO confirmation process to check if a pricelist already
exists for the vendor. If not, a new pricelist line is created, including the
discount if it is present.
task - 3380306
closesodoo/odoo#126804
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
1) fix automatic creation of documents when attachments are added
to product templates/variants chatters
2) fix duplication of documents
3) fix deletion of documents
Delete child record before deleting parent record.
Before this commit, when trying to delete a product document,
we deleted the parent record first, before trying to delete
the child, which had been deleted (cascade) already.
Part-of: odoo/odoo#135894
In this viewtiverse, the heroes remove the context dependencies for
`get_views`, from the views and python fields (such as domain). To reduce
inconsistencies and the number of rpc.
Current issues:
* There may be inconsistencies in views at the JavaScript level. Some
overrides modify the behavior of get_views or domains on fields via
context keys, therefore by changing the action, the rendering may be
different. However, these views are cached. However, the cache key
(Javascript) does not reflect the entire context, and requires additional
post-processing from the server.
* Multiple rpc for the same rendering. get_views being dependent on the
context, as soon as it changes, a new rpc is performed. In most cases,
when JavaScript needs the same view, there is no change depending on the
context, the rpc is useless.
* Inconsistency when rendering subviews, some views could be different
depending on the context, this context can be modified in the view itself
via the context attributes. However, the JavaScript client does not redo
an rpc for each change of these sub-contexts. Therefore the result may be
inconsistent.
Solution:
Limit as much as possible the number of context keys provided when calling
get_views, and use the context provided as a cache key. The authorized
keys are 'lang' and '*_view_ref'. For the cache key, options are added in
the get_views method.
Instead of using the context, it is inserted into python expressions.
This will be evaluated by JavaScript and thus avoids inconsistencies.
task-3414108
task-3414068
closesodoo/odoo#135145
Related: odoo/enterprise#47584
Signed-off-by: Raphael Collet <rco@odoo.com>
This method & logic is not used nor necessary anymore with
the multi-company fixes and improvements done in the recent years.
* All requests coming from website are automatically done in the website
company.
* check_company restrictions forbid the use of records from different companies
* multi-company security rules restrict the access to records from the current
company.
Part-of: odoo/odoo#121986
Currently the user cannot modify the order as he adds new attribute to the product.
In this commit he will be able to do that
task-3451377
closesodoo/odoo#131514
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently there is no efficient way to suggest extra-options to
customers in PoS or eCommerce. Extra options should be easily selected
by customers (or PoS waiters) with checkbox. Each checked option would
add an extra-price to the product price and appear on tickets,
receipts, invoices, kitchen display, ...
This commit introduces a new type of attribute: multi-checkbox. This
will not create product variants. A default extra-cost is defined at the
attribute level, but it can be changed at the product level.
The new attribute is available in Sales, not yet in eCommerce nor in PoS
(it will be in a future task).
task-3256585
closesodoo/odoo#130915
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Introduce new model of "Product Documents" to hold documents linked
to a given product template/variant, displayed on:
* quotations
* confirmed sale orders
* e-commerce product page
This will also replace the previous "Digital Files" (website_sale_digital)
logic & module, which allowed to specify product documents available
to customers after the SO invoice was paid.
This exact feature will be lost after upgrade, since we only keep the
choice to link documents on quotations/orders, but:
1) on e-commerce, carts are supposed paid when confirmed
2) on portal, the "Online Payment" settings makes sure the users
have to pay to confirm their quotation.
therefore we consider new configuration sufficient, without needing
a "paid order" choice as well.
task-3249201
Part-of: odoo/odoo#132739
__Current behavior before commit:__
`_get_own_attribute_exclusions()` returns the product template attribute
value (ptav) even when `ptav_active` is **false**. This makes the
frontend crash when we add a product that has such ptav to a sale
order.
__Description of the fix:__
Prevent ptavs with `ptav_active = false` to be in the result of
`_get_own_attribute_exclusions()`.
__To reproduce:__
1. Create new Product template
1. Add 2 attributes with at least 2 values each
1. Click on the Configure button next to the first attribute line
1. Click on the first attribute value
1. Add an exclusion line for the newly created product template and one
of the value from the other attribute
1. Put `ptav_active` of the ptav to `false` (not sure how to do it
except from the ORM but one customer managed to do it)
1. Try to add the product to a sale order line
1. `TypeError: Cannot set properties of undefined (setting 'excluded')`
opw-3466451
closesodoo/odoo#133808
X-original-commit: cf58369310f13377cd70794bf777f4e9198f643a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The product configurator can have irrelevant disabled options if the
product selected has some archived variants
Steps to reproduce:
1. Install Sales and Inventory
2. Create a product with two attributes, each with two values (e.g.
Color: C1, C2 and Weight: W1, W2)
3. Open one of the variant, add some stock then archive it
4. Delete the attribute Weight from the product
5. Create a SO for any customer and add the product
6. The product configurator dialog opens but the C1 color is unavailable
Solution:
Only return the archived combinations for which all of the attribute are
still used in the product
opw-3427753
closesodoo/odoo#132420
X-original-commit: d5cd215dcf1b7e633c86ad734274a65827368ade
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Steps to reproduce the bug:
- Enable “Product packing” in the inventory settings
- Create a storable product “P1”
- Add a package with barcode “123”
- save the changes
- Delete the package
- Try to set the same barcode “123” for the product
Problem:
A validation error is triggered: "A packaging already uses the barcode"
Solution:
When we delete the package from the product, we have to delete
completely the “product.packaging" record.
opw-3378288
closesodoo/odoo#131825
X-original-commit: d01d8a9cedec2d1c17469538103340fc934470f1
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
The default pricelist automatically created for companies if the pricelists
are enabled should (like it was before with the Public Pricelist record in
the data) take precedence over newly created pricelists record.
This can be enforced by creating the default pricelist with a higher priority
(lower sequence).
closesodoo/odoo#130232
X-original-commit: ea1e83514bd6190a516f2cf92f800625876b789e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
use product tags to display information as color/image on the product
page, enable filtering by tags, add tags to specification/comparison
table. Remove the link between ribbons and tags because there is no use
as we are able to show the tags on the page, add ribbon to
product.product
task-3299538
closesodoo/odoo#124299
Related: odoo/upgrade#4824
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
If an inactive currency is given as company currency write values,
it is unarchived, but before the company update.
Therefore, if the unarchiving of the currency enables the multi-currency,
a default pricelist will be created for the company, but with the wrong
currency since it still wasn't updated.
This commit postpones the automatic creation of pricelists after the update
of the company, making sure the currency of the pricelist is the expected one.
opw-3423706
closesodoo/odoo#128958
X-original-commit: f7c90e4e1c5b6a3335e7c9b9e209a786d4238434
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Current behaviour:
After archiving the public pricelist (14.0 to 16.1,
as 16.2 does no longer have a public pricelist),
when creating a new pricelist, it replaces the previous
pricelist with all partners.
1 Second pricelist
2 First pricelist
Expected behaviour:
New pricelists should go after the previous one
1 First pricelist
2 Second pricelist
Steps to reproduce:
1. Go to settings, activate Pricelists
2. Head over to Sales->Products->Pricelists
3. If applicable, archive the public pricelist
4. Create a new pricelist (named 'First')
5. Create another pricelist (named 'Second')
6. Go to Contacts, select any contact
7. In Sales & Purchase see Pricelist
8. Second pricelist is set, should be First
Cause of the issue:
_order is set to "sequence asc, id desc"
Since new pricelists have a sequence of 16 by default,
new pricelists (with a higher id) get placed first.
Fix:
New pricelists without a sequence number get sequenced based on the
highest sequence number in existing pricelists
opw-3282880
closesodoo/odoo#121441
Related: odoo/enterprise#43591
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
One of the main issue with ormcache is that the invalidation clears
everything, meaning that some value, slow to compute but with a long
lifetime, can be removed from the cache because an easy to invalidate
value is cleared, like after writting or creating a product has an
example.
Most example in the code will try to invalidate the cache of the models
doing something like `env['ir.qweb'].clear_caches()` but it is
finally equivalent to `env.registry.clear_cache()`, and cross worker.
The idea is to have multiple cache, maybe with specific sizes for a
specific purpose.
Having one per model is maybe a bad idea because it will be difficult
to size the LRU correcly, and it is too dynamic. Checking invalidation
may be expensive.
The proposed solution is closed allow a limited number of named caches,
using onse sequence per cache. This is actually close to the
cache_longterm.
We want to discourage using a specific cache for one use case in
the buisness code. Adding a cache shouldn't be something easy, doable
in stable.
Note that we could also change the invalisation mecanism using an
insert only table. We an check the sequence of this table, but also
fetch all invalidation messages.
Another possible improvement, especially if we have more than x cache is
to have a global sequence, checking signaling would mean to check the
main sequence, and only the other ones if the main one changed.
Note that this poc is inspired from the long term cache but not all
use case where applie yet.
Part-of: odoo/odoo#119813
Steps to reproduce:
1. Create a product "My Test Product" (no attribute)
2. Create a quotation, select the "My Test Product" product and confirm the sale order
3. Go back to product and add an attribute "Size" with values "L", "XL"
4. Create another quotation, select the ""My Test Product" product => crash
We consider archived combination of attributes as forbidden combination in
the configurator, but when the archived product doesn't have any attribute,
the `archived_combination` was an empty list, which wasn't supported well
by the product configurator logic (client-side).
To quickly fix this issue, we can simply stop sending empty archived combination
(i.e. when the archived product had no attributes).
opw-3410383
closesodoo/odoo#127335
X-original-commit: ca1ac1a115fe06a0a2d2de0fb131a58019f73631
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Field `product.product.lst_price` is not recomputed after changing
`product.template.attribute.value.price_extra`.
Computation of `product.product.lst_price` is not triggered because
`product.product.price_extra` is not recomputed because of the missing
decorator.
closesodoo/odoo#126968
X-original-commit: c7034cb9973532da8011f5fc78d50d859b704500
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
The whole contextual price of products relies on multiple context keys:
* uom
* pricelist
* quantity
* date
The related logic has already been partly removed/deprecated on products,
but the computation of discounts for events/event booths are still relying
on that logic, though imperfectly.
This commit makes sure this hacky logic (relying on those contextual keys)
is as clear and reliable as possible.
We factorize and harmonize the remaining use cases, with a dedicated constant
and specific methods, making sure:
* currency conversion
* price & discount computations
are coherent, while clearly explaining that it should not be used for
any new feature/logic/code.
We also restrict context updates as much as possible (there won't be
any discount when the pricelist is configured to hide the discount from the customer)
closesodoo/odoo#123848
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit improves the performance of `_is_applicable_for`, by:
1) Leveraging the `product.category.parent_path` field.
2) Use `applied_on` for the `if` conditions, which is ~100% faster than using
the many2one fields due to the related record initialization.
These micro-optimizations are important because of the way `_is_applicable_for`
is used.
See: https://github.com/odoo/odoo/blob/0a5d84289/addons/product/models/product_pricelist.py#L169-L193
Which, for demostration purposes, could be simplified to:
```
for product, qty, partner in products_qty_partner:
for rule in items:
if not rule._is_applicable_for(product, qty_in_product_uom):
continue
```
On a database with 470 products, and about the same number of pricelist items,
these optimization result in a ~30% speedup when computing prices for all
products at once. It may be even better depending on how many nested product
categories are used in the database and in the pricelist rules.
closesodoo/odoo#125670
X-original-commit: 3619f77c73092e800aab10f0df09ca5775545da3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
- Standard price (cost price) is there for variants and for product template when there are no
variant, as it has no sense the have one otherwise. Templates with variantS have a cost of 0.
- On the website, product shown are the product templates, but you select and then buy the product
product (variants).
- The pricelist can be set to make a discount based on the cost.
==> If such a pricelist is used, the product templates having more than 1 variant are shown with a
price of 0 until you can select the wanted variant
opw-3232621
closesodoo/odoo#124594
X-original-commit: 561eba8f2adece4c21ea46c1bd050779ea3dc676
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
add chatter to product pricelist to improve collaboration. Track
currency, company, country groups, discount policy and website fields.
task-3316528
closesodoo/odoo#121244
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
So that we can in the future harmonize more easily the discount
computation between sale, point_of_sale, e-commerce, ...
closesodoo/odoo#123849
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
If applied, this commit will solve the issue of the rounding method
AssertionError while configuring any negative value in pricelists.
Steps to produce:
- Open Sale > Products > Pricelists > Create/Open any Pricelist.
- Add a new line in Pricelist Rules.
- Set computation as 'Formula'.
- In the Rounding Method field configure any negative value i.e. -1.56.
- Error will be raised.
Fix this issue by preventing the user from entering the negative value in
Rounding Method.
Sentry-4208813474
closesodoo/odoo#123539
X-original-commit: f7b0eddf3124b15bb223379a513965fa2a017851
Signed-off-by: Parth Solanki (paso) <paso@odoo.com>
While creating a new product in product category with barcode value in inventory
module, `_check_barcode_uniqueness` method is called. In which variable 'domain'
is passed, and getting wrong value.
Steps to Produce:-
1) Go to Inventory then configuration
2) Click on 'Product Categories' under products
3) Click/Create Product Category
4) Click stat button 'product'
5) Create a product
6) Then add barcode value
7) Click on Save
8) Trace-back will be generated
Reason:-
While creating new product from product category when user add the barcode value
in product form, the '_check_barcode_uniqueness' method is called. In this
method the value of 'domain' is getting updated by reference from variable
'domain' from method '_search' present in the same model.
This results in a traceback with the message
'Invalid field product.packaging.categ_id'.
Applying these changes will resolve this issue.
sentry - 4073963761
closesodoo/odoo#121072
X-original-commit: ce9889e314ae696773ce040f662569e281abe700
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
What are the steps to reproduce your issue?
- Create a product with more than one attribute.
- Let say color White, black and purple
- Create a 'draft' invoice for the purple product variant
- Remove the 'purple' attribute value from the product
- It will archive that variant (because the account.move linked to it)
- Try to delete the attribute value from menu Sales > Cofinfiguration > Attribute
What is the current behavior that you observe?
- technical error message
What would be your expected behavior in this case?
- non-technical message for end-users
Solution :
- Change both message to tell user he cannot delete the value if the value has been referenced somewhere else.
opw-2623583
missing forward-port of db1e52f0234f73e1bda22a411baba7b1f0994d5a
closesodoo/odoo#120495
X-original-commit: 0c8c43d50a574d73d9d5ac925eb16faf730a76ba
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Following 83c52575d0 we activated or created pricelists as soon as a
currency was activated/created/deleted, for every company that might already have another
pricelist setup done, which was quite confusing.
With this fix, we ensure this will only happen:
- at company creation
- when enabling the pricelist feature
- when enabling the multi-currency setting (only the first time, unless the pricelists were
disabled manually afterward)
closesodoo/odoo#120039
X-original-commit: 4c0146d939e40e9433794802388cf06147e716f2
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
before this commit, when deleting a product
category from a db where expense category
is already deleted before this commit [1]
is raising exception
after this commit, exception wont be shown
in existing db where expense category is
deleted.
1 https://github.com/odoo/odoo/commit/09e4b2fb586ac83adb984672e027ce6dd62affb2closesodoo/odoo#119754
X-original-commit: 20b5518110b233ba3b59158a8362db04b9a89aad
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When your pricelist item price is based on an other prcicelist in
another currency, the wrong currency is given to the function
_get_product_price. we sould give the currency of the base_pricelist
instead of the target one.
Here is a example:
We have a priclist in INR based on a pricelist in USD. And the company
currency is euro.
When we go for the first time in '_compute_base_price', where we'll call
_get_product_price to get the price from the base pricelist (the $ one)
We get as src_currency the USD and target the INR. Since we are calling
_get_product_price with INR as currency, when _get_product_price will
call _compute_base_price, we'll get EUR as src_currency and INR as
target.
This will lead to apply on the EU price (the one on the product) the
rate of EUR->INR then apply over it USD -> INR. Instead of EUR -> USD
and then USD -> INR
closesodoo/odoo#119505
X-original-commit: 8ace9942368688dc1183133f451ea788a03e0f14
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
The product configurator dialog was still in legacy code as it was not
required for the migration of the views to OWL. Now that we're moving
forward with the removal of other parts of the legacy code, this dialog
had to be converted as well.
Some parts of the logic have now been rewritten in OWL, getting a better
share of the logic between the server and the client.
The product configurator in e-commerce still uses the old implementation
and will be refactored in another task.
task-3056806
closesodoo/odoo#106511
Related: odoo/enterprise#39525
Related: odoo/upgrade#4550
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This API is much more sensible for making subqueries. Specifically, one
can generate a subquery without the clauses LIMIT and ORDER BY.
Part-of: odoo/odoo#112126
This simplifies the use of subqueries by avoiding some costly default
order on the model or the idiotic order='id'. Method _flush_search()
has been adapted accordingly.
Part-of: odoo/odoo#112126
Romain Derie