When a user is subscribed to a channel with many messages,
the discuss initial rpc /mail/client_action can become very
slow (in production, the rpc took > 20s when subscribed to
the Community mailing list). This is due to the query in
_get_message_unread, counting the number of unread messages.
This commit adds an index on the relation mail_channel_partner,
this allows postgres to perform only index lookups, and speeds
up the query by 2 order of magnitudes.
From v4.1.0 of the documentation (2015-06-29), the HMAC SHA-1 key is
deprecated. Indeed, it should be considered as a legacy option to
guarantee compatibility with older skins.
The HMAC SHA-256 key should be used instead, and moreover, it seems that
any new skin created does not support SHA-1 at all, even if the option
is available.
The merchant signature code is inspired from the documentation example.
Source: https://docs.adyen.com/developers/hpp-manualFixes#9786
opw-676081
In 8.0, the amount currency field was displayed
in the journal items list view
when choosing, thanks to the `quick add` widget,
a journal with a currency set.
Otherwise, if the journal had no currency set,
the column was not displayed.
It was done thanks to the key
"currency" passed in the context.
From 9.0, the `quick add` is no longer used,
and, due to that, the amount currency field
was no longer displayed in the journal items
list view at all, despite if the journal
had a currency set or not.
In technical words, `currency` was
no longer passed in the context,
making the invisibility property
set with
`invisible="not context.get('currency',False)"`
useless.
As this widget is no longer used, there
is no other choice than either
always display the column, either never.
We choose to display it only if you have
the multi-currency group (as this is the case
in the journal item form view)
We also take the opportunity to move the column
next to the debit & credit column, this is more
meaningful.
opw-676059
When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.
Used case:
- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice
Before the fix: the asset is created twice.
After the fix: the asset is created once.
opw:674674
Note: This is a cherry-pick of commits 9d14230 and 58a5b5e
In v8.0, when a procurement is cancelled and the quantity remaining on
the PO line is zero, the line is deleted. It was not the case anymore
after the Purchase refactoring.
opw-675493
When creating a partner with company_type='person' and with an invoice
adress, the created partner must stay a person.
Now a partner which is not a comany can have an invoice address.
Fixes#11730
opw:675322
If the feedback of a form is too slow, people might be tempted to
click a second time, trigerring a second request. If, after that,
the result has not been received yet, the user might be tempted
to click a lot of time because he is angry at such slowness. This
behavior would trigger a record creation each time the user clicked
the submit button. This fix disables the button once it has been
clicked once, and re-enable it if the record could not be created,
which means that there was an error in the input and the user needs
to change the values and try again.
The button has been changed to a span to avoid the default browser
behavior to post the form when no function is bound on the send button.
When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.
Used case:
- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice
Before the fix: the asset is created twice.
After the fix: the asset is created once.
opw:674674
When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.
Used case:
- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice
Before the fix: the asset is created twice.
After the fix: the asset is created once.
opw:674674
The pricelist field is not a mandatory field on the partner. A default
value is usually defined for any new partner created. However, if the
pricelist is manually removed from the partner, errors (tracebacks) will
occur in the eCommerce when no pricelist is found.
We cannot make the field mandatory, as it could potentially break the
workflow of some users which are not using eCommerce. Therefore, we
simply log an error message to help debugging.
opw-673453
The "Resumes and Letters" action simply displays ir_attachments
linked to hr_applicant objects; but there is no default_res_model
in the context so no ir_attachment you create is actually
displayed in the kanban view.
Since the goal of this action is simply to display attachments
linked to applicants, it makes more sense to disable the create button
and to force people to upload resumes and cover letters through
the applicant record.
Avoid raising an access denied error for messages that
the user has indeed be notified about.
The issue arose when a message posted on a document inaccessible
to the user was notified to one of the channels the user
is subscribed to.
The access control logic on messages relies on 2 heuristics
to grant read access to a message:
a. either the user was notified about the messages, by being
a follower of the document, or a subscriber of a channel
following the document (in that case the user can see the
message but not the document)
b. or the user has read access to the document on which the
message is posted (in that case the user can see both
the message and the document)
Case `a.` sometimes fail to match when a message got notified
to several channels including one the user was not subscribed
to. Depending on the order of the returned rows in the SQL
query, the "foreign" channels could shadow the channels of
the user, making `a.` a non-match.
If case `b.` did not match either, the user would have the
`read` access denied, even though the message was visible by
the `search()` method.
The fix explicitly makes case `a.` match if the user was
notified in *at least* one channel.
This was not done through a change of the SQL query ORDER,
for readability reasons.
From 9.0, a sales order to invoice is no longer a
sales order in the state `manual`, but with the
Invoice Status "to invoice".
Before this revision, the sales order to invoice
were simply not counted at all, and this
count always displayed 0.
opw-675919
When a user validates an invoice linked to a SO, he might want to modify
it afterwards thanks to the 'Modify' option in the refund wizard. This
will create a refund, reconcile and create a draft invoice.
The issue is that the draft invoice is not linked with the SO.
The fix is to link, in this specific case only, the draft invoice to the
SO. At the same time, we have to make sure to:
- unlink the first invoice (to prevent counting the quantity as invoiced
in the SO)
- keep track of the first invoice/refund in the invoice list of the SO
opw-673446
On the `res.company` model, the fields
`name`, `phone`, `email`, `website`, `vat` are
related field on the `partner_id` of the company.
When creating a new company, the partner
associated to the company is created automatically,
it's handled in the overrided `create` method
of the model, but it forgots the values
`phone`, `email`, `website`, `vat` at the moment
the partner is being created.
opw-675526
Use 'display: none' instead of 'visible: hidden' for the config button in
columns' header so that the columns' title can take full width if that button
is hidden.
Bonus: if the config dropdown is open, the button remains visible.
When a PO is created from a reordering rule, we should make sure to use
the purchase UoM of the product. Any PO line automatically created or
modified will be a PO line in the purchase UoM.
opw-673309
For the partner ledger report, since LEFT JOIN are used in the request
we could get NULL values which broke the following code.
note: issue reported on 7c6c188
Commit 3b19fa426b fixed a bug where the column title of kanban group
was overflowing its area when too long. However, when the column is
folded, the title is now really small (width of the folded column)
and then stopped to add the "..." ellipsis.
The solution is to let the text overflow when the column is folded.
As noted in the csv module documentation*, up to python 2.7 it is best
to used UTF-8 as input (and worst to use UTF-16 csv).
closes#11792
opw-674756
* https://docs.python.org/2/library/csv.html
This fixes the case where the lines of a one2many field are modified several
times by onchange methods: instead of retrieving the most recent updates, we
merge them with former updates.
This solution was written as an improvement of a proposal made by Alexis
Delattre and Sébastien Beau as #11620.
When writting a value on a translatable field in a different language than
English, the submitted *raw* value was saved in the database.
This could cause the following issues:
- empty value (provided as `False` by the web client) saved as the string
'false' in the translations table
- no encoding or sanitization convertion
- ignore size parameter on the translatable field
Process the submitted translation through symbol_set method to clean it before
storing it blindly in the database.
This allows to convert `False` into `''` for empty value and fixes#10862
Before showing a chat notification, a check is performed to ensure that the browser does support
notifications. On browsers that do not support Notification (IE, android native,...), the check was wrong and
would eventually cause a traceback. This will no longer happen.
* It is always better to restrict the read to the fields that are actually needed
* In this particular case, since _get_task is called during the create() of an an analytic line with task_id set,
it would result in reading the analytic line being created, which will overwrite the cache for stored computed fields with wrong empty values.
Restricting the fields to read means that computed fields are not read and keep their appropriate values