The goal of the module was to communicate with livechat operators on our
production server, except the feature is disabled on our prod and we don't plan
to reactivate it any time soon.
closesodoo/odoo#52691
Related: odoo/upgrade#1313
Signed-off-by: Christophe Simonis <chs@odoo.com>
This is normally not supposed to happen to have a payment method without a receivable account set,
as this is a required field. However, it happens the receivable account cannot be found during upgrades
and this is a bommer to block the upgrade for that point, given the user can correct this by himself,
without requiring a manual intervention from our upgrade support.
However, this must be ensured this receivable is well set before opening a POS session.
closesodoo/odoo#52862
X-original-commit: 88cad346445f21d1513c066e965fc7df59582a56
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit, published column was not shown as option and user not able
to multi edit at a time in list
In this commit, we ease the purpose of multi edit at a time and keep a column
in option so user can keep hide it when not needed and can show as well.
task-2153812
Closes#43029
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, the left panel input widgets were considering the
values between 0 and 1 as 'inactive' and thus were forcing their
default value if the user entered those. As the default is most of the
time 0, entering 0.9 gave a 0 result for no apparent reason.
Part of https://github.com/odoo/odoo/pull/52821closesodoo/odoo#52841
X-original-commit: ee08dbb27afe165035ee683884737d4867034913
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When 'data-apply-to' was introduced to be able to target different
elements for snippet option methods, we kept triggering the
'content_changed' event on the main option element. This can be a
problem if the main option element is not in an editable element and the
elements targeted by apply-to are, as that editable element would not
be marked as dirty.
Note: the bug could actually still be produced, even in Odoo <= 13.0
where the apply-to param does not exist, by using a option method
which searches by itself for an inner element in an inside editable
element. This is considered as a limitation for the time being.
Part of https://github.com/odoo/odoo/pull/52821
X-original-commit: 906b2d9d4679c03365f949633e3c90319724deb8
Issue
- Runbot (or install every modules needed)
- Sales > Any order (or create a new one)
- Enable all columns
- Remove all lines then add a line
- Select any product
The "i" icon container is not large enough
so it's partially hidden but if you resize
the window, it will be corrected.
Cause
Since there is no icon (display none) before
selecting the product, the _freezeColumnWidths
method computes the width without the icon
When selecting the product, the icon is added
but the width is not adjusted.
Solution
Change d-none to invisible so that, the icon
is there but not visible and the width
computation will be correct
OPW-2269665
closesodoo/odoo#52840
X-original-commit: 0058ba467e7cf2f1bb0b8f606c7d4559897a31c4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Issue
- Install "Fleet" app and open it
- Add new car with user X as driver and set state as "Registered".
- Add new car with user X as future driver and set state as
'Waiting list'
The user is set as "Plan To Change Car".
Cause
When a user is set to a new car as a future driver,
the user will automaticly be set as "Plan To Change Car".
Solution
Add condition to set as "Plan To Change Car" only if the user
new car state is not "Waiting List".
opw-2259606
closesodoo/odoo#52836
X-original-commit: 6d35733e61b1d8b18acc3510046423aec7fe1c85
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Issue
- Install Contacts
- In systray, open #general
- Mention anyone (except your user)
- Send
- Click on the mention
It does nothing
Cause
In thread_window _onRedirect, we pass
the _open method bounded to this.
But this = the #general thread window
so it will open the general thread again.
As it is already open, it does nothing
Solution
Modify the open method in order to
receive the returned channelID and
pass it to the call
OPW-2265580
closesodoo/odoo#52834
X-original-commit: 5957aa317e8bb5b0041a1b5d8256cb3ff7d9fe42
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
The abilty to use a custom control panel for an action
seems to have been lost with 18e5416.
With this commit the action config can specify a custom
component to use as control panel.
Usefull for o-spreadsheet integration.
Task 2238915
closesodoo/odoo#52807
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
The point of sale user interface has been adapted to work on mobile
devices.
We modified the design of payment lines to look like payment methods and
stack them together in the mobile view.
When you had a cash method, the amount was not preffilled during
payment, now we always prefill the amount to keep it more simple.
closesodoo/odoo#51891
Task-id: 1887609
Related: odoo/upgrade#1334
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The domain field on a website is used:
1) to get the right website in case of multi-website
2) to compute base URL of canonical URL
For the 2nd usage, a scheme can be set (eg. https://hello.world) that
will be used instead of default http://
opw-2266224
closes#52784closesodoo/odoo#52796
X-original-commit: bc2899ba0905fe14a481d922a8fc57decf069692
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
We already have BDO tag as allowed tag in sanitized HTML that is
similar to BDI tag, so this commit also adds BDI in allowed tags.
BDI* tags make sense in email since email client can have different
orientation than Odoo (alternative is to use `<div dir="auto"></div>`).
*: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/bdi
opw-2256982
closes#52787closesodoo/odoo#52801
X-original-commit: 68edebb0d862acb3dc14f839aaef744306c5e269
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Translate the repair fees description in the language of the partner, as
done for repair lines.
opw-2274120
closesodoo/odoo#52760
X-original-commit: 0bc7ac2a9d60534f0e7bec120ad716bbb7d13155
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Generally, Users are not necessarily aware that they can quick create a most
records by simply typing in their name+enter in the many2xxx field input.
The exact purpose of this commit is to make sure the user discovers the quick
create feature of our many2xxx fields.
For that, when the input is empty, display 'Start typing to create a record...'
at the bottom of the dropdown when can_create is set and no_create_edit option
not set. So the user can easily understand that by typing and pressing enter
will create the new record.
Also "Search and Create" options in the dropdown only been shown to the user
when it type anything in the input box as the same case in the "Create" option.
Task : 2266557
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Accessing the "Create and edit" option can be bothersome when testing:
- you must click on the m2o dropdown to open it
- input a value
- click on the "Create and edit" m2o item
Now, a helper exists to compile all these tasks into a single helper:
the many2one 'createAndEdit' function.
Usage:
`await testUtils.fields.many2one.createAndEdit('m2o_field', "ABC");`
Before this commit, the mock server "_mockDefaultGet" method was a bit
naive:
- it accepted any 'default_' field coming from the 'kwargs.context'
regardless of the existence of the field
- it accepted any value for these fields
Now the method is looks a bit more like its original server-side
counterpart:
- the context keys are added if they correspond to actual fields
- a pseudo validation removes many2one fields values not corresponding
to any record
Change event onboarding rainbow message to something more relevant. Default
message is considered as less user friendly than the new one.
Before this commit the category_id for a tag had no label displayed. We choose
to wrap the category_id field inside a group so that field labels shows up.
In settings, wrap the tag_ids inside a div.o_setting_right_pane so we can have
the left border displayed correctly, like most fields in settings.
Finally remove "Online" template from the event_data since it acts like a
dummy type without pre-defined data.
Task 2257884
closesodoo/odoo#52472
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Introduce an automated tool to create leads from event registrations. Events
are a powerful source of leads as they attract attention. This leads to leads
with good quality as they mark interest while gathering contact information
which allows to follow-up.
This merge aims at automating this process by automatically creating leads
based on user-defined rules.
SPECIFICATIONS
Add a new module event_crm. It allows to create leads automatically based on
event registrations. This is done based on rules defined in a new model
event_lead_rule.
Add a new menu "Lead Generation" in the configuration tab of an event. It
allows to create generation rules. Those are a set of conditions to generate
a lead with some pre-filled values as the type of lead, tags or salesperson.
SPECIFICATIONS: CREATION TYPE
There are two types of lead creation:
* per attendee: create a lead for each registration;
* per order: create a lead for a group of registrations;
The last one is only available through interface if it is possible to register
a group of attendees in one action (when event_sale or website_event are
installed). Behavior itself is implemented directly in event_crm.
Basically a group is either a list of registrations belonging to the same
event and created in batch (website_event flow). With event_sale this
definition will be improved to be based on sale_order.
SPECIFICATIONS: CREATION TRIGGERS
There are three options to trigger lead creation. We consider basically that
lead quality increases if attendees confirmed or went to the event. Triggers
allow therefore to run rules:
* at attendee creation;
* at attendee confirmation;
* at attendee venue;
This trigger defines when the rule will run.
SPECIFICATIONS: FILTERING REGISTRATIONS
When a batch of registrations matches the rule trigger we filter them based
on conditions and rules defines on event_lead_rule model. Heuristic is the
following:
* the rule is active;
* if a filter is set: filter registrations based on this filter. This is
done like a search, and filter is a domain;
* if a company is set on the rule, it must match event's company. Note
that multi-company rules apply on event_lead_rule;
* if an event category is set, it must match;
* if an event is set, it must match;
* if both event and category are set, one of them must match (OR). If none
of those are set, it is considered as passing;
If conditions are met, leads are created with pre-filled informations defined
on the rule (type, user_id, team_id). Contact information coming from the
registrations are computed (customer, name, email, phone, mobile, contact_name).
SPECIFICATIONS: OTHER POINTS
Note that all rules matching their conditions are applied. This means more
than one lead can be created depending on the configuration. This is
intended in order to give more freedom to the user using the automatic
lead generation.
Once a lead is created for an event registration, a stat button on the event
is available to show the number of leads generated for this event and to
be able to find them in one click.
Additionally on the lead form, a stat button will be display to show the
registrations linked to this lead. On registrations a stat button is also
displayed to find the leads created from it or from its group.
Most of code has been written to run in batch, in case multiples rules have
to run on a set of new registrations. Tests are added to ensure behavior.
See sub commit for more detail.
LINKS
Task ID 2166679
PR odoo/odoo#52334
Upgrade PR odoo/upgrade#1292
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to avoid running lead creation rules when importing
registration data. Indeed import is used to bootstrap databases and/or to
update records in batch. As those are not necessarily "new" customer
information creating leads on this information adds more noise than real
utility. Moreover import can run on huge batch of records and lead creation
imply some computation that would slowdown import process.
LINKS
Task ID 2166679
PR #52334
Upgrade PR odoo/upgrade#1292
PURPOSE
Introduce an automated tool to create leads from event registrations. Events
are a powerful source of leads as they attract attention. This leads to leads
with good quality as they mark interest while gathering contact information
which allows to follow-up.
This merge aims at automating this process by automatically creating leads
based on user-defined rules.
SPECIFICATIONS
Add a module allowing to test a complete event install: add all event
dependencies. Currently only crm rules are tested as part of the lead
generation tasks. Future commits will add notably tours using all features
of event.
LINKS
Task ID 2166679
PR #52334
Upgrade PR odoo/upgrade#1292
PURPOSE
Introduce an automated tool to create leads from event registrations. Events
are a powerful source of leads as they attract attention. This leads to leads
with good quality as they mark interest while gathering contact information
which allows to follow-up.
This merge aims at automating this process by automatically creating leads
based on user-defined rules.
SPECIFICATIONS
Include in generated lead description answers from attendees to questions
defined using the website_event_questions module.
LINKS
Task ID 2166679
PR #52334
Upgrade PR odoo/upgrade#1292
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
Introduce an automated tool to create leads from event registrations. Events
are a powerful source of leads as they attract attention. This leads to leads
with good quality as they mark interest while gathering contact information
which allows to follow-up.
This merge aims at automating this process by automatically creating leads
based on user-defined rules.
SPECIFICATIONS
Display group-based option for rules as registrations can now be created by
group.
LINKS
Task ID 2166679
PR #52334
Upgrade PR odoo/upgrade#1292
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
Introduce an automated tool to create leads from event registrations. Events
are a powerful source of leads as they attract attention. This leads to leads
with good quality as they mark interest while gathering contact information
which allows to follow-up.
This merge aims at automating this process by automatically creating leads
based on user-defined rules.
SPECIFICATIONS
Ensure information updated on sale order also updates lead information.
Also display group-based option for rules as registrations can now be
grouped by sale order.
LINKS
Task ID 2166679
PR #52334
Upgrade PR odoo/upgrade#1292
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
Introduce an automated tool to create leads from event registrations. Events
are a powerful source of leads as they attract attention. This leads to leads
with good quality as they mark interest while gathering contact information
which allows to follow-up.
This merge aims at automating this process by automatically creating leads
based on user-defined rules.
SPECIFICATIONS
Add a new module event_crm. It allows to create leads automatically based on
event registrations. This is done based on rules defined in a new model
event_lead_rule.
Add a new menu "Lead Generation" in the configuration tab of an event. It
allows to create generation rules. Those are a set of conditions to generate
a lead with some pre-filled values as the type of lead, tags or salesperson.
SPECIFICATIONS: CREATION TYPE
There are two types of lead creation:
* per attendee: create a lead for each registration;
* per order: create a lead for a group of registrations;
The last one is only available through interface if it is possible to register
a group of attendees in one action (when event_sale or website_event are
installed). Behavior itself is implemented directly in event_crm.
Basically a group is either a list of registrations belonging to the same
event and created in batch (website_event flow). With event_sale this
definition will be improved to be based on sale_order.
SPECIFICATIONS: CREATION TRIGGERS
There are three options to trigger lead creation. We consider basically that
lead quality increases if attendees confirmed or went to the event. Triggers
allow therefore to run rules:
* at attendee creation;
* at attendee confirmation;
* at attendee venue;
This trigger defines when the rule will run.
SPECIFICATIONS: FILTERING REGISTRATIONS
When a batch of registrations matches the rule trigger we filter them based
on conditions and rules defines on event_lead_rule model. Heuristic is the
following:
* the rule is active;
* if a filter is set: filter registrations based on this filter. This is
done like a search, and filter is a domain;
* if a company is set on the rule, it must match event's company. Note
that multi-company rules apply on event_lead_rule;
* if an event category is set, it must match;
* if an event is set, it must match;
* if both event and category are set, one of them must match (OR). If none
of those are set, it is considered as passing;
If conditions are met, leads are created with pre-filled informations defined
on the rule (type, user_id, team_id). Contact information coming from the
registrations are computed (customer, name, email, phone, mobile, contact_name).
SPECIFICATIONS: OTHER POINTS
Note that all rules matching their conditions are applied. This means more
than one lead can be created depending on the configuration. This is
intended in order to give more freedom to the user using the automatic
lead generation.
Once a lead is created for an event registration, a stat button on the event
is available to show the number of leads generated for this event and to
be able to find them in one click.
Additionally on the lead form, a stat button will be display to show the
registrations linked to this lead. On registrations a stat button is also
displayed to find the leads created from it or from its group.
Most of code has been written to run in batch, in case multiples rules have
to run on a set of new registrations. Tests are added to ensure behavior.
LINKS
Task ID 2166679
PR #52334
Upgrade PR odoo/upgrade#1292
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
When duplicating a registration its SO and SO line should not be copied as
it may impact a done or ongoing SO with payments already done.
LINKS
Task ID 2166679
PR #52334
Prepare event_crm link module addition by cleaning some views. Notably buttons
box has to be added directly in event and not in event_sale anymore. It allows
to add content in it independently from event_sale presence.
LINKS
Task ID 2166679
PR #52334
PURPOSE
Introduce a clearer way of handling registrations for single / multiple events
occurring at the same time and place by
* improve attendees kanban view, notably by better supporting mono and multi
event (hide unnecessary information);
* introducing a Registration Desk menu item to manage multi-event mode;
SPECIFICATIONS
Improve attendees kanban view, notably due to the following issues
* event_ticket_id as char field is hard to recognize. Notably with attendees
with same ticket directly in the kanban view;
* missing explicit icon/button of the event registration state;
Handle mono-event (coming from an event) / multi-event (global attendees
view) modes.
Replace "event_ticket_id" text by colored badge (random color on each
"event.event_ticket_id.id"). Move this field directly into event as now
tickets are supported in event, not only with event_sale.
Add button or text linked to the registration state on top-right of card.
Introduce a computed "payment_status" selection field, allowing to display
status of a registration, based on its SO and ``is_paid```field. It is better
fro UX and display. It is not stored as currently stored fields are sufficient
for current requirement. Add it to the kanban view.
Prepare barcode improvements by improving _get_registration_summary returned
data dict, adding some information to display in event_barcode.
Mobile specific: put button as big buttons on the right of the card, ensure
all cards are displayed using same height and display correct.
LINKS
Task ID #2214290
Community PR #47511
Enterprise PR odoo/enterprise#9190
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Introduce a clearer way of handling registrations for multiple events occurring
at the same time and place by
* improve attendess kanban view;
* introducing a Registration Desk menu item;
SPECIFICATIONS
Introduce a computed "payment_status" selection field, allowing to display
status of a registration, based on its SO and ``is_paid```field. It is better
fro UX and display. It is not stored as currently stored fields are sufficient
for current requirement.
Add it to the kanban view.
Prepare barcode improvements by improving _get_registration_summary returned
data dict, adding some information to display in event_barcode. Reorganize
registrations actions, and prepare a generic one leading to attendees kanban
view for registration desk.
LINKS
Task ID #2214290
Community PR odoo/odoo#47511
Enterprise PR odoo/enterprise#9190
PURPOSE
Introduce a clearer way of handling registrations for single / multiple events
occurring at the same time and place by
* improve attendees kanban view, notably by better supporting mono and multi
event (hide unnecessary information);
* introducing a Registration Desk menu item to manage multi-event mode;
SPECIFICATIONS
Improve attendees kanban view, notably due to the following issues
* event_ticket_id as char field is hard to recognize. Notably with attendees
with same ticket directly in the kanban view;
* missing explicit icon/button of the event registration state;
Handle mono-event (coming from an event) / multi-event (global attendees
view) modes.
Replace "event_ticket_id" text by colored badge (random color on each
"event.event_ticket_id.id"). Move this field directly into event as now
tickets are supported in event, not only with event_sale.
Add button or text linked to the registration state.
Kanban card structure is therefore
-----------------------
Attendee Name
Event Name (if in multi mode)
Booked by partner_id.display_name ICON/BUTTON
Ticket in a tag format
-----------------------
Buttons and icons, if registrations is
* canceled (nothing to do in Kanban, open the form view) => Canceled text
* unconfirmed and is awaiting confirmation => Attended text
* confirmed and is awaiting attendance confirmation => Button
* done, end of the flow => Icon
Mobile specific: put button as big buttons on the right of the card, ensure
all cards are displayed using same height and display correct.
LINKS
Task ID #2214290
PR #47511
PURPOSE
The purpose of this task is to improve the interface by removing the
fa-building icon which is automatically appended by the property field
(i.e. company-dependent) and, instead, indicates that a field has
company-specific values in the tooltip of the field.
closesodoo/odoo#52313
Taskid: 2266519
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
A method was written to copy translations from the template objects
(chart template) to the instantiated chart of accounts when installing
a multilang coa. (e.g. to have the translations on the accounts, taxes, ...)
The problem was that to call this functionality, this module inherited
a method, that was renamed in the meantime. The consequence being that
this method was never called.
We renamed the method correctly here.
closesodoo/odoo#52769
X-original-commit: bb31ce3bc6c0c7e1e101d93924eccea995206733
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
The entries comming from the optional parameter 'mapping' passed at the
instantiation of a registry were never considered when returning the
registry keys or entries. This is no longer the case.
closesodoo/odoo#52768
X-original-commit: e094ddd0ffaf3357e64ca5941ffc2e0454c24ab7
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Some companies have their office in a country, and sell and pay taxes in another one. Before this commit, they couldn't use Odoo's tax report, as the country set on the res.company than the one to be used with their taxes. It is now possible to do that, using a config parameter.
closesodoo/odoo#52734
X-original-commit: 1728dfadeac252f5cd26d7770d044ae5f06a3352
Related: odoo/enterprise#11039
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Previously, there was only one static "Sale" ribbon. Users might want to
have many types of ribbons, for different levels of sales, or to
indicate that a product is sold out. This commit lets the user create
custom ribbons and use them on prodcuts on the shop page. Additionally,
setting a ribbon on a product used to require a reload, this is no
longer the case. All ribbon modifications are stored in a cache and the
RPCs to put them into effect are only done on save.
task-1981170
Part of odoo/odoo#47574
Related: odoo/upgrade#1079
Related: odoo/design-themes#219
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Previously, the "Image full" option was on a per product basis. This is
very strange, because in most cases you either want all of your product
images to take up the entire card space, or none of them. This commit
makes the option into a global option for the shop page, so it can be
toggled for all products at once.
task-1981170
Part of odoo/odoo#47574
Before, only when you had installed the Belgian
structured communication module, when you sent an
invoice by mail then only the structured communication
would be added in the mail.
But it should be visible all the time when
you have a payment reference.
closesodoo/odoo#52618
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
When set scheduled date on PO line, set it to be the last minute of
that day to correctly decide the late of the receipt.
Task 2265912
PR #52693
Related: odoo/enterprise#11034
Related: odoo/upgrade#1323
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Some change to imporve reminder mail usability:
1. Scheduled date on POL of the PO form now is always editable.
2. Improve tooltip for the reminder email
3. don't show number of days when reminder email not checked on
both PO and partner form.
4. only show "confirm receipt date" button in debug model
5. In the mail, format date by partner.lang
6. Add button to send preview reminder mail
7. On default, receipt_reminder_email on res.partner is False
8. merge expected_date with date_planned (done by FP)
Task 2265912
PR #52693
Sébastien Theys