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
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.
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
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
Declaring the keyword argument `context` in an API v7 `orm.browse_record` can
lead to mixed API v7/v8 inheritance bugs (`context` will be treated as a
function parameter instead of being injected in `self.env.context`). As the
context is already propagated in line 953, we can safely remove it from line
971.
Closes#13115
When the user name entered hasn't an email specified the error message wasn't
displayed in the reset view.
The error message was in e.name, not e.message
Using the constructor `new Event()` is not supported in IE >= 9.0
(tested on IE 11). It raises the below error:
`Object doesn't support this action`
This revision implements the Polyfill `CustomEvent()` suggested
by the MDN here:
https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent/CustomEvent
and uses it if the `new Event()` call fails.
opw-690984
Due to the following revision:
456d7b38f1
The company on the order line was not assigned
when creating a new line in an existing sale order.
The company was correctly assigned when you created
the order line with the order, and when changing the company
of the order, but not when adding a new line on an existing order.
This new trigger repairs this regression.
Due to the following revision:
295b96c0b3
The company on the version and items was not assigned
when creating a new pricelist version on an existing
pricelist.
They were if you changed the company of the pricelist,
thanks to the triggers added in the above revision,
but not when they have just been created in the pricelist.
These new triggers repairs this regression. It also handle
changing the `pricelist_id` of a version (this is doable through
the "Sales > Configuration > Pricelists > Pricelist Versions" menu).
Fixes#14631
If wkhtmltopdf is missing, a call to a report will be catched to warn the user.
In case of a report generated indirectly (e.g. via an attachment on an email
template), the rendering would crash.
As warning the user is better than returning a traceback, raise a UserError.
Closes#14535
It's possible that the command `wkhtmltopdf --version` returns an empty
string (in the use case, it output later in stdout "wkhtmltopdf: error
while loading shared libraries: libfontconfig.so.1: cannot open shared
object file: No such file or directory").
We chose to display the report in html in this case and also to show
a warning to the user inviting him to fix his installation.
- adds position before to COP currency in res_currency_data
- adds address_format to Colombia in res_country_data
- CLA signature for kurkop
Closes#10618
- Create a new assets
- Set a any gross value, any number of depreciation, and any number of
months in period
- Set "Prorata temporis" to True!
- Save, then confirm the asset
- Post at least one of the line by clicking on the red bubble next to it
- Click on "Modify Depreciation" and choose another number of month
- Click on "modify" to confirm the modifications
The depreciation of the latest posted month is duplicated. However, the
first unposted depreciation should be the first period after the last
posted period, as it is the case for non prorata temporis assets.
opw-693081
session.context no longer exists, it is session.user_context
Add the missing context in the message_fetch call. The dates in the chatter were
not formatted according the user locale.
The tacked messages in the chatter were parially translated.
e.g. "Lead created"
The call did not gave the user context and the subtype message was not
translated.
Closes#14589
Variable `membership_line_ids` was misspelled `membership_lines_ids`
Thus the list of partner returned has extra partners not filtered by search domain
Closes#13768
For the field "tax_ids", a command must be written in the the returned dictionary.
In this way, the ids of the tax will be set on the account move line.
opw:689806
Olivier Dony