In the tests environmnent, we don't want img and iframe nodes to
perform RPCs when they are inserted into the DOM. For img nodes,
we prefixed the src attribute by '#test: ' as soon as they were
inserted into the DOM. Unfortunately, this didn't work as expected:
an RPC was done to fetch route '/web/tests?' (i.e. the tests page),
because everything after '#' in the url isn't sent to the server.
This rev. completely removes the src attribute of img nodes, and
set a 'data-src' attribute with the original src attribute's value,
so that it can still be checked in the tests.
Tests using this attribute have been adapted accordingly.
In the tests environment, we listen to the 'DOMNodeInserted' event
to remove the src attribute of img and iframe nodes as soon as they
are inserted into the DOM, so that they don't perform RPCs.
However, this listener was bound in the create(Async)View, and
createActionManager helpers only. This rev. moves it to the
addMockEnvironment helper which is more global, and basically used
by all tests.
Moreover, we now listen to the 'DOMNodeInserted' event on the body,
instead of on the widget, as it may happen that some content is
inserted into the DOM outside the widget itself (e.g. dialogs are
appended to the body).
Before this rev., the aggregates values displayed in the footer of
list views were formatted according to the field type, and the
field's widget was ignored, whereas it should be used by default.
For instance, if the 'float_time' widget is set on a float field,
the sum should be formatted as FloatTime as well.
Closes#22724.
Before this rev., the list of selected records wasn't correctly
reset when the list was reloaded (e.g. when coming back using the
breadcrumbs). In the UI, the records weren't selected anymore, but
in javascript, the list of selected records wasn't empty. As a
consequence, the aggregates were wrongly computed, and always
displayed 0.
Closes#22725.
Before this commit, when a planner made a link from an action, the view_type was always 'list'
This prevented the view from being properly loaded, as an action of view_type form wouldn't be recognized
After this commit, such links are well formed, and form view_type actions are correctly loaded
OPW 806758
Since the <widget> tag is not used anymore in any of our views, it was
not really properly supported. In particular, the form widget was not
notified when the state of the form view has changed, which makes it
very difficult to actually do any useful work.
With this commit, we make sure that the widget method 'updateState' (if
it exists) is called with the new state whenever it changed.
This should allow developers to do useful work without having to work
around the issue. Note that this is not really a perfect solution, since
the updateState methot may or may not have been implemented.
I think that we need some kind of ViewWidget abstraction, which could be
used to have a better and more complete API for widgets in a basic view.
And AbstractField could inherit from ViewWidget.
This allows rpc requests in `HttpCase` to use the cursor `self.cr`, which is
now shared between the Python test and the rpc requests. This simplifies code
to prepare a JS test, and code to check the result of a JS tour.
Fixes#12237
Fixes country_id and company_id mismatch in 65832dc.
Removes the view added by said commit as it was not a true stable
fix since it required users to update the module.
This commit uses a workaround to get the missing company_id field
which is monkey-patching the fields_view_get of the model, as
suggested by rco.
This commit also removes the exception catches that were rendered
useless by the False value given to the raise_exception parameter
of phone_format, introduced in 65832dc as well.
This commits fixes the behaviour in the website form as the phone
numbers were sanitized but never saved as such on their record.
This commit also renames the Phone Validation config setting to
suit its true functionality.
Activity mixin adds an activity_date_deadline field that is a related on
activity_ids. This one is a o2m using a domain based on the current record
model. Indeed activities are cross-model, like mail.message.
However as it is stored it generates are a lot of unnecessary computation
when activities are updated. Indeed when activities change the related
computation is triggered for every model inheriting from the activity
mixin. It then applies the domain in order to find record to update. This
generates a lot of void queries because only one will match the activity
model.
This commit makes the field not stored anymore. Indeed it is used mainly
in filters. Same functional result can be achieved using a computed and
searchable field.
We gain a lot of queries when creating activities as indicated by the
counter update in this commit. Creating a record inheriting from activity
mixin is a bit improved since there is less computed field to compute.
Creating an activity costs a lot less queries and we gain about 40%
in term of query required to create an activity when a lot of models are
using the mixin.
On community runbot it makes a gain of 2% when installing all modules.
This commit allows to save 13K queries on 587K (current) which is quite
good.
Rev. dbdd742 introduced the 'baseMode' parameter of field's nodes
in the BasicRenderer. Its purpose is to encode the generic mode
of the field, regardless of its readonly modifier (i.e. in form
views, the baseMode of all fields is the mode of the renderer and
in list views, the baseMode of all fields is 'readonly', except for
fields in the row being edited, whose baseMode is 'edit').
Unfortunately, when the value of the readonly modifier of a field
was 'readonly', its baseMode was changed from 'edit' to 'readonly',
which shouldn't, as the baseMode's value should not be affected by
the modifiers.
This produced a bug when a field had a readonly modifier, as once
its value became true, the field was rendered in 'readonly', and
whatever the value of the modifier afterwards, it always remained
in 'readonly'.
The rev. ensures that the baseMode is no longer impacted by the
value of the readonly modifier.
Closes#22729
Having a product on which a group of taxes apply (containing children taxes, obviously)
Make a sale
Validate the entries
Before this commit, the account_move_line created from the pos.order.line
had only the group of taxes as their tax_ids
Which is inconsistent against what account.invoice do,
and against what the generic report tax does
After this commit, we imitate what happens on invoices, and the movel line
created from the pos.order.line has the children of the group and the group as tax_ids
OPW 806089
Before this commit, on the reconciliation widget in Firefox
filtering lines through the input triggered a Traceback
This was due to the use of the absence of a defined "event" parameter on the handler
After this commit, filtering does work as expected
opw 813791
Before this commit, user see a traceback:
(res_users.partner_id in (3,ARRA.. ...
operator does not exist: integer = integer[]
After update from initial commit
After append from commit 1bb74b7588
Now, extend to allow [1].extend([2,3])
This commit closes#22944
Courtesy of @paulius-sladkevicius for reporting
Purpose
=======
Ease the process to add receipt from the mobile app
Specification
=============
Add an "Attach Document" action button.
On mobile, it should open the camera app + have a link to choose a photo from the gallery
Purpose
=======
Add the possibility to easily attach a document on a record. That could be used for to attach receipts on expense for example.
Specification
=============
Add a new widget (AttachDocument) to allow attach document from mobile/web directly on record form
After attaching document it will call action given on widget, that action will be a method name on given model
The parentedMixin doesn't automatically set the parent, so when this mixin
is used, the parent must be set manually. This wasn't done at several places,
and thus those elements weren't destroyed with their actual parent.
In master, we should probably make the ParentedMixin set the parent itself.
Before this rev., it might happen that the parent of BasicModel instances
wasn't correctly set to the Controller instance. It was actually set to the
ActionManager instance, which is never destroyed. So when this happened,
the BasicModel instance wasn't destroyed when it's controller was.
The parentedMixin doesn't automatically set the parent, so when this mixin
is used, the parent must be set manually. This wasn't done at several places,
and thus those elements weren't destroyed with their actual parent.
In master, we should probably make the ParentedMixin set the parent itself.
Before this rev., it might happen that the parent of BasicModel instances
wasn't correctly set to the Controller instance. It was actually set to the
ActionManager instance, which is never destroyed. So when this happened,
the BasicModel instance wasn't destroyed when it's controller was.
The parentedMixin doesn't automatically set the parent, so when this mixin
is used, the parent must be set manually. This wasn't done at several places,
and thus those elements weren't destroyed with their actual parent.
In master, we should probably make the ParentedMixin set the parent itself.
Before this rev., it might happen that the parent of BasicModel instances
wasn't correctly set to the Controller instance. It was actually set to the
ActionManager instance, which is never destroyed. So when this happened,
the BasicModel instance wasn't destroyed when it's controller was.
- create a product comp1 tracked by lot
- make an inventory adjustment for comp1 ; 1 quant with lot1 and 1 quant
without lot
- create a bom for product finished1 composed by 1 comp1
- create a mo for 1 finished1, reserve it
- the mo reserved the quant with lot1
- produce finished 1
- unlock the mo
- change the component from lot1 to lot2 (that do not exist)
- the write on a move line will trigger a re-reservation that will
fallback on the quant without a lot (that's how untracked quant for
tracked products are handled)
- delete the move line, it'll unreserve with lot2 and fail
We fix the issue by applying the same logic of fallback on the untracked
quants in the unreserve of a move line.
We add a test for the unreserve of a move, as it simply unlink the move
lines.
opw-814914
Martin Geubelle