- BS5 uses native inputs instead of pseudo-element for some
input like checkbox, radio, ...
in BS5 input checkbox don't have "virtual visual" checkbox anymore
(::before), so we remove the relative's rules
- removed `.custom-control` class
- `form-switch` use a new layout system in BS5 we adapt the code to
match the Bootstrap approach (inline SVG).
- In tests, we don't check the exact value of the background as it
change in community/enterprise, and it's difficult to check the value
of an SVG.
- Overflow in progressbar is now hidden.
-> we had to restore it.
- In BS5 margins in forms/inputs has been changed
-> we had to restore it (e.g. 'mb-3')
- .form-group, .form-row, .form-inline
> Dropped form-specific layout classes for our grid system.
> Use our grid and utilities instead of .form-group, .form-row,
> or .form-inline.
- .input-group-append and .input-group-prepend
> Dropped .input-group-append and .input-group-prepend.
> You can now just add buttons and .input-group-text as direct
> children of the input groups.
Ref:
[1] https://getbootstrap.com/docs/5.1/migration/#forms
Task ID: 2766483
Part-of: odoo/odoo#95450
This commit removes the unnecessary measures(like partner latitude/longitude)
from the lead related graph views. Also, we try to order the measures and keep
time related measures(Days to Assign, Days to Close, Exceeded Closing Days, etc)
first and revenue related measures(Expected Revenues, Prorated Revenues, etc)
last.
Note that with this commit, recurring revenue related measures will be displayed
only when the feature is activated.
ent PR: https://github.com/odoo/enterprise/pull/21981
Task-2674367
closesodoo/odoo#79167
Related: odoo/enterprise#21981
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: website_crm, website_crm_partner_assign, website_customer,
website_forum, website_hr_recruitment, website_membership,
website_slides, website_slides_forum
This commit adapts "customize show" options from several website modules
by creating new options available in edit mode.
See merge commit for more information.
task-2710582
On an heavy database searching for company leads or assigned leads can be
costly. Having an OR does not necessarily triggers index usage and query plan
uses an index scan.
It is less costly to do two searches: one for the base domain (based on
commercial entity) and one for the assign domain (based on partner assigned).
Task-2770994
closesodoo/odoo#88538
X-original-commit: 6957d7a57cb3bf25d552d3f8f2760db46ace5e3a
Signed-off-by: Thibault Francois <tfr@odoo.com>
Commit "[IMP] core: don't save visitor default session" moved the geoip
from the session to the request with a deprecation warning. This commit
adapts the remaining modules to use `request.geoip` instead of
`request.session.geoip`.
Geoip is always set on the request but it can be an empty dictionnary in
case the geolocalization failed.
closesodoo/odoo#86015
Task: 2789035
Related: odoo/enterprise#25192
Signed-off-by: Julien Castiaux <juc@odoo.com>
Two lines have been inverted in ``_get_access_action`` override, leading
to access rights not being correctly checked. This currently leads customers
with token to land on portal without token, which is not the expected
behavior.
Followup of odoo/odoo@a018735closesodoo/odoo#86646
X-original-commit: dd7d60aca8718763aaa211e138f684d8797f5d8c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, if we have both customer and assigned partner names,
they are displayed in a single line separated by an arrow icon.
However, if we have long customer name, arrow icon and assigned
partner name are not visible on card.
This commit improves the display of names by making a few changes
- breaking the line before the arrow icon
- displaying both customer and assigned partner name with text overflow
- adding a tooltip on customer and partner names
- improving tooltip on the arrow icon
taskID-2763930
closesodoo/odoo#85264
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Recently with commit[1], we changed the sequence for partner grades and
partner activations at db level (from asc to desc) to see the records
created with data files in our chosen order (for example Gold, Silver,
Bronze instead of Bronze, Silver and Gold).
However, there are several drawbacks with this approach. For example
during db upgrade, all the existing records needs to be adapted to
keep up the order of records created by data files.
This commit reverts change of order at db level, and instead adapts the
sequence of the records being created with the data files in a way that
they are still in the same order we wanted. And it will also maintain the
order of the records manually created by users after db upgradation.
commit[1] - https://github.com/odoo/odoo/commit/b28aae2
taskID-2765577
closesodoo/odoo#85235
X-original-commit: 5cc309744de5c2d5713d6bd95d02a66c21aaf11e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, for the better first user experience, few partner activation
levels are available by default (added in data files). Since there is no
way to archive it, the only way to not use them in your production is to
delete it. But it means that on each migration, it will be restored.
To improve that, this commit introduces 'active' field in the activation
levels so that one can easily archive them if they are of no use, and
this way they won't be again created every time when db is migrated.
This commit also adds a search view with 'Archived' filter to see the
archived activation levels easily.
taskID-2753985
closesodoo/odoo#84401
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose
=======
The module website_crm_partner_assign has its own partner_longitude
and partner_latitude values that are resolved independently, when the
linked partner doesn't exist yet.
So when a lead is turned into an opportunity and a partner is created,
the address info is copied to the new partner, but not the geolocation.
In case these partners are supposed to be geolocalized (for example
on the FSM application), the geolocation will be recomputed despite
the fact that this information was already available at the convertion
time.
closesodoo/odoo#84890
Related: odoo/enterprise#24517
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Improve performance in often used views and fields in a normal Odoo usage.
SPECIFICATIONS
On res.partner model in website_crm_partner_assign, convert the computed field
``_compute_implemented_partner_count`` to use read_group. Performance test
have shown it could be costly.
Also rename ``implemented_count`` to ``implemented_partner_count`` to better
match ``implemented_partner_ids`` naming.
Task-2752043
Part-of: odoo/odoo#83806
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Purpose of this commit is to make ``get_access_action`` private as it is not
necessary to expose it directly. Website management is also made explicit
using a ``force_website`` parameter instead of relying on context key of the
same name. This allows to better understand the method code flow.
Contains also some code fix / improvements :
* Website forum: update code to better skip the frontend redirection if the
forum is not active and frontend is not forced;
* Website slides: respect force website parameter in redirection;
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
``get_portal_url`` is already used in portal mixin. As we are in a side
module doing things not really related to portal mixin let us inline it
directly as it is used only once anyway. Indeed this method does not give
any portal url just a base url with a db parameter, used afterwards to let
people connect to the db.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
closesodoo/odoo#82627
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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.
Romeo Fragomeli