The cell containing "Add to Cart" button that adds suggested accessories
in the cart has col-* classes. Thus it there is "flex-item" CSS
properties that make no sense since there is no container and the
sibling are not flex items.
So the button tried to take 100% of width and this commit just fix its
proposed width to 25%. Before change width was 16.7% width for large
screen, 25% for medium screen and 33.3% for small screen. I choosed 25%
since it seemed a good default (we don't need 33.3% since .btn is
whitespace:nowrap so the size will be higher than 25% if necessary).
opw-1914994
closes#29287
Before this commit:
While user was opening first time line chart graph, at that time undefined
label values were not being converted into undefined string due to misplace
code. So it was giving traceback error
After this commit:
Code has been moved to proper place.
Joint work with msh-odoo
Issue-ID: 1882328
closesodoo/odoo#29306
Suppose a statement line having 'SO022' as name.
Suppose a move having 'INV/2018/0001' as name and 'INV/2018/0001 SO022' as ref.
The previous behavior didn't work because '20180001 022' = ANY({'022'}) was False.
This commit changes the matching by computing the array in both size and checking the intersection.
{'20180001', '022'} && {'022'} is True
closesodoo/odoo#29299
Steps to reproduce the bug:
- Write a model in lunch.py called "my.model"
- Install module Lunch
- Erase "my.model" in lunch.py
- Upgrade the module Lunch
A error was raised when processing function "_process_end" because
the ir.model.data record of "my.model" was not deleted
opw:1908813
closesodoo/odoo#29247
- Activate Invoice Online Payments
- Create an invoice for 2000, make a partial payment of 500.
- Send the portal link to the client
- Open the portal link => the amount due is 1500
- Pay the invoice
The amount to pay is 2000 instead of 1500.
opw-1909118
closesodoo/odoo#29284
when selecting a line with a partner, all propositions for other partner dissapeared and we have no way in the manual reconciliation to remove the partner that is set up, so we removed the fonctionality to set the partner automatically when selecting a line in case of a manual reconciliation.
closesodoo/odoo#29289
In the manual reconciliation widget, after a reconciliation with a writeoff is done, there is still an empty line displayed with the "new" icon. This commit removes the "new" icon on empty line.
When trying to reconcile the following line with the manual reconciliation widget
(company currency in EUR)
Debit Credit Amount_currency Date Currency
13.11 0 0 10/26/2018 /
0 34.16 -39 11/09/2018 USD
And a write off with the following value:
Debit: 21.05
The write-off created was not with the correct debit and the entries were not totally reconciled.
The reason being that the method was converting the 21.05 with the USD rate of today and changed the debit.
We should never convert debit/credit as debit/credit in the manual reconciliation widget is always displayed in company currency. However if all entries are with the same currency, the writeoff should also have that currency set.
This commit fixes this behavior.
Joining on a case is far to be optimal. doing 3 left joins and a coalesce is faster.
partner_id is a required field in res.partner.bank, but some migrated database have
records in res.partner.bank model without id. To keep existing behaviour, the third
join (the one on the name) is kept for backward compatibility.
closesodoo/odoo#29276
The fields amount_total, amount_total_signed, residual, residual_signed,
all sum values that are unsigned or in different units, as they may be in
different currencies.
Therefore their display in the pivot view can be confusing, misleading,
and may lead people to file bug reports.
Since support for hiding measures has been added in commit 24f7c7ce7f,
we remove these fields from view.
opw 1909046
closesodoo/odoo#29211
Try to print a survey answer which has a date question
Before this commit there was a traceback because the value_date
which is a Date field was not JSON dumpable
After this commit, the survey answer prints well
OPW 1914984
closesodoo/odoo#29250
Steps to reproduce the bug:
- Configure to use UoM
- Make an inventory adjustment for all product
- Select one product one the inventory line, and select the UoM
Bug:
All the UoMs were selectable but only the uoms in the same category of
the product are allowed.
opw:1911941
closesodoo/odoo#29238
The pivot view may sum fields that are not really summable:
unsigned values (e.g. in the case of refunds)
values in different UOM, currencies (any different units really)
Which causes confusion when these fields are displayed.
We add support for the string and invisible attributes in the pivot view,
so that a field can be given a more informative name or hidden altogether.
opw 1909046
closesodoo/odoo#29144
In case there is a large amount of data to display, the 'Manual
Reconciliation' widget suffers from high CPU consumption, and therefore
slowness.
This is mainly due to the line rendering (function `_renderLines`).
Indeed, unlike the 'Bank Statement Reconciliation' widget which
retrieves the data partially, the 'Manual Reconciliation' widget
retrieves and renders all the data. No offset is implemented in this
case, neither for data retrieval nor rendering.
With this commit, we implement a partial rendering of the data
retrieved. This means that all data are fetched when loading the widget,
but only a part of it is rendered. We make use of the existing 'Load
More' mechanism to display more data. By default, 30 accounts or
partners are loaded.
By combining this with PR #28958, we aim to make the widget more usable
for large data volumes.
opw-1903575
closesodoo/odoo#28959
Have a one2many display records in a kanban subview,
which opens a form view when edited.
Edit a field displayed only on the form view.
A call to _applyX2ManyChange is done without giving it the viewtype argument,
therefore the fieldinfo is taken from the wrong view, traceback ensues.
opw 1914163
closesodoo/odoo#29607
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