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>
The "TypeError: Mixing apples and oranges" error message is raised when
users are using recordsets from different models together. The error
message was confusing some users thus have been reworded to be more
explicit.
The initial proposal was to replace "apples" and "oranges" by "torchons"
and "serviettes" but it was rejected because the French are not capable
not to mixup the two. They suggested to instead replace "apples" and
"oranges" by "pain au chocolat" and "chocolatine", this was rejected
because none of us understood the difference between the two, they both
are couques.
closesodoo/odoo#62266
Task: 2366612
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Steps to follow to reproduce the bug:
-Go to the Contact app
-Choose any contact
-In the contact form> go to the "sales & purchase" tab and try to assign a user in the "salesperson" fields
Problem:
You can choose any user regardless of their type. While normally we can only choose internal users
Solution:
Add a domain to the "user_id" fields to only see users of the kind "internal type"
opw-2468819
closesodoo/odoo#67642
X-original-commit: 1361686fe502be137a4757c9092fab4223d484f8
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
When an index has name 'tablename_fieldname_index', this index is
dropped if the field has index=False. This lead to dropping a
user-created index or dropping/recreating the index when index=True is
set in a dependent module. Some info is logged instead.
closesodoo/odoo#67602
X-original-commit: 6a87318df296a11e3300723ca0c8b49c0dcf5fa7
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When table name is long enough, the foreign key constraint name computed
by odoo and the one by PostgreSQL are different, for the same table,
column and definition, are different. As an example,
base_partner_merge_automatic_wizard_res_partner_rel(partner_id) foreign
key is named
base_partner_merge_automatic_wizard_res_partner_rel_res_partner_id_fkey
in Odoo while it's
base_partner_merge_automatic_wizard_res_par_res_partner_id_fkey in
PostgreSQL. This difference trigger a useless foreign key drop/create.
closesodoo/odoo#67601
X-original-commit: 353b415c74da057d5e81cce4d309bebb5f0f2927
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, we only check if another endpoint can be serve in case of
404 not found. Idea was that each url has only one endpoint.
Fun effect is that if record doesn't exist, route doesn't match, so in reality
we had one endpoint but we fallback too to check if another match.
But it doesn't match a recurring case, when you archive a record, and want to
create a redirect for your seo and customer to another record, it is just
ignored because the url math a controller (that return 403 since you don't have
anymore the access right)
Since ask to the customer to delete the record is not always possible
(e.g. a product already sold) now we check if a fallback match for 403.
closesodoo/odoo#66030
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Previously, when clicking on an illustration in the editor, the image
options would be unavailable with a message saying that it was due to
technical limitations, and that the user should reselect the image in
the media-dialog for quality options to become available. This was
caused by the fact that in order to support more than one customizable
color in illustrations, they are now saved inside the database with an
url containing which colors are customizable inside the url's query
parameters. Since the endpoint that finds which attachment corresponds
to which image src was looking for an exact URL match, but query params
are trimmed on the client side before talking to the endpoint, they were
no longer matching.
This commit fixes that by searching for attachments whose URL matches
the provided one with or without any extra query parameters.
closesodoo/odoo#67625
X-original-commit: b26319c3c9409e8724fadeec80e63ea94dc8d599
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps:
- Create a second company
- Go to Website > Products > Products
- Create a product for all companies
- Click the "Go to Website" smart button
- Click "Edit in Backend" in the top-right corner
- Change the product's company to the one you're not on
- Go to Visitors > Visitors
Bug:
Access Error:
The requested operation ("read" on "Product" (product.product)) was
rejected because of the following rules:
(Records: Two prod (id=42), User: Mitchell Admin (id=2))
Explanation:
It happens because of the rule `product_comp_rule` which prevents
reading a product from a different company.
This commit filters the visited products on the current companies.
opw:2467138
closesodoo/odoo#67614
X-original-commit: 984adb180ab1a255fac086fd61478141074e8d31
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
- Install purchase_product_matrix
- Go to Purchase and create a PO
- In PO Line, type a text (i.e. test) in product field and use quick create option
Description and UoM fields should be updated following product creation, but they are not.
"onchange_product_id" is not triggered.
"purchase_product_matrix" module overrides "purchase.order" form view by replacing product_id
field by product_template_id field.
"_onFieldChanged" function should execute "_onTemplateChange" when product_template_id is changed
and if id is set, which would trigger "field_changed" on product_id, but it cannot be done after
a quick create as id is false.
opw-2462538
closesodoo/odoo#67605
X-original-commit: 3c082b9a47be35579a454f13edc230ac3029922d
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
The gallery slider index was wrongly calculated when the gallery had no
active element, as the jquery method .index() will still return -1 when
no element is found.
task-2472041
closesodoo/odoo#67563
X-original-commit: 666fc3697bd7d70cfa0dd92f0a401b771196bb27
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
As the container div of the fullscreen indication stays on the page to
be displayed, it was obstructing the click events of the elements it was
displayed on. The user could not access what was on top of the screen.
The solution was to remove pointer events for that div so that it
doesn't interfere with other elements on the page.
Related to https://github.com/odoo/odoo/pull/65255closesodoo/odoo#67589
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
PURPOSE
Duplicate lead records are an issue for CRM users
To prevent sales representatives from contacting a prospect that:
- Already refused an offer from another sales
- Already accepted an offer from another sales
- Is already discussing with another sales
The purpose of this task is to inform the CRM user that there are
some possible duplicates for one lead and let the user decide how
to handle the case.
SPECIFICATION
- Add a computed field to count the number of potential duplicates.
- Add a stat button on the form view of a lead to display the number
of potential duplicates. When the user clicks on it, the leads
considered as duplicate will be displayed in a kanban view.
- Add a lost ribbon on the kanban view to quickly visualize the lead
state since the duplicates can be lost leads.
LINKS
Task ID : 2151017
closesodoo/odoo#61834
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the default stop was equal to default start, creating events with duration = 0.
closesodoo/odoo#67146
Taskid: 2475473
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In India, we need to configure taxes like this:
- 6% applied on base amount
- 6% applied on base amount
- 1% applied on 1.12 * base amount
If both 6% taxes are affected the base of subsequent taxes, it gives the following result:
- 6% applied on base amount
- 6% applied on 1.06 * base amount
- 1% applied on 1.06 * 1.06 * base amount
Thanks to the new 'is_base_affected' field set on the second tax, it gives the expected results.
closesodoo/odoo#66134
Task: 2343958
Related: odoo/upgrade#2254
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The fleet vehicle_id must be visible on vendor refund
opw:2471784
closesodoo/odoo#67280
X-original-commit: 7144321c3fd13f83241ae7e4be71a9a4d576a871
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Users with the rights 'Manual Attendance' get (read-only) access to their
own attendances.
closesodoo/odoo#66934
Taskid: 2438863
Related: odoo/upgrade#2216
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The "Add" button was not propagating the context, therefore records
couldn't get their default values set from the context keys `default_XXX`.
closesodoo/odoo#66876
Taskid: 2464991
Related: odoo/enterprise#16664
Related: odoo/upgrade#2207
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce the bug:
When trying to import or create a expense product with supplier taxes,
the supplier taxes were removed.
PS: The field vendor taxes is available in the expense product view
opw:2444551
closesodoo/odoo#65403
X-original-commit: 02d0591b73f5acd8c94e65cda3af1158c3a2254a
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The "Departure Reasons" where hardcoded and couldn't reflect all the
valid departure reasons (like "End Of Fixed-Term Contract").
This commit introduces a new model `hr.departure.reason`.
closesodoo/odoo#66905
Taskid: 2447056
Related: odoo/enterprise#16709
Related: odoo/upgrade#2211
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Display notification to give feedback to user.
And reload the view with the params "next".
closesodoo/odoo#67219
Taskid: 2344276
X-original-commit: bd33f283a1fa39815481ca28918c65ac7b48d641
Related: odoo/enterprise#16830
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
With Worldline, the cancel command fails when the card was already inserted.
closesodoo/odoo#67560
Taskid: 2415526
X-original-commit: c71f71fab63d2ccb1faeccbe54425f5b0fb488f0
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When canceling a purchase order generated from a SO, a warning activity
is generated on the SO to warn the salesman that the PO was cancelled.
But the activity message was incomplete, because the cancelled PO lines
were given as 'purchase_lines' to the rendering context, but expected
as 'purchase_order_lines' in the qweb template.
This commit ensures that the correct key is used and that the activity
message is clear and complete.
Fixes#67508closesodoo/odoo#67572
X-original-commit: ba7336a9d696e8506943edca2f3871f78fac3e99
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Thibault Delavallée