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
The 'Expand All' feature was tested, but in the test environment
RPCs are mocked, and everything is synchronous (by default). So
even if the tests passed, the feature actually didn't work because
of a deferred (the reload deferred) that wasn't waited for.
Keys 'pivot_measures', 'pivot_col_groupby' and 'pivot_row_groupby'
can be specified in the context and are meant to be used by pivot
views to determine the initial measures and groupbys. Before this
rev., the new implementation of the pivot view simply ignored them..
Before this rev., the _mockReadGroup function only supported
grouping on one field, and if called with an array of fields of
length > 1, the remaining fields were ignored.
Grouping on several fields is now supported, and some tests had
to be adapted.
Keys 'pivot_measures', 'pivot_col_groupby' and 'pivot_row_groupby'
can be specified in the context and are used by pivot views to
determine the initial measures and groupbys. There were typos in
some of them in this sale_timesheet template.
Before this commit, the save method in the basic model did not properly
react when the rpc fails. In that case, the returned deferred stayed
indefinitely in the 'pending' state. This is a big problem, because the
basic controller put that deferred in a mutex. As a result, every
subsequent operations (including field changes!) were indefinitely delayed.
To reproduce the issue, you can find any form view where some python
business logic will cause a fail in some cases. For example, create a
new inventory adjustement, click on 'Start inventory', then add a line
in the x2many with the same product as another line. Saving that record
will fail, but then, the form view is broken: no interaction will work.
Before this commit, row decorations were only computed at the initial
rendering for a list view, then never recomputed. Most of the time, it
is not an issue, but list view can be edited, and in that case, it may
be a problem. With this commit, we just override the confirmChange
method to recompute the various decorations.
Note that in bonus, decorations now works in realtime, when editing a
list view (in saas-15, they simply did not work when editing a record)
Also, we now use the same evaluation context as everything else in the
web client: the eval context from the record, not some custom handmade
context like before.
Eval contexts are not easy... They should be different when sent to the
server and when evaluated in the web client. In this commit, we fix
some small issues:
- when evaluated on the web client, x2manys should be a list of ids,
when sent to the server, it should be a list of commands
- dates should be converted to string
- always add current_date in the evaluation context, as a magic key (it
was previously only available in row decoration context evaluations)
PURPOSE
=======
Currently we can choose to load the xmlid of a menuitem if web_tour is installed by setting the attribute `load_xmlid=True` on the view.
This is strange for 2 reasons:
- Searching all the ir.model.data on menuitems with load_xmlid=True to compute its xmlid, searching the related subtree on the returned structure of the method load_menus is quite complicated for the perfomance gain (if there is any perfomance gain to do it)
- This is not working in community in frontend, as only the root menuitems are loaded, thus it is the `load_menus_root` instead of the `load_menus` that is called. This issue prevent a tour step to be displayed correctly on community and enterprise on a menuitem.
SPECIFICATION
=============
Remove all the `load_xmlid` attributes and the related mechanism and move it into base to always load the xmlids for all the menuitems. It won't bee to heavy as the result is cached.
It's better the keep the current mechanism (Load the xmlids from ir.model.data and insert them into the tree) as we only make 1 search to the ir.model.data
Antonio Espinosa