On a form view of model A, if a many2one field (model B) has a [tree|form]_view_ref in the context
(to display a custom 'Search More...' tree view dialog for example),
when clicking on this field to display the model B form view, the context key *_view_ref is passed
when loading subviews (model C) making them crash because the view ref corresponds to the model B.
After this commit, '*_view_ref' keys in the context are dropped when loading subviews
closesodoo/odoo#29022
This commit has several parts:
- fix ordering of attributes and values
- fix/create python logic (notably for checking the possibility of a combination
and for price computing)
- fix currency
- display correct info on the views without the need of JS (prevent flickering)
- fix various issues with website and SO
- add a lot of tests (both unit and tour)
================================================================================
*** Make consistent the filtering and ordering of product variants ***
Filter & Check possibility
==========================
The first variant shown on the website should always be possible.
When activating the customize "list view of variants", we don't want to show
impossible combination on the list.
We also don't want the user to be able to add to cart an impossible variant.
Show appropriate messages when no combination is possible.
Order
=====
We want the variant order to be consistent with what the user selected with the
sequence fields. The display order on the website should be the same than the
display on the various backend views.
This implies also fixing the order of:
- product.attribute
- product.attribute.value
- product.template.attribute.line
- product.template.attribute.value
The general order is now: (parent,) sequence, id.
Before, it was already a mix of those, but not always in the same order, and not
every key for every model. The name has been removed from the order: either we
sequence them correctly, or we want them in the creation order.
On the website, the first combination shown by the python should be the same as
the one that will be computed by the JS to prevent flickering.
Ideally there should be no RPC at page loading if the python has computed
everything correctly, but it is currently not possible to achieve because the
view logic for website_sale_stock is only in JS.
================================================================================
*** Fix product template and variant price computation ***
Move and improve the get_combination_info method:
- take into account tax included/excluded settings (B2B/B2C)
- take into account pricelist discount policy (striked price)
- fix inconsistencies when price after pricelist would be 0
- use proper rounding and discount compute with the currency helper methods
- fix an issue where context "partner" would have a mix of id and recordset
================================================================================
*** Fix currency conversions ***
The list_price and lst_price of a product are always encoded using the currency
of the product.
The results of "combination info" are always returned using the currency of the
pricelist if given, or the currency of the product.
The prices on an order (line) are encoded with the currency of its pricelist.
================================================================================
*** Fix dynamic variants access rights ***
Public users on the e-commerce should be able to create product variants if the
configuration of the attributes of the product template is set as "dynamic".
This uses "sudo" to bypass create security rules for public users.
Multiple checks are done to ensure that it creates a valid product variant.
================================================================================
*** Miscellaneous bugs, tracebacks and necessary improvements ***
In general:
- correctly show warning when no variant is possible
- don't let user add to cart an impossible variant (from optional product
modal or from any RPC), both in interface and controller logic
- fix as much flickering as possible by correctly pre-computing in python/views
- move business logic from controllers to models
- correctly add no_variant and is_custom values on the SO line description
Sale order:
- fix traceback when emptying the product_id field from configurator
website_sale:
- correctly compute first image / carousel, and correctly swap images when
changing variants, without duplicate image or zoom problems
- don't use list view of variants when it doesn't make sense
- added missing product info when adding a no_variant attribute to cart
- fix cart accessory product computation
website_sale_wishlist:
- fix it with dynamic variants, no_variant and is_custom
website_sale_comparison:
- fix it with dynamic variants (comparison and alternative products)
website_sale_stock:
- fix it in general (some flickering still present)
================================================================================
Authored by @seb-odoo with contribution from @awa-odoo
task-1910821
closesodoo/odoo#28079
The product image zoom was computed in the start method, and an "on load" event
was set in some but not all cases.
This commit makes sure the load event is always set, to correctly recompute the
zoom feature when the image is later changed (for example, changing variant).
This is important if the mouse must stay on the element after it has been
clicked. This is the case for the product image zoom, which will be tested in
the following commit.
Activate variant by default with demo data: since we have demo data creating
variants, the database will be more consistent if the option is also activated
by default. It also allows to gain time when making a demo or testing feature
using them on a new database.
While dragging kanban record which have a cover image set, the kanban view
creates extra space, which makes it difficult to properly target a
position.
This is because of a jquery.ui issue for sortable when helper=clone is used.
In that case, then jquery.ui sortable will create a clone of current element
after hiding it. Note that jquery.ui tries to get height to current dragged
element after making it hidden(display: none) and display: none, so the element
does not return actual height and hence it gives innerHeight which considers
height of the image also and extra space is generated.
An alternative solution is to add start event in sortable option and
1) show ui.item
2) get height of the element and
3) hide ui.item, which gives proper height of the current dragged element
But removing helper=clone will also fix the issue and is not actually required.
Note that some special care had to be done to prevent the click from the
drag and drop operation to actually open the record.
Related to task: #1865788Closes: #25734closesodoo/odoo#29642
This commit 9eac6c6377 expects a returned value
from function called "_run_valuation".
But this function always returned None.
opw:1907021
closesodoo/odoo#29302
Before this commit, it was not possible to sort
the rows of a pivot view while in comparison
mode. This fix makes it now possible. Note that
in comparison mode, a click on a header of type
"measure" will sort the rows according to the
column values coming from the data of interest.
closesodoo/odoo#28411
opw-1917444
In the "Chart of Accounts" view, the action to view journal items show
up twice. This was because, two action windows had the same name, one
is for view journal items, and the second one is for view jounral items
for Tax Audit.
After this commit, the second action is named
"Journal Items for Tax Audit".
closesodoo/odoo#29597
Lang / Context is implicitely added in the query using this._rpc
Before this commit if you set the title 'Title 1' for your website in the main
langage and after edit the title as "Title 2" in another language, it was the
main title that was replaced instead of the translation.
Now we use this._rpc that bind automatically the context and so the current lang
that we are editing.
closesodoo/odoo#29596
Since the product configurator task, the optional product modal was
always using the backend style instead of the theme style.
task-1911015
closesodoo/odoo#29587
Ignorant fools have been saying for more than a decade that <table> elements
should not be used for layout.
Once again, Odoo proves them wrong. You just need the right css.
opw 1914139
closesodoo/odoo#29498
- When resending a failed mail the code could crash.
The issue is caused by the fact that calling `_get_recipient_data`
with the parameter `pids` only, returns as the partners' groups the
value `None`.
The codes that uses the result of this method consider the groups as
an iterable and crash when trying to iterate on a `NoneType`.
OPW-1916498
closesodoo/odoo#29408
- Set a TZ on the user different from UTC
- Export a record containing a datetime, e.g. the Order Date of a SO
- Import the file
The Order Date is changed on the record.
The data export is always in UTC, but the data import takes into account
the user TZ, which explains the difference.
There is no good way of solving this in stable. We have 3 choices:
1. Do nothing: the flow export then import the same data is broken, as
explained above.
2. Export in the user TZ: if the file is imported in a third-party
software, we break the flow.
3. Import in UTC: if the file is generated from a third-party software,
we break the flow.
Whatever the choice is, we either break a flow or keep an inconsistent
behavior. We choose option 2, assuming that in most cases the user wants
to export the data in his TZ, therefore keeping the values displayed. We
only do it in v12 in order to mitigate the impact on existing
installations. A proper fix should be discussed for v13.
opw-1915631
closesodoo/odoo#29576
The `export` method accepts a `context` parameter, but doesn't use it.
This actually hides an incorrect test: when exporting in French, `Bar`
should be exported as `titi`.
opw-1916511
When you try to change the accounting plan it sets off an access error.
To change the accounting plan it must delete and create some records in
the model 'ir.property' and none of the current security groups have
access to do it.
This issue was not present in the version 11.0 because in that version
the administrator was also the super-user.
In version 12.0 the administrator and the super-user were dissociated.
This was changed to level-up (sudo) the rights of the administrator
when the ir.property are deleted.
Note that, this fonction have two pre-existing constraints to avoid
issues when configuring an accounting plan: it can only be changed if
there are not alredy existings accounting entries;
and only the administrator can change it.
closesodoo/odoo#29493
- Create a new DB with `base_automation`, without demo data
- Switch to developer mode
- Go to Settings, then 'Load demo data', validate
A traceback occurs.
An error since the demo data in `base_automation_demo.xml` are pointing
to `model_base_automation_lead_test`, which is a test model. It is
therefore not created whithout demo data. The error is:
```
bad query: b'RELEASE SAVEPOINT "5159....."'
```
However, that's not the real crash. Indeed, in case the installation of
demo data crashes, `demo_failure_todo` is supposed to handle the
situation like a boss. But in this case, the DB cursor seems unusable.
Therefore, the following crashes like a gros caca:
``` python
todo = env.ref('base.demo_failure_todo', raise_if_not_found=False)
```
Solution: use a new cursor.
opw-1916918
closesodoo/odoo#29528
Have an invoice and a credit not in one journal
Go on the dashboard for journals
Before this commit, the count of invoices in draft took into account
both invoices and credit notes, while clicking on the button to see the invoices/credit notes
only showed invoices
After this commit, clicking on the button show both invoices and credit notes
It is worth noting that this is the behavior in v11.0
And that the way the dashboard is computed cannot allow to differentiate
within the kanban records, invoices and refunds as two separate buttons
OPW 1916135
closesodoo/odoo#29482
The _name_search did override the domain's search
by OR'ing it with a loose condition on the driver_id.
As a result if an upstanding Odooer added a strict filter on the driver_id,
it was ignored in favour of the loose one.
opw 1915639
closesodoo/odoo#29515
In case you edit your shipping address (that is the same for billing) you don't always
undersantad that you are editing at the same time the billing address.
opw-1914185
closesodoo/odoo#29484
Recent works in the orm (see [1] for example) changed the behaviour of
the server in the case of onchanges: it tries to optimize Odoo by
sending a minimal diff to the web client in onchanges.
Concretely, this means that the web client receives commands 4 (link to)
instead of command 1 (update + record data). It also sends a minimal
diff in that case. This is a big issue for the web client, because it relied
on the knowledge of the data from the command 1 to be able to evaluate some
modifiers.
The good news is that we can mitigate the issue in one case: we do not
actually need to evaluate the modifiers in the case of a command 4
(comming from the server), because we can assume that the record is
valid. So, we simply bypass the check in that case.
Note that this should fix most of the problem, but a deeper problem
still remains: a crash can still happen when an onchange modifies a
record in a one2many (but in a different page), and we also have a
modifier which needs to be evaluated.
opw: #1904514
[1] https://github.com/odoo/odoo/pull/29086closesodoo/odoo#29172closesodoo/odoo#29086
On a record with a large x2many, the web client does not load all the data of
the lines (because of paging). If a line is modified by an onchange, at some
point the client will determine whether lines are valid (all required fields
are provided). It is possible that the client cannot evaluate the validity of
the modified line because of missing fields. In order to avoid this situaion,
the server sends all fields on modified lines.
Set a BOM to create 10^k units of Product P, using n units of raw material R.
On R, put rounding to 1 unit.
Create a MO to produce 1 unit of P.
Since it needs n/10^k units and rounding is set to 1,
it sets 1 unit of R to consume.
Now "update" (quantity to produce) to 10^k'.
It correctly updates the quantity to consume.
However, since it doesn't update the unit_factor, when you "produce",
it will consume 10^k' units instead of 1.
We copy the way the unit_factor is initially computed when updating the lines.
opw 1903776
closesodoo/odoo#29067
The translation had wrongly `</ i>` which from a report broke some
initialization of some snippet of the website editor.
es_CO, es_DO, es_EC languages are not available in transifex so this
change is done manually for them.
opw-1907752
closes#29135
This commit complements the removal of pycompat PY2 helpers and shims
from base by removing / adapting references to these helpers from the
enterprise code.
When installing ecommerce app in a fresh v12 database
the fields invoice_policy and description_sale were missing in
the product.template view form
opw:1911612
closesodoo/odoo#29059
Survey has troubles displaying correctly the datetime picker widget
especially when more than one has to be instanciated. This merge fixes
several issues related to the datetime widget when displaying the survey
in customer (front-end like) view.
See sub-commits for more details about each change.
This merge is related to task ID 1912194.
closesodoo/odoo#28966
The link "Manage your payment methods" didn't work on the website because
the variable acquirers is a list of records.
This list has been created in function "payment_method" with the route
'/my/payment_method'
opw:1913299
closesodoo/odoo#29142
1. Update tax Groups with N07-2018
Restrict Tax groups just to the 5 available in Norma 07-2018:
* ITBIS
* ISR
* ISC
* Propina
* Otros Impuestos
2. Do not use 'none' to hide taxes
This affect taxes reports, as those reports evaluate the
type_tax_use field
3. Rename Taxes and Description for N07-2018
4. Change group taxes name and missing childrens
5. Add account groups to template and CoA
6. Add various missing data
opw-1912626
closesodoo/odoo#27172
lul-odoo