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.
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.
... 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...
The attribute `group_expand` allows to reorder and add empty groups to the
result of `read_group`. Enable this feature for other fields than many2one
fields.
Before this commit, fields were selected on activation (focus) but only
after a setTimeout. This setTimeout is in fact not necessary. Removing
it allows to test the selection in unit tests.
`DebouncedField` and `InputField` classes were not properly factorized,
some of the DebouncedField code had to be part of the `InputField`
class (which is a specialization of `DebouncedField`). Indeed the
`FieldText` class, specialization of `DebouncedField` class, was missing
properties which were part of `InputField` and was duplicating code
which was already defined in `InputField`.
For example, it was not possible to navigate out of text fields in
editable list views with the right/left keys as this was part of the
`InputField` class.
Note: the FieldTextHtmlSimple class was implementing the `commitChanges`
function differently than `DebouncedField` but this was in fact not
necessary. This is why documentation update has also been done for this
by this commit.
Rev[0] and [1] introduced a versioning on product's attachments through an
ECO creation or through a stat button on the product form view. These revisions
added some fields on the ir attachment model: a many2one and a boolean field
with a default value, and due to concerns over the migration of databases with a
lot of ir.attachment records (like ours), we adapted the implentation in rev[2][3].
We deemed reasonnable to remove the "active" field, as adding an active field not
in the “base” module of the model could impact other modules that did not took into
consideration this field. Also, this field only had a meaning when mrp_plm is
installed, and ir.attachment is used in various places in contexts across Odoo.
So, rev [2] and [3] changed the implementation of the versioning to only link
ir.attachment to an ECO record, forgetting the functionality of archiving directly
through the product form view stat button (without an ECO).
To introduce back this behavior, we chose to create a model to handle the mrp
attachments (named “mrp.document”) which inheritS ir.attachment. This way, we keep
the behavior of ir.attachment and we do not alter the original table.
This commit moved the priority field already set on ir.attachment to mrp.document
and adds the active field that will be used in mrp_plm to archive/versioning purposes.
linked commit:
[0] https://github.com/odoo/enterprise/commit/99138b6711760a7562cb9559663aef6a4208a48f
[1] https://github.com/odoo/enterprise/commit/4f88eb409776c1c4bc8f8d71d845b913c3604a54
[2] https://github.com/odoo/enterprise/commit/7e1c73cfc84cd23b6ba87dab713c3078de16568d
[3] https://github.com/odoo/enterprise/commit/ee1c4b29b8872dac9c525fcc6acdf80b5ef73131
This rev. fixes 2 issues about many2many fields displayed with
an editable list view, occuring when the user edited some values
in the list.
First, the many2many field was re-rendered each time one of its
sub-widgets triggered a 'field_changed' event, and thus the row
the user was editing was no more in edition and the focused field
was no more focused. This was quite annoying.
Second, when the user saved changes made in the editable list view,
only a command 6 (REPLACE_ALL) was sent, so updates of subrecords
were never saved.
Before this rev., if you opened a form view with, e.g. a float
field, that is unset, and then click on edit, then save, it
actually saved the new value for the float field (being 0),
whereas it shouldn't do any RPC as nothing changed.
This is because the former code couldn't detect if the value "0"
in the input is there because the field is still unset or if the
user simply set it to 0.
By default auto_search is set to `True` on window actions, this mean
that for example on a list or kanban view the records will be searched
on the view opening without any user action needed.
Setting it to `False` disable this.
Doing this had two drawbacks:
- depending on race condition, the view could be displayed before the
search view was loaded,
- the code expected `active_search` to be present which was not the case
in this instance.
Before 151c9074 the second issue would not happen (active_search was set
directly resolved if a search was not to be done) and this commit also
wait for the search view being ready before showing the view.
opw-741186
opw-741546
closes#16805
This way if phone validation is activated users will have to enter correct
phone numbers. This will greatly help having correct data in customer
tables and improve efficiency of CRM-based flow.
This commit proposes to ease field error management by having a
structured json response having field name as keys and error message
as value. Controllers can return a specific error message for some
fields that is displayed in a popover.
This bridge module adds phone / fax / mobile number validation for lead
and partner models, using the recently-introduced phone validation tool
module.
This is done at onchange level and is therefore not blocking or
computationally heavy. Its main use is to help salesmen correctly
entering or checking phone numbers when using Odoo.
Using phonenumbers library this module adds tools methods as well as a
small mixin for models that want to activate phone number validation
and formatting.
Formatting can be done always using an international format or having
both national and international format. This is configured on the
company.
Note that phonenumbers library is optional. Installing this module without
having the lib installed just skip its use but should not crash.
The process of evaluating a domain is not really difficult, but the hard
part is getting the evaluation context right. The evaluation context is
supposed to contain informations coming from various sources (active id/ids,
session context, ...). Before this commit, we just ignored the context coming
from the action.
This could cause many problems. For example, in the Inventory
application: create a picking, add 10 ice cream in initial demand, force
assign, click on scrap. A form view should be opened (with the context
coming back from the button_scrap method). In that formview, there is a
many2one Product. Clicking on it should perform a name_search with a
domain looking like ['id', 'in', [64]]. This domain is the result of
the evaluation of "[('id', 'in', context.get('product_ids', []))]".
Before this commit, product_ids was ignored, so the domain was always
['id', 'in', []].
In this commit, we simply add the element context in the list of sources
when computing the evaluation context (the element context is the
context given to the view, which is the way an action give a context to
a view)
In short, handling context is hard...
When you send a mass mailing to muiltiple partner, if some of them have
no email adresse, it can lead to errors because of the variable 'recips'
is not set if the first occurence in the 'for loop' has no email.
To fix this, we always set the variable 'recips' by replacing the 'elif'
close by a 'else' one
introduced in rev: https://github.com/odoo/odoo/commit/65ed4553a50fdbefc986b7d21f87a81c42b743c7
If the picking has no carrier set, do not open the put in pack wizard
and keep the behavior of a classic picking. Also, filter the delivery
packages according to the carrier (note: this doesn't work at the moment
because of a bug in the new views, but it'll be fixed very soon, so we
merge anyway).
Also, remove an harmless typo in `manage_package_type` method.
If the option 'event_open_popup' is set to true, then the calendar view will open events (or records) in a FormViewDialog. Otherwise, it will open events in a new form view (with a do_action)
Before this change the t-call can use only receive a literal as parameters:
<t t-call="template.name17" />
This call render the template 'template.name17' with the current context.
Now, we can defined an expression with braces (same syntax that t-attf):
<t t-call="template.name{{ 10 + 7 }}" />
This call render the template 'template.name17' with the current context.
This change allows for greater flexibility for applications using qweb.
(The performance due to this change is unchanged during rendering time.)
- Create an article with one supplierinfo (with a delivery delay and a
min. quantity > 0) and a customer delivery delay
- Trigger the creation of a PO by a procurement order for this article
The supplier delivery delay is not taken into account in the date order
of the PO because the seller is not selected.
This is because the procurement quantity is not sent to the seller
selection.
opw-16702
Closes#16702
These commit are the 3rd part of improvements
of Services flows.
It introduces 2 important parts
- timesheet revenue: how much the timesheet bring back
money.
- timesheet overview: a kind of dashboad to see the financial
state of a project, grouped by employee or billable type
Other improvements are UX, adding missing settings, hide
some technical fields, ... to ease the configuration and
day-to-day usage.
This commits add the timesheet overview on the project
kanban. Instead of redirecting to timesheet list, the user
will see a more detailled view.
The timesheet dashboard shows the amount per billable types,
the numbers of hours provided per employee and per billable
types, ...
This view is integrated with the search view : changing the
filter will shows you the informations for your selection.
The purpose is to give the user a global view of the project
(or other timesheet) financial situation in the same place.
This overview is made to be extended in enterprise to add
a section to compare past (timesheets) and futures (forecasts)
activities.
Jérome Maes