commit b4ec51021b forgot about the case where no domain was supplied
or when the conditions on it were not fulfilled.
before this commit, a traceback was thrown and no event was shown
After this commit, no errors and all the relevant events are shown
opw 782985
When logging multiple elements in one log call in the new Firefox
version, all the elements are kept on one line. So if the second
element starts with a line feed, it will not go under the first
element but still be at the right of the first element, on a new
line.
If the kanban view is grouped by a readonly field, it should not be possible
to drag&drop the record from one column to another as this will trigger a
write on this readonly field.
It should however be possible to resequence records so the option `containment`
is used in the records.
Closes#19390
Rev [1] was intended to be applied when changing the lot of the produced
product on the manufacturing order, somewhere along the line the code
was also called when setting the lot_id on the work order. When used in
this context, it broke the reconciliation between the reserved move
lines and the temporary move lines because a lot_produced_id was wrongly
set.
We fix the issue by only applying the code on prod move. This is done by
checking if the move is a production one through the stock move, because
there we are able to differenciate the raw material and production move,
not on the move line where production_id is always set.
[1] 471115b06aFixes#20964
Before this fix, when adding the attribute delete=0
on a listview, it was still possible to delete records
via the menu 'Delete' in the sidebar.
After this fix, this should not be possible to delete
records when delete=0.
The attribute delete was hard-coded to true, as there was
a traceback when it was set to false. It was simply due
to a misplaced closing brackets that was hiding an
assignment, which resulted to calling a method on undefined.
Before this fix, when adding the attribute delete=0
on a listview, it was still possible to delete records
via the menu 'Delete' in the sidebar.
After this fix, this should not be possible to delete
records when delete=0.
The attribute delete was hard-coded to true, as there was
a traceback when it was set to false. It was simply due
to a misplaced closing brackets that was hiding an
assignment, which resulted to calling a method on undefined.
Before this commit, it was not possible to reexecute functions using the
_.throttle function in the same test (e.g. drag and drop two elements in the
studio tests).
Do not forward-port this after 11.0
After sending a message, if one switched in edit mode in the form view, the
created message disappeared.
This is because the model is not aware of messages (they are created through
their own routes, message are not handled as other one2many fields with commands)
and the widget was reset with a new datapoint instance when switching in edit mode.
In this rev. we keep the model informed of the new messages by directly writing
the message ids in the datapoint.
Note that the includes on FormController and BasicModel are one in the
form_renderer.js file to fix this issue in existing database without adding
files. Another revision will be done in master to add the correct files.
opw-781353
- Create manually an account move
- Add a line with a credit != 0
- Click on "Add a line" => crash
`line_ids` does not contain the credit since it was not filled in.
opw-782980
This commits make the computation of amount to invoice
and amout already invoiced on sale order line works
with invoice policy based on delivered quantities.
Before this, the upselling of delivered quantities
was not working: you were seeing the upsell amount
in the amount to invoice (qty delivered > qty ordered).
Notes:
- When a product is not delivered (qty delivered = 0), its
amount to invoice is zero too
- Draft invoice are not take into account really; they are
included at sale order price (discount on draft invoice does
not impact amounts to invoice/invoiced)
Also, when a SO in state 'draft' or 'cancel', its amount
to invoice should be zero, but its invoiced amount should
take all validated invoices into account.
Finally, more correct trigger are set on the compute
method, to trigger recomputation on right moment.
This commit also compute the 2 amount fields as sudo, since
the amount should not be dependent of access right of current
user.
To check those different points, this commit provide some
more tests with ordered and delivered product, SO cancelling,
upselling or delivery, ...
Always return a `sale.order` object, otherwise calling method may crash
since they expect receiving such an object.
opw-761344
Manual forward-port of 0888602831 which has
been lost during normal one.
Using `with_context({'use_babel': True})` overrides completely the
environment context. Therefore, the lang is lost and the date is
formatted in the default language.
opw-779753
After commit 996a817071
The portal report on picking only check if
the user has a 'read' access on picking.
If he can read it, sudo is called and thus
record rule/access right on component objects
are not necessary.
This commit removes useless rights for portal users.
If we have a payment in october and a statement in november and the lock date is 1st november, we can't reconcile both because we try to write statement_id on payment but there is the lockdate constraint. This is not correct and we should be able to reconcile both even after lock date as it is the case for other moves.
The pad_project addon has a simple mission: allow the user to choose if
he wants to use pads in all tasks from a given project.
This is a noble goal, and the code actually works for projects which
have a 'use_pad' field set to true. However, when a project has
'use_pad' set to false, we have a critical issue, due to the way the pad
widget works.
The pad widget is kind of strange, because it is set on a field which
contains the url for a pad, and it should write itself (the same value),
whenever someone writes on the pad, so the server knows it has to fetch
the result and write it on the 'real' field. This means that the pad
widget has to write its value each time the user modifies the pad
content and press save. However, fun fact, we have no way of knowing
when something was changed inside the pad iframe, so we actually save
the value each time the form view is saved.
So, we have a problem now: the description field AND the description_pad
field are always saved, and they interfere with each other.
In this commit, we put the description_pad in readonly mode when it is
invisible, so we do not save its value at all for each edit/save cycle
(and prevent interference). It actually prevent calling the
generate_pad_url method, but a pad is still created by the server code
each time a task is created.
Before this commit, asynchronous field widgets (with willStart async),
with a non empty template had a problem: the invisible modifier was not
applied properly.
The reason is that the code that applied the modifiers was called
directly after the widget was 'willStarted'. This means that if this is
async, and if there is a template, the $el in willStart will be replaced
by another $el after, which will remove the invisible modifier.
This was an interesting problem with the pad widget (it is asynchronous
the first time a pad widget is instantiated)
Before this commit, asynchronous field widgets (with willStart async),
with a non empty template had a problem: the invisible modifier was not
applied properly.
The reason is that the code that applied the modifiers was called
directly after the widget was 'willStarted'. This means that if this is
async, and if there is a template, the $el in willStart will be replaced
by another $el after, which will remove the invisible modifier.
This was an interesting problem with the pad widget (it is asynchronous
the first time a pad widget is instantiated)
backporting 76b724294a
OPW 779208
closes#20996
original commit message:
Add a 3 use cases with tests that were failing before.
datetime filters were not working correctly on stop filters
The `_get_recurrent_date_by_event` was only computing recurrency on the start
field of an event which can make a difference. A recurring event
start=2017-01-01 09:00:00; stop=2017-01-01 10:00:0
was not matched in a search ('stop', '>', '2017-01-01 09:30:00')
The filter != was not handled in the recurring use cases.
e.g. making the search 'start is set' in the web client is equal to
('start', '!=', False)
Searching with only a start filter matching recurring events but not the
first ("real") occurence, was returning no result if no stop filter was present.
start=2017-01-01 09:00:00; count=5
had no result in a search ('start', '>', '2017-01-02')
In left menu used for switching between "apps" particular menu, the
apps names were not translated.
This commit use the "string" attribute which is translated instead of
"data-string" fallbacking on data-string (so things still work without
updating the module).
opw-781728
closes#20972
Because the uom field on production lot is a related field of
product.prodcut, we shouldn't change the uom of a product through the
production lot formé
Consider this: a form view with a one2many list view. In the one2many
list view, there is a many2one field. When opening the manyone in a
modal form view, there is a many2many field. In that situation,
clicking on 'Add a new record' on the many2many field had the
unfortunate effect of interfering with the one2many field in the main
form view, which caused a crash or the modal form view to close
unexpectedly.
The issue is that an event was simply not properly stopped at the proper
location. This is usually not a big deal, but, as described above, it can be
a problem in some cases.
Lucas Perais (lpe)