This way, XMLRPC calls can get request details form the standard
`odoo.http.request` system.
Move jsonrpc to the same controller while at it, for coherence.
Fix#24183
When ir.values was removed and the "action" ir.values were merged
directly into the actions themselves, "client_action_relate" was
discarded as unused (and possibly too similar to
client_action_multi?). *However*:
* it was actually used implicitly as "relate" was the default key2 of
the <act_window> XML tag
* and it had a crucial difference from client_action_multi:
client_action_multi is shown on both form and list views by default
and only on list if multi=True, whereas relate is shown on *either*
the form or list view (tree if multi else form)
This means without relate the actions which should be only visible on
the form view are now on both list and tree, which leads to
overpopulated `Action` menus and odd behaviours (e.g. actions relying
active_id on lists, which id do they get and why?)
=> reintroduce relate as "action_form_only" for the specific case of
multi=False and either no key2 or a key2 of client_action_relate. If
multi=True then binding_type=action.
Fixes#20124
Followup: Task 1843603 to remove #multi and redundancy
The transcoding of a mail (transforming CSS into inline styles on the
element nodes of the mail) used the form:
property:value;
So when a mail is saved, it would be eg. with `style="property:value;"`
and when it is being edited "property:value" is removed if available via
CSS stylesheet given the structure.
But the sanitize_style (introduced in bfe7aafa7) adds an espace before
the value (which is more pretty but was probably not choosen in
transcoding to decrease size of mail):
property: value;
so the inline style would not be removed when editing possibly causing
conflict with the editor.
With this commit, the sanitize_style doesn't add a space. It could have
been changed in transcoding but the code is already rather slow and we
don't want to use a regex replace or two string replace instead of the
current one string replace.
opw-1841107
New records (with a NewId) are not necessary in the cache, but should
not be prefetched.
This check has been omitted during optimisation in b0c08a6846.
opw-1843566
opw-1843636
opw-1843683
opw-1843548
opw-1843629
opw-1843657
Closes#24595
Users will be more likely to look for a module named email marketing
than they would be searching for a module named mass mailing.
Task #1825294Closes#23634
When trying to convert -1.5 into a time format, instead
of displaying -1:30, the widget will show -2:30, which
is confusing. The float time qweb widget does not handle
correclty negative, when its javascript version works
correclty.
This commit fixes this problem.
Purpose
=======
Add the possibility to create private addresses, only accessible for a subset
of users.
Specification
=============
- Add a new 'Private' partner type
- Add a res.groups in base 'Access to Private Addresses'
- Add ir.rules for the following behavior:
- Every employees/internal users can read non-private addresses
- Only users in group_private_addresses can access private addresses
- Add in base a simplified form view for private addresses
- A HR Officer is automatically granted in group_private_addresses
- Use the simplified form view to open the address_home_id form on employees
Instead of searching for ids in the whole cache, search for the ones we will potentially prefetch.
Example: imagine you have 1K records in cache, and only 3 records in your prefetch set. Instead of retrieving the 1K records that have a value in cache, retrieve which of the 3 records that have no value in cache.
Since 1a58e108 (on 10.0 and over) parameters are no longer present when
logging sql queries.
This removes some of the usefulness of the feature, and this commit adds
them back.
Since mogrify returns a byte string in the database encoding, we decode
it using the corresponding python encoding.
opw-1839241
closes#24446
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
Purpose
=======
Allow to define users groups on a res.user with computed fields based on the 'groups_id' field.
Specification
=============
Add compute/inverse methods to manage specific groups on a res.users.
These methods should be used on fields defined like one the following cases:
1. A boolean field with the compute/inverse method and an attribute group_xml_id.
Example:
has_group_discount_per_so_line = fields.Boolean(
"Discount on lines",
compute='_compute_groups_id', inverse='_inverse_groups_id',
group_xml_id='sale.group_discount_per_so_line')
2. A selection field with the compute/inverse method, the selection got from '_get_group_selection'
and an attribute 'category_xml_id'
Example:
group_sales_team_user = fields.Selection(
selection=lambda self: self._get_group_selection('base.module_category_sales_management'),
string="Sales", compute='_compute_groups_id', inverse='_inverse_groups_id',
category_xml_id='base.module_category_sales_management')
The fields will be set according to the groups defined in the 'groups_id' field, and the 'groups_id'
field will be modified according to the modifications made on theses fields when saving the users's
form.
Rev. 374af56 changed the way 'button' nodes are rendered in basic
views (form, list, kanban). As a consequence, their 'name'
attribute wasn't transmitted to the produced html elements anymore.
However, this attribute is very convenient to debug views, and to
write selectors in tests. For instance, it broke the test added by
rev. 8d17a2a once forwardported in master.
This commit reverts 1ce5bea.
The settings view is supposed to open a new record on the model
res.config.settings, perform the default_get and onchange calls, then
display the result.
However, once this is done, if the user then clicked on some links
(which do save the current record and navigate to another action), then
click on the breadcrumbs to come back to the settings view, then the
settings view will reload the current record, which has an id, and this
also will update the url.
This could be a problem. For example, in a multicompany settings,
reloading a settings view from an id will reload the settings for a
given company, even if the user changed its current company.
To fix this issue, we make sure the basic model for the settings view
'forgets' the res_id key, so it will be compelled to actually reread a
new settings form record.
Odoo Translation Bot