_snailmail_print can be called on multiple letters, and this can lead to a timeout from IAP Service. However, letters are sent, credits are consumed, but letters aren't marked as sent. To avoid that, we force the sending to IAP service to be done letter by letter.
closesodoo/odoo#68107
X-original-commit: 3d8ad1e68583fa1b354ff36f902ccb0405270bb2
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Steps to reproduce the bug:
- Create a multi-company environment with two companies A & B
- Create two sales taxes TA & TB, one for company A & one for company B
- Created a shared product P and assign both TA & TB
- Login with user having access of both companies
- Open POS session and select P
Bug:
A traceback was raised
opw:2422866
closesodoo/odoo#68102
X-original-commit: c087868a9a2b0aed22e8418b120f849bf680f918
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Create a product with:
Cost: 60.80
Quantity On Hand: 999.0
- Go to Inventory / Reporting / Inventory Valuation
- Click on export all (little button next to "Inventory at date")
The field "Total value" have too many decimals: 60739.2000000004
This occur because of the multiplication: it yield the correct value
(60739.2), but every rounding attempt done, even in the ORM, will
mess up the representation
https://github.com/odoo/odoo/blob/042298f8c949fba470eda6ad90f94c95ca291030/odoo/fields.py#L1333
opw-2438384
closesodoo/odoo#67558
X-original-commit: 67cf82962688360cfe25c6b2118a7dbd17a6ee95
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Steps to reproduce the issue:
- Let's consider a product P (11€) with a 10% included tax T1
- Let's consider a fiscal position FP that mappes T1 to a tax T2 (0%)
- Let's consider a website that displays prices with tax included
- Let's consider a portal user PU with FP as fiscal postion
- Log with PU
- Go to the shop and filter products to see P
Bug:
The price of P was 11€ instead of 10€
PS: When adding P in the cart, the correct price is displayed.
opw:2472528
closesodoo/odoo#68081
X-original-commit: e7bfadea847012ee956b7bb425688b5f9ccda9cf
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When Odoo routes incoming emails it is looking for existing messages in
database using Message Ids which are coming from e-mail header
References.
In Odoo the message id looks pretty long like
743570479975566.1584086032.522504091262817-openerp-message-notify@ip-172-31-45-160
As it declared in [RFC2822] long header bodies can be "folded" using
CRLF+WSP. And some mail clients do that very thing. They split
References header body which contains Message Ids by "\n ". The example
of mail client where it can be reproduced is apps.rackspace.com We
created Sales Order in Odoo, sent this quotation to the client email. He
replied with e-mail, and this email can't be matched with any existing
message id and as result it's not attached to the Sales Order.
RFC2882: https://tools.ietf.org/html/rfc2822#section-2.2.3closesodoo/odoo#68077
X-original-commit: 559f6cf62711ad45557eddec3af7c66616724eb5
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Payments made on eCommerce via a payment acquirer (i.e. Stripe) generate an
"account.payment" record where connected user's "child" partner is used for
partner_id of the payment, instead of commercial partner, as it is done for
payments registered on invoices.
For consistency, commercial partner should also be used for these payments.
opw-2457390
closesodoo/odoo#68065
X-original-commit: b738068be53621b23d9f19befdfdef50534ef434
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
- Create an internal user with ONLY the following rights:
* Point Of Sale: User|Administrator
* Purchase: User|Administrator
- Connect with created user
- Open a POS session and validate an order
- Close session
- Validate closing & post entries
The access is denied when trying to create account move due to following rule:
"Purchase User Account Move".
When validating session and creating account move, sudo is applied if user has no
"create" right on "account.move".
In the particular case where user is a purchase user or admin, he also has "create"
right on "account.move" and sudo is not applied when validating session (as it would
have been if he has no purchase rights).
However, as defined by "Purchase User Account Move" rule, he is limited to account
moves where type is in ('in_invoice', 'in_refund', 'in_receipt').
But the account move created when closing and validating session is of type "entry",
and therefore user cannot validate session.
A POS user should be able to close and validate a session, either he is a purchase
user or not.
opw-2456783
closesodoo/odoo#68060
X-original-commit: 4779ff2369f1f632429f5305bc4a84db730c3dfe
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
The code from v13 used to look for partners in JS before making the RPC, which
was much faster, and also gave better results by returning partners that were
already known and therefore more likely to be selected.
The same logic is reintroduced here, and further improved to take into account
all known partners and sort them according to the likeliness they will be
selected based on various criteria.
task-2413776
closesodoo/odoo#68045
X-original-commit: 930e090ced8134c3819a5a87b9052467ba23e8e4
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Issue
- Install "Accounting"
- Change user language to arabic
- Go to Customer Invoices list view
- Try to filter on field "Created On"
Traceback is raised from the DatePicker Component
Cause
The cause is two fold:
There is an issue in moment that behaves abnormally when its internals
are not able to extract the month in a locale, and, instead of returning an
invalid moment, it returns a valid moment with the month set to January
which just happens to be the first month of moment's default locale
ref: https://github.com/moment/moment/issues/5600
Secondly, the defaultProps "locale" of the DatePicker was set to moment.locale()
at the file's initial loading, that is, before any user locale parameters were loaded
The bootstrap datepicker was then set with the wrong locale, and the case fell under moment's issue
After this commit, the locale of the DatePicker is always the one of the user, and there is no traceback
opw-2460156
closesodoo/odoo#68059
X-original-commit: e2c46bb80e1e312dd34ac554d79813ef35282e62
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Before this commit, calling unpatch on an object that hasn't been
patched before crashed (before reaching the code that handles the
case by throwing an Error). This scenario is now properly handled.
This commit also defines specific Error classes for the patch and
unpatch faulty cases, so that they can be elegantly catched (in
tests for example).
closesodoo/odoo#68057
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
In tests, we might want to disable a specific patch for a specific
test (e.g. to remove a monkey patch done when another addon is
installed, to test the behavior of the current addon).
Before this commit, it was possible to unpatch at the beginning of
the test, but we couldn't re-patch when the test was over.
Feature required by task~2392303
Some customers are scared of clicking on a button that says "Accept &
pay" directly from an email.
So, instead of using the online features, they download the PDF, sign it
and return it.
It seems legit, due to the text that you can read, so as an UX
enhancement, I propose to change that button's text.
@Tecnativa TT27664
closesodoo/odoo#65597
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In simple search by qty_available we use optimized method. Before this commit
that method didn't work when product doesn't have stock moves and domain
includes zero qty, e.g. ``[('qty_available', '>=', 0)]``, ``[('qty_available',
'=', 0)]``, etc
The problem comes from https://github.com/odoo/odoo/pull/66652closesodoo/odoo#68042
X-original-commit: 629ce193e4725919c1aeede000517564f0e8adf1
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
The error message raised when linking a wrong SOline and a task used
unclear/incomplete information.
This commit improves the displayed message, replacing:
* the SO id by the SO reference, since record ids are not really useful to
end users.
* the product name by its display name, to include variants details.
closesodoo/odoo#68041
X-original-commit: 8db6e654a50d38001c42247b33392aad90cab821
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models..
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS SUMMARY
Make subscription work using partners only. Remove channel ability to follow
records. Remove channel auto-follow. Simplify channel notification flow by
using directly members and not a delegation through a channel self-following
trick. Thread notification is simplified and channel specific behavior is now
implemented directly on ``mail.channel`` model.
Remove ``channel_id`` field from follower model. Only partner_id is kept.
Starting from now on followers are partners only.
Remove support of channels when posting a message. Messages now belong to
a single thread using standard ``model`` / ``res_id`` pair even for
``mail.channel`` records. Remove ``channel_ids`` support on ``message_post``
and from Message model. Channel content is now computed like all other
documents.
As a side quest, following updates are necessary
* remove ``message_channel_ids`` field from ``mail.thread``. Indeed there
will not be any follower being ``mail.channel`` anymore;
* remove ``channel_message_ids`` field from ``mail.channel`` as they now
use standard ``message_ids`` field;
* remove various ``channel_ids`` linked to followers (server actions, invite
wizard, ...);
* remove duplicated ``is_subscribed`` field on ``mail.channel``, duplicate of
``is_member``;
With this merge, following features are modified
* channels cannot follow records anymore;
* messages cannot belong to a business document AND channels at the
same time. A channel is now behaving like all other business documents;
* following a channel using partners to be notified of discussions. Only chat
or mailing lists notify their members;
Finally various code places are improved: renaming, more modular approach,
... See sub commits for more details. Each commit explains more in details
its change and purpose / specifications.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Thanks to @seb-odoo for in-depth review.
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
After all those changes, query counters can be updated according to latest
runbot state. Some counters decreased, meaning simplifying models leads
to a performance increase. Hopefully. Or bugs. Or both.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Now that recipients in notification process are always partners due to
simplification of MailFollower model we can safely simplify the structure
used to collect and propagate recipients information.
Before this task it was a dictionary with a list of partner related data and
a list of channel related data. It is now simply a list of partner related
data, leading to various code cleaning.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Purpose of this commit is to make low-level API of subscribe process a bit
easier to understand and use. Notably some parameters are now defined as
named parameters in order to better understand calls.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
In this commit we force messages to belong to a single document using
``model`` / ``res_id`` pair. It is not possible anymore to link a message
to channels using ``channel_ids``. A message belongs to a document and
is displayed in that document's chatter.
This change implies modifying a lot of domains, notably in chatter. Indeed
discuss for channels does not use ``('channel_ids', 'in', [3])`` domains.
They now use ``('model', '=', 'mail.channel'), ('res_id', 'in', [3])`` like
other documents fetching their messages.
This commit also removes ``channel_message_ids`` field on ``mail.channel``
model. As channels are now considered as standard documents they will use
``message_ids`` field like all other documents. Linking a channel on a message
is possible only as a link in message from now on. It is not possible to push
it into a channel anymore (no more listener channels, no more channel link).
Finally a global cleaning also linked to all previous commits is done.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
In this commit we remove support of ``channel_ids`` parameter when posting
a message. This means we do not support notifying channels as side-part
of notification mechanism on a document. Either we post on a channel and
its members are notified, either we post on a business documents and its
followers are notified. There is no possibility to add channels as being
notified when posting a message.
This is done as a followup of removing followers being channel-based and
prepares ground to make channel use model / res_id as all other documents
inheriting form mail.thread.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
As there is no way to add channel-based follower anymore we can remove all
fields and code supporting this feature. Notably we can remove ``channel_id``
field on ``mail.follower`` model as well all code using it, notably compute
methods.
In this commit we also make ``partner_id`` field required as now followers
are always partners. Email, name and active fields are now simple related
fields on the partner.
Code computing data about subscription is also updated and simplified. As
we do not have channels anymore but only partners all custom SQL queries
are now simplified.
JS models for Discuss are also cleaned. Following python change, JS models
are simplified to match the backend models. Channel_id is removed, partner_id
is now required, and various code is updated according to the simplified
model.
Side note: we could probably get rid of specific index on ``partner_id``
field. However we have to ensure we never search for followers without being
in a model / res_id context. This will be done in another cleaning step to
be sure performance are not broken.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Remove ``channel_ids`` field from ``ir.actions.server``. As we removed
support of (un)subscribing channel-based followers there is no need anymore
to have a field to add them through server actions. We can now safely remove
this field as it has no use anymore.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Remove ``channel_id`` field from ``mail.invite.wizard``. As we removed
support of (un)subscribing channel-based followers there is no need anymore
to have a field to add them in invite wizard. We can now safely remove this
field as it has no use anymore.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Remove ``message_channel_ids`` field from ``mail.thread``. As we removed
support of (un)subscribing channel-based followers there is no need anymore
to have a field to access them. We can now safely remove this field as it
has no use anymore.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Remove ``channel_ids`` argument and support from ``message_subscribe`` and
``message_unsubscribe`` API. Indeed we do not support adding channel-based
followers anymore. Only partners should be added or removed from followers.
It also allows to simplify API and understanding of both methods.
Various addons are updated to match the simplified (un)subscribe API. Some
enterprise addons may also be impacted.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
Support mentioning partners on channels like done on other documents. When
there is an user input (comment or email) that mentions someone that specific
recipient is not notified. Its notification will be done in Inbox or email
depending on its choice or customer state.
This feature somehow replaces the follower-based support that is now removed
on channels. It allows to ping people and send them notifications. It is
less broad (limited to a post with ping) but already gives flexibility when
using channels.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Channel now use only their members for notification purpose. Having followers
is redundant with members. Moreover as followers are not taken into account
for notification people may think followers mechanism is broken on channel.
Let us simply prevent from adding followers on channels and remove the widget.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models..
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
In this commit we remove the auto-follow mechanism on mail.channel. It is
used as a trick to have self-notifying channels. When posting on a channel
it listens itself. When a channel listens to a record its members are notified
depending on channel type. It means that a channel following itself notifies
its members in a magic way.
We decided to remove this magic and instead do a cleaner implementation of
this mechanism. ``_notify_compute_recipients`` method from ``mail.thread`` is
now overridden on channel model. It computes recipients to notify using a
custom SQL instead of the generic one given by ``mail.thread``. Some other
code adaptation is done to ensure notification on channel model is done as
intended on that specific model.
As channel model is somewhat different from classic mail.thread enabled
models let us implement its features in a more traditional way. More overrides
and less magic !
QUERY COUNTERS
Due to changes in ``channel_partner_ids`` fields being a computed inverse
searchable field there may be an additional query when performing a message
post as indicated by ``test_complete_message_post`` test. This is due notably
to message_format fetching channel_ids information. A call to ir rules on
channel is performed that uses ``channel_partner_ids`` as part its rule domain.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Purpose of this commit is to better differentiate channel members technical
model from partner members in code :
* ``channel_partner_ids``: contacts member of a channel, filtering notably
on active and checking ACLs on res.partner business model. This one
should be used whenever we deal with members of a channel at business
level;
* ``channel_last_seen_partner_ids``: memberships of a channel and technical
model. This one should be used for internal processes and members
management;
Also containing
* clean naming or API of methods managing channel members. This should
not change anything functionally as only code renaming / cleaning is
performed;
* improve performances of channel member auto subscription by aggregating
all members to add and creating them at once;
* check the use of ``mail.channel.partner`` and ``res.partner`` records
through ``channel_last_seen_partner_ids`` and ``channel_partner_ids``
Channel fields;
Functionally nothing should change with this commit. It only cleans code
in order to prepare future modifications.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATION
Channel holds two fields computing current user's membership on channel.
``is_subscribed`` is a duplicate of ``is_member``. It is therefore removed
to keep a single field.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Purpose is to prepare modifications in models by doing a preparatory cleaning
of some fields and model definitions. Notably
* move mail.channel.partner im_livechat override in its own file;
* slightly re-order member-related fields on channel or mail.channel.partner
models, and split long lines;
This commit should not change anything functionally as it contains is only some
code move and reordering.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Purpose is to use available tools, easier for debug and asserts than doing
everything manually. It prepares future changes in channel model that may
have an impact on bus notifications.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Purpose of this commit is to remove unnecessary t-raw. When dealing with
numbers (len of a list or an integer coming from controllers) we may use
t-esc instead.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
As reading attachments is not possible for portal users displaying a
message in mailing list frontend crashes if there is any attachment linked
to the message. Moreover downloading it would be impossible as access is
not granted.
In this commit we display attachments as sudo. Indeed if current portal user
has access to the message he should be able to access its attachments as they
are part of it. Moreover missing access tokens are generated on the fly to
enable download of attachments.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
When people (un)subscribe from mail channels through frontend interface
a confirmation email is sent. However if this emails fails if may be
displayed in channel chatter as there is an underlying ``mail.message``.
As this message contains recipient-specific content it is better to avoid
displaying it.
Mail message_type is therefore set to ``user_notification`` meaning only
author and recipient have access to message content. Moreover it is never
displayed in any chatter.
In this commit we also remove custom layouting of mail template bodies. We
instead fall back on rendering template body encapsulated within a notification
layout.
Finally some more information for author is also added: author is set to
channel creator, and email_from to formatted email of the company instead
of its simple version.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Bus holds tests about bus notifications sent when changing bundles. Currently
it checks that exactly 4 notifications are sent during the test, being of
type ``bundle_changed``. However if other notifications are sent during
``bundle_changed_notification`` tour test fails even if notifications are
not linked to bundle events at all.
In this commit we fix this test by checking that we have 4 ``bundle_changed``
notifications sent during the tour. Other notifications are ignored for that
specific test.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Purpose of this test is to avoid failing tests due to list ordering not
being always predictable in channel_info.
Some out of office tests are dependent on channel_info ordering. Indeed one
test relies on members list ordering (using [0] and [1]) instead of fetching
the right member in the given result list. In this commit we
* ensure members in channel_info effectively match expected members;
* check content of the right channel info member instead of relying on
list order;
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Purpose of this commit is to enforce model cleanliness by avoiding ugly
defined ``mail.channel.partner`` records.
``mail.channel.partner`` model is a decorated many2many relationship between
channels and partners (members). Both ``partner_id`` and ``channel_id`` fields
should be required. Members of a channel are always partners and belonging to
a channel is mandatory in that decorated m2m table.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
A context key is added allowing to bypass user / channel synchronization
when creating users. This is used notably in tests to avoid subscribing
new test users to "general" channel created as default data.
Purpose is to avoid interferences in query-based performance tests. It also
avoids unnecessary data creation and/or update when it is not necessary
especially in tests.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Before this commit ir_filter tests were calling model.search() with an
array as order. It was not a problem because none of the tested filters
was actually using the sort and the falsy empty array was therefore
ignored by model.search().
After this commit ir_filter test calls model.search() with a string as
order.
task-2453416
See https://github.com/odoo/odoo/pull/65554closesodoo/odoo#68036
X-original-commit: f326ba2d14e4fdd811426c6381b7e5bc3c1d657b
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
In this case for scenario with multi-company, the new line of the reward product, should be set with the taxes for company of the current sale order.
Before this change the taxes that are selected were for the all companies setted in the product.
closesodoo/odoo#68029
X-original-commit: eb6ba44a6bfd0ebfce887edc307e0306765e5183
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce the bug:
-Create a time-Off request R1 for 27/01
-Refuse R1
-Create another Time-Off request R2 for the same date 27/01
-Set R1 in draft
-Try to delete R1
Bug:
A ValidationError was raised:
You can not set 2 time off that overlaps on the same day for the same employee.
opw:2447540
closesodoo/odoo#68005
X-original-commit: 22db3d4168b61f2904e331ac570a1df4904d9791
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
`_prepare_invoice`
Since a3afb98, the `invoice_line_ids` value is replaced in
`_create_invoice`.
This broke some custom client overrides based on overrides of
`_prepare_invoice`.
This commit brings back the old behavior, ensuring that the
`invoice_line_ids` values
specified by `_prepare_invoice` are extended but not replaced.
closesodoo/odoo#68015
X-original-commit: 9beceb0fd4572bdada30cf4ded235c1ff634083c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this, due to the order the lines were interated on (their sequence), some lines were duplicated without parent, making the duplicate report's layout different from its parent. We now ensure we treat the lines in an order that guarantees the parent line has always been copied before its children.
closesodoo/odoo#68011
X-original-commit: c815342b986851e0a4733ed5bf9fbcc7f8fb7442
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this commit it was rather painful/cluncky to find a way to remove this block.
By setting a name on the block we can easily xpath it to replace it or add extra content within.
This makes it easier for external devs to influence this view.
closesodoo/odoo#68010
X-original-commit: d418e4e16a46a0d499e606598b3524eabd19e5fd
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The current behavior was to set the label as memo in the payment register wizard.
However, this is to restrictive when a vendor bill hasn't any payment reference but a bill reference.
In that case, the user is expecting to have the bill 'ref' in the payment 'memo'.
Since the matching rules in the reconciliation widget are matching line.name, then line.move_id.ref and then line.move_id.name, the same logic is applied here to construct the payment 'memo'.
closesodoo/odoo#68004
Opw: 2440389
X-original-commit: 92ceb86d58f4d78c8a4256f29d101d3730517b93
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The Lunch module can automatically send an email to a supplier with the
daily orders at a configured time. It can also remind the users via chat
so they don't forget to order their sanddwish.
Before, two high frequency cron jobs were responsible to check every 20
and 5 minutes if we reached the moment when to send the email to the
suppliers or the notification to the users. Together the two crons were
executed 360 times a day.
The new model uses a dedicated daily cron per supplier record and per
alert record, the dedicated cron is created on the fly and its moment of
execution automatically updated to reflect the supplier/alert record.
See also #41858 for prior work.
closesodoo/odoo#63749
Task: 2416741
Related: odoo/upgrade#2044
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
fda-odoo