A context is attached to the ValidationError object when elements in the
view arch are broken. This context helps to locate the error in the
source file. When the view processing fails outside of the arch
evaluation, such context is missing.
closesodoo/odoo#68157
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Issue:
In case of MTO on the component tracked by serial of the subcontracted
MO, if the picking generated by the MTO is complete
before record component on the subcontracted picking, when we
record the component, move lines is duplicated, one for the
reservation (due to the MTO chained move) and a other only with the
quantity done. Then it is painful to register component.
Fixes:
Don't the call of `_set_qty_producing()` when we click on
'Record Component', the user should it self applied the `qty_producing`.
closesodoo/odoo#68151
X-original-commit: e61ae06572db8aa5d1c3ecea754d3be6719eb55b
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before 1721ec1363 and fdc4ef97c9, Odoo did work fine when the
user had another default schema than 'public'.
This commit restores this behaviour by searching
for existing objects in the user's current schema,
which is the first in the schema search path and
the one used when no schema is specified when
creating objects.
closesodoo/odoo#68144
X-original-commit: 223781b34afacd1c0c5674d395cece6d472b048c
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This commit fix a bug introduced in #66551 where a mismatch has been done between
session.user_context.allowed_company_ids and session.user_companies.allowed_companies.
This commit also adds the following tests:
- a JS test in order to prevent future unwanted issues regarding multi company
in BasicModel.
- a Python test in order to ensure that session_info['user_companies'] is not
involuntarily changed.
closesodoo/odoo#68025
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Remove legacy arguments (`subdir`, `pathinfo`) of `file_open()`,
they were not used anymore and made the code more complicated
- Drop the long-deprecated support for files inside zip archives,
considering that zipped modules were discontinued a long time ago:
278ed718e9
- Remove the redundant `_file_open()` method, that should never have been
called directly anyway
- Add the possibility to filter allowed file extensions, in order to
avoid opening up access to arbitrary addons files, such as .py files,
depending on the context of use
- Split up the verification of the file path, to make it accessible
without actually opening the file, as a separate `file_path()` function.
closesodoo/odoo#68043
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Current behavior before PR:
mail notification not sent when using the full composer.
Desired behavior after PR is merged:
mail notification will send when using the full composer.
LINKS:
PR https://github.com/odoo/odoo/pull/66421
Task-2446855
closesodoo/odoo#67933
X-original-commit: 349f07670ea4938e7fc3d9fa3a6fc5fae40dac65
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit aims to allow ones to customize the condition whether the
optional column dropdown should be rendered or not.
PR enterprise : odoo/enterprise#15205
task-2392303
closesodoo/odoo#66979
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The current rules would allow through a selector of the form
:not(sel1, sel2)
then because the matcher thing just splits on `,` it would store the
incorrect sections
:not sel1(
and
sel2)
as separate selectors in the rules cache, raising an exception when
matching against elements.
Move all the rules to a single regex, and add a rule to exclude any
situation where a comma or an open parenthesis is inside of an open
parenthesis pair: we can't just check if there's a closing parenthesis
with no intermediate `,`, because the selector could be
:not(:nth-child(3), sel2)
in which case the selector would "pass" as the regex would match the
nth-child's closing paren to the not's opening. This means some
selectors *could* be unnecessarily blacklisted, but currently we don't
have any such nested pseudo-classes so...
If we want to resolve this, we need to actually parse the
selector (using something like Sizzle I guess) in order to properly
split the selector-list and take a real look at the selector's
structure. Maybe one day.
closesodoo/odoo#68093
X-original-commit: d50c3b07f1c0644ac8e412f099ddd7b139671060
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
_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
Julien Castiaux