More information from https://en.wikipedia.org/wiki/Decimal_mark section:
"examples of use"
`The following examples show the decimal mark and the thousands separator in
various countries that use the Arabic numeral system.`
`Style: 1,234,567.89 Countries: Malaysia, Mexico, New Zealand, Pakistan,
Philippines, Singapore, Taiwan, Thailand, United Kingdom, United States`
Closes#14402
In Sale settings, enable "Personalize the sales orders and invoice
report..." and also "Show line subtotals with taxes included (B2C)".
Print an invoice ==> traceback.
This is because the field `price_total` doesn't exist on an invoice
line. Note that this field exists on a SO line.
opw-694438
The location field is shown all the time. However it is only used for 2-steps
which is more complicated to configure and understand. That is why advanced
routings group is used to hide this field in other cases.
onchange_operation_type on repair line sets source and destinations locations
when changing the type. However the code does not handle multiple warehouses
in one company. Now the first found warehouse is taken into account and
code does not crash anymore.
Having 'Post Inventory' button highlighted makes it look like a necessary step
to take. However in practice using 'Mark As Done' is sufficient. Moreover this
action also posts the inventory.
Removing the oe_highlight makes it look like an optional step. It is still
necessary in some cases with SO / MO when not all products are produced.
- complete_name field should show the entire hierarchy of locations.
However currently it stops at first non view location. This commit
fixes the complete_name computation.
- name_get should correctly handle translations. It is now correctly
computed instead of relying on stored value which could be incorrect
depending on langages. Moreover name_get displays short name like
old implementation of complete_name.
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 translations in language X
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.
opw-691752
Closes#14310
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
Revision a93ef48a70 stopped computing
the pseudo-fields for user groups when the user was not an admin.
This was a workaround to let portal users acces the preferences
menu without having read access to res.groups.
This fix is no longer necessary as the groups are now computed
in super-user mode. In addition, it creates an inconsistency
in the behavior of fields_get(). For instance there may be
cases where non-admin users are granted access to the regular
form view of res.users, and this would crash because the
view contains fields that would not be returned by `fields_get`.
The performance impact should also be negligible, given the
limited number of user groups in most databases.
-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
Mass Mailing campain cannot use Mail Templates anymore (the user now
has to duplicate a previous Mass Mailing if he wants to start a new
one with a mail body which looks like the old one).
So this menu became useless and confused the users. Mail Templates are
a technical feature which is used by other module to send automatic
emails and these can be edited through debug mode in the Settings app.
Resolve#14148.
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'.
Updated the deployment documentation, to inform developers about
the new location of the odoo-wsgi.py file that's needed
go deploy odoo as a wsgi application
Closes#14337
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
This is an oversight during the port of
3de53fa165
in the forward port revision
3a2147d95c
In the revision 3de53fa165,
the code has not only been moved,
but the variable passed to the method `rereserve_quants`
argument `move_ids` changed as well.
This has been missed during the port of the revision.
This leads to the invalid computation of the `done` quantity
in the pickings in some cases were the quants need to be
re-reserved.
opw-690244
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
- Create two expenses
- Group them in one expense sheet
- Remove one item from the sheet (trash icon)
- Save
The expense is completely deleted.
opw-693548
When getting the price from a account.move.line, the uom set
on the line must be taken into account.
Before the fix:
-Set anglo-saxon accounting
-Create two units of measure Box and Mot where 1Mot = 10Box
-Create a stockable product with Box as unit of reference and set with
real price and perpetual
-Create a SO with a Mot of this product
-Confirm the SO and create the invoice
-Validate the invoice
Bug:
In the journal of entries, only one box was counted for the debit and the credit
instead of 10.
NB: The function _get_anglo_saxon_price_unit must return the price unit of the
product in the unit of measure of the account.invoice.line.
opw:693075
Jeremy Kersten