Fix and issue is similar to odoo/odoo@1f06cc416
When clicking on delete icon before saving current list row edition (by
clicking outside the editable field), it could lead to traceback in some instances
because the deletion and saving are done concurrently.
closes#627
opw-695743
Version 9.0 comes with a revamped accounting system, and the
cashbox system for cash control on bank statements was changed in the
process.
The POS App was updated to use the new system, but failed to
reuse the existing cashbox control if one already existed.
This worked as expected on bank statements directly, but not
on POS sessions where a new cash control had to be input every time.
This fix requires an update of the views, but works in a
backwards compatible manner. Users who do not sync their view
definitions will still be able to work (but will still experience
the bug).
Rev 87a3fe92de revamped the
rescue session system in an attempt to simplify it, but
created new problems.
The rescue system is designed for accepting POS orders
that belong to a POS session that is already closed.
After 87a3fe92de:
- The system tried to automatically reuse an existing session
that matches the properties of the closed one. This will often
come as a surprise to the POS users, with orders appearing
from nowhere in a live session, possibly invalidating the cash
control steps, etc. Using a separate new session with an obvious
"RESCUE" name is much better for users. They will be able to
review the rescued order separately as well.
- When no open session was available, the system tried to create
a new one (without the rescue flag). This could often fail
because existing sessions could conflict with the new one, completely
breaking the recovery. (E.g. a session from the same POS but
with a different user) The rescue flag was designed to avoid this
pitfall, allowing multiple extra rescue sessions to coexist with
live ones.
This patch restores the use of the RESCUE flag for recovery
sessions, and forces the creation of a new session for every
recovered session. Recovery sessions will also be labelled as
"RESCUE" now, making it things more obvious for end users.
There seems to be no need to reset to the root category
on the product list every time we switch back to
the list from another screen. Unless a full refresh
was requested (e.g after closing an order).
This avoids losing the currently selected category
after each screen switch. It can be quite convenient
to stay in the same category while the cashier is
processing items that need to be weighed, for example.
This commit allows POS screen widgets to distinguish
when the user is expecting a full reset of the
target screen, vs. simply re-displaying it.
When switching back from the scale screen to the
product screen, the order summary was re-drawn
and always scrolled at the top.
This happens because the redraw takes place in the
background while the scale screen is still displayed,
so the new area does not know its size yet and
cannot be scrolled properly.
Swapping these operations around fixes the issue
and it happens fast enough to be invisible to the
user.
The order of variants(product.product) is (re)defined each time the attributes
of a product.template are modified. The order of these variants is computed according
to the order defined on "product.product" which is ordered by 'default_code,name_template'
and also the sequence of the product.attribute.value.
But when a new product.attribute is created, the default sequence is the order of creation of your new values.
So if the sequence of the attributes is changed after modifying the product.template, the new sequence will not
have any impact on the order of the variants. The sequence of the attributes must be defined first
before modifying the attributes on a product.template to have an impact on it.
opw:693135
In invisible to make the 'monetary' widget work.
Makes sense as it is the same behaviour as the form view where the currency is displayed on monetary fields, even if the use has no multicurrency acces.
Closes#14714
This reverts commit dcf50bf242.
The commit should not have been forward-ported after 9.0 since
Model update method has been @api.multi'ed.
This also introduced an issue since changing the first line would
change the date_planned of the order (which would alter subesquent
updates).
opw-697680
The feature "set all date to all order line" on a purchase order allow
user to update the schedulded date of all order lines.
It was backported in 9.0 with 401a3cfa but in 9.0 date_planned was not
stored, the button would wrongly set the scheduled dates of the lines to
the minimum date.
With this commit the functionality should work as expected, unless
someone use an out-of-date template in which case the functionnality is
disabled.
opw-697680
note: PO date_planned is stored after 9.0 so this commit must not be
forward-ported.
The model does not actually need this feature, as the hierarchies of packages
are not expected to be deep. Performance wise, updating columns `parent_left`
and `parent_right` may actually suffer from concurrent updates that require
retrying requests.
Currently when someone is added as follow to a document default subtypes
are computed if no specific subtypes are given to the subscription. However
if internal subtypes are set as default those are added to all new
followers. It should take into account customers and shared users and avoid
adding them internal subtypes.
Customers and shared users are not notified of messages using an internal
subtype. So currently there is no information leak. However with this fix
we ensure internal subtypes are not followed by external people even if
no notification is created.
Steps to reproduce:
-Install website_quote
-Add a language French
-Create a quotation template
-Add a line with a new prodcut
-Translate the field description
Bug: Traceback becasue the field quote_description was not translatable.
opw:697508
For example: https://abc.def:8080
It is already allowed for the printer in main point_of_sale module.
Apply the same schemes in pos_restaurant.
Closes#13769
When renaming a warehouse, the sequence are renamed.
Previous sequences uses slashes while the new one backslashes.
Keep consistency between sequence from origin and new one.
Closes#13774
* ccd6fc6 already fixed the bug of the account move for expenses with more than 1 taxes but the taxes were not used.
Adding in `_prepare_move_line` to be included in the created move line.
* added Contributor License Agreement
Closes#12849
The account move line created for a tax must have the right account_analytic_id
according CONDITION.
CONDITION(inspired from function compute defined on model "account.invoice.tax")
if the tax is for an "in_invoice" or an "out_invoice" => tax_code = 'tax_code_id'
=> the account_analytic_id of the tax must be set to 'account_analytic_collected_id'
if the tax is for an "out_refund" or an "in_refund" => tax_code = 'ref_tax_code_id'
=> the account_analytic_id of the tax must be set to 'account_analytic_paid_id'
note:forward-port upto saas-6
opw:694821
Before this revision,
using a selection field with as possible keys `0`,
such as `require_payment` in `website_quote`,
resulted to the records field values to be stored
as `NULL` instead of `0` in the database.
This leads to the inability:
- To distinguish records with this selection field not set
or set to `0` (as both are stored as `NULL`)
- To search for records with the field set to `0`
(as they are considered not set)
For instance, while having `website_quote` installed,
search for sales orders with `Payment` set to
`Not mandatory on website quote validation`: It won't
return any result, even if you have some.
opw-697454
filter 'products' doesn't exist on product.template, it is named 'consumable'
rename 'search_default_products' to 'search_default_consumable' in actions
Closes#14690
The account move line created for a tax(with analytic = True) must have
the same account_analytic_id than the account move line created for the
taxed amount.
opw:694821
Nicolas Lempereur