When changing the company of a sales order,
the change was not propagated to the related, stored, company field
of its sale order lines
These triggers makes that happen.
opw-694683
When changing the company of a pricelist,
the change was not propagated to the related, stored, company fields
of the `product.pricelist.version` and the `product.pricelist.item`
These triggers makes that happen.
opw-694683
In some cases, when the destoy method of 'Tip' calls the off() function on
'$breathing', even if this one is not defined.
To fix this error, we check that '$breathing' is not 'undefined' before
calling off() on it.
When tax cash basis is used, the user might face the error "Wrong credit
or debit value in accounting entry !". A detailed use case can be found
in issue #14158.
The reason is that a float representation of `1.0` of the field
`matched_percentage` will become `1.000...2` when used in Python.
Therefore, such an expression such as `line.credit_cash_basis -
line.credit * matched_percentage` might lead to a slightly negative
value for the credit/debit, which will not pass the condition `CHECK
(credit+debit>=0)`.
Fixes#14158
opw-692797
Previous implementation did not allow the user to search for pages 'name'
but only on the slugified name.
Now we slugify the needles before to find a match.
1. Create a new page: 'The new'
2. add a link on your website and try to find this page...
- Before this commit, the only ways was to type 'the-new'
- After this commit 'the new', 'The new', 'The-new', ... will match
This commit closes#10771
Rev. 3f7d350fe21d9e2afb35a9ce3e2652940e3f259d1 introduced
auto-cancellation of the edit mode when the user clicks
outside the edited line.
The unfortunate downside was the auto-cancellation of the
edit mode also when the user presses ENTER while the
line is not valid.
This is especially annoying when using barcode scanners to
fill in values, as scanners usually send an ENTER keystroke
at the end of the input sequence.
When a many2one field is focused this event will often occur
before the autocompletion popup has a chance to open. At that
point the line is considered invalid, and the edition mode
is cancelled! If no field is considered dirty yet on the line
this simply drops the whole line, otherwise it will open a
navigation confirmation popup. Both results equally prevent
the use of barcode scanners.
This patch makes sure the edit mode is only cancelled when the
user indeed clicked outside the line, and not for other cases
where save() is requested, such as an ENTER keystroke.
The hw_scale module uses its own internal thread
for reading weights, independently of the polling
done by the POS screen.
The shortest internal reading interval is around
200ms, so polling every 50ms is useless.
150ms seems a good compromise in terms of perception
and resource use.
When we are trying to use the button 'set date to all order lines, we
get a traceback saying, that update cannot be done, because it ensure
that there's only one record. (After 9.0, there is no more this
'ensure_one').
This bug has been introduced in rev: https://github.com/odoo/odoo/commit/401a3cfaf6fd09f594e45c181e908900acba3777
To fix it, we iterate over the order lines, and do the update of each
line.
This commits fixes the following scenario:
1. load the translations for any language
2. modify the source of a translated record (e.g. email template body)
3. click on 'load translations' button (flag)
4. execute the translation wizard for the same language (to refresh)
The translation of the modified record was duplicated.
This was due to the field src in the database being different than the msgid in
the po file. The src value is updated on the insert_missing call.
The matching on src for type='model' translations is only needed due to the
translations that are split (e.g. xml views or html content). For the other
translations, matching on the rec_id is enough.
Detects the xml_translate and html_translate fields to avoid matching on src for
these translations.
opw-691752
Closes#14310
-amount_currency in model account.analytic.line is a related field to move_id.amount_currency
where move_id is an account.move.line
-amount_currency is computed in function create on model account.move.line by considering that
amount = debit - credit (since 8.0)
-amount in model account.analytic.line is computed by considering that
amount = credit - debit (since 8.0) in the function _prepare_analytic_line.
So when creating a customer invoice with an analytic account in another currency, the created
analytic line has an amount which is the opposite of its currency_amount.
This commit also reverts the commit 7fca8ad89e to keep the same
behavior as in 8.0 for the creation of an analytic line from:
- an expense
- an invoice
- a task
The computed not stored field analytic_amount_currency displays the currency amount with the right sign.
opw:694085
Without this patch, when a product was added to cart, if this addon
was installed, it always landed in English in the SO.
This happened because the context, containing the current language,
was being aborted here (`context=None` instead of `context=context`).
This commit closes#14340
When a picking is partially available, and the company works in 'just in
time', they often need to re-check the availability of some products
just before sending them.
In 8.0, it was totally possible, to recheck the availabilty of products.
To fix this, we just add a button when the picking state is 'partially
availbale', which does exactly the same as 'Reserve', but is secondary
and contains the label 'Recheck availability'.
This reverts commit 897290dd3f.
It seems it breaks other use case, since this was fixing more a
usability thing (need to click back on code view to save code view
changes) it is better to revert than to add drawback.
A better fix should be introduced, or the solution would be to not fix
it and have a warning indicating what needs to be done.
opw-693052
Commit a572b8115c removes the inverse function of the `date_planned`. This
is necessary to avoid unexpected changes of the scheduled dates.
However, this removes the ability to set the scheduled dates of all
lines at once.
This commit introduces back the functionality thanks to a new button.
This way, the functionality remains without unexpected behavior.
Backport of rev: https://github.com/odoo/odoo/commit/2cf80e00752c68e443b0cd442ee50f7d6daaa455
opw-692873
A misleading behavior occurs with the recomputation of scheduled date.
Here is the use case:
- Create a PO with 2 products
- For the product 1, set the scheduled date to today + 7 days
- For the product 2, set the scheduled date to today + 14 days
When saving, the scheduled date of product 2 is reset to today + 7 days.
This is of course unexpected, but moreover, a different behavior can
happen depending on how the scheduled dates are modified. In the
previous case (both products have now the same scheduled date), one can
observe 2 situations.
Case 1.
For the product 2, set the scheduled date to today + 14 days and save.
In this case, the scheduled date of product 2 is not reset.
Case 2.
- For the product 1, set the scheduled date to today + 8 days
- For the product 2, set the scheduled date to today + 14 days
In this case, the scheduled date of product 2 is reset to today + 8 days
when saving
The reason of a different behavior in the 2 situations is that the
scheduled date of the PO is changed in case 2 and not in case 1. Since
the scheduled date of the PO is changed, it triggers the inverse
function `_inverse_date_planned`.
When saving, it is not possible to know whether the scheduled date of
the PO was changed on purpose by the user or recomputed. There are 2
solutions to get a consistent behavior:
- Force the scheduled date of each line to be the same than the
scheduled date of the PO. However, this makes the scheduled date of
the line useless.
- Do not change the scheduled date of the lines when the schedued date
of the PO is changed. However, this removes the ability to reset
automatically the scheduled date of the all lines at once.
This is the second solution which is chosen with this commit.
opw-682934
opw-684063
Closes#12904
Backport of rev: https://github.com/odoo/odoo/commit/4326d864d83125abc8f82dfb0089021abf22f9ca
opw-692873
When Anglo-Saxon accounting is activated:
- Use two different accounts for Input/Output for Stock Valuation
- Create a vendor bill ==> by default, the Input Account for Stock
Valuation is used
- Validate the vendor bill
- Refund the vendor bill
When the refund is created, the Output Account for Stock Valuation is
used. There is actually no obvious reason to use this account instead of
the account originally used.
opw-691571
It seems Paypal does not always send the same responses on auto-return
even when PDT is off. Although not reproducible on a Paypal sandbox,
sometimes the system auto-return to /payment/paypal/dpn without any
meaningful POST data. This seems to only happen with new accounts
that use the 'Hermes' web application of Paypal.
The correct thing to do would be to add a new field on the paypal
payment provider for PDT token and make the PDT flow available
to users; but this is a stable branch and this fix is already
sufficiently delicate. This shall be done in master though.
From this revision on, users can then activate PDT on their paypal
account, set the PDT token as an ir.config_parameter value (WITH
GROUP RESTRICTION SET TO ADMIN/SETTINGS GROUP!!!) and the system
will process these requests correctly.
There is a multi-company record rule on `res.partner.bank`,
meaning you cannot see the bank accounts of other companies.
Making a constraint on `sanitized_acc_number` alone prevent
to create a same bank account into different companies,
while you cannot see this bank account from the other
companies.
In this case, the user tries to import its bank statement,
and it contains a bank account which already exists
in the database but for another company than the one
he is currently importing the statement, and,
- it cannot find it because of the multi-company rule,
- it cannot create it because of the constraint
The constraint must take into account the company
opw-690969
The revision
a1d6c2d631
has been ported with an oversight:
except_orm is no longer imported in this file,
besides, the new way to raise these warnings is to
use "UserError" instead.
opw-693779
If the graph view was left while a nvtooltip was shown (thanks to
keyboard shortcuts or during loading time), the nvtooltip remained
and was only destroyed when leaving the action.
Now they are automatically removed with the view as they are now
placed inside of them instead of inside the body element.
When there is a shipping address, this is the second select tag which
is used(defined in website_same_delivery/views/website_same_delivery.xml)
opw:693127
On an accounting journal, when checking "Dedicated refund sequence",
choosing the refund sequence is mandatory. This is the subject of the
below revision:
d94c449547
Since the refund sequence field was available only for with the debug
mode, the user was not forced to choose the sequence, while he must be.
This is not possible to use the dedicated refund sequence if you do not
choose it there.
opw-693955
Instead of hardcoding the IN & OUT endpoint
addresses for the ESC/POS printers, we now
attempt to auto-detect them.
This should increase compatibility with many
compatible thermal printers that are simply
using a different address, such as the
- STMicroelectronics POS58 Printer USB
- HU HAI SUNCSW Receipt Printer Co.,Ltd. Gprinter USB Printer
Fixes#12890
The scenario when using the code view is the following :
- click on code view button to use code view
- make changes
- click on code view button to get back to wysiwyg view
- save from the wysiwyg view
If the 3rd step is not done:
- for the inline editor, we lose the changes that have been done in code
view,
- for the iframe editor, we lose the entirety of the content.
At one time the user was forced to go back to wysiwyg before being able
to save, but this have been removed hence the present usability issue.
With this fix, when the editor content is saved, if the user is in code
view he is automatically set back to wysiwyg view.
closes#14339
opw-693052
Before, it did a search to see if the package existed,
but the only thing it needs to do is see if the package
on the pack operation corresponds to that of the quant. (no need to check children also)
There is a test added:
A picking with 120 pieces incoming, 120 in pack 1, 80 in pack2
When we deliver those in a picking out, with product pack operations: (by taking them out of the pack)
120 from pack 1 and 80 from pack2,
we should only have 2 quants and links between moves in the end
And before, it generated 3 because it matched the wrong quants and made the wrong links.
opw 693760 closes#13836
In 9.0 when the pos user was not at least in the group Accountant
(group_account_user), he was not allow to close or open the balance
when the pos session was configured in cash control.
ps:be carefull with the old rule: Point Of Sale Cashbox Line POS User
deleted with a26b805f5e
opw:69251
This commit fixes the driver to respect the new device
registration mechanism via hw_proxy.rs232_devices.
It also refactors the code to more easily support multiple
scale protocols, and introduces support for the ADAM Equipment
AZExtra scale protocol. (Might be compatible with other ADAM
Equipment scales)
Support for th AZExtra scale is experimental at the moment,
especially given two annoying problems with this model:
- they do not support proper probing (stays mute until a
non-zero weight is measured), so they have to be probed
last and *assumed* to work
- the scale beeps when a read attempt is made and the
weight is not stable yet, or the weight has been already
read previously. This constant beeping during operation
is mitigated by extra delays between readings, but might
still prove to be a major issue for supporting this scale.
RS-232 drivers now need to register any device
they are handling in the hw_proxy.rs232_devices map.
This will prevent other drivers from probing them,
possibly messing up with the device.
Any update to rs232_devices must be done while holding
the hw_proxy.rs232_lock.
The hw_scale driver will be updated to use this mechanism
in the next commit, that will also handle a new RS-232
scale protocol.
Denis Ledoux