Have an account move which lines have all the same partner
Have a bank statement, without a partner
Enter the reconciliation widget for the bank statement
All the lines appear
Select one of the lines of the account move for the partner
Before this commit, all other lines disappeared from the proposition
including the ones for the partner selected
This cas because when having set a partner on the widget,
only receivables and payables accounts were searched for
After this commit, all account move lines for the partner are searched for
OPW 1942936
closesodoo/odoo#31488
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Go to Menu / Accounting / Vendors / Bills
Search a partner with too many opened invoices
- E.g. 713 opened invoices (709 local currency, 4 foreign currency)
Choose all them
Press Open Action -> Register Payment
Wait to open the view.
Before this patch line_profile result
Total time: 1141 s
Line # Hits Time Per Hit % Time Line Contents
================================================================
243 2922 1,139,417,018.0 389944.2 99.9 amount_total = sum([MAP_INVOICE_TYPE_PAYMENT_SIGN[i.type] * i.residual_signed for i in payment_invoices])
After this patch line_profile result
Total time: 12 s
Line # Hits Time Per Hit % Time Line Contents
================================================================
243 2862 11,733,108.0 4099.6 98.1 invoice_datas = invoices.read_group([('id', 'in', invoices.ids)], ['currency_id', 'type', 'residual_signed'], ['currency_id', 'type'], lazy=False)
It means 95x faster
closesodoo/odoo#31313
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Purpose
=======
This commit fixes the shared dict in the survey statistics computation that
causes surveys to incorrectly share the same stats when computed in batch.
Puprose
=======
This commit fixes the survey to allow sending invitation even if the survey
has no pages as long as the questions_layout is 'page_per_question'.
Have a product that is an event, with the price of 1500.
Create a ticket for this product in an event, with the price of 600.
In a SO, add a line with this ticket.
Before this commit, when you change the product, to another product that
is also an event, the event, the ticket and the price stayed the ones of
the first product.
Now, the event, the ticket and the price are updated when the product is
modified.
opw-1940368
Werkzeug version was being checked to avoid passing quote=True to
werkzeug.utils.escape (as that parameter was changed to `True` *and
deprecated* in 0.9).
However because DeprecationWarning was made silent by default in
Python 3.2 and the way the check is implemented worked for 0.9 it
looks like nobody really noticed it's broken in the usual manner of
half-assed version checks: works for 0.9.0, doesn't work for
0.12.3 (because lexically 0.12.3 < 0.9.0).
Fix by using proper version parsing and comparing the result of that.
See also: odoo/odoo#28116closesodoo/odoo#31553
Signed-off-by: "Xavier Morel (xmo)" <xmo@openerp.com>
The location_id and warehouse_id fields on product.template are just
dummy field intended to add something in the context that will be used
to compute the data being rendered (eg. for location, the quantity
displayed is the quantity of the product in the searched location).
But the feature was broken at a point, and has been solved in 11.0 with
7c7b099273.
This solution was not implemented in 10.0 up to saas-15 since this is
not acceptable for a stable version.
This changeset is only for 10.0 up to saas-15 to implement the fix
differently.
opw-1945417
closes#31475
Have a product that is an event, with the price of 1500.
Create a ticket for this product in an event, with the price of 600.
In a SO, add a line with this ticket.
Before this commit, when you change the tickets qty in the SO the price
change from 600 to 1500.
Now, the unit price stays the one of the ticket.
opw-1940368
Install Invoicing (account) and uninstall it. It results to a an error
because some views required by `payment.acquirer` are deleted before
the acquirers.
The problem is due to the way copied views are deleted, since 1388b7f
they are removed before the module uninstallation. The related commit
faced a similar problem where copied views were deleted too late
during a module uninstallation.
The two problems are revealing that the copied views have to be removed
as part of the module uninstallation, more precisely after all records
refering to them has been deleted but before the schemas has been
cleaned.
opw-1943286
closesodoo/odoo#31443
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit:
The `if` condition doing a `View._views_get` was supposed to be a sort of
'hack' for when the error occured in a child view (as the template raised would
be the parent, not the broken child).
But since we refactored that part to use etree, it was actually going into that
condition for every error even if the error was in the called template.
Proof is, we only set `editable` in that if condition, meaning going in the
else would actually prevent to show reset template.
Indeed the following code would always be true:
et = etree.fromstring(view.with_context(inherit_branding=False).read_combined(['arch'])['arch'])
node = et.find(exception.path.replace('/templates/t/', './'))
as read_combined returns all the view hierarchy DOM
Note: We could not fix this by checking exception.path against `arch` as we
could have false positive (eg the child view replace the <p> element by another
<p> element which is broken, then the path would be found in the parent view
even if the error was in the child view).
closesodoo/odoo#31515
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
In saas-11.3 "Is a Landed Cost" (landed_cost_ok) was moved from the
product accounting tab, to the inventory tab.
The inventory tab is only shown for product not of type service, but the
field should be shown when product is of type service, consu or product.
With this changeset, "Is a Landed Cost" is displayed in the top and
"Split Method" is hidden: to specify the split method, this needs to be
done from products in Inventory > Configuration > Landed Cost Types, or
by the list view of cost lines when creating a landed cost.
opw-1949329
closes#31714
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The filter parent_res_name was already in the original search view so
the duplicated one was not needed and caused to have two times the
filter in the search view with possible different behavior.
opw-1949559
closes#31707
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Commit 6af6da5c5 introduced a duplicated term to the file .pot, which
causes the following error when trying to re-load translations:
```
ON CONFLICT DO UPDATE command cannot affect row a second time
HINT: Ensure that no rows proposed for insertion within the same
command have duplicate constrained values.
```
This commit removes on eof the duplicates, leaving only the valid one.
```
```
closesodoo/odoo#31683
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In the recent control panel refactoring, selecting '(no result)' (when using the
autocomplete on a many2one for example) was no correctly handled and was leading
to a traceback.
It is now correctly handled and the search bar is correctly re-rendered.
Task 1936745
closesodoo/odoo#31438
When calling the initial (create / default_get) onchange, the SSF
would send the list of fields in whatever order was provided by the
fields map of fields_view_get.
The web client uses view ordering, and it turns out some uses / tests
have dependencies between onchanges (e.g. _create_payment in
test_account_reports) which break on some orderings of the fields.
Send the initial onchange using view-ordered fields in the SSF as
well.
closesodoo/odoo#31494
In 187c32c2 some improvements were made for conserving/restoring group
bys on the pivot view.
This introduced an issue on the column group by:
- before reload, if we set manually a column group by (+ icon in the
header) it would be saved and not lost (unless a context or filter
in the search view override it)
- after reload, the following manually set column group by are not saved
anymore on subsequent reload (the column group by at the first reload
are set back)
This behavior is not normal since the behavior (conserving or losing
column group bys) should be the same at first reload or second reload.
The issue was caused by the duplication of group bys that were not
synchronized (one on the column root header, one on the pivot model
instance).
Without the change, the added test failed with: "Column groupby not lost
after second reload" and product_id is hidding from the object
pivot_column_groupby dictionary (having only "customer").
Using _.clone on initialRowGroupBys was necessary change because without
duplication of "groupbys", the initialRowGroupBys would be changed on
expandHeader which is unexpected.
opw-1941095
closes#31407
[FIX] models: do not erase master version
For a translated field with a callable method (e.g. xml_translate), when
modifying the value of this field in another language than en_US, the master
version was lost.
Before this patch:
>>> record.arch = "<h1>Title</h1>"
>>> record.with_context(lang='fr_FR').arch = "<h1>Titre</h1>"
>>> record.with_context(lang='fr_FR').arch
"<h1>Titre</h1>"
>>> record.arch
"<h1>Titre</h1>" # lost English version
After this patch:
>>> record.arch = "<h1>Title</h1>"
>>> record.with_context(lang='fr_FR').arch = "<h1>Titre</h1>"
>>> record.with_context(lang='fr_FR').arch
"<h1>Title</h1>" # write had no effect
>>> record.arch
"<h1>Title</h1>"
When modifying a translated HTML field in English, a matching to detect the
difference and avoid losing the translations is done.
This is not supported for update in another language.
The main reason is the difficulty to detect changes in the architecture.
To update translations, the supported way is to go to the list of translations
and update them there.
Before this patch, the given value in another language was given to the SQL
query and made an update in database:
if single_lang or not (has_translation and field.translate is True)
-> True or not (True and False) -> True
If a field is callable, it should also be ignored, the same way than
translate=True fields
opw-1887162
closesodoo/odoo#31451
Before this commit:
-> Debug mode
-> Settings
-> Database structure
-> Fields
-> Any selection field
=> The field `selection` of the ir.model.fields form view does not
display the selection options of the field being viewed, this is because
the selection field is not registered at `_reflect_field_params` of
`ir.model.fields`.
After this commit:
The field is properly registered; for Selection fields with static
options, these are shown as-is, for fields with a lambda function as
options, the string 'function' is displayed, and for fields using a
function name as a string, the same string will be displayed.
Fixes#28360closesodoo/odoo#31207
Improve performance (*3) on _compute_product_availability
`mapped` makes use of orm prefetch, which is inefficient in this use
case when facing high volume.
closesodoo/odoo#30545
On some devices and chromium with printing option "Background graphics",
a printed receipt on the point of sale could have a black bottom below
the receipt content.
This is caused by the point of sale black background and happen rarely
because most frequently browser printing remove backgrounds.
opw-1940434
Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
closes#31472
Let's assume a many2one field with a lot of possible values. The
user clicks on 'Search More...'. In the opened dialog, only 160
records are available (their ids have been obtained with a
name_search, with the optional text the user could have typed in
the many2one input).
Before 4cd379cf, that extra domain on ids was removed automatically
as soon as the user interacted with the search view in the dialog.
This was especially useful when there were more than 160 records.
However, this was rather an happy coincidence than a designed
feature.
From 4cd379cf, the ids selection was added to the initial domain
of the list, so they couldn't be removed from the domain
afterwards. The user was thus stucked with its preselected 160
records.
This rev. doesn't restore the former behavior, but rather improves
the current one, as follows:
- when there is no text in the many2one input (i.e. no value to
filter on), we bypass the name_search, s.t. all records are
available in the dialog
- when there is some text in the input, we perform a name_search (as
before) to get a list of record ids, and we add a special filter
to the search view in the dialog (the filter on those ids), s.t.
the user can remove it if he wants to access the remaining records.
- finally, the limit is now set to 320, to mitigate the problem
Issue reported on the saas-12.1 migration pad.
closesodoo/odoo#31232
Before this rev., it crashed when the user clicked on a pivot cell
in the dashboard, whereas it should have performed a do_action to
open the records in a list view.
This was due to a leftover event handler (with the handler function
being actually removed) in commit 38dc5c18b.
Issue reported on the saas-12.1 migration pad.
closesodoo/odoo#31367
- When selecting "Unpaid invoices" or "Invoices to validate" on the
accounting dashboard, the list view opened doesn't filter with the
journal selected.
closesodoo/odoo#31397
On the portal, edit a Lead in order to make/edit the
next activity
Change the activity type
Before this commit, the modal closed when clicking on the selection field
This was because the wrong method was called
After this commit, the modal stays and the activity type is changed
OPW 1943428
closesodoo/odoo#31349
The reconsiliation code was looking for the aquirer_reference instead of
the reference to find out the corresponding transaction. Which leads to
not finding the corresponding transaction.
This behavior comes from the creation of the moule setting its own tests
in error in PR: https://github.com/odoo/odoo/pull/24802closesodoo/odoo#31365
Installing the 'lunch' module add css rules to the generic list view
styling, modifying the styling of all the list views by the simple fact
of being installed.
The goal of those rules is that in list view a table cell with the
o_text_overflow class should still be displayed as a table-cell (and not
a block/inline-block).
Without the lunch module a list view's cell with the o_text_overflow
class is narrower and break the alignment between this column and the
headers.
This commit moves the necessary rule (display property) to the web
module and apply them globally.
Remark: module's css rules shouldn't override globally the one from
'web'.
Original commit: https://github.com/odoo/odoo/commit/855c6dac25fccaf9312543022001ed0b360d6e13closesodoo/odoo#31506
A workorder has a one2Many to stock.move to represent the production raw moves. Putting 'workorder_id' on the production finished move will set it as raw moves in the workorders
closesodoo/odoo#31132
A manufacturing order creates its raw move in an onchange when saving the form
view. As the MO has no name at this stage, the raw moves reference stay 'New'
even when marked as done
This commit change the moves reference once the MO is confirmed
Main purpose of this merge is to lint and clean front-end templates and
widgets in eLearning.
Including
* lint and clean JS and CSS for fullscreen widgets;
* refactor reordering of slides and categories, handle void categories;
* refactor category addition and slide archive widgets;
* simplify progressbar;
* lint slide like and crouse join widget;
* improve course main page, restore review tab;
* various fixes, improvements and lintings;
See sub commits for more details. Thanks to everyone involved in this
branch. So much people to tag, I have a bit la flemme.
Incoming in a near future: improved main slide page, cleaned fullscreen
widget, design-linted profile page, and probably more fixes.
Merge related to task ID 1941250 (basically, "fix eLearning post-merge").
closesodoo/odoo#31394
Lucas Perais (lpe)