Before this commit, routes were prevented to be accessed if the route model was
not accessible from the current website, eg you couldn't access blog1 which is
set to website2 from website 1.
That would raise a 404 even from admin/editor.
This commit introduce that behavior at a lowel level in a generic way, instead
of having to write it on every route.
Note that routes without a model converter won't benefit from this.
Closes#63499closesodoo/odoo#64313
Related: odoo/enterprise#15688
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The mobile app's authentication bases its feedback to the user on the
error message returned by the server.
Sadly, in case of multi-databases, no error message are properly
returned when the user provides wrong credentials (presenting only an
empty Snackbar).
This difference of behaviour was introduced in the commit
odoo/odoo@07d5ea3 which goals was to give more power for JsonRequest's
error handling customization. To do so, the catching of the exception
(if one happens) was delegated to the caller instead of the JsonRequest
itself.
This change indirectly introduced a difference about the treatment of an
exception between mono and multi-database :
* mono-database was already catching the exception and handling it
properly (see in
https://github.com/odoo/odoo/blob/f05f8ef647a4eaba49d8a20eb8068f1c7a702297/odoo/addons/base/models/ir_http.py#L235-L241).
* multi-databases didn't catch it.
This commit restores the parity between both use cases by applying the
same behaviour (as described in the commit odoo/odoo@07d5ea3):
```python
ir_http.dispatch():
try:
request.dispatch()
catch Exception as e:
ir_http._handle_exception(e)
ir_http.handle_exception(e)
request._handle_exception(e)
```
Steps to reproduce:
1. Open the mobile app;
2. Try to register an account with a wrong password with multiple
databases;
3. The snackbar is empty and no error is shown => bug;
Task ID: 2287176
closesodoo/odoo#64965
X-original-commit: f54c97f6214c235bac931184c6e533a7fa72fbe2
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When using the Calender synced with Google, if the user tries to delete
an event, an error message is displayed: he has to archive it instead.
To reproduce the error:
1. Sync Odoo Calendar with Gogle Calendar
2. Add an event
3. Click on it > Delete
Error: UserError message: "You cannot delete a record synchronized with
Google Calendar, archive it instead"
To make the flow simpler and faster, when clicking on "Delete", the
server will archive the event. When archiving an event, the server
deletes the corresponding event on Google Calendar. As a result, the
next time the user loads his Odoo Calendar, the sync Google->Odoo will
delete the archived event.
OPW-2440339
closesodoo/odoo#64957
X-original-commit: 109ffab4a5d3e77d330d7fa4cc5fd39017bdf561
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Issue
- Install "Ecommerce" app
- Go to 'Shop' page and edit it
- Add a "Dynamic Products" block
- Click on it to edit it :
- Select any template
- Select `Desks` as product category
- Save
- Go to "Website -> Configuration -> eCommerce Categories"
- Delete the "Desks" category
- Go back to Shop page
Error : "Record does not exist or has been deleted".
Cause
The search domain is looking for child categories of dataset.productCategoryId
(who does not exist anymore in the above case).
`child_of` do a browse() to fetch the records, and therefore generate
an error if category not found.
Solution
Log warning message if unexptected domain and return empty records set instead.
This commit also reverts commit 0de069b8ca9fb005ba5b076984f5677de25889ee that generated the issue.
opw-2440917
closesodoo/odoo#64947
X-original-commit: e452d30f739db39a088248a3109c8c49cff9d49f
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Before this commit the custom snippets were saved across websites
because the RPC mechanism used by the save & reload does not include the
context by default.
After this commit the custom snippets are saved for the specific website
as initially intended.
No migration is needed: already created snippets that have been created
across all sites will have the correct lifecycle because of the
copy-on-unlink system: trying to delete one will make it specific on
other websites.
Related to task-2374802
closesodoo/odoo#64963
X-original-commit: 42e0f9112404541d1c11ba35e7a3d9bcb939f73b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* = hr_holidays, im_livechat, website_livechat
A huge amount of components where rendered for no reason, notably when typing a
new message (at every key press), which significantly slowed down the interface.
There were 2 causes to this number of renders:
- OWL rendering all children automatically, even if their props didn't change,
unless `shouldUpdate` is overridden, which is now done.
- `useStore` selectors being way too generous in what they observed
task-2399731
closesodoo/odoo#64958
X-original-commit: a0472425251d429a0828eff1675c84b3f24527d8
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In 13.0, some account.move.line fields (amount_currency, debit, credit
and account_id) couldn't have a value when the line is of type 'note'.
Skiping them during line copy for notes is not an issue.
During 12.0->13.0 migration, we were facing issues with "grouped similar
invoice lines in a single move line", because this feature is not
available anymore in 13.0. To avoid any "loss of data" during migration,
we used lines of type note to create "missing" invoice lines in move
lines without altering accounting in any way. As a consequence, we have
13.0 databases with lines of type note having values for fields who
couldn't have ones.
closesodoo/odoo#64962
X-original-commit: 677edafeaf8d691764178f5e7e9639017b0249a8
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- On account_edi_document, lock the documents successively instead of all at once.
- Lock account_move that should be cancelled. Before, cancelling the invoice after cancelling it on the web-service could fail.
- Lock ir_attachment that might be unlinked. Before, attachments that weren't attached to any model could become unreachable but still present in the database when an invoice was cancelled or a new attachment was produced.
closesodoo/odoo#64946
X-original-commit: 8d0c25f359f92533eb25f2990d6e2aceef33b77a
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
This mobile specific code does not work correctly because
`if channel in channel_previews` always returns false due to the dict having
channel ids as key and not channels.
A fix could be to look for id instead of record in the dict, but at the same
time this is dead code, there is no need for mobile specific channel info.
task-2412157
closesodoo/odoo#64945
X-original-commit: a27907e27fb99a523c7b2d58544c36073640511c
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, on pivot view when a user adds some groupBy the
dropdown menu remains always open.
This commit restore the same behaviour like on desktop.
Steps to reproduce:
* Open an app with a Pivot view
* Select the Pivot view
* Add one "groupBy"
* The dropdown remains open => BUG
Task ID: 2439742
closesodoo/odoo#64944
X-original-commit: 298f3900a8f4c80fe06585634ce97c7725cf7f7d
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
Add two indexes (on `product_id` and `product_tmpl_id`)
on the `mrp.bom` model to speed up `_bom_find`
which is highly used and it uses always the `product_tmpl_id` and
sometime the `product_id` in the search domain.
Performance Gain:
With a DB with 2K BoM, a `_bom_find` search (`product_id` and
`product_tmpl_id` are in domain): The SQL execution time
is +- 5 times faster.
task-2390516
closesodoo/odoo#64934
X-original-commit: 64861aed03b616820d717bc08e7c38c56145e0f2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Use UNION ALL instead of UNION to let PostgreSQL
filter out rows before sorting and avoid Unique check.
Note that it shouldn't change the result because each 3 SELECT
doesn't have domain intersection.
Improve performance the `_get_orderpoint_action` and the Forecasted
Inventory.
Performance Gain:
With a large Database (5K products, 120K stock move, 20K quants, etc):
To open the Forecasted Inventory:
Before: 10.06 sec +- 0.02
After: 3.98 sec +- 0.07
task-2390516
X-original-commit: 0a89bc231aaadee959deb6cda4aa09318b08f591
Avoid to filter in a loop and use a read_group instead to group by
product-warehouse outside.
Also remove costly useless code.
Performance gain
----------------
On a large database (120K stock move, 5k product) where
+- 700 manual orderpoints will be create during the open of the
replenishement report:
Before:
16.14 +- 0.16 sec of python. (SQL time is +- 14 sec)
After:
1.33 +- 0.91 sec of python. (SQL time ==)
task-2390516
X-original-commit: 569b45d5cb139825690a90189b7a360f3fa89815
`o.location_id.id == g['location_id']` =>
`Comparing apples and oranges: stock.location(243,) == (219 ...`
replace by the correct code and avoid warning.
task-2390516
X-original-commit: 461a3e737c4ffe048b738dd09f83571602324257
Replace union of RecordSet by union of OrderedSet to reduce the
complexity and improve the scalability. It can be a bottleneck to
huge number of move to assign.
task-2390516
X-original-commit: e89105144a34ee73981db383ac0625dcaf63b27b
Replace union of RecordSet by union of OrderedSet to reduce the
complexity and improve the scalability. It can be a bottleneck to
huge number of move to validate.
task-2390516
X-original-commit: d9510aee26578e1b345a7700f7c94032d5745bf4
This commit fixes a nondeterministic issue during the rainbowman tour.
We make sure that the record is properly created and the kanban reloaded before
moving on to the next step, ensuring that the tour completes without race
conditions.
Task-2426257
closesodoo/odoo#64921
X-original-commit: f332541bc84d6110c90d4c5e736892f185fff3df
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Like any snippet creating dynamic elements on page load, we need to
use a special class on those elements to mitigate the undo/redo system's
imperfections.
closesodoo/odoo#64893
X-original-commit: 0d9a782681fcbd50ca687ae3158dc12f5b3571cb
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
1. Go to Settings > Accounting and set a Check layout
2. Go to Accounting > Vendors > Payments
3. Create 2 payments to Vendors, and Confirm (but do not print).
- Payment Type: Send money
- Partner Type: Vendor
- fill in any Amount
- Payment Method: Checks
4. Go to the accounting dashboard, click on "2 checks to print"
5. Select both payments and print the checks from the Actions menu
6. Refresh the page.
Both payments still show up with the "Checks to print" search filter
enabled. They also shows up in Accounting dashboard as checks to print
opw-2427523
closesodoo/odoo#64908
X-original-commit: 8ad9c16d7b10da17795c805b0541f0a3a9256dc4
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Before this commit:
-when moving a snippet using the drag and drop button, two drop zones
instead of one was added at the initial location of the dragged
snippet.
-when moving a snippet using the drag and drop button, no drop zone
was added at the initial location of the dragged snippet if the snippet
was alone in its parent. For example, the left jumbotron in the banner
snippet.
-the drop zones handled by the "children rules" were never vertical
when it was necessary.
This commit also refactors the code to avoid some duplicated lines.
task-2312878
closesodoo/odoo#64884
X-original-commit: b259b8069f74088bd8add50ddab76c1a7630ac8f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- Create a promotion of discount 10% with coupon (A)
- Create a promotion of fixed discount (50$) with coupon (B)
- Create a sale order of 50$, apply A and then B
Order will have a negative total.
This is due to the check done on the order amount, which needs to be
checked without the current program, to allow correct stacking of
promotions
opw-2410666
closesodoo/odoo#64848
X-original-commit: 22598c88638aaa2570c88f5bdf01d185abadd086
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
This reduces the number of cache invalidation and recompute.
Because the full environment was not flushed anymore everytime, the test
:TestSaleProject.test_project_overview_by_project was failing.
closesodoo/odoo#49276
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Task 2230635
Add _populate implementation for:
* Bank Statements
* Journals
* Journal Entries / Invoices
* Payments
* Reconcile Models
Load a chart of account for the first 3 companies, and load data only
for companies with a CoA installed.
Add a new function to generate random datetime within a range
around a base date.
This allows the base date to change in the future or to be set to
today's date easily.
The CHF currency was duplicated. Instead of using an hard coded list,
select from all the active currencies.
These are USD and EUR on a clean DB but it is easy to change if we want
to populate with another currency in some use case, without changing the
code.
* When setting company_id on the res.partner, the parent might have had
a different company_id
* We should not consume res.partner's when creating res.user's but
creating new ones instead.
Set up a DEMO product with
- warning message on sale
- variant
- Order Grid Entry as Sales Variant Selection
Create SO, configure this product
Warning message doesn't display
opw-2442352
closesodoo/odoo#64894
X-original-commit: 50ccbdb983fda289cb9fe740ae711d510386d878
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Configure an email server and create a login account with a space like
"foo bar". In odoo configure an Outgoing mail server using that account,
there is an error because the username is misconsidered invalid.
The errors resides in the IDNA implementation of Odoo, we try to split
the username to get a login and a domain in order to encode the domain
using the ponycode algorithm. In case the username was not an email
adress but just a single name, the single name was mistaken for a
domain. As domain cannot have spaces, an error was thrown.
opw-2419024
closesodoo/odoo#64885
X-original-commit: 61b0a859b76ebffe083e10b25e4af52702dfb61f
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Before when there were long labels, this was leading to an overlapping
of the text.
Now, we display the whole label but in multiline with a maximum number of
characters per line depending on the number of columns.
The font size will also be compute depending of the number of characters
per line and with the length of the longest word in the labels.
task-2382681
closesodoo/odoo#64877
X-original-commit: 58bd6a51041d1c0c011810823caf540995428c2a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
A purchase journal cannot be created without a default expense account
A sale journal cannot be created without a default income account
opw:2431278
closesodoo/odoo#64854
X-original-commit: c0af2df89dbe8f0cea384f15b2a7e3d53a16dfc6
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
account_tour_upload_bill is using an inherits only to use a single m2m
field. This will remove the inherits and simply add the field directly
into the account_tour_upload_bill model.
task id #2339702closesodoo/odoo#59169
Related: odoo/upgrade#1899
Signed-off-by: William André (wan) <wan@odoo.com>
RATIONALE
For historic as well as internal reasons many CRM features were added into a
module called "website_crm_score". This module was mainly developed to manage
Odoo's prospects based on our own processes and rules. It included
* automatic lead assignment on teams, based on a score (lead scoring) and
team- and salespersons- specific domains;
* support of web pages (page views);
* support of multi sales team membership for salespersons;
This task aims at dismantling this module to make sure those valuable features
can be used by all CRM users
* lead assignment is moved into CRM;
* lead scoring is replaced by PLS and automatic probabilities computation;
* page views is now managed through visitors;
* multi sales team memberships is moved into CRM;
PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICATIONS: SALES TEAMS MEMBERSHIP
Move sales team membership model from website_crm_score (enterprise) directly
into sales_team. It allows to have the base requirements to correctly handle
mono and multi sales team for salesperson.
Membership is modeled using a decorated many2many relationship. Members of
a sales team are res.users. Subscriptions are crm.team.member linking a team
and an user. It is a rename of team.user model coming from website_crm_score
as well as some other relational fields renaming.
Part of old team.user model is moved directly to sales team, part of it to
crm module (notably assignment limits). Its support will be improved in the
upcoming commits. Assignment related fields will be cleaned and used when
moving assignment directly into CRM.
SPECIFICATIONS: MONO / MULTI TEAMS
Purpose of this commit is to allow to use either mono salesteam mode, either
multi salesteams mode. Basic CRM use mono membership: a salesperson belongs
to a single sales team. It is however possible to choose to work using multiple
memberships. This is configured through a configuration parameter available in
CRM configuration settings.
Mono salesteam behavior
* a given user can be member of a single sales team at a time;
* when moving an user from team to team, its existing memberships are
archived to keep history of what has been done within this team;
* display an alert when creating a new team member that would archive
existing memberships;
* displayed members on team form view are directly res.users records to
avoid displaying unnecessary layer when using a simple CRM;
Multi salesteam behavior
* a given user can be member of several sales team at a time;
* unicity contraint (user_id, crm_team_id) is still enforced;
* displayed members on team form view are crm.team.member records as
advanced configuration can be done directly at that level;
In all cases when adding a new member check for archived membership before
creating it. If an archived version of the member exists it is unlinked in
order to avoid breaking the unicity constraint.
Archived memberships can be managed in its dedicated menu for advanced sales
team use.
SPECIFICATIONS: COMPANY-BASED DOMAINS
Improve support of multi company. Sales team can either be linked to a given
company, either be cross companies (company_id = False). Currently it is easy
to have issues while trying to add users from a companyA to a team belonging
to companyB.
When using mono membership mode
* members are res.users records;
* a domain is added on users to belong either to the team company, either
to all available teams if team has no company;
When using multi membership mode
* members are crm.team.member records;
* a domain is added on user_id field of membership records so that they
belong either to the team company, either to all available teams if team
has no company;
Those domains are implemented using a computed field it is not directly
translatable to a domain. Domain is added directly on field at model level
and include the "avoid shared users" domain leaf.
SPECIFICATIONS: CHECK_COMPANY
``check_company`` attribute is set on team member allowing to automatically
detect badly configured memberships. Check company is activated on user_id
and team_id fields of crm.team.member model to ensure they match.
SPECIFICATIONS: LEAD ASSIGNMENT
Move sales team automatic lead assignment from website_crm_score (enterprise)
directly into sales_team. Some cleaning and renaming is performed while moving
the code as it is old fashioned.
Scoring feature is removed completely from lead assignment. Indeed we consider
PLS is a better feature and provides more accurate results.
Minimal scoring specific field on team is removed. Indeed it can also be
integrated directly into domains linked to a sales team as this is a field
directly available on lead using ``probability``. It allows to reduce fields
of team model and move all logic in the team's domain itself.
Overall behavior as been kept as close as possible from the original one.
Purpose is to avoid too much undesired changes between versions.
In this commit we also add tests for automatic lead assignment.
ASSIGNMENT PROCESS DESCRIPTION
1- LEAD TO TEAM ALLOCATION
Allocate leads to teams given by self. This method sets ``team_id`` field
on lead records that are unassigned (no team and no responsible). No
salesperson is assigned in this process. Its purpose is simply to allocate
leads within teams.
Heuristic of this method is the following:
* first we randomize all teams;
* then for each team
* find unassigned leads, aka leads being
* without team, without user -> not assigned;
* not in a won stage, and not having False/0 (lost) or 100 (won)
probability) -> live leads;
* if set, a delay after creation can be applied (see BUNDLE_HOURS_DELAY)
parameter explanations here below;
* keep only leads matching the team's assignment domain (empty means
everything);
* assign maximum BUNDLE_SIZE leads to the team, then move to the next team.
This is done to ensure every team will have leads enough to fill its
capacity based on its domain;
* when setting a team on leads, leads belonging to the current batch
are also merged. Purpose is to clean database and avoid assigning
duplicates to same or different teams;
* for all teams that still have capacity (aka: a search on unassigned
available leads with team domain still give results), do another
assignment round. Each round teams are randomized so that team order
is not always the same;
Note that leads are assigned in batch meaning a team could receive leads that
could better fit another team. However this heuristics is based on hypothesis
that team domains do not overlap. Indeed if a company has several teams they
will probably target separate market segments: country-based, customer type or
size, ... Having several teams using same assignment domain could lead to less
fairness in assignment process but this should not be the target use case of this
heuristic.
Leads are allocated by batch. This can be configured using a config parameter.
Batch size depends on cron frequency, lead pipeline size and members assignment
maximum. Finding an optimal heuristic for this parameter is not easy as it
depends on internal processes and organization. Higher batch size leads to
better performances when running automatic assignment. It can also give unfair
results if teams domain overlap or if pipeline is not big enough to fill all
teams capacity.
2- LEAD TO MEMBER ASSIGN
Main processing method to assign leads to sales team members. It also converts
them into opportunities. Its main purpose is therefore to distribute team
workload on its members based on their capacity.
Preparation
* prepare lead domain for each member. It is done using a logical AND with
team's domain and member's domain. Member domains further restricts team
domain;
* prepare a set of available leads for each member by searching for leads
matching domain with a sufficient limit to ensure all members will receive
leads;
* prepare a weighted population sample. Population are members that should
receive leads. Initial weight is the number of leads to assign to that
specific member. This is minimum value between
* remaining this month: assignment_max - number of lead already assigned
this month;
* days-based assignment: assignment_max with a ratio based on ``work_days``
* e.g. Michel Poilvache (max: 30 - currently assigned: 15) limit
for 2 work days: min(30-15, 30/15) -> 2 leads assigned
* e.g. Michel Tartopoil (max: 30 - currently assigned: 26) limit
for 10 work days: min(30-26, 30/3) -> 4 leads assigned
Assign process then follows the following heuristic
* take a weighted random choice in population;
* find first available (not yet assigned) lead in its lead set;
* if found:
* convert it into an opportunity and assign member as salesperson;
* lessen member's weight so that other members have an higher
probability of being picked up next;
* if not found: consider this member is out of assignment process,
remove it from population so that it is not picked up anymore;
Assignment is performed one lead at a time for fairness purpose. Indeed members
may have overlapping domains within a given team. To ensure some fairness in
process once a member receives a lead, a new choice is performed with updated
weights. This is not optimal from performance point of view but increases
probability leads are correctly distributed within the team.
SPECIFICATIONS: REMOVE WEBSITE CRM SCORE
Remove website_crm_score module as its core business is not moved. Scoring
itself is not used anymore as it is replaced by automatic lead computation
(PLS) and all other features are moved to core CRM application.
SPECIFICATIONS: IMPROVE ASSIGN PROCESS
Various commits are added to improve assign process. See sub commits for
more details. Global behavior is not changed but details are improved like
* include leads with probability being 100 but still not won
* ensure automatic assignment works out of the box
* continue filling salespersons pipe when they win leads
* improve team opt-out from lead automatic assignment
* limit allocation to teams when running automatic assign
* log manual assign and improve feedback message
* simplify evaluation of assignment domains
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#9499
Upgrade PR odoo/upgrade#996
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
SPECIFICATIONS
Move mail.channel.partner and mail.moderation models into their own file.
This makes some noise in diff but as channel is quite an heavy model let us
do this once for all.
Move mail.channel.partner views in their own file, as for python models.
Also containing
* separate and reorganize fields by main definition;
* separate and reorganize methods by categories, notably CRUD + orm, members
management, moderation, mailing, IM, commands;
* reorganize compute section: compute (by field order), constraints then
onchanges;
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
Some tools methods do not necessarily require to be public.
Cleanup a bit mail addon by moving menu definitions in their own file
according to guidelines.
No functional change should be involved in this PR as only some code move
and light renaming has been performed.
LINKS
Prepares Task ID-2070632 (Discuss channel task)
Prepares Task ID-2419762 (SM channel task)
COM PR #64862
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
SPECIFICATIONS
Purpose is to better spot future query counter updates by ensuring current
thresholds effectively match runbot state. Some query counters for admin
are currently a bit lower than expected, probably linked to various ORM
improvements and cleaning done since last counter update.
LINKS
Prepares Task ID-2070632 (Discuss channel task)
Prepares Task ID-2419762 (SM channel task)
COM PR odoo/odoo#64862
Sébastien Theys