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.
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
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
When we are on a partner form view, we get the total invoiced containing
the child contact of the current partner. But when clicking the button
we only see the invoices of exactly the current partner.
In most locations of the code this has changed (since 347c784da) and
this part should also contain the descendants contacts.
opw-744929
closes#17188
In the case of a chatter on a calendar virtual event, there was a number
of issue because the record ID was of the type "[REAL ID]-[VIRTUAL ID]".
This caused issue when fetching and posting message with the composer.
opw-744405
closes#17179
Ruchir Shukla