Currently when converting leads we may end up with False being compared to
a void partner recordset. Due to the use of != this leads to unnecessary
update of leads when no partner is involved in lead convert.
By comparing recordsets everytime we save queries and performance each
time a convert on a lead without customer is done. This leads to about
saving 150 queries in heavy duty tests.
Task-2722512 (Lead: performance in convert without customer)
Task-2722513 (Lead: performance master task)
closesodoo/odoo#81028
Related: odoo/enterprise#23094
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Fixed error on rendering template of email_template_lead_forward_mail when
clicking Forward to partner.
Issue is
'dict' object has no attribute 'lead_id'.
This was because in Odoo v14, jinja was used and using a dict like properties
was ok. With QWeb it crashes and we have to correctly handle the dict.
Fixes#79492
Task-2657930
closesodoo/odoo#80259
X-original-commit: 7facd634328ad2038a13f75a3616b753e8fef147
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The state value 'open' does not exist on model account.invoice.report
opw:2666887
closesodoo/odoo#80206
X-original-commit: 2e7c667f56f84c9bd516711685ca886ff25a5965
Signed-off-by: William André (wan) <wan@odoo.com>
Jinja was tolerant to missing variables, QWeb not at all. Let us fix templates
that use outdated or invalid variables.
Task-2657930 (Email templates fixup)
X-original-commit: 1c179d58bf2d4e4c3c9b05d08475966d75754cc6
Part-of: odoo/odoo#79895
Purpose
=======
Hide non-relevant fields for a portal user. E.G. we want to hide the
notification type, the menu customization... Because those fields
make no sense for a portal user.
Force the non-internal user to receive notifications by emails since
they can not open Discuss.
Task-2508521
Part-of: odoo/odoo#77766
Co-authored-by: nounoubensebia <neb@odoo.com>
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
Add more fields when we merge multiple leads to be sure not lose
valuable information.
Specifications
==============
Those fields are propagated to the destination if the value on the
destination is Falsy
- referred
- color
- recurring_revenue
- recurring_plan
- function
- lang_id
- date_deadline
- reveal_id
- lead_mining_request_id
- reveal_ip
- reveal_iap_credits
- reveal_rule_id
- event_lead_rule_id
- event_id
The "lost_reason" field is propagated to the destination only if it's
lost (otherwise, it makes no sense to have a lost reason on a non-lost
lead).
The field "iap_enrich_done" is set to True if at least one lead has been
enriched.
We also keep the sum of all the lead tags (and remove any potential
duplicates).
The address is taken from the lead with the most non-empty address
fields (sorted by highest rank if multiple lead have the same amount
of non-empty fields).
Task-2447721
PR odoo/odoo#75742
- Right now, if you click on 'Geolocate' button on partner form view, and if
partner has no address, it gives no feedback and user doesn't know what
happend.
With this commit, if the geolocating does not work, user will get a toast
notification telling him that 'No address found' to avoid confusion.
- When we click on 'Automatic Assignment' button from crm form view,
if there is no country set on lead, odoo skips the process, but we get the tag
that 'no partner available' which is not correct. It should be
there only when odoo actually tries to find the partner based on
lead's country.
This commit fixes the behavior by showing a toast notification to
user in this case, saying 'There is no country set in address'.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
Currently the 'Opportunities' stat button on partner form view does not show
the opportunities where current partner is assigned one, it only shows the
ones that have current partner(and it's children) set as a customer.
This commit includes such opportunities (where current partner is set as
assigned parter) in the count of stat button and on the view we get when
clicking this button.
taskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
This commit improves the following:
- Hides the icons under the 'Contact' section if the related
information is not available.
- Moves the 'Next Activity Date' next to 'Next Activity' on
opportunity edition dialog, and opens the date-picker to
schedule next activity below the input instead of above it.
- Increased the height of 'Details Next Activity' textarea so
that 'Next Activity Date' picker can be shown within the modal
without introducing scroll-bar.
- This commit renames the label 'Title' to 'Opportunity' to avoid
confusion, and auto-fills it based on the 'Contact Name' for the
modal that is used for creating opportunities from front-end.
Apart from that, this commit also improves string of the button
responsible to create new opportunity from front-end.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
This commit display the assigned parter on kanban view of opportunities next
to the partner (if assigned parter is set). For example, if the customer name
is 'Main Contact' and assigned partner's name is 'Assigned Contact', it will
appear in following format:
Main Contact → Assigned Contact
If there is no customer and only assignd parner, it will look like
→ Assigned Contact
Note that if there is only customer, or no assigned partner and no customer,
nothing changes in the view.
taskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
- This commit removes `selection` widget given on 'Partner Level'
and 'Activation' fields on contact form view to allow users to
create records for them on the fly (with 'no_open' option).
- This commit moves geo-location related fields below the parter assignment
related fields in the 'Partner Assignment' page of contact form view.
- This commit adds default lowest 'Partner Level' and 'Activation' (based on
sequence) while creating assigned partner on the fly from opportunity form
view. The purpose is to allow user to select the created partner again in
'Assigned Partner' m2o, which displays only partners having 'Partner Level'
(grade_id) set.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
- For sake of having basic config for 'Partner Level' and 'Activation'
in contact form view (until user discovers the dedicated menus under
CRM > Configuration > Resellers) in blank db, this commit moves the
demo data related to 'Partner Level' to data, and adds new data for
'Activation', in following sequence:
- Fully-Operation
- Ramp-up
- First Contact
Also, higher ranks for partner level and activation are considered
better, and so the tree views for them now display the records in
the order of their rank (highest on top).
Note that with this commit, we remove 'Platinum' partner level and
it's references that were available in demo data.
- Apart from that in this commit we have also done these changes,
- Renames the menu 'Partner Level' to 'Partner Levels' and adds
action helper for the same.
- Adds action helper for the 'Partner Activations' menu.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
While we try to open an opportunity from front-end page it will throws a
traceback. In this commit we have fixed the traceback, the traceback occured
because while rendering the template `portal_my_opportunity` we were using
an invalid field `res_model_id` for searching the corresponding model activity
types, in this verssion we have `res_model` field instead of `res_model_id` thus
we have updated this field instead of using the invalid field which doesnt
exist.
TaskID-2443894
closesodoo/odoo#78288
X-original-commit: 25d5d7bbfbe4ce054ebd3494a04e028498dbd441
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Right now when editing the opportunity, all the activity types are listed in
the drop-down, even those which are specific to other models.
After this commit while editing the opportunity, we now display
only activity types which are either specific for 'crm.lead', or those
which are not linked with any models (common for all).
TaskId-2443894
closesodoo/odoo#77924
X-original-commit: eda10ddcacdcb016c1282252d3b65dc37c934221
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The exists method (of BaseModel) doesn't work with model
without SQL table but with a table query (see
f2ceef0e2f)
This method is call when we try to read a forbidden
record (`forbidden = missing.exists()` in `_read`)
- Fix it by using a Query object (which able the case).
- Also use a partition method instead of duplicate it in the method.
- Fix the CRM Lead Report which can return a Falsy id
task-2633558
closesodoo/odoo#77644
X-original-commit: 70a68615c722e7145b2ba8bb7ca86a8373b5aa4e
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
When a portal user is editing opportunity from front-end, there are
two date inputs, 'Expected Cloing' and 'Next Activity Date'. But both
of them have two pickers for selecting date, a native one and a
bootstrap one, which was probably side effect of commit[1].
With this commit, we only keep the bootstrap picker so that it
respects the date format based on language, and for the check,
to make sure it doesnt break the backend (see ticket from commit[1]
for more details), we simply consider the date with year less than
1900 as invalid.
We also provide a bit more space for bootstrap datpicker to open while
setting the closing date, so that the scrollbar is not introduced on
the modal. And for the next activity date, we make sure that the
picker is opened always on top of the input (which is not the case
currenlty in some screensizes, sometimes it is opened below the input
so it is hidden under the extra scroll introduced with picker).
commit[1] - https://github.com/odoo/odoo/commit/b2b639b693dd7215e3ee501ac89c35f3a6b88bb5
TaskID-2624728
closesodoo/odoo#77289
X-original-commit: da7cac9b1293a0b8d5375e1b4a470f41fe76e8a4
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Use a template for merge post messages and clean how fields are displayed,
notably by fixing the display format, and the field order.
Indeed, previously posted lead merge message contained all fields in an
alphabetical order, even ones that had empty values, which is not very user
friendly in terms of display.
Now, the displayed fields are determined and ordered by sections, which greatly
improves understanding the various information.
Please note however, that it has the downside of not including all fields
anymore.
The merged leads information are included in a "read more/read less" enabled
block using the "data-o-mail-quote" feature to get a nice rendering and avoid
cluttering the Odoo chatter UI.
Within the sent mail however, the full text is directly visible when viewing
through a mail client.
Task-2451164
closesodoo/odoo#75946
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
We clean various graph archs taking into consideration that:
- the default type of a graph is "bar".
- a bar chart is by default stacked.
- the field attributes type="row" and type="col" does not make sense for
a graph view (since its implementation was separated from the pivot
implementation a long time ago))
- the boolean attributes should now take 1 or 0 as value (but the other
values are accepted for retrocompatibility).
Part-of: odoo/odoo#76065
Bug
===
1. Login as "Portal"
2. Go to "/my/opportunity"
3. Create an opportunity
4. Edit this opportunity from the frontend and set the probability empty
=> Save, an error is raised
Technical
=========
The probability is set to "None" and not to "False", therefor the
verification "probability >= 100" in the write method of the lead will
raise an error.
By using False instead of None, this verification will work.
Task-2613208
closesodoo/odoo#75100
X-original-commit: e58048350b670b88c31c88cc57cdf6cc38b22f80
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Inserted content comes from markup so it's safe by
definition. Apparently missed it when cleaning up the server-side
templates.
Also remove the useless `ref_content` local, that's what `0` is for.
Issue
- Install 'addons/website_crm_partner_assign' module
- Create a partner X without a phone number (edit only name).
- Save and click on "Opportnuties" stat button
- Create an opportunity Y and set X as customer
- Edit it and set "Joekl Willis" as assigned partner
- Logout then login with portal user (Joel Willis)
- Go to "My account" page and click on "Opportunities"
- Select the opportunity Y and edit "Contact"
- Change phone number then save
Access error message:
(not allowed to access 'Contact' (res.partner) records)
Cause
When editing the opportunity (OPP) phone (or email_from) field,
if a partner is linked to the OPP and the phone is different,
we will update also the phone of the partner.
User portal is not allowed to edit partner.
Solution
If user has write access on lead, use sudo() to update lead.
Raise an error if a user want to update a non allowed field
from portal through the contact lead form.
opw-2530744
closesodoo/odoo#72453
X-original-commit: 7d41ab05e5b3d78df5f60848ad440988cd98b6e0
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Description of the issue/feature this PR addresses:
It is currently quite difficult to differentiate users. Most of the time, people
don't take the time to upload an actual avatar so everybody looks the same. This
PR generates a custom avatar with the users initials and random color to
differentiate them. For res.users, res.partner and hr.employee, image fields now
hold the binary image and avatar are used to show the image or svg.
Current behavior before PR:
Avatar had only random colors and was being saved in database, being inefficient
Desired behavior after PR is merged:
A new mixin defines image fields and in case no image is set, it generates an
SVG image with the user's initials and random color.
closesodoo/odoo#69819
Task: 2404630
Related: odoo/enterprise#18199
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Currently, across Odoo, there are around 40+ many2one fields defined with a
'selection' widget. Since the many2one widget has options to limit record
creation and opening, there is no reason to define a many2one field with a
selection widget. The selection widget does not allow for searching, and is
limited to 100 records.
PURPOSE
to update the definition of any many2one on which we applied a 'selection'
widget, and instead use the standard many2one widget with disabled
opening/creation instead.
after this commit,
for each many2one field defined with widget="selection", widget="selection" is
replaced with options="{'no_open': True, 'no_create': True}"
Task : 2476488
closesodoo/odoo#68387
Related: odoo/enterprise#17316
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
If 2 partners have the same weight, the first partner will
have 2 times more chance to be chosen.
Task 2246367
closesodoo/odoo#67992
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
* account, analytic, calendar, coupon, crm, crm_iap_lead_website,
delivery, digest, event, event_crm, fleet, gamification, hr,
hr_expense, hr_skills, im_livechat, lunch, mail, maintenance,
mass_mailing, membership, mrp, point_of_sale, pos_mercury, product,
purchase, purchase_requisition, sale_management, sales_team, sms,
stock, stock_landed_costs, survey, website_crm_partner_assign,
website_event_exhibitor, website_event_track, website_forum,
website_slides, base
This commit removes oe_edit_only labels and adds placeholder
on fields in form views from a lot of apps to minimize the
shift when switching mode.
task 2330101
Right now, the 'CRM > Reporting' menu is accessible only to the sales
managers. However, we should let users of all access right levels to
see their reporting while making sure it does not give them access to
data that does not match their rights.
This commit thus changes group applied on 'CRM > Reporting' menu from
'sales_team.group_sale_manager' to 'sales_team.group_sale_salesman' so
that from sales person to manager, everyone is able to the reporting
based on their rights.
For the below sub-menus, record rules already exist, preventing data breach:
- Dashboard (crm_enterprise)
- Leads (crm)
- Pipelines (crm)
- Activities (crm)
However, for data under 'Partnership'(website_crm_partner_assign) and
'Lead Generation Views' sub-menus(crm_iap_lead_website), we introduced
the needed access rights / record rules to ensure basic users can only
see the data they have rights for.
TaskId - 2357311
closesodoo/odoo#64202
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to make clearer how final opportunity value are
computed or chosen when merging leads. Functionally nothing should change
with this commit.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
Follow-up of 13a4544707053295565c33580526f6a8a16f556b
Where we fixed the portal *list* of opportunities but did not notice that the
associated *form* also had the same issue.
To recap the issue:
When you remove the 'company_id' on a crm.lead, you also remove the computed
'company_currency'.
When trying to view this kind of leads in the website_crm_partner_assign portal
form page, it would raise an error while trying to display the planned_revenue
in the missing currency.
Now, we display the number without any currency sign, which is a "best effort"
solution, just the same as on the crm.lead form view.
So it will look like "9000 at 47%" instead of "$9000 at 47%".
Task-2444539
closesodoo/odoo#65199
X-original-commit: c3007ac621d95ee487560a95eeaf925b56c01ab7
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
- The precision on geolocalisation fields were set to (16,5) which
caused rounding when data was comming from Goolge.
After this commit:
- The precision on geolocalisation fields are set to (10,7) which is
aligned with what Google does.
This precision of (10,7) is actually already used in the Sign App.
task-2426985
closesodoo/odoo#64401
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Prepare sales team membership and lead assignment improvements by
reorganizing and cleaning some code bits.
SPECIFICATIONS
Tools methods should be private by default to indicate those are not part of
official convert or merge API for leads. In this commit we make convert and
merge tool methods private, keeping only main API methods public.
LINKS
Task ID-2428882
Prepares Task ID-2086889
COM PR odoo/odoo#64196
ENT PT odoo/enterprise#15610
When you remove the 'company_id' on a crm.lead, you also remove the computed
'company_currency'.
When trying to view this kind of leads in the website_crm_partner_assign portal
page, it would raise an error while trying to display the planned_revenue in
the missing currency.
Now, we display the number without any currency sign, which is a "best effort"
solution, just the same as on the crm.lead form view.
So it will look like "9000 at 47%" instead of "$9000 at 47%".
Task 2416841
closesodoo/odoo#63657
X-original-commit: aafbde0b72347b348a7a5a59c934f063247ba4de
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
Same change in several areas where translations existed:
- website editor notification popup
- elearning share popup
- forum remediation filter popup
- event registration attendees popup
- portal rating popup
- stripe payment error popup
And many other locations where there were no translations yet
"×" has been replaced by its UTF8 character.
Also introduced aria-label where missing.
Before this commit the close icon was included in translated resources.
For example, in Spanish the "×" had been turned into "&veces;"
thus not rendering an icon anymore
After this commit the close icon is not a translated text anymore and
remains an icon across all languages
https://github.com/odoo/odoo/pull/60186
task-2312878
closesodoo/odoo#62250
X-original-commit: 9896af94ebc887d98ccf44e6568ef7eeb5a27172
Related: odoo/enterprise#14937
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The first stage has not always its sequence equal to 1. So if the
probability was for example equal to 0, then the salesman will not
be set to the new lead.
Since when we create a lead, the default stage is the first one in
the sequence. We only need to check if the lead is not already won
when we create a lead and try to assign the salesman to it.
task-2329327
closesodoo/odoo#61816
X-original-commit: c5059aa151430eebd62e9f000fe43e87bdd89ff3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- CRM--> Configuration --> Tags
- Delete the tag "No more partner available"
- CRM --> Lead --> Automatic Assignment
Bug:
It will raise Traceback
`AttributeError: 'NoneType' object has no attribute 'id'`
as Tag is not Present.
With this Commit:
It will add Tag if it exists on database.
closesodoo/odoo#61470
X-original-commit: 631030ae179c65ae0d99603046b5a09ffe00c408
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Including demo data this time
closesodoo/odoo#58862
X-original-commit: 575abde110acb3d12b25f177a863374becef0894
Related: odoo/enterprise#13705
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
PURPOSE
Clean code and be and more performance oriented.
SPECIFICATIONS
Various portal pages hold references to archive_groups. It was a summary
of customer documents for portal, containing a count of all documents split
by model.
Currently its computation is not used. Indeed archive_groups is displayed
only in 'my_details' page that does not hold any document-based reference
or code call. Other calls to archive_groups are dead code as the result is
not used. Since 13.0 it is even not computed on standard pages to speedup
their load (as it was not used).
It is not used anymore and its computation and references can be removed
safely, especially with v14 in mind for which we want to remove dead code
to maintain.
Followup of odoo/odoo#55228
LINKS
Task ID-2329081
PR odoo/odoo#55800
PR #12368closesodoo/odoo#56859
X-original-commit: e75086000ee4317b2ad2994db5d906fbcbd5081f
Related: odoo/enterprise#12830
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Thibault Delavallée