The function _get_bom_component_qty has been deleted by odoo@2ddc35a
But this function was still used in 10.0 in function _get_anglo_saxon_price_unit.
opw:742462
As administrator is used to create all records from website form he is
also put into followers. This creates a lot of unnecessary notifications
and/or emails depending on the system configuration.
Using the magic context key this behavior is modified. Administrator
will not follow every records created through the website form anymore.
The callback_eval field has a groups parameter of
base.group_system. Without this patch everyone not part of that group
ends up with an access right error when the system attempts to read
that field.
Previously this was not a problem because all code reading
callback_eval was executed with the superuser already. New code has
been introduced however that does not do this (eg. paying with a
payment.token from the backend).
opw-741181
Before this commit, numbers in list views were right-aligned
depending on the widget they were using (float/monetary). Now, the
input text alignment is inherited from the parent which should
solve the problem.
The field move_line_ids was present in the view and used only for display
purposes. However modifying another field triggering an onchange (e.g. a payment
line) was recreating the move lines.
Recreating the accounting entries may trigger an error if the entries are
already posted.
The entries are recreated because:
1. the move_line_ids is loaded with the default tree & form view for
account.move.line records, displaying several fields
2. some of the fields (e.g. reconciled) are computed
3. the initial onchange recomputes all the computed field, including the one
on the one2many (e.g. recomputing move_line_ids.reconciled)
4. the field being dirty, the onchange returns the value of move_line_ids with
[(5,),(1,id,{...}),...]
5. trying to save the modified lines may fail
Replace the field by a simple readonly integer field.
opw-741205
- Create a bank statement for Partner A, with one line of 1000 EUR
- Open the reconciliation widget (click on "Reconcile")
- Using another browser, open the same reconciliation widget
- Create an entry for the opened balance in browser 1, click on
"Reconcile"
- Create an entry for the opened balance in browser 2, click on
"Reconcile"
The entries are created twice, no check is performed to verify that the
statement line is already reconciled.
opw-741824
saas-14 is no longer present on Transifex. A pr is still the most efficient way
to backport translations done on upper version.
Closes#16750Fixes#16749
The typical multi-company record rule is
['|',('company_id','child_of',[user.company_id.id]),('company_id','=',False)]
As the company is just created, the current user does not belong to the company.
Create first without company (to still check the access rights) and after add
the company in sudo
Can not apply the same patch for stock as locations and sublocations are created
based on the warehouse company.
Fixes#16807
Before this commit product quantity was computed as if the uom on the product represented the *unit* in which a product was sold
Hence, in the report, it produced something like this:
I sell 10 packages of something, which is sold essentially by 10 itself = which makes a total unitary quantity of 100
This wrong behavior has been introduced in 10.0 by 9c5d4cd60c
After this commit, the computation is done to match the *standard* unit of measure in which a product quantity is *represented*
OPW 741745
Closes#16834
Before this commit, when hitting the "Discard" button in an editable
list view, the line switched to readonly mode but with the undiscarded
data (even though the data was properly discarded and not saved).
Fortunately, the fix is in fact making the save/discard/update system
more consistent. Here are some reasons why:
- the `_confirmSave` method is now used after a save or a discard
(while it was before only called on readonly views where a change
was made by a special field widget).
- Abandonning a record (discarding a new unsaved one), is now the
responsability of `discardChanges` (and not `_setMode`).
- The renderer `updateState` method is used when its state is updated.
- ...
Note that setting the renderer mode is now taking care of deferreds
properly (the widgets deferred are now considered when switching
a row to readonly/edit mode).
Before this commit, it was not possible to see the difference between an
unset float field (with a 'false' value) and a set field (for ex, with
value 0)
This was due to the fact that the formatFloat/formatMonetary functions
format false values as the number 0, unlike many other formatting
functions.
Add a check for the presence of color field. (only applies when "useContacts" is not set)
Before this fix, if the view xml does not set "useContacts", the calendar view fallback on the color attribute (not required) which may be non-existent on the model and on the view.
web_calendar.js:799 is using "if (color_field.type == "selection")" so its throwing this error when color is not defined:
Uncaught TypeError: Cannot read property 'type' of undefined
Note: Small fix, long diff. Read the specifcation section to understand why.
PURPOSE
=======
The child allowance is an amount to decrease the withholding taxes due to family charges.
SPECIFICATION
=============
Instead of having a salary rule with a fixed amount for the child allowance, we should have a salary rule on which the amount is computed with a python code, that take the minimum between the original fixed amount and the remaining withholding taxes to pay.
As the field 'amount_python_compute' isn't in the field declaration on the csv file, we have to add it and modify all the lines. The result is a quite long diff for a small fix.
Before this commit, only fields which were specializations of the
`InputField` were handling up/right/down/left navigation in editable
list view. As m2o field is not an `InputField` (yet?), it was not
possible to navigate from one of those for example.
Now, navigation events are handled by the `AbstractField` class. If a
given field has to handle navigation a different way, it is its
responsability to stop the associated navigation event. For example,
`InputField` instances are stopping the left/right event if the cursor
is not at the start/end of the <input/> element.
Also, before this commit, there were many events ("move_down",
"move_left", "move_next", ...). Now there is only one event for
navigation: "navigation_move". This event is given a "direction" data
("left", "next", ...). It also comes with a "target" data which is a
reference to the last `AbstractField` instance the navigation event
has crossed.
- RML Reports
- Webkit Reports (most part already removed by 13b9982c62)
- LocalService in netsvc.py
- rename attributes like rml_% to report_%
- rename ir.actions.report.xml to ir.actions.report
- allow rendering directly on an ir.actions.report by calling render method
- remove 'controller' report_type
- remove unused res.font stuff
- remove print_report method in models.py (not used)
- restore removed call to pdftotext process in test_reports
Before, the field google_drive_authorization_code was duplicated in the view, making it impossible to change the code consistently
Now, the config is handled by google drive as it should
OPW 742062
Closes#16836
... in x2many editable list views.
Field widgets can detect that they are at the origin of a
field_changed event, so that they don't re-render themselves when
they are being edited.
This didn't work for fields inside x2many list views. This wasn't
a big problem for most of the fields, because the cursor position
was automatically reset after a re-rendering, but it wasn't
working for monetary fields that empty their $el before each
re-rendering.
This rev. fixes the issue by making the field widgets inside
x2many list able to detect that they are the origin of a change,
and thus removes the now useless code that restore the cursor
position.
The 'get' method in the basic model is called very often (too often, but
that is another issue). For a large list with many columns, it can be
quickly be called more than 10k times.
In that function, we had to protect our integrity by performing a deep
clone with $.extend, so noone else can be allowed to change something in
our internal structure. This is good in theory, but not so good in
practice, as $.extend is a really expensive operation.
Also, we try to have the smallest external API by deleting useless keys.
But instead of keeping a blacklist of private keys, it is simpler to
have a whitelist of public keys.
So, what we do is to explicitely construct the object returned by key,
since we know the types of every values involved. This is more
explicit, and at the same time, much faster.
Also, we propagate the options for elements of type list. This is why I
had to change the isFieldSet method.
In a benchmark I just ran, loading and rendering a large list (200 rows,
7 columns) went from about 2.7s to 0.7s.
We still do way too much work, but at least it is much faster...
Csaba Fazekas