When opening a modal on top of another, we expect the associated
modal-backdrop to be over this another modal (so that it is grayed).
This was not the case as bootstrap forces the modal-backdrop z-index
to a lower value than the modal's one (see fix comments in the changes
below).
Closes 16971
If the record with id `res_id` on the model `res_model` doesn't exists anymore, do not call name_get method on it in the method `_compute_res_name`. That could lead to tracebacks or inconsistencies.
In the list controller, some code to determine the active domain to
export was causing a crash. It was easy to see: just select all records
in a list view, then click on 'Export' in the sidebar.
Note that the data_export code is still quite old, and did evolve
organically. It does not conform to our new design principles, in
particular, the way component should communicate. But this is a task for
another day.
Due to a bad refactoring of this method during the remove of the
'report' module, a traceback occurs when resetting an invoice to draft.
This is due to the retrieve_attachment method that is used as an api.model
instead of api.multi.
Let's consider the product category PC in valuation = 'periodic' and the product P
with the category PC.
When creating a vendor bill with P, the account on line doesn't have to be
the stock input account but the expense account.
opw:744409
Currently the variants are ordered by the attribute value in the name_get. That way, all the attributes aren't displayed in the same order.
Ordering by the variant attribute name will solve this issue.
Closes https://github.com/odoo/odoo/pull/17034
In v9 the right filter to use is based upon the message_needaction
field coming from mail.thread . Indeed this gives records containing
messages demanding an action which is the right way to use the
needaction mechanism in 9, like done in all other addons inheriting
from mail.thread.
Closes#16769 .
Indeed through portal users can post a message. Form used in order to
do so include a csrf token. However this one should not be propagated
to message_post because it is not a mail_message model field.
This creates unnecessary warnings.
Closes#13956 .
To CFDI 3.3 the SAT provide the new catalog that need be used to
"RegimenFiscal" node used by the company that emit the documents.
Definition:
Atributo requerido para incorporar la clave del régimen del
contribuyente emisor al que aplicará el efecto fiscal de este
comprobante.
And the attribute need the code from the catalog, and validate that it exist.
In CFDI 3.2 the attribute was required but free. Then the code also
could be used in CFDI 3.2.
Like fiscal position have not field to save the code, is used the next
structure
`code - name`
And when is used this element in the XML generation take only the first
three characters.
`company_id.partner_id.property_account_position_id[:3]`
Backport of 10.0 commit: 5331a87f81
The snippet options are attached to `closest`, `all` and `is` functions
to be able to find/check DOM they are associated to. Their behavior
depend on the snippet option type: the search in the DOM is either done
in the body, the editable parts, the editable children only, ....
The problem is that when searching from a given DOM element, jQuery
won't match the elements whose selector contains this given DOM element.
Or in code terms, jQuery find function behavior is:
`$('A').find('A B')` <=> `$('A A B')` (not `$('A B')`)
This was indeed a problem on the job position apply form pages where the
main editable element is the <form/> element itself. Indeed, the snippet
options' selectors which began by 'form' were not able to match. Worse,
the selector is used for a jQuery search for drag & drop and saving but
not for initialization (where it is used as a `is` check on clicked
elements). So, some DOM were able to be modified by options but not
properly (re)configured before saving.
opw-705902
opw-741305
It should not be possible via /shop/change_pricelist/<pl_id>
to change to a pricelist that is not marked as selectable.
is_pricelist_available method should do that, but is not,
because it calls get_pricelist_available with show_visible=True,
instead of show_visible=False
:param bool show_visible: if True, we don't display pricelist where
selectable is False (Eg: Code promo)
Closes#17220
With the new views, the special attribute password was no longer
supported. We simply reintroduce in this commit proper support to
display password fields with *.
Note: we may want to display passwords with a static number of *, but
this requires some thoughts on the usability of the change. We simply
reintroduce the previous behaviour here.
If the method commitChange from the widget FieldTextHtmlSimple was
called in mode=readonly, a traceback was displayed. This is not very
common, because most save operations are done in mode=edit, but it can
happen in readonly mode: when the user clicks on an action button, then
the form view is saved, if necessary.
To reproduce this bug, just open a form view for res.users, and click on
the Change Password button.
This field is used with the multilang module. As only one language is spoken in Dominican Republic, this definition is useless and furthermore it raises a warning in the logs.
Description of the issue/feature this PR addresses:
The Chart of Accounts was missing accounts needed for correct
inventory valuation using perpertual method, and also a seggregation
for payroll accounts, to differ employee retentions from company
contributions.
Current behavior before PR:
Wrong accounts used for perpetual inventory valuation
Payroll accounts not showing difference between employee retentions and company contributions
Regulatory reports are hard to make without the right accounts tag
Desired behavior after PR is merged:
The correct accounts are now created and assigned for inventory valuation. And payroll accounts are correctly segregated for the payroll rules coming in the next PR.
The accounts will also have their corresponding tags for having regulatory reports based on the "control account" for hierarchy, which was removed in v8.
This changes are also needed for a WIP of a PR coming to the
Enterprise repository, for building legal reports based on account
and tax tags.
In anglosaxon accounting's stock valuation, the case where invoice and company currencies were different was not managed properly, because of a syntactic error in the condition checking this case.
Was PR #17259
for computed street fields.
Qweb reports delete the node if the value is Null but won't if the value is an empty string. And then, l10n_mx_edi module has errors because there are nodes with empty string and the minimum value is one char.
Courtesy of Vauxoo. Was PR #17169
OstapYakovenko