* 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.
This module adds some extra fields to the partner model, in order to be able
to manage extended addresses. However, those extra fields were not present
into the company model, thus making partner's addresses and company's
addresses displaying somewhat inconsistent.
This change takes those fields that were already present into the partner
model, and adds corresponding fields into the company model and view, so
addresses from both models are now shown the same way.
Closes#16547
In Python 3, `raise` can take:
* nothing (reraises)
* an exception *instance*
* an exception instance `from` a traceback
The Python 2 forms `raise type, instance` and
`raise type, instance, traceback` are deprecated and should be replaced.
Fixers:
libfuturize.fixes.fix_raise
#8530
hr_holiday was the only module that used a widget=toggle_boolean on a
button in a list view. That behaviour was implemented as a column
widget in the previous list view, and was not reimplemented in the new
views. The feature is useful, but this was not done properly: it is
better to use a widget on a field (that was the intent) instead of doing
a weird hack like it was done.
With this commit, we update hr_holidays to use the ToggleBoolean widget,
which is supposed to work on every views.
Also, we fix the toggleboolean widget (it was not properly rendering
tooltips, and changes were not saved in readonly list view).
Note that it as the side effect of being better from the point of rpcs:
before, the list view had to reload itself. Also, another advantage is
that models do not need to implement custom methods (such as
toggle_payslip_status) just to toggle a boolean...
Before this commit, the code that handled buttons in list view was kind
of simple, and did not reload the view after.
But clicking on action button is not only a problem for the list view,
the form view already had something in the controller doing exactly
that. With this commit, we move that code to the basic controller, and
use the method in the list view.
Currently applying a color to a kanban item applies it to the whole
card. This creates usability issues as the content is not dynamically
updated to match the chosen color.
This commit proposes to apply the color only to the header and let the
card content standard. It helps designing cards that are always usable
and readable.
In general, I think that we can safely consider that crashes are not the
intended behaviour.
In this case, viewing metadata crashed because we tried to format a date
which was not parsed (so, a string), instead of a moment object. We
simply just parse the date before, and it works as intended.
With new records, it could happen that clicking on a button in the
header was followed by actions using the wrong id. This was caused by a
field name="id" in the view (see sale order view, in the
delivery.view_order_form_with_carrier inherited view).
In that case, the id was registered in the changes list, and caused
invalid data in the record: its data.id was set to null.
This commit solves two issues with deletion:
- deleting the last record in a form view now triggers a history_back
action, which means that the view will be changed back to the main
view (a list view for example), instead of staying in form view
- deleting a record did reload the view twice in some cases.
When evaluating a context, we need to use the server format for dates,
because the context will ultimately be sent do the server. Also, moment
objects are not known by pyeval, so they simply cause a crash (for
example, see bank statements form view, edit it, click on 'add an item')
With this commit, we make sure that the evaluation context is correct,
with respect to dates (we use the toJSON method, because that is the way
we get the server compatible date)
Default mail.alias for crm.team are currently recomputed/modified
when *setting* use_leads on the team (type changes from opportunity to
leads), but not the other way around (*unsetting* use_leads doesn't
rollback type to opportunity).
Fix this issue.
Leaves over the issue that *disabling* the global setting doesn't
recompute aliases, which it probably should.
OPW-728690
In general, with the new views, we execute immediately and recursively
all onchanges, even from a x2many in a form view. It allows for nice
interactivity, for example, recomputing immediately a total or a tax in
a sale order when an order line changed.
However, we are used to treat x2manys in a slightly weird way: for
example, if you add a line in a one2many, then click elsewhere, most of
the time, it is validated. But if the line is 'incomplete' (I mean, if
a required field is not set), the line will not be validated, but be
automatically discarded. If it was dirty, a confirm dialog will open.
So, to keep in line with that semantic, we have decided that onchange
will just not be done until the line is 'valid'. This will avoid
trouble when someone add a line, it triggers some onchange which changes
some values in the form, then click somewhere else, the line is
discarded, but the changed values persist. Most of the time, it
probably won't be a problem, because another onchange will be triggered,
but it is some useless work anyway.
Use case when it can happens (non deterministic):
- Enable product variant
- Have different stock moves with the product variant
- Click on the stock moves in the section reports
- Switch to pivot view
-> Traceback : can't find path of null
This happens in the js in the function find_path_in_tree,
this function try to find path for children object. There is
a condition root.children[i].path[l] === path[l] (2 strings
comparaison).
With product variant this condition can be overpass when it should
have been triggered. The product path string is represented as follow
[Ref]Name(variants) -> Sometime the variants in the string do not have
the same order and thus the condition is never true and the function
return null instead of the correct root.
This commit corrects the name_get function for product product
in order to always return the variants in the same order.
The introduction of the new RPC framework (see
0df9968433,
e574027056 and
2106e3dd2e) replaced RPC calls made with
web.DataModel by web.rpc. The arguments in the fail callbacks for
these are different.
For web.DataModel an error object and a jQuery event are passed. The
jQuery event had to be DefaultPrevented to avoid web.session from
trying to show a traceback dialog.
For web.rpc an error type and an error object are passed. This caused
errors because the code was calling preventDefault on the error
object. Because it bypasses web.session entirely a traceback dialog is
never shown, so we don't have to worry about preventing it anymore.
Now that users with restricted access can view the dashboard graphs,
access rules need to be applied upon fetching the data.
This commit also adds the missing access rules on sale reports.
xmo-odoo