In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
The field `ssnid` is used on the payslip. However, it is not available
in any view, therefore it is impossible to fill it.
We replace by the `identification_id`, which is the field commonly used
for identification.
opw-742204
Closes#16798
With this commit, we prevent view dialogs from changing the 'global'
environment in the view manager. Here is how it could cause a problem:
* open a form view for a bill of material
* click on one of the component, it will open a form view in a dialog
(and will change the environment with a wrong res_id)
* click on the many2one product -> it will open a new action in the
background, and change the environment again
* click on the breadcrumb to come back to the bill of material: the view
manager will try to restore the correct res_id (which is the wrong id
from the component form view), the form view will do a read (when
reloading the data), will get an empty result, will update its
information with no data, then will be in a wrong state which means
that the basicmodel will fetch a x2many with a wrong res_ids list
* boom
- Activate multi-currency: EUR is main currency, USD is secondary
currency
- USD currency rate is:
1.2 on 2017-01-01
1.5 on 2017-02-01
- Create a journal in USD (e.g. Cash)
- Create a tax with Cash Basis activated
- Create an invoice of 100 USD on 2017-01-15
- Register a payment of 100 USD on this invoice on 2017-02-15
- 4 journal entries are created:
the payment itself
the exchange rate difference
the cash basis linked to the payment
the cash basis linked to the exchange rate difference
The cash basis linked to the exchange rate difference should not be
created, it is not necessary. The amounts are already included in the
cash basis linked to the payment.
opw-728767
Purpose
=======
- product form is a bit disorganized with fields showing up at wrong place:
- inventory tab for services -> to remove
- subscription & events fields under Invoicing tab
- inventory tab is not structured
- invoicing and bill control fields are not grouped together
- etc.
Before this rev., there might be a crash when the user quickly
clicked several times on the browser's back button. This crash
occurred in the code saving/restoring the scroll position of the
current action.
When clicking fast on the back button, several actions are
executed but don't wait for each other (those actions are triggered
by the hashchange event), so when it is fast, and mainly when the
appswitcher is involved, it may happen that we try to get the
scroll position of an action that isn't loaded yet.
opw~741814
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.
Lucas Perais (lpe)