This commit adds a new model, Payment Method, which stores
a reference to the payment acquirer's database and a reference to
a partner. Each payment module must have its own implementation.
The implementation is completely abstract but may not suit every
provider's way of implementing recurring payments.
It was removed at 2df9060d97 and broke
tests in community modules that relied on it.
Tests using it should switch to the new get_db_name() method.
Closes#7054
The commit 3269ad8f get back the behaviour of 7.0 (which changed in
october 2014) that when a field is overrided via the old api, attributes
of a previous definition of the field are lost.
This fix corrects the case when this behaviour might have had an effect
so specified attributes overrided don't get lost.
related to opw-639712
In 7.0, a field overriding an inherited model would overwrite all the
previously set field attributes. In v8 the new API allow us to keep
previous attribute, and only overwrite attributes of our wish.
Following the commit 7b1ef708 (october 2014) an old api field overriding
could conserve previous attributes values in some cases (if the new value
is falsy (None, "", 0, False, (), {}, [], ...) when it should not. It
was partly an optimization to diminish the size of orm registries
dictionaries to save memory (this patch has been tested with all odoo
modules and added +/- 3M).
This commit (proposed by rco) should overwrite falsy value (so the
behavior of v7 for old api fields overwritting is re-introduced) and
get back the behavior of old api in V7.
closes#7035
opw-639712
When the uom(Unit) set by default is not in the same category than the uom category of the product,
the uom of the product is set.
When the uom is changed, the theoretical quantity and the real quantity are recomputed.
opw:641027
When a product is scrapped, we set the reservation_id of the scrapped move on
the quant corresponding to the original move (e.g., the move which brought a
manufactured product from production to stock). By doing so, we will subtract
the quantity to scrap from the appropriate quant.
opw-641852
When filling the form (for invoice or delivery details), once a field has been
filled, it's no longer possible to remove the value of this field.
e.g. set a company, not possible to remove it when modifies the address
This is due to the `get(key)` call that is considered as False with empty
strings. Instead, check the existance of the key.
Still not accepting mandatory in the form (not checked in this method).
Fixes#7017
The stat button count included only reserved seats,
while, when clicking on the button, all attendees
were displayed: draft, confirmed, canceled, done.
Usability speaking, this isn't right.
Besides, once the attendee actually attended the event,
it wasn't anymore included in the count, which is not logical
either: by "Confirmed", you expect the reserved attendees
and the attendees already there.
In addition, on the kanban view, the link said "confirmed" attendees
as well, but redirected to the list with all attendees.
The "expected attendees" value on the kanban was along a "report"
link, bringing to the report where only confirmed seats are displayed.
Kind of non-sense.
Finally, the decision made:
- For an event, the more natural count that you want to see first
is the "expected" attendees, including draft, reserved and attended
attendees.
- Both buttons, on the form view and the kanban view now includes
draft, open and done attendees, and redirect to the list view
displaying only these attendees (canceled excluded).
- On the kanban view, you have a count more including the confirmed
attendees, including the open and the done attendees.
opw-642134
If an event exists on Google but was not synced yet in Odoo, the synchronisation
would fail.
When self.OE.found is False, self.OE.event is not defined and trying to access
it would fail (it's a python object, not a recordset)
Check the ownership after making sure the event is present in Odoo.
Fixes#7034
!! THIS SHOULD NOT BE FORWARDPORTED TO MASTER !!
When loading an action with a specific url (e.g. when refreshing the
browser), the view displayed before refreshing should be loaded
directly (except for form views, for which we need the default
view to be loaded first to keep the breadcrumbs intact).
Before this rev, it automatically first loaded the default
view for the model (i.e. the first view in the views' list), and
then switched to the previously displayed view. This sometimes
produced an error when using a filter needing a field not available
in the default view (e.g. Reporting > Project > Issues Analysis,
switch to the second view 'Graph', and then refresh -> Error).
This revision introduces a new key in the View widget: multi_record.
This key distinguishes views that aim to display several records
(e.g. List, Kanban ...) and those that display a single record (i.e.
Form and Diagram). We use this key to decide whether or not the
view stored in the url should be directly loaded (yes for
multi-record, no otherwise).
This reverts commit 291eb111b3.
By putting into the flags object the default_view stored into the
context (i.e. the one written in the url), it happens that a View
Manager tries to open a view which is not available. For instance,
Sales > Sales Teams. Then refresh the page. As we are in a Kanban
view, the view_type = Kanban is stored in the context. Then click
on Quotations in a Kanban card. It doesn't work because the
ViewManager tries to open the Kanban View of the Quotations which
doesn't exist.
When a logged call is created from the tree view, the mobile phone of the
partner is not filled in automatically, while it is in the form view.
opw-640549
When a user tries to log into a postgresql database with no view web.login (this
happens if the database is not an odoo database or using a previous version of
odoo), the rendering failed, producing a 500 error (with no detail for the user)
Instead, redirect to the database selector with an informative message.
Fixes#3443
The database selector page is a jinja template with no access to database
required so should be able to be displayed on any database.
Future improvement could verify the version of base module for even more precise
verification before login (but need to make sure it's always accurate).
When a sale order has in state != draft, we raise a error message since commit
f6c65a3d9e.
But if we don't reset the sale order id from the session, the user cannot
continue to navigate on website because the user will have the error each time.
If the state of the PO is 'approved', there is no transition foreseen in
order to cancel the PO.
The user might be blocked in the following situation:
- Create a purchase order with invoicing set as Based on incoming shipment
- Validate the purchase order, create the shipment
- Then, cancel it (the shipment)
- Return back in the purchase order, the PO should be in shipping exception
- Hit the "manually corrected"
- Then, try to cancel the PO: nothing happens.
opw-641014
da92283 was an attempt to fix tests due to screwed-up conflict
resolution during forward-port at 8b5a1f1.
This has been fixed with b173e8e. Now, time to test correctly.
Canceled lines must be excluded from most of the operations done on a purchases orders.
The check has been done in some places but some of the loops on the order lines do not do it.
This commit correct them.
having lines with products using a different UOM for
sales and purchases
If a product does have a (different) purchase uom, we should first
take it as a base for calculating prices as the standard price relates
to it and not the sale (normal) uom.
Closes#6829
opw-640616
I had to install libldap2-dev because of this error: lber.h no such file
or directory. After this package's installation, the requirements
installation works with no errors. So I guess it's needed too.
closes#6971
Since 31d817e, we rotate then session at login/logout.
Unfortunatly, `openerpframework.js` does not support session id change
at authentication and keep old one.
In order to keep compatibility with existing js clients (including 7.0
ones), we do not rotate the session at authentication.
Fixes#6948Closes#6949
Damien Bouvy