Rename the field 'osv_memory' on 'ir.model' into 'transient', and make it a
regular field instead of a computed one. When instantiating a custom model,
use its value to make transient models.
This commit alone will make your server crash on an existing database. A small
database migration is needed: simply add a boolean column `transient` (with
default value false) in table `ir_model`.
Pack operations will not appear in a transfer wizard or bar code interface anymore, but
in the picking form itself. Some wizards are still needed however to ask whether a
backorder needs to be created and whether we need to do an immediate transfer
The biggest change in the model is in the picking where the locations of the picking
are not a related anymore, but need to be set. That is why the tests need to be changed.
This allows also to have pickings without moves initially and just move one pack e.g.
Locations won't be visible on stock moves in a picking either. (as they should be those of the picking)
In order to avoid confusion, the pack operations are created immediately when stock is reserved and we
are not waiting until the wizard or the bar code interface is launched anymore.
The recompute button previously in the barcode interface will only appear when the reservation changed
and the user indicated in the pack operations that something was moved already. Otherwise it will
recompute the pack operations. That way the reservation on the stock moves, is reflected by the pack operations.
Return pickings are not confirmed automatically when confirming the return wizard.
That should make it possible to choose another location for the return. (Don't return in output e.g.)
Barcode scanning is not in this commit.
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
POS users/managers should not have any access
to the account.move/account.move.line, since
they are not accountants.
Regarding the bank statements, they should only
have access to the ones coming from the POS
specifically.
opw-628000
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
Allow to add a step between address and payment form to allow to customize the
checkout form.
Only fields prefixed with x_ value are allowed. So it's to the user to implement
automated action if they want write on a default field not prefixed by x_.
Raphael Collet