- A simple POS user doesn't have the rights to write
on pos.config, not even to write the `current_session_id`,
so it must be done as sudo.
- If no fields is specified to `search_read`, it reads all fields.
The simple POS User cannot access all fields on `account.journal`,
(e.g., the computed fields implying `account.payment` records)
opw-659079
This revision is related to 432f199.
Since the above revision make sure to change the
editable list to `bottom`,
the order of the list should be done on the `date` (asc),
on this view, as this is more likely that, when adding a new line,
that the date set on this new line is
more recent than the dates on the other lines.
The new added line should therefore appear directly at the bottom
of the list, to avoid consufing the user.
Besides, the default order of the model `account.analytic.line`
is set to `date desc, id desc`
opw-659892
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")
Because we now correctly format numbers, we have to parse the number
strings with web.parse_value(), then calculate the new amount and then
convert them back to a correctly formatted number string.
The number popup uses gui.numpad_input() which now only allows the
correct decimal separator (before this it was hardcoded as '.'). So we
now have to use the correct decimal separator in that particular popup.
Because of that we also have to correctly format the default tipping
amount AND also parse whatever value we get back from the popup through
web.parse_value().
Although you could do this formatting directly in the NumberPopupWidget
constructor, this would not be ideal because this widget is also used
for numbers that shouldn't adhere to the formatting (eg. PIN numbers).
In some places '.' was hardcoded as a decimal separator. Because now
payment amounts now get passed through web.parse_value() this causes
issues when the the decimal separator is not '.'.
opw-660024
Before this revision, the button "Pay now" on the quotation
in the frond-end was display only if the sale order
was in the state `manual` and that there was not
yet any payment transaction.
The thing is, since the release of 9.0,
the `manual`state no longer exists in `sale.order`,
and the pay now button was therefore never displayed.
From this revision, the condition to display the button
is based on the `invoice_status`, which need to be `to_invoice`,
meaning there is something to pay:
- The sale.order needs to be in states `sale` or `done`
- At least one line has to be invoiced:
- If the product has the `invoice_policy` set to `order`
- or if the product has the 'invoice_policy` set to `delivery`,
and at least one quantity has been delivered.
opw-659931
Jeremy Kersten