- Default gender is male
- Default marital status is single
- Move some fields from the contract to the employee (permit number, visa number, visa expiration date)
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
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.
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).
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 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
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 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.
Currently default displayed sales team in dashboard are the one current
user is member of. However as an user can be member of only one sales team
it is not very easy to manipulate.
This commit improves that behavior by adding a favorite mechanism. Users
can favorite several sales team. Those are displayed in the dashboard
allowing users to decide which sales team to display independently of
being a member of the team or not.
Dashboard now also display a search bar in order to be able to change the
default behavior and choose other filters if necessary.
A security rule is updated as salesmen should be able to read several
sales team from now on.
This commit modifies the way field widgets can specify the fields to fetch.
Before this commit, a key `fetchSubFields` was used to fetch the `display_name`
and the `color` in the many2manytag, but this behavior wasn't generic.
A new key `fieldsToFetch` has now been introduced ; it should contain the
definition of all fields to fetch.
Introspection attributes on function and methods were originally
prefixed with func_ or im_ e.g. im_class or func_name. For coherence with the
rest of the data model, Python 3 added dunder attributes (__func__,
__code__) and removed the old style, the dunder attributes were
backported to Python 2.6.
Use dunder attributes everywhere we're currently using func_* or im_*
attributes.
Fixers:
lib2to3.fixes.fix_funcattrs
lib2to3.fixes.fix_methodattrs
#8530
Most of the type aliases in the types modules are remnants from when
the corresponding builtins were just conversion functions and not
proper types (before type and class unification).
Python 3 removes them, and thus `types` essentially can't be used in
P3, it now only contains "interpreter" types which can't trivially be
obtained elsewhere (e.g. GeneratorType, CodeType, TracebackType) and
tooling to dynamically create new types (added in 3.3).
Convert a bunch of types usages in yaml_import to use the
corresponding builtin types.
fixers:
lib2to3.fixes.fix_types
#8530
The editable list view (and the x2manys) have been reimplemented, but
the user experience was not totally (this is an understatement)
polished. With this commit, we reintroduce a good functionality:
pressing enter on the last line of the list creates a new line.
Also, this commit removes a 'debug: true', leftover by someone with a
trigram starting by F and ending by WI.
When we load a field data with many2many_tags widget, there is no views in the
field info but instead we need to fetch the default fields,
e.g. color, display name and id.
Before this commit, all the fields with value `false` on record creation
were deleted from the given parameters for the `create` rpc.
e.g. it was impossible to untick a checkbox in the settings, the `false`
value was not saved in the created record.
Activities now have recommended next activities. Based on next activities
configured on activity types, it allows to implement light workflows
using next activities feature.
This feature was removed when refactoring crm activities to generic
activities. People asking to remove it were visibly wrong and it is
now implemented back as it was in v10.
Yannick Tivisse