This is a small correction of odoo/odoo@3aad756 ; a traceback occured when ESC
was pressed in a list view with modifiers.
The `confirmChange` was done on the parent datapoint (of type list) which has no
attribute `evalModifiers`.
`confirmChange` is now called on the record datapoint. Note that for x2m, it
means that all modifiers linked to the parent record won't be re-evaluated (but
this wasn't probably intended as this is a bit overkill).
Closes#22718
A traceback was occuring when downloading the pivot view without data.
The export function expects the attribute `main_row` set on data, which
is defined in `_prepareData`. The latter wasn't called because of the `return`.
Closes#22728
Before this commit, when filing a phone number field on a model form (typically on website_form),
the module phonenumbers would try to parse the number against the country of the model.
However, this call fails when the number starts with 00 instead of + and that the model
doesn't have a country_id field or if said field is not set.
For this specific case, we chose to skip the number parsing altogether as providing a default
country to the parser can lead to a wrong parsing. i.e, phonenumbers.parse(+32477111111, 'US') will
find the number as US-based when it is a belgian number.
solves issue #22513
Also corrected a faulty behaviour where the option to have a number parsed in its international format
field `phone_international_format` on `res.company` was never properly assessed when the field comany_id of a
model was not present in the model's form view. Added company_id field on opportunity's form view for a proper fix.
Also fixed a syntax error in a logger.
Before this commit:
On portal (My Account > Invoices > Pay Now), a stripe payment in a normal
currency (eg: a non integer currency) would debit the amount *100.
This comes from b335ae0348 which added a workflow to handle integer
currencies but it also sent the *100 amount to /website_payment/transaction
that would create a TX with that amount instead of the normal amount.
Now, the normal amount is correctly sent to the backend, the multiplied amount
is just sent to StripeCheckout handler to correctly display the amount on the
popup after clicking on "Pay Now".
Note: the amount will be multiplied on the backend independently ecda057e11
Traceback because the `_get_asset` function was called by the
`theme_customize` route without the `values` argument (which is not
necessary for the feature).
Closes https://github.com/odoo/odoo/issues/22516
When we validate an order that need to be invoiced, and the customer is
not set, you have to enter a customer, but your order is finalized so
you have a traceback saying it cannot be modified when you try to set
the customer.
When the invoicing fails, we don't set the order as finalized.
Use case to reproduce:
- create a product A with serial number
- add 2 product A in stock
- create a delivery order with this 4 product
- Check Availability
- add 2 more product A in stock
- Check Availability
- in the first line the quantity is now 3
It happens because _update_reserved_quantity on stock move
try to add the quantity reserved on simililar move lines.
Howevever in serial case we don't want to have a move line
with a reserved quantity greater than 1.
In mail change about activities in 07f1e902 when opening the record of a
notification, kanban view was in the action views but there doesn't seem
to be a reason and this caused an issue on enterprise mobile (since
kanban view if available has priority).
opw-804529
closes#22848
In Colombia customers can legally identify themselves with various
codes, one of which is the RUT. This is the traditional TIN and
adheres to the rules implement by base_vat. The other types however
don't and so shouldn't be checked by base_vat.
opw-781247
The l10n_co_verification_code field shouldn't have been added in
l10n_co. Instead users should simply append the verification code to
the VAT. This way the vatnumber module used by base_vat will handle
validation correctly.
Removing this is necessary because otherwise we give the impression
that the verification code doesn't have to be included in the VAT
number which makes base_vat complain.
The l10n_co_verification_code will be removed in master.
opw-781247
The default sale and purchase tax are determined by the default_get
method of wizard.multi.charts.accounts. It will pick the sale and
purchase tax with the lowest sequence.
This adds a sequence field in account.tax.template.csv so the default
ones can be given a lower sequence.
opw-781247
Use case to reproduce:
- Install delivery/batch picking
- Process 2 pickings in a batch.
-> Traceback due to ensure_one.
It happens because the action_done method in delivery is
not multi and batch_picking launch action_done on multiple
picking.
This commit makes action_done in delivery multi.
Previous to this commit, installing sale_managmenet/account_invoicing
would add some menu items for the `sale/account` module
(which contains all the logic for the sale/accounting flow)
and it would also install sale/account since it's a dependency, however,
horror would strike if one were to go and uninstall
sale_management/account_invoicing: nothing happens!
This is because these "facade" modules don't actually install anything, and
uninstalling an app does not force the uninstallation of its
dependencies, thus the `sale/account` module would stay installed, along with
the views introduced by the "facade" module.
To fix this, we create an uninstall_hook which forces the removal of
the ir.ui.menus that the "facade" modules introduce, so that the
functionality remains (for modules that depend on it) but it's not
user-accessible (because it should only be accessible to users if the
facade module is installed).
When exporting to a tarfile, we first export each module's translations
to a file on the FS, then create a tarball from all of them.
With the P3 bytes/string split, translation export was defined to export
to a bytes IO object in order to work correctly with CSV (which work on
bytes IO for better cross-version compatibility). However the tgz file
export was left opening module's files in `w` mode, which in P3 means
text, which blows up as POFile expects to ultimately write to a bytes IO
object: it uses text, and a StreamReaderWriter is used to translate that
into an underlying bytes IO.
Fix by explicitly opening the files in binary mode.
Fixes#22700
A name_search on attribute line would possibly ends up with a domain like:
['|', ('attribute_id', '=', 'm'), ('value_ids', '=', 'm'),
('attribute_id', '=', 'm')]
which would just search the attribute.
This is caused by calling the default name_search. This commit forgo
the default name_search when we are in this attribute line special case.
courtesy-of: @fmdl
opw-813505
closes#22619closes#22760
Before this commit, when having a simple employee (group employee) accessing the form view
of hr.employee, there was traceback because the field is_address_home_a_company was not in the view
This is because of commit 2d777d5
which restricted this field to the group_hr_user (Officer) in Python
When the view itself is not group-restricted
The JS loads everything from the view but puts invisible=1 on sections that have a group
The field, in our case, is forbidden before that and is not loaded, whereas the domain in which it is used is loaded
After this commit, the view loads correctly, while avoiding leaks as intended
OPW 813721
Christophe Simonis