Before this commit, the `report_invoice_wizard_preview` was rendered well in
html and in the preview (settings page) but not when downloading it ; the
"total" table was pushed all the way to the right.
opw-3648586
closesodoo/odoo#149509
X-original-commit: 232c257c1554f2f47b589a971cdf9f98227ef53c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Adrien Milis (miad) <miad@odoo.com>
A model can specify a preferred company (cid) when redirecting someone from a mail
link.
Before this commit, this cid was taken into account when redirecting only if the
user is logged in.
With this commit, even if the user is not logged in, the redirect link will take
that preferred cid into account.
opw-3613144
closesodoo/odoo#149254
X-original-commit: e70a27d820d94dba7e8c45865ddc5fbc46f9f26f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Adrien Milis (miad) <miad@odoo.com>
*: website_event_sale, website_sale_slides, website_event_booth_sale
In website_sale, we have a setting to prevent the sale of zero priced products.
It works fine but triggers also on order of free events, free event booths and
free courses.
This is unwanted behavior and a check has been added to still allow those three
product types to be sold for 0.
Task-3388254
closesodoo/odoo#147589
X-original-commit: ab839650be3f04422aab8af81b72af475c0b6fd7
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before the commit, there was a small issue where a foldable badge would be
slightly smaller in height than A4 paper.
This commit fixes this by giving foldable badges more height.
Task-3389338
closesodoo/odoo#143079
X-original-commit: 0bca59b43bb195f8fc5feef315c7694eba6df326
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, the "Print Labels" button shows for all products except
services.
However, this button does not make sense for event_booth, event_ticket, course,
... products
So we only show this button for storable, consumable and combo products.
Task-3390587
closesodoo/odoo#136753
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In this commit, we add the 'foldable' option to the domain widget in crm and
event_crm.
Task-3458063
closesodoo/odoo#132008
Related: odoo/enterprise#45768
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
With this commit, we now raise a UserError if a user tries to save a template
with a composer that has no attached model.
Task-2504439
Part-of: odoo/odoo#126049
Before this commit, all mail templates were shared, which was cluttering the UI
for everyone.
Now, each user can have their own templates that they can edit and save. Access
is done through the mail composer wizard, where users can only access their own
templates and templates that don't belong to anyone.
Some groups are considered as admins and can access all templates in
Settings/Technical/Email/Email Templates:
- Sales Admin
- Project Admins
- Helpdesk Admins
- Accountants
- Event Admins
- Recruitment Admins
Task-2504439
Part-of: odoo/odoo#126049
Before the commit, the _get_seen_list() function in the mass_mailing module was
not able to correctly identify all the duplicate email addresses in a given mass
mailing. This was because the function chose and used only one way to find an
email address for each record in the mailing list, even though there are many
ways to find an email address for a record.
For example, a crm.lead record might have an email address in its partner_id
field, but it might also have an email address in its email_normalized field.
This can vary from record to record.
To fix this issue, the _get_seen_list() function was updated to only look at the
email address to which emails have already been sent, rather than trying to
fetch it from the record itself. This ensures that all duplicate emails are
correctly identified and that no duplicate emails are sent in the mass mailing.
Task-3234378
closesodoo/odoo#135081
X-original-commit: 66f9aa25af049aa3faf0f76475a4a2b63b5d0903
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose: set `lang_id` and `visitor_ids` fields on leads generated by a lead
generation rule.
We check that there are several languages used on the website to make sure the
visitor's language is relevant. Then we propagate the visitor's language when
creating leads.
Task-3293050
closesodoo/odoo#124303
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
With this commit, partner information and utm fields are pre-filled when
creating an opportunity from the many2one `opportunity_id` in `sale.order`.
Task-3442793
closesodoo/odoo#133904
X-original-commit: fb70b749e655a22ff038dff06f6317d34381d33d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Adrien Milis (miad) <miad@odoo.com>
This commit fixes an issue introduced in #118966. For the mobile preview
feature of email marketing, styles used to be loaded by rendering an "empty"
template with the necessary styles. These styles, however, are no longer
imported in a template, but instead in mass_mailing's manifest.
The fix is to manually load the bundle and create the link tags to add the style
to the mobile phone preview.
Task-3465776
closesodoo/odoo#133400
X-original-commit: b2796d8016be83a1d08f28ef48e98db90c07da69
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes a traceback when trying to install demo data from the UI.
Steps to reproduce:
- create a database with website_event_track_live installed and without demo data
- load demo data from the UI (settings)
- odoo.exceptions.AccessError: You are not allowed to create 'Website Visitor'
(website.visitor) records.
There is a traceback because the installer can't create `website_visitor`
records because there are no groups that have create access rights for that
model.
This is because xml_import used to get an environment with root privileges, that
can bypass access rights, but now the environment is a parameter passed to the
function and doesn't necessarily have sudo
This change was introduced in
5bf1207#diff-8e4705d5ab335a8dfc2c70eeedc502a92695989f97c4f19184b49634c2c4ad55L583-R583
; with this commit, the environment used by xml_import doesn't necessarily have
sudo, so we simply make sure `load_demo` loads data with sudo.
Task-3202914
closesodoo/odoo#129946
X-original-commit: 85834371e0eede05858cb2dc33412396c6e5c5bf
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Adrien Milis (miad) <miad@odoo.com>
This commit implements the `mail.tracking.duration.mixin` with the
`statusbar_duration` widget for `crm.lead` and `project.task`.
The goal is to compute and display how long a record has spent in each stage in
the statusbar of their form view.
Task-3032773
Part-of: odoo/odoo#108554
This commit implements a new widget in mail, `StatusBarDurationField`. Purpose:
seeing how long a record has spent in each stage in a form view.
It is implemented for records with a `many2one` status field and gets the data
from the `duration_tracking` field of the record. `duration_tracking` is computed
by adding the `mail.tracking.duration.mixin` to a model.
Time is shown using a luxon Duration object. "narrow" specifies that time is
expressed with one character and luxon takes care of translations.
Task-3032773
Part-of: odoo/odoo#108554
This commit implements a mixin, `MailTrackingDurationMixin`, that can be added
to a model with a `many2one` field. It computes the time a record spends in each
value the many2one field takes and stores it in a JSON field
(`duration_tracking`).
The primary use is with the StatusBarDurationField
(`widget='statusbar_duration'`), to compute and display the time a record has
spent in each stage in the form view statusbar.
To specify on what field the computation has to be done, the model that inherits
from this mixin has to specify `_track_duration_field`. (e.g.
_track_duration_field = 'stage_id')
Computation is based on `mail.tracking.value` messages, so tracking has to be
activated for that field.
Task-3032773
Part-of: odoo/odoo#108554
Before this commit, no check was made on conditional questions to see if their
condition was valid when taking a survey.
With this commit, if the survey is not in "random mode" (in which case,
conditions do not apply), there is a check to see that a conditional question
has a valid condition. If not, it is not used in the survey.
Task-3083488
closesodoo/odoo#113303
X-original-commit: f14d1f89ee9c78d481ce1f30ef74bdad9ef0cd7e
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, in the partner portal, all CRM stages were displayed for an
opportunity, even the non-relevant ones.
Now, only the stages that apply to this opportunity are displayed
Task-3133070
closesodoo/odoo#112665
X-original-commit: 9b385f034058d18608c9873a8a1e8fe44e220f1e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the mail scheduler in event bypassed the email_from field
in the selected template, implementing instead its own logic.
With this commit, the scheduler respects the `email_from` field from the mail
template, and only implements its own logic if that field is not set.
Task-3092425
closesodoo/odoo#111462
X-original-commit: ef503e62480c774e8a0d193666cc4cce5ab90282
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, when using the `many2one_avatar_user` on the `user_id`
field of the crm tree views, an error was thrown because the domain of `user_id`
refers to `user_company_ids` which the view did not have access to, so it
wasn't yet computed.
The field was added in invisible to the tree views so that it can be computed
before being accessed.
Task-3053146
closesodoo/odoo#105688
X-original-commit: 558607d98798d6a55adbcd98a6648a888286c3c9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the field opportunity_id was only visible in debug mode in
the sale.order form view. It was correctly pointing to opportunities but, when
used to create new records, it was creating leads instead.
The field is now always visible so users can link sale orders and opportunities
and a context was added so that the field correctly creates opportunities
instead of leads.
Task-3039802
closesodoo/odoo#104123
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In the quick create form views in CRM, the 'recurring_plan' field is missing
(or rather invisible). It is a required field so it prevents the use
of the quick create.
The purpose of this commit is to let it be visible again to users.
Task-3007756
closesodoo/odoo#105311
X-original-commit: d0deb895bba8deeddb95fc8919ded29b80a869f9
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose:
In the Forecast view of the CRM module, when recurring revenues are activated,
they are not shown in the progress bar of each stage of the kanban view. Only
the prorated expected revenue (non-recurring) are shown. In the regular
kanban view, they are shown.
To display them, we extended the CrmKanban view, which already possesses this
behavior, since behaviors relevant to the CrmKanban view are also relevant
to the ForecastKanban view.
As for the forecast kanban cards, when recurring revenues are activated,
they show "regular" recurring revenues instead of "prorated" recurring
revenues. Expected revenues are prorated. This is misleading for users.
The goal is to show prorated recurring revenues instead of just
recurring revenues.
Task-2994146
Task-3006404
closesodoo/odoo#102037
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
miad-odoo