Purpose
=======
From product stat button (purchase) on click of purchase lines open Purchase line's form view, the view is not correct and it is not intended.
Specification
=============
Stat button of purchase orders in product form view, on click of line do not open form view of purchase order line only list view...not form view (restrict to open form view).
- 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.
Purpose
=======
Stripe is now a payment acquirer that can be used to manage subscriptions, just like Authorize and Ingenico.
Specification
=============
For Stripe : add "Subscriptions" and "Save Cards" as features on the payment acquirer selection screen
Purpose
=======
If a method doesn't exist when running scheduler, log an error instead of raising an AttributeError
The goal of a cron method is to go ad far as possible.
Purpose
=======
This bidouille on the ORM command seems to be from another age where the onchange on o2m list were not working well.
The issue is that _convert_to_write could return commands like (6, 0, []).
In that case the last tuple element is not dictionary, but a list.
Specification
=============
Fix that brol.
Purpose
=======
As there's no 'xfa_account_id' configured on the module installation, the demo data are not created.
Specification
=============
Remove them.
Before this commit, the posbox was built and in the process the permissions of the repo were whanged
As a result, there was a diff in the repo, making it un-upgradable
After this commit, the permissions on the posbox' Odoo repository are unchanged, and no diff is to be seen
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')
- Create 2 SO, one with a down payment
- Validate the down payment invoice
- Select both SO, and choose "Invoice Orders"
- Create the invoice
The down payment is not deduced from the invoice.
It is more logical to take it into account at this point of the process.
However, changing this in stable is a major change of behavior.
opw-779954
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
Kinjal Mehta