After initial implementation CSRF protection had been left poorly
documented tripping up users and developers (#9538, #10139).
Add a warning in the logs for developers, and a more extensive
explanation of the whole thing in the @route docstring (and the official
documentation).
Fixes#10158
user_has_groups is used to check for groups in e.g. view attributes (`@groups`).
When trying to format lists of groups in views, it would break down as it would
pass e.g. `\n some.group` to `res.users.has_group`, which would look for
an xid with the module `\n some` and (oddly enough) not find it.
Theoretically could also handle that inside res.users.has_group but it seems
ever-so-slightly more risky, and has_group is only used programmatically and
should thus already be called correctly.
fixes#9797
Models' write function has a return value which was not propagated when
overriding it for ir.ui.view in website_version module.
opw-658965
note: fix was already present in enterprise f0975cb
in `view_pivot.js`,
the method `view_loading` must wait the `self.fields` variable
to be defined before working properly.
This `self.fields` variable is filled in the `prepare_fields` method,
which is called in the `start` method, through a deferred named
`load_fields`.
`view_loading` is called in `start`, in `views.js`.
Therefore, in the overriden method `start` of `view_pivot.js`,
the call to `_super`, calling the `start` of `views.js`, must wait for
the `load_fields` deferred to be resolved.
Otherwise, the `self.fields` variable, mentioned above, won't be
filled in time.
opw-660153
If no timezone was defined for the user,
the timezone sent to Google for the events
syncrhonization was set as `False` instead
of the right default value `UTC`
opw-660171
Before this the only thing that would ever be printed was 'Guests: ',
because it was only added when receipt.customer_count evaluated to
false. Another issue is that receipt.customer_count doesn't exist in the
point_of_sale module. It is created by pos_restaurant, so there's where
it should be added to the receipt.
- The revision 950d66c086 brokes
the current inheritage. We replace it with a stronger inheritage.
- If the product is not published, the portal user cannot access
it on its product page `/shop/product/`, there is therefore
no need to set the link to this page.
opw-660191
This revision is related to 950d66c086
There is no need to browse the product as `sudo`, this is already
the case, as the template `website_portal.orders_followup` is rendered
with `order` browsed as `sudo` in the qweb context variables.
When a product is linked to several "supplier.info" records with
the same name or same product_name, the name or product must only
appear once.
opw:660107
1.In a SO, it's the line description that should be displayed rather
than the product name, for multiple reasons:
- The portal user may not have the right to see the variant attributes
values, and therefore the portal user would see which variant
he bought
- The description line can be customized by the salesman, adding,
extra information and so on
- The description line is within the customer language
2.If the product is not published on the website, the portal user
cannot see the product image, but the image should nevertheless
be displayed for his portal quotations. In addition, this is possible
to install `website_portal` without having installed
`website_sale`, and in such a case, the field `website_published`
is not even available on `product.product`.
opw-660191
By default, users can only create/edit/unlink
personal `ir.values`, the values with themself as
`user_id`.
Setting the default `deposit_product_id` should
therefore be done as sudo in case if the `deposit_product_id`
default value has already been created before by another user
but is no longer valid.
opw-660180
Timesheet lines are meant to have no product, and instead rely
on an implicit "Service" product. The UoM used is the company's
project UOM (project_time_mode_id), and the nominal cost of this
product is set on each employee.
Forcefully using the SO product as was done before is useless
and actually caused inconsistencies. The `unit_amount` value
would be expected in the UoM of the SO product, while still
being computed/set in the company's project UoM.
When no nominal cost can be found for an employee, the cost is
assumed to be 0, so the `amount` value is 0 too.
In addition, the product field is not supposed to be visible on
any form where timesheet lines are recorded.
This patch fixes various bits of logic related to this, including
parts which expected the `amount` value to be non-zero, or
the product to be set.
Zip range and state filtering were added at
377a6ecab0, but the
precedence between country, group, vat_required,
and not required were not correct.
This commit fixes the precedence as follows and adds
the corresponding tests:
0. Explict position on partner
1. Direct match on all criterions
2. Match on country+zip before country+state
3. Match on country before country group
4. Match on `vat_required` criterion on all
the above before trying them all again without
The function "product_uom_change" was built to reset the price unit
of a SO line when the uom was changed. Before this fix 503820a, the
price unit of the SO line only depended on the price list then it was
not needed to pass the fiscal position to this function.
After this fix 503820a, the price unit of a SO line also depends on
the taxes set on the SO line(e.g.:if an included tax is deleted, the
price unit must be recomputed without this tax). Then to recompute the
unit price, the function "product_id_change" must take into account
the fiscal position set on the SO to consider the right taxes to
recompute the unit price.
The fiscal position set on a SO must be passed to onchange_product_uom
each time it will be called because the price unit will be recomputed.
Was available before 3098ab7fd1.
This time, a special key in the context is required as this behaviour is quite slow.
(This commit could have been named "Dirty Hacking")
Martin Trigaux