Indeed accessing a m2m applies record rules, meaning recipients are stripped for public and portal
users. However when displaying recipients of a chat it is necessary to know which are the
recipients.
Moreover a crash occurs when accessing notifications about email being sent or not. As messages
in the tree are now browsed as super user there is no access rights issues anymore.
Currently, when rendering a list view cell with a many2many we would
empty the list of ids, and fill it again once a name_get is resolved.
But in some instance, the code could use the data when it has been
emptied out.
For example, if we set the tax_id field (inside the order_line list view
inside the sale.order form view) as requred, if we modify the order line
and save directly (without clicking outside of the list view) we can get
an incorrect error saying that the "Order Line" is not valid.
It has been reproduced when saving with CTRL + SHIFT + S on google
chrome and firefox, and there have been reports that for some
configuration it also happen when clicking on the "Save" button.
This commit change the behaviour so the value is kept whilst the name_get
is ongoing, and just use a default "false" value for the name during this
interval.
closes#13478
opw-668067
Analogous to 6fde72abeacdac6e36a0c623c024252839f993ae but now instead
for the 'split' button.
Additionally this uses float_compare with the rounding set on the uom of
the operation to determine if there are any units left, which is more
correct.
opw-685908
When a stock.pack.operation gets created by a stock.picking, it will
have its pack_lot_ids set. This way the user has an overview of what
lots are available and how many of each are still left.
When splitting the stock.pack.operation these where lost. The still
unpacked stock.pack.operation would always have an empty pack_lot_ids
field. The reason for this is that those records where reassigned to the
newly created and packed stock.pack.operation.
This resolves the issue by copying pack_lot_ids that are still
available (qty_todo > 0) and assigning them to the original
stock.pack.operation.
opw-685908
add customer_email_data in the add_message function, otherwise he would crash
later trying to get this key's value's length and nothing would be displayed
for the website visitor.
An error arises when adding a rule to a group (Settings > Groups >
Rules): "Mixing apples and..."
The issue comes from an oversight of commit 1ec7b28a09, which modifies
the value of the parameter `value`, while it should not.
opw-688434
In some cases, users change the sequence of base
views in order to have one applied before the other
e.g. when there is two inherited views doing
```
<tree position="inside">
...
</tree>
```
The priority of the views will have an impact on the
fields order in the tree.
On update, the change of priority done by the users
was overwritten, even if the priority of the view
was not defined in the XML code of the view.
The priority of the views should be overwritten only
in the case were the priority of the view
is specifically set in its definition.
opw-688470
This is an oversight during the conversion to the new API
in the revision
788c1334e2
`html_translate` allows to split the source term
in several pieces, so the translations can be done
pieces by pieces.
For HTML fields, this is the default method of translation,
EXCEPT if `sanitize´ is set to `False`.
Unfortunately, this is the case for this field, and therefore
`html_translate` must still be precised for this field,
while, for other HTML fields, not having `sanitize` set to `False`,
`translate=True` is enough to use the method `html_translate`
opw-688470
This is an oversight during the conversion to the new API
in the revision
788c1334e2
In the above revision,
```
visible_attrs = set(l.attribute_id.id
for l in product.attribute_line_ids
if len(l.value_ids) > 1)
```
has been converted to
```
visible_attrs_ids = product.mapped('attribute_line_ids.attribute_id').filtered(lambda attr: len(attr.value_ids) > 1).ids
```
which leads to a change of behavior:
Before the conversion, the filter is applied on the attribute line `value_ids` field:
`if len(l.value_ids) > 1`, `l` being one item of `attribute_line_ids`
After the converison, the filter is applied on the attribute line `attribute_id.value_ids` field
`filtered(lambda attr: len(attr.value_ids) > 1)`, `attr` being the `attribute_id` field of one item of `attribute_line_ids`
Therefore breaking the availability of the product variants in the products pages of the ecommerce.
e.g.
Attribute color, values red, blue, white, black
The product "Tshirt" is defined with as possible colors values red only.
Before, the filter would not return the attribute `color` for this product,
as the product has only one possible value for this attribute
After, the filter would return the attribute `color`, since this attribute
as more than one possible values (but, not for this product)
opw-688470
The class `oe-search-options`
has been renamed to `o_search_options`
at the revision
977db823c7
See the full explanation of the bug fix here:
4601b044a6e4dbf162cfca9bf0be5ff2a21dd4f5q
Before this commit, only partner really assigned to the lead AND with a grade was
able to see their leads.
Now we check that the top level partner (commercial_partner_id) has a grade, and show
all the leads under this commercial_partner_id.
Try to get the same behaviour that previous portal backend.
opw-688359
The goal is to display the number of issues that are in projects
with a "portal" privacy setting. However, this setting is used by a
record rule to limit access to the project to followers only; this
means that you should add all the customers who submit issues to your
support project. This makes no sense.
To circumvent this problem, the domain of projects with this visibility
setting is fetched as sudo.
A portal user couldn't change his address details if he was
of type `contact`
This happens because users usually
have no access to write their parent company.
opw-688192
Closes#13430
When a snippet contains two p elements, they will both get the
"o_default_snippet_text" when placed in the page. The individual p are
then automatically selected on mouseup event. This induces strange
behavior when trying to select the two paragraph together ; indeed
only the paragraph on which you mouseup will be selected.
This is an oversight of the revision
cb486d7eb6
In the above revision, which converts the module
`stock` to the new API,
the return value of the method `action_confirm`
has been changed:
- Before, it returned the list of move ids that have
been confirmed,
- After, it returns `True`
The former return value is expected by `mrp`,
when using kits BOM: In this use case,
the purchase of one product can lead to the reception
of multiple products, and therefore the confirmation
of one move can lead to the confirmation of multiple
moves.
In addition, the move that was initially confirmed could
no longer exist after the call of the method `action_confirm`.
The method `action_confirm` of `stock.move`
is expected to return the list of moves that were actually confirmed.
e.g. in purchase, before the conversion to the new API (<= saas-10),
to assign all the moves that were created through
the action confirm of the initial move, and not only the initial moves,
thanks to:
```
move_ids = moves.action_confirm()
moves = self.env['stock.move'].browse(move_ids)
moves.force_assign()
```
The above code has been wrongly converted in the new API with just
```
moves.action_confirm()
moves.force_assign()
```
Which changes the behavior, as, before, all the moves that were
created through `action_confirm` were being assigned, and, after,
only the moves with which the method `action_confirm` has been called
are being assigned.
Besides, with the kits BOM, the move with which `action_confirm` was
being called no longer exists after the call, and attempting to
call the `force_assign` method on it leads to the error
`Record does not exist or has been deleted.`
opw-688231
The goal of this controller is to display issues that are in projects
with a "portal" privacy setting. However, this setting is used by a
record rule to limit access to the project to followers only; this
means that you should add all the customers who submit issues to your
support project. This makes no sense.
To circumvent this problem, the domain of projects with this visibility
setting is fetched as sudo.
Christophe Simonis