When you define recurring maintenance requests on an equipment, the
maintenance duration and the maintenance team is not set on the created
requests.
The problem comes from the creation method called by the cron that
doesn't use the duration and maintenance team to create new requests.
We now use these fields in the request creation
* The module was not loading the fiscal position templates before executing the template generation.
* Also, as reported in #15384, at the second installation it was crashing because of a missing xml id (which is not supported currently). This last bug was fixed by giving specific xml_ids instead of skipping the data.
This reverts commit 929d983575.
In some cases, the records have no xml_id like
in module l10n_jp, the way the account.fiscal.position.tax.template
are declared in account.fiscal.position.template.csv doesn't set
an xml_id for these records. So when using, the function create_record_with_xmlid
it raised an error if the record has no xml_id because it tried to concate
a string with a boolean with "str(company.id)+'_'+template_xmlid.name".
Fixes: #15384
opw:707704
Only allows a manager to unlock a PO. Otherwise, when the option
'Confirmed purchase orders are not editable', any user can unlock a PO
and modify it.
opw-707035
When we select a variant on a product page on the eCommerce, this can
change the product image.
With this commit the change is also reverberated to the picture
displayed by the zooming feature.
opw-708089
When a message is not part of any channel, the message counter is
incremented while the message won't appear in any channel. This leads to
an inconsistency between the number of messages displayed in the status
bar and the actual messages in Discuss.
opw-706884
Commit b2cf955e made the lot_id always required in the
produce wizard of the manufacturing order (without work orders).
It should only be required when the finished product is tracked by lot.
The notification mail template of a SO and an Invoice displays the logo
of the company. However, the logo is always the logo of the superuser's
company.
When accessing the logo from an email client, the UID is not defined.
Therefore, we fall back on the superuser, and display the logo of his
company.
We add the support of a `company` key in the kwargs, so we can force the
company from which we retrieve the logo. Note that this key was used
elsewhere, such as:
addons/web/static/src/js/web_client.js
opw-705420
The mistake was Abandonned Orders instead of Abandoned Orders.
This mistake has been corrected in master with commit 2e40f53279
This commit create an english translation file for stable version 10.0
Trying to use "group by" in the product margins menu creates a traceback with a keyError.
The problem is that the function stores a recordset in the dictionary and then tries to
get it back with an integer.
This commit solves the problem by storing the product id in the dictionary instead of
the product itself.
- Go to Sales > Product Variants
- In the search field, type a letter (e.g. 'p'), then select a
corresponding pricelist ('Public Pricelist' in demo data)
=> Crash
This is because `name_search` returns a list of tuple, not a browse
record.
Fixes#15443
The field user_domain allow to get the list of users for which a
challenge is applied. The javascript framework for a char_domain widget
sends a JSON list to the server, but the server saved it as a string in
a Char field.
Hence we can have a list (in values received by write or create) or a
string (when getting the field value of a record).
Since 0c649644db this caused an error when user_domain was not empty.
This commit solves it by having _get_challenger_users always receiving a
string.
opw-708177
To reproduce:
- Create a product A with the routes Manufacturing & Make to Order
- Create a product B with the routes Make to Order & a custom one "Move
from Shelf 1" (see screenshot for the configuration detail)
- Create a BoM for product A which contains the component product B
- Sell product A in a SO and confirm it
- It creates a delivery order for product A, a manufacturing order for
Product A & B and an internal transfer for product B
- The move for product B from WH/Stock/Shelf 1 to WH/Stock is indeed
linked to the move for product B from WH/Stock to Virtual Location/Production
- Cancel the sales order
- All stock moves are cancelled, except the one related to the internal
transfer (WH/Stock/Shelf 1 to WH/Stock)
When the manufacturing order is canceled, raw material as well as
finished moves are canceled. All procurements with finished moves as
"Destination Move" are canceled as well. However, in this use case, a
procurement has been created for a raw material.
The solution is to cancel procurements for raw materials as well, so it
cancels the internal transfer.
opw-706100
In mobile view, the mass mailing kanban view crashes.
Commit eee1d8c159 aims to prevent drag and drop for mass mailing.
However, in mobile view, the the drag and dropd is by default
deactivated, and "sortable" is not initialized.
opw-708140
- Install a language other than English, set it to your user.
- On any model, send a message (the recipient should be a user, not a
simple portal user).
- The recipient receives a notification with a primary button half
translated, for example "Vue Task".
When the call is performed to method `message_post`, the sessioon
context is not added to the RPC request. Therefore, when the model name
is read (method `_message_notification_recipients`), it is done in the
default language.
Note that this is the case for any RPC request using the `call` JS
function.
opw-707678
Several fixes are addressed in this commit:
- displayed value of writeoff amount now give proper result accordingly to the selection (but that selection may still be wrong!). This is still not ideal but at least it reflects what users can see in the list selection.
- exclude from the reconciliation, entries that have already the boolean 'reconciled' set to True. They shouldn't be passed to reconcile() but are still needed to balance totally the reconciliation so users have to select them.
- avoid crash if no writeoff needed on batch reconcile: Even though the wizard might declare that a writeoff is needed, in batch mode it might not be the case since the reconciliation is done in multiple passes for each currency. If no write-off is needed, no write-off move is created and the code tried to add a boolean variable to a recordset and raised a fruit-salad error (mixing apples-oranges).
Forward-port of https://github.com/odoo/enterprise/commit/8a55b3f9f7a7524583effb8198c03ebf695131bd
There are multiple problems with the editable view list. It should be
solved once and for all in the work-in-progress master.
This commit fixes a bug with readonly checkboxes. When a field is
readonly, the table cell gets the "o_readonly" class which changes
its style and behavior. When entering edition, the cells are hidden
except the ones with this "o_readonly" class so that their style are
not affected. The "o_readonly" cell content however was hidden thanks
to a "color: transparent;" rule to let the form readonly field show
the value. The problem is that checkboxes... are not hidden with this
"color: transparent;" rule. Also, the "o_readonly" class is not toggled
during edition while the readonly status could be... so the right fix
would be to get rid of this "o_readonly" class and let the inline form
handle the behavior, but this would affect style and possibly break
unknown behavior.
This fix adds rules to handle the checkbox case correctly.
Steps to reproduce:
Go to any pivot view (for example Sales > Report > Sales) and add
the current view to your personnal dashboard (in the search view: Favourites > Add to my Dashboard)
Go to the dashboard, traceback because $buttons was not defined.
opw:707296
In a MO, change a product in "Consumed Materials" by clicking on "Search
more...". It crashes.
Clicking on "Search more..." triggers the onchange since it empties the
line. Since there is no product on the line anymore, it crashes.
opw-705644
When tax_calculation_rounding_method is configured to round_globally the
compute_all method of account.tax will not round the taxes based on the
currency. The result of the compute_all function is used when creating
the tax parts of a pos.order account.move.
Taxes are aggregated per session, so 2 orders with orderlines in them
with the same tax will turn into 1 single tax account.move.line. To
correctly handle round_globally, we round all tax values we have after
processing each order.
Fixes#14672Fixes#14673
In revision fc813847d8,
`_compute_total_invoices_amount()` was assumed to
give the invoice residual within the company currency but,
in the case the payment_currency is different than the company_currency,
it returns the amount in the payment currency.
In this case, we actually need the total invoices residual
within the company currency.
The amount of the invoice in the payment currency was wrongly
computed when a change of rate in the invoice currency occured between
the invoice date and the payment date,
when the invoice currency was neither the company currency
nor the payment currency.
e.g.
Company in USD. Exchange rates:
07/02 08/02
HKD 7.0 8.0
EUR 0.90 0.94
Invoice: 100,000 HKD, date 07/02, worthing 100,000 / 7 = 14285,71 USD
Payment: 13000 EUR, date 08/02, worthing 13000 / 0,94 = 13829,79 USD
The invoice amount within the invoice currency was computed:
100,000 / 8 * 0.94 = 11750€
While the invoice, at the time of the invoice date, worth actually
14285.71 * 0.94 = 13428,57€
When the invoice, payment and companies are all different,
the invoice amount in the payment currency must not be computed from
the amount in the invoice currency computed at the invoice date
to the payment currency, since the rate of the invoice currency
changed, and the amount in the invoice currency at the time
is no longer the same today.
In simple words, `amount_currency` of the invoice
was computed using the 7.0 rate
e.g. 100,000 / 7 = 14285,71
while, when the rate changes, computing from the invoice currency to
the payment currency, which are both different than the company currency
it will first convert the amount to the company currency, using the new rate:
e.g. 100,000 / 8 = 12500€
and then convert to the payment currency:
e.g. 12500 * 0.94 = 11750€
opw-640248
When making an inventory adjustment in multi company,
the default location_id was all the time taken from
'stock.warehouse0' even if the user was not allowed to read
the warehouse. Inspired from _get_default_location in pos_config.py
Backport of 8955d15e9d
opw:706704
In SQL, if there is no quote around the table/field, the result will
be returned as case insensitive.
This was causing a bug in the kanban view which was not displaying
the records because x_AA_count was named x_aa_count.
Yenthe V.G