When creating a new `account.account`,
or writing on an existing one, changing the
`type`, the source of the related field
`internal_type`, `user_type_id.type`, was
re-written (re-stored) because the field
was not read-only.
In addition, the re-store of the value
of this field triggered the re-store of the related
field `internal_type` on all other `account.account`
records using this `internal_type`, which leaded to:
- Performance issues
- Potential access rights issues, if this leaded
to write operations on records to which the user
does not have the access (multi-company rules, among others)
Forcing the field as read-only allow to not pass the value of this
`internal_type` from the web client to the server when
creating or editing an `account.account`.
Besides, the field is required in the view, to correctly trigger
the according onchange method:
```
@api.onchange('internal_type')
def onchange_internal_type(self):
```
opw-660292
Closes#10143
Analytic accounts are inherited by project.project, and in some cases it is useful to have a link from the account to the project.
This is a usability-fix, not a code-fix
When an expense is recorded and linked to an analytic account, the
associated line will appear in the timesheet.
This fix links prevents linking an account analytic line to a timesheet
sheet if the line is not a timesheet.
Somehow related to a4b6e3a8
opw-657917
If the kanban view is loading grouped records, the dataset of the view
itself is the concatenation of the dataset of each groups.
But when using "Load more..." on a column, these records are not added
in the view dataset which is thus desynchronised. This could lead to an
error down the road.
closes#10156
opw-659016
This revision is related to 7be2403cf5
The payment acquirers must be fetched if the quote
needs a payment.
Besides, as explained in the above revision, the state
`manual` no longer exists sales orders, and therefore
this must no longer be used to determine if a quote
needs a payment or not.
opw-660575
1. To change the page title, you now have to call
`set_title` from `require('web.web_client')`
2. Without the `type="button"`, the `Change Password`
button is regarded as a `type="submit"`, therefore
submitting the form, on `web` on click,
and `web` doesn't expect this POST request.
The POST request must be done on
`/web/session/change_password` only.
opw-660567
- 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
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
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
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
As the stat button "Quotes(s)" counts Quotations only (draft SO),
and the stat button "Orders" sum the total of Sales orders only (confirmed SO),
clicking on the buttons should open the SO list with the according filters
set.
Closes#9715
opw-660041
This revision is related to 5257721
`record._columns` doesn't contain all record fields,
computed non-stored fields are not included in `_columns`,
Therefore, when a computed non-stored field was used in the QWeb xml,
this crashed with a Keyerror exception.
Using `_fields` solves this issue. Nevertheless, translate
is not always set, but is set when the fields is indeed translatable,
so the use of `getattr` was required.
opw-660072
Before this rev., no notification was sent on the bus when the user presence
changed. Thus, the bullets displayed in Discuss were never updated and stayed
as they were on the initialilization of the chat_manager (on webclient launch).
This rev. makes the bus.presence notifications work, and handles them client
side.
Moreover, the disconnections detection is now performed at each poll (with a
maximum of 1 per minute), instead of randomly (1/100 chance) at each poll, as
it scales better than the former solution. We also added a cron that performs
this check every 5 minutes. It is needed to detect that the last connected user
just disconnected (useful for visitors in the website, trying to talk with a
livechat operator).
Also, the 'away' status is now handled client side, as it makes more sense
that way (being away at each poll, e.g. every 50seconds, during 10 minutes
doesn't mean that we didn't come back between two polls).
Finaly, in bus.js, CrossTabBus, we moved the code writing in/reading the local
storage after the tab registration as this code depends on the fact that the
tab is the master tab or not (and this is known only once the tab is
registered).
This rev. was necessary in stable because the livechat uses the user status to
detect if there is an operator available, and this was often inaccurate.
Moreover, it improves the user experience of the chat in the backend.
The traceback ocurred when the operator closed a livechat channel chat window,
and then unpinned it from the sidebar in Discuss. Then, if the visitor sent
him a message, the channel was automatically re-pinned to the operator, who
received two notifications: the first one being the new channel info and the
second one the message itself.
The channel fold_state being 'closed', the window manager was trying to close
it again, which produces the traceback as the channel didn't exist in the JS
cache anymore (it was re-added to the cache when processing the message
notification, so just after).
Anyway, closing this channel was useless as, even if it was in the cache, it
would already been closed. So this rev. simply checks whether or not the
channel is in the cache before trying to close it.
Denis Ledoux