As the journal is mostly set in the Odoo world the _default_journal
method is not needed during create, but in case you only have
partner_id, account_id and type in vals you will have retrieved a wrong
journal in case you have an incoming invoice.
closesodoo/odoo#28635
If `description` contains an image, the loading time of the kanban view
can be rather long. Since the field is not even used in the view, it can
be removed.
opw-1915193
closesodoo/odoo#29034
The field sale_id on model stock.picking is not defined in stock module.
So the rule was wrong when sale_stock was uninstalled.
opw:1912564
closesodoo/odoo#29145
When analysing the code thanks to Pyflame it cames that the 'prefetch_fields()'
function was runing most of the time. In order to improve the global performance,
I change the context of the move_lines : 'prefetch_fields = False'. It permit to reduce the
time of computation of the prefetch_fields and to avoid the MemoryError.
N.B.: The database of the customer (on saas) contains 1.3 millions of entry and to reproduce the issue
I have to set the HardMemlimit to 0.9 Go and the SoftMemLimit to 0.5Go.
OPW-1910422
closesodoo/odoo#29231
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
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
Create a "Cash Rounding Method" C with
Rounding Precision: 0.05,
Rounding Strategy: Modify tax amount,
Rounding Method: DOWN.
Create an invoice I with rounding of currency C, with some tax line and nonzero
rounding.
When you now print the invoice, the tax amount is not the same,
as it shows the field "amount" instead of "amount_total".
Fix courtesy of Olivier Jossen, Braintec
opw 1909215
closesodoo/odoo#29079
* web_editor
When an user saves its website, all the animations are destroyed so that
a clean DOM is saved. This is particularly important for snippets like
the latest post one that would crash the page if not cleaned before
saving.
Two cases were found where animations were not cleaned before saving and
this is what this commit fixes:
- When an user used the undo/redo system, all animations were lost as
the DOM is recreated.
- When an user duplicated a snippet, animations were not restarted on
the cloned element.
closesodoo/odoo#29159
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
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
Steps to reproduce the bug:
Let's consider a product P with a unit price = 10
- Create a SO for two lines of the same product P
- Validate the SO and create the invoice
- Refund the invoice and validate it
- Go to Reporting > Sale report and select "Invoiced amount" as measures
Bug= -20 was displayed for the invoiced amount.
Technically, the two refund invoice lines of P were used two times in function
_compute_invoice_amount because for each SO line we catched all the refund lines
of the same product.
opw:1906445
closesodoo/odoo#29095
**Description of the issue/feature this PR addresses:**
Addon hr_attendance adds a check_in/check_out status icon in every card of the employee kanban view. The status is figured out using computed field ``attendance_state``, itself relying on a computed Many2one field, ``last_attendance_id``.
The current way to compute the latter field seems to fetch all attendances before getting the most recent one. For each employee. Which causes the employee kanban view to load very slowly (~30 sec in 90-employee Camptocamp's instance).
This PR suggests to load only the last attendance entry.
Co-authored with @guewen
**Current behavior before PR:**
Employee kanban view loads very slowly.
**Desired behavior after PR is merged:**
Employee kanban view loads reasonably fast.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#28953
Suppose that a Task is added on a task via a studio customisation.
Then the _get_message_needaction method gets called on the onchange of the
toplevel task, which triggers another call to _get_message_needaction.
During that update, we get a self with a model.newID; its ids field is empty,
so the list of tasks res itself is empty.
As a result the method crashes on a malformed query.
This can in turn prevent the completion of some higher-level operation,
e.g. a state change on the task.
opw 1909043
closesodoo/odoo#29084
Have:
- Model A with a x2m to model B
- Object A with multiple objects B in x2m (that will be sorted)
- On the list view of model A, click on a column to sort by a field
- this field shall not exist in B
- open a record A (towards form view)
Before this commit, the sorting of the x2m crashed, because the key orderedBy was propagated
Due to commit e713ed2a69
After this commit, it doesn't crash
OPW 1913133
closesodoo/odoo#29094
Usecase to reproduce:
- Enable 'Managers must approve orders'
- Set agreement type as 'exclusive'
- Connect as purchase user
- Create a requisition and an RFQ linked to it
- Confirm the RFQ
It raises a usererror that ask to close other PO linked
to requisition.
It happens because the purchase requisition code do not take
care of double validation on PO. It will try to close the requisition
once button_confirm is called. However it will only write 'to approve'
on PO state and thus trigger the requistion error will be raise since
all linked PO are not 'done' or 'cancel'.
In order to fix it, the action_done on requisition should be call
on button_approve instead of button_confirm. (button_approve is
automatically called when double validation is not enable).
Task: #1884410Closes#28068closesodoo/odoo#29049
Modifying a source term in an XML/HTML translated field can lose translations
if the same term is translated in several languages.
closesodoo/odoo#29078
The other methods do test password length before verifying it, so even
if check_credentials() is not meant to be called directly, it's better
to keep it consistent with the alternatives.
Closes#29023
We now support version 0.12.5(.1), which is available for all recent Debian and Ubuntu versions,
and contains quite a few bug fixes. An up-to-date version of Odoo 10 or later is required, for
pixel-perfect compatibility with the result of 0.12.1.3.
See also the wiki for more info: https://github.com/odoo/odoo/wiki/Wkhtmltopdf
Firefox for android gives atraceback when clicking the print receipt
button. This traceback is caused becaus Firefox for Android does not
support printing.
This fix replaces the traceback by an explanation why it is not possible
to print.
Also backport for safari-fix
closesodoo/odoo#28919
/!\ Should not be forward-ported in *12.0* /!\
Because of the mechanism to bind change / click event in the 10.0
implementation, when we are in edit mode on a product page, the event
handlers that are in charge of updating the cart quantity can still be
triggered.
After this commit, click / change event while updating cart qty will
not be effective in edit mode.
task-1825889
Closes https://github.com/odoo/odoo/pull/24211closesodoo/odoo#29224
- Create a product A with a sales price of 40
- Create a pricelist where product A costs a fixed price of 100
- Assign this pricelist to a customer
- Connect as the customer on the eCommerce
On the eCommerce, the price for A is displayed as: ~~40~~ 100.
We only display a price difference if the pricelist price is smaller
than the sales price.
opw-1885443
closesodoo/odoo#29141
- Create a product with 2 variants A & B
- Set a weight on the variants (btw, the weight field is not available
on the template in this case)
- Create an invoice for A, validate
On the intrastat report, the weight remains 0.0.
The report clearly takes into account the weight of the template, not of
the variant. We use the product weight, and fall back on the template
weight.
opw-1913305
closesodoo/odoo#29178
This revision brings the compatibility for our reports
using wkhtmltopdf 0.12.5.
Up to now,
the supported wkhtmltopdf version was 0.12.1.
The goal of this revision is to add the compatibility
to wkhtmltopdf 0.12.5,
while keeping the same exact rendering than in 0.12.1.
There is a behavior change with the `--dpi` parameter,
which no longer has a "zoom" level effect as it did with 0.12.1.
To deal with it, we pass the `--zoom` parameter when
the detected version installed of wkhtmltopdf is after 0.12.2,
with a ratio 96:dpi. 96 being the default dpi of wkhtmltopdf.
This trick allows to render the reports with the exact same
zoom level, whatever the dpi value configured in the reports paperformat.
(at least with dpi values up to 149, after 150, included,
the dpi parameter with wkhtmltopdf 0.12.1 as a weird behavior,
it no longer zoom out)
opw-1907346
closesodoo/odoo#28864
Fixing it directly by commit since there is no es_AR on transifex.
The issue of the ticket has been solved by transifex, this is for
another similar issue that has been found.
opw-1907924
closes#28923
Wolfgang Taferner