When we print or post_message of an invoice it is set as sent.
But when we multiprint, we do not use each invoice post_message but
create directly mail.mail then send them in batch.
Thus the invoices are not set as "Sent".
With this change we make a special case.
opw-1910937
closes#28852
Purpose
=======
As we try to open a mail.compose.message on a model that doesn't inherit
from mail.thread (Mimic a cowboy yellin' "Yihaaa" while shooting into the air
with one revolver in each hand).
Specification
=============
The only way to fix this issue while keeping the feature (Open a
mail composer) is to open the mail composer in mass_mail mode and
to remove the model on which it should be called.
The template won't be rendered in the mail composer but will
be rendered when sending the mass_mailing obviously, while avoiding
the unavoidable traceback when clicking on the 'Send' button
closesodoo/odoo#28849
The gengo module is used for automatic translation, if you try to
uninstall the module, at some point the required models/fields of
gengo no more exist but the module is still in use by odoo for
every translation.
This commit fixes the problem by disabling the gengo translations
when the system is installing/uninstalling a module.
opw-1906293
closesodoo/odoo#28806
The "Get authorization code" button in the General Settings >
Integrations > Google drive was not correctly rendered on firefox.
This PR fixes that bug by correcly rendering the button, it has
been tested on both Firefox and Chrome
opw-1907644
closesodoo/odoo#28672
- The value returned by the method `_portal_ensure_token` is False due
to a cache issue.
The value is generated written using the `sudo` environment while in
the current user environment the cached value is `False`.
After generating the value, the cache is not cleared, thus letting the
method return `False`
closesodoo/odoo#28836
Before this commit, we had the following issue:
1. Open two tabs A & B.
2. Receive a message from a channel in tab A.
3. Mark it as read in tab A by clicking on the
chat window of the channel.
> The unread counter is correct in tab A: no
unread messages on this channel, and the
messaging menu counter has been updated.
> The unread counter is not correct in tab B:
it still has unread messages on this channel,
and the messaging menu counter has not been
updated.
The issue was caused by not notifying the updated
unread counter to the widgets when receiving the
'channel_seen' notification from the longpoll.
It was working in tab A because this is were we made
the action, so that it already marked messages as
read without waiting for the longpoll response.
However, Tab B has to wait for the longpoll response
to update the unread counter. It was updating the
counter, but it was not notifying the widgets.
This commit fixes the issue by letting the widgets
know when the unread counter has been reset.
Task-ID 1911239
closesodoo/odoo#28833
Fine-tuning of commit: d60f2ab0e2
Which applied when the next action was to create a new activity.
However the problem is also present when the next action is to send an email.
We extract the logic in a new private function to share the code in both cases.
opw 1904156
closesodoo/odoo#28819
On save, the editor will ask to parent widgets if something needs to be
done first. The website navbar will receive that demand and asks to its
action-capable components to do something. For example, the content menu
handles page-related options saving. However, some users with limited
access rights do not have the content menu... but the website navbar
expects that the save action is performed. So, this empty action is
defined here so that all users have an 'on_save' related action.
This was only happening since 12.0 as 'on_save' actions were introduced
there to save page-related options.
closesodoo/odoo#28810
Transfer accounts created for payment acquirers was ignoring the prefix of the main transfer accounts and was always creating accounts with code 000001, 000002, etc.
The reason is because the method was called on an empty recordset
closesodoo/odoo#28789
In a mutli-company account with multiple websites for the
differents companies, the 'contact us' form creates leads in the
company of the admin instead of the one linked to the website.
This PR corrects that behavior by setting a 'company_id' field
to the company_id of the user in case that field is missing on
models that require it.
opw-1907375
closesodoo/odoo#28749
- Create a dynamic product P1 with an optional product P2
- The list price of P2 is 20
- Create a pricelist where P2 is free (fixed price of 0)
- In a SO, choose 'Configure a product' and choose P1, add
In the modal which suggests P2, its price is 20 instead of 0.
This is because we fall back on the list price when fetching the
combination prices.
This should not be necessary since:
- a pricelist is required to fetch a price
- a pricelist should always contain a rule applying to all products
Therefore, the list price doesn't need to be used as a fallback.
It is then necessary to modify the test tours by adding a partner on the
SO before selecting the product. Anyway, this is usually the way to go
since the selection of the partner determines the pricelist.
opw-1902456
closesodoo/odoo#28687
- Install Sales
- Go to Sales > Orders > Customers, 'Invoicing' tab
- Add a Bank Account
The 'External Link' button (which allows opening the form view) on the
bank account is not visible.
More generally, in the case of a One2many list view in a `<group>` tag,
the 'External Link' button of a Many2one field (which allows opening
the form view) is not visible.
The `flex: 1 0 auto;` should not be applied in the list view.
Corresponding PR in v11: #28812
opw-1903158
closesodoo/odoo#28741
In a form view (account.invoice), have a date field as:
<field name="date" options="{\'datepicker\': {\'warn_future\': true}}"/>
Open a record with the field set to a value
Click Edit, click save
Click create
Before this commit, the value of the field of the new record
took the one of the previous record
On account invoices, it resulted on having the popup "The record has been modified etc...."
And it was not possible to create an invoice from another one
this was because we passed the same reference object for the datepicker
After this commit, there is no popup as the field do not take a value from the framework
OPW 1906085
closesodoo/odoo#28759
When a module creates a record from a model M that `_inherits` from some parent
model P, the method `_load_records` creates an XML id for the record, and an
extra XML id for the parent record. The corresponding `ir.model.data` entries
must be created in the right order (parent record, then record), so that the
record is deleted before its parent record.
closesodoo/odoo#28805
The "sent" field on an invoice indicates if it has been sent to
customer or not.
When the invoice is sent to a customer from a form view the sent was
set, but when it was sent from the "Send" action on the list view,
it was not updated which seems wrong.
opw-1910937
closes#28796
When clicking on notifications "Late", "Today" or "Future" for the crm.lead model,
the search view called "crm.lead.search.lead" was taken instead of "view_crm_case_opportunities_filter".
and then the filters "Late Activities", "Today Activities" and "Future Activities" didn't
exist.
opw:1905722
closesodoo/odoo#28793
If a theme post copy wants to enable/disable a view, this is to
enable/disable a given functionality which is disabled/enabled
by default. So if a post copy asks to enable/disable a view which
is already enabled/disabled, we would not consider it otherwise it
would COW the view for nothing.
closesodoo/odoo#28772
This commit only re-indents the COW feature code and adds comments to
help understand its tricky parts. Also evaluate the 'no_cow' flag only
once per write.
closesodoo/odoo#28753
Install the accounting module, create a new payment for a customer
go to payment matching, reconcile the payment for the account
'Account recievable' and select a tax. There is a traceback
because of a incomplete implementation of the tax computation.
This commit complete the implementation and add the missing tests.
opw-1903172
closesodoo/odoo#28591
As of 12.0, the `parent_left` and `parent_right` special fields previously
used to store the tree structure have been replaced with a single
`parent_path` field. See also PR #22558.
This merge fixes a crash in discuss, in addition to re-introduce some _quality of life_
features that have been mistakenly removed from the chatter and from chat windows:
### 1. No crash when searching messages
This was caused by the addition of moderated channels. In short, fetching twice
the same message was performing a re-render of the thread due to a mis-consideration
of a moderation status change. When the fetch reaches the fetch limit, the re-render is
considered as a "load more" fetch, which only works when there is at least one message
registered for the current search.
This is fixed by re-render when there is a change of moderation status only.
Task-ID 1910180
### 2. Easily mention followers and employees in chatter
When mentioning a user from the chatter in a document, it was always
fetching all partners in a arbitrary order. As a result, it was hard to mention
followers and employees.
This is fixed by re-introducing the previous behaviour on mentions, which
groups them by followers, then employees, then all partners.
Task-ID 1910111
### 3. Show message document link in chat window
When a message is linked to a document, it usually shows a
link next to the message. This still works in the Discuss app,
but not in chat windows.
This erroneous regression was caused by a refactoring.
This is fixed by re-introduced document links on messages in chat
windows.
Task-ID 1910119
closesodoo/odoo#28744
Revision on https://github.com/odoo/odoo/commit/299ebb2cdf63de2e3967da0d2f3e7effd239812b
The commit above added the notion of moderation, which
requires re-rendering the thread when a message has its
moderation changed (i.e. the message is deleted on reject
or is no longer marked as 'pending moderation').
However, this condition was triggered even when the
moderation status on the message has not changed.
This introduced a crash when using the search in discuss:
- Access a channel with more than 30 messages, so that
not all messages have been fetched.
- Search messages in this thread so that it displays more
than 30 messages, and the last message of those has already
been fetched.
> It crashes with "Cannot read property 'getID' of undefined".
The bug comes from re-fetching messages: it behaves as a
"load more" fetch, although no message has been stored yet.
A "load more" fetch requires at least one message in order to
determine the minimum message ID to fetch, thus the crash due
to having no message to get such an ID.
Here's the explanation why it fetches with load more:
when performing the search and fetching the same last message,
it will detect that it has already been fetched. Its moderation
status is 'accepted', and it will assume a change of moderation
status. This will trigger a fetch and render of the thread.
At this moment, if the search exceeds the fetch limit, not all
messages will be fetched, so that this fetch is considered as a
"load more" fetch.
This commit fixes the issue by only re-rendering the thread
when there is a change of the moderation status on an already
fetched message. Since changes of the moderation status are
handled by means of the longpolling, it should be rare to run
into the case of having a change of moderation status on a
message while using the search on a thread.
Task-ID 1910180
Revision on https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c
The commit above consisted of refactoring the JS mail module.
A small regression was introduced on messages linked to a document
from a chat window: it was no longer displaying the link to redirect
to the document that this message originates from. This issue was
only isolated to chat windows: it was working fine in the Discuss app.
This commit re-introduces the displaying of the document link on
messages from chat windows.
Task-ID 1910119
Revision on https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c
Resulting of the mail JS refactoring, the list of prefetched suggestions
has been changed as follow:
- before: list of list of mention suggestions `{Array<Object[]>}`
- after: list of mention suggestions `{Object[]}`
The change resulted in wrongly thinking that wrapping the list of
suggestions in a list was pointless, thus simplifying it as a simple
list of mention suggestions.
However, because of this change, it has become much harder to
mention employees and followers of documents from the chatter:
it now always fetches all partner suggestions at all time, whereas
before it was suggesting followers, then employees, and finally all
partners based on the input of the user.
In fact, there was a purpose of using a list of list of prefetched
mention suggestions, which is to group suggestions by "priority":
followers first, then employees, and all partners as a last resort.
This commit re-introduces prefetched mention suggestions as a list
of list of partners, so that it re-becomes easier to mention
followers and partners of a document from the chatter.
Task-ID 1910111
- This commit prevent to send notifications to inactive users.
- This fixes a bug where two partners have been merged and one of its
users is archived.
If one of the two users is inactive the code might use its `notification
type` preferences instead of the active user's one.
closesodoo/odoo#28730
The query was computing the count for all mailing lists, not just the
one being requested. This prevents optimizing the SELECT with indexes.
In addition, using a subselect for the blacklist forced a full table
scan on the contacts - switching to a LEFT JOIN avoids that.
With a blacklist of a few hundred thousand entries, and a table of
mailing list contacts in the same order of magnitude, this brings the
SELECT from 3+ seconds down to 3 milliseconds - with the same result.
Bonus: no need to perform the regexp extraction of emails to test for
NULL values -> substring(x) is NULL iff x is NULL.
When a bounce is received, we look for matching partners in order to
increment the bounce counter. However by using [`ilike','email`] we carry
the risk of matching emails that contain the bounce email:
['email', 'ilike', 'john@hitmail.com´]
will also match 'random.john@hitmail.com' for example.
Using strict equality is safer, and the worst that can happen is that
we fail to count one bounce.
Before this commit, when enabling a generic view from a specific website
context and that view already had a specific view for this website, the
view was duplicated again instead of writing on the already existing
specific one.
This is because we did not consider inactive views when checking if a
view that is being written already has a website-specific view.
closesodoo/odoo#28743
When using the media dialog, when uploading an image, the image list
refreshes itself properly. This was not the case for documents as it
was... refreshing the image list too instead of the document list. Also,
when uploading a document, it is supposed to be added in the page
directly and the media dialog is supposed to close. This feature was
broken for the same reason: the iframe system of both tabs which were
using the same name.
Bug introduced with https://github.com/odoo/odoo/commit/abde8bddf8ec45cf12aab59e95c330321158cfba
(even though is was technically wrong for the same reason before).
Closes https://github.com/odoo/odoo/pull/28722
This PR fixes some miscellaneous issues:
- performance issue in read_progress_bar
- performance issue in activity view
- crash in ungrouped kanban view with progress bar
closesodoo/odoo#28715
The progressbar widget is not supposed to be displayed in non grouped
mode. Before this commit, this situation resulted in a traceback. For
example, if the user has an activity on the subscription model, and
tries to open it, it will open an ungrouped kanban view.
With this commit, we check first that the kanban view is in grouped
mode, before loading the progress bar data.
Nicolas Lempereur