PURPOSE
=======
During the Salary Package Configurator implementation, some improvement have been made to improve the fleet management module
- When duplicating a fleet vehicle cost (for example when duplication a vehicle contract), duplicate the included costs too.
- Add a field Cost Description on the list view
- Rename 'Acquisition Date' into 'Immatriculation Date'
- Rename 'Car Value' into 'Catalog Value (VAT incl.)'
- Add a information field 'Residual Value on a vehicle'
- Prevent an employee to have several cars
- Only display opened contract on the vehicle form view
- Add the driver on the odometer list view
- Rename 'Odometer value' into 'Odometer at creation' on a vehicle contract
- Restructure to vehicle model form view to be bearable by a human eye
- Show the handle widget on the fleet vehicle state list view
- Show configuration menuitems to fleet managers, not only debug mode
- Create an expense sheet
- Line 1 is 500
- Line 2 is -200
- The total is 300 => a payment of 300 is made
When the payment is validated, the expense is not set as paid.
In v10, one expense line = one account move. In order to know if the
expense is paid we check that each account move is completely
reconciled. The account move of 500 is never completely reconciled by
the payment of 300, so the expense stays opened.
This simply cannot be supported in v10, since each expense line is
handled in a separate account move.
opw-740492
Before this commit, the form dialog was open twice when you tried to
add a new record on a one2many if you were already in a modal.
The event wasn't stopped, so the first form dialog was correcly rendered
but the second one tried to load the same form view on a wrong model.
The basic model did not transfer field options to special data methods
from fields. This was mostly not an issue, except for the widgets that
actually need them, such as the status bar and the domain editor.
This was only visible when opening views with different view types,
but this is a problem in general. We should have a better mechanism to
help widgets fetching data, but for now, this is the best we can do.
This test executes the QUnit js test suite. Since the new views,
this suite keeps growing, which is good. The default timeout
for phantomjs tests is 60 seconds, which starts to be tight for
test_01_js when the runbot is overloaded.
So this commit increases the timeout of this test to 120 seconds.
The views can specify js (and css) libraries to lazy load when
they are instantiated for the first time. The previous
implementation was too naive as it always loaded the specified
libraries in parallel. However, it may happen (e.g. gantt view)
that some of those libraries depend on other ones.
This commit implements a mechanism to handle libs dependencies
between each other. For instance, specifying:
js_libs: [
['a', 'b'],
['c'],
],
will load 'a' and 'b' in parallel, but wait for them to be
loaded before loading 'c'.
The new implementation still supports the old syntax. So,
js_libs: ['a', 'b', 'c'],
will load 'a', 'b' and 'c' in parallel.
In a notebook, tabs may have an invisible attrs. The first visible
tab should be active in any case. This wasn't working at the first
rendering of the view, because the invisible attrs was evaluated
for each tab, before processing the next ones, so the it couldn't
find a next tab to activate.
This fix ensures to process all tabs (i.e. generate their DOM
element) before evaluating their invisible attrs, and trying to
find which tab to activate.
Mode 'readonly' is a concept of list and form views. When
switching from a graph view to another view, then switching back
to graph, there was a crash because 'readonly' is not a known mode
of graph (in graph, mode is used to determine the type of graph to
display (pie, chart or bar)).
This is due to commit odoo/odoo@ef6b330 which aims to reset the
mode to readonly when coming back to a form view using the
breadbrumbs.
Before this commit, concurrency issues were mostly handled by the mutex
in the basic model. That mutex makes sure that save and change
operations are properly serialized. However, this is not enough. Here
is an example:
1. we have a required field with an onchange and a current value
2. the user changes the value to an empty value. This triggers an
onchange
3. the user clicks on save, before the return of the onchange
4. the controller checks with the renderer if it can be saved. At that
point, the onchange is not yet complete, so the values stored in the
fields are still the initial ones, which are valid (non empty value
for required fields)
5. so, the controller request a save operation
6. the model add the save operation in the mutex, wait for the onchange
to complete, then apply the save operation
7. we end up with a required field with an empty value
The issue here is that the model properly saves and apply onchanges, but
the responsability to check if a record is valid (which depends on the
modifiers AND the field widgets) is the renderer's responsability (it
has to ask the question to all its sub field widgets).
So, we need to serialize 3 operations: applying the onchange, checking
if the save is valid, and saving the record. This cannot be only in the
model, so we need to add a concurrency control mechanism somewhere else.
What we do in this commit is to add a mutex on the basic controller (it
will most likely be used by the list controller as well). In this
mutex, we currently serialize the field change operation and the save
operation, but I assume some other operations will need to be handled by
the mutex.
In addition to this, we also change some asynchronous methods to return
a deferred, so we are ready for other kind of asynchronous behaviour in
the future.
During refacotring of the new settings, the group='xxx' has been removed.
Withtout it, the implied_group are only apply to the group Employee.
In this case we want that group_portal and group_public have also the group
to have the option on the website.
opw-740751
The account payment widget did not work at all, since we pushed the new
views. With this commit, we adapt the code to the new views (note: the
file account_payment_widget was renamed in account_payment_field).
XML-RPC can't serialize None, as a result methods callable over RPC
must return something (True, False, an actual value) otherwise an
error is generated when their result is serialized and sent back to
the client. It happens that JSON-RPC has different limitations and can
serialize None, so MRP had multiple button/action methods which could
be called over JSON-RPC but would break when called in XML-RPC for no
reason.
Fix them by returning `True` or result of `write`.
OPW-728844
When a journal entry is created automatically from an invoice
validation, that logs an internal note with the text
"This account entry has been created from:". There should be
a clickable invoice's reference after but there was only an empty space.
The problem come from the method that call the template
"message_origin_link" with the selected invoices as arguments.
The template use the attributes id, _name and name. But for the
invoice object we want to use the number attribute instead of
name. The name of an invoice is empty by default and thus is
rendered as a blank in the template.
This commit modify the template and use the property display_name
instead of name. "display_name" use the number for the invoice and
is still correct for other object.
The invoice name is just a reference and is not required, so if you
use the field name of the invoice it can return an empty string.
The name_get method returns the invoice id + invoice number and
eventualy the invoice name.
When adding a field on a model, only the _inherit were checked, not the _inherits.
This commit fixes the following bug:
1. install `sale` (adding the field `sale_order_count` on `res.partner`)
- field `sale_order_count` is created on `res.partner`
- the ir.model.field is tagged with module `sale`
2. install `point_of_sale` (adding another field on `res.users`)
- field `sale_order_count` is created on `res.users`
- the ir.model.field is tagged with module `point_of_sale`
When installing sale, the model res.partner is returned in the list of impacted
models, on which _create_fields method is called but not res.users.
A direct consequence of this bug is that, the fields translations are in the
wrong module. May fix some uninstallation bugs too.
Closes#16104
Currently the link is always the website link once website_portal is
installed. However it is better to use the generic /mail/view controller
that chooses the right redirection depending on the user trying to access
the document.
Currently the link is always the website link once website_portal or
website_quote is installed. However it is better to use the generic
/mail/view controller that chooses the right redirection depending on
the user trying to access the document.
This commit also fixes redirection in website_quote that is always
redirecting to the front-end. Classic users should land on the backend.
Indeed seeing the front-end page is rarely interesting for them.
get_formview_action is now called as sudo to avoid access rights issues
when browsing it and trying to determine the ID of the form view to
display.
However in some cases it can be interesting to know the real user trying
to access the form view. The original uid is therefore added as parameter
of the method to have the best of two worlds.
In 9.0 the argument pay_journal in function pay_and_reconcile must be an id
but in 10.0, pay_journal must be a recordset with one element. So it was
not possible to call this method by rpc in 10.0
opw:725737
In Python 3, ``print`` becomes a builtin function. This is available
in Python 2 by importing the ``print_function`` feature from
``__future__``, the feature is conveniently still available in Python
3 (it just does nothing).
Fixers:
libfuturize.fixes.fix_print_with_import
#8530
* in P3, the iterator stepping method has become a dunder method (next
-> __next__), the protocol has not changed, add a __next__ alias to
the iterator-next definition (nota: ir.config also has a next method
but it's not part of an iterator, so don't alias it and don't
convert calls to it)
* since ~2.6, a builtin (next()) has been added to step an iterator &
allow for a default (in case of iterator end), convert all manual
stepping to the builtin
Fixers:
libfuturize.fixes.fix_next_call
#8530
Don't check ids with "id is None" statements, as it won't match if id is False. This caused some bugs with MRP when confirming a MO with no calendar defined, if mrp_operations was installed.
When we have purchase orders and we return some products to the
supplier, we now have the possibilty to set those moves as 'to refund'
and so the quantity received is decreased.
Because the feature 'to refund' already exists on the sale orders, we
will generalize it in the module 'stock_account' which is a dependency
of both 'sale_stock' and 'purchase' which are the both module that use
the feature 'to refund'.
Before this commit, in the reconciliation widget, the reconciliation alert (exclamation mark) was displayed, even for amounts less than the total. It does not make sense, so we just hide it in that case.
When deleting payment tokens from website, in My account, by clicking
on button "Manage your payment methods", the public user, the user and
the portal user got a 403 error. But when creating a subscription
for a customer with admin user and setting a payment token for
the company of this customer. This payment token could not be deleted
or modified by its users. In a few cases, it's needed to delete or
modify a payment token, for example, when the expiration date of
the payment token is expired.
opw:740169
When the user changes the filters in the search view, this one
triggers up an event to notify its environment that its state
changed. This came with the new views, as before the search view
triggered an event on itself (i.e. used 'trigger' instead of
'trigger_up'). At some point, 'trigger' will be deprecated and
'trigger_up' will be used instead, everywhere.
The code in mail hasn't been updated accordingly, so the thread
wasn't updated when the user changed the filters.
When a user opens a record in a form view, the chatter is
displayed. Then, if he clicks on 'Create', the chatter is removed
from the DOM (there is no chatter in create mode). After saving
the newly created record, the chatter is displayed again, but the
same widget's instance is kept.
However, when being removed from the DOM, the event handlers bound
on elements of the chatter (e.g. 'New Message', 'Log a Note'...
buttons) are automatically unbound.
So before this rev., the buttons didn't work anymore once the form
view had switched to create mode. In this commit, we detach the
chatter's $el before updating the view, so that its handlers aren't
unbound when the old content is replaced by the new one.
Before this rev., some keys were added to the context of a record
if there were x2many fields in the form view with a context
defined on their node (containing *_view_ref keys, specifying the
fields_view to load to display the relational data). Those keys
should not be added to the main record's context, and it may cause
errors (e.g. click on the 'Procurements' stat button in the Product
form view).
when calling 'read' to fetch a record and 'search_read' to fetch a
list of records.
I don't know where (or if) it is used, but it seems more correct
like this (and mostly, it was the case in the old views, so we
re-introduce the same behavior).
Before this fix, default values for many2many fields (i.e. 'replace' commands)
weren't correctly handled by the model, so the default values weren't set for
those fields.
Yannick Tivisse